Как сделать дизайнеров счастливыми бесплатное чтение

Эта книга – о том, как выстроить процессы в дизайн-команде, чтобы ее участники были счастливы на работе. Такая формулировка может показаться непривычной, ведь обычно качество процессов оценивают с точки зрения их пользы для организации, а не для сотрудников. Но я убежден: удовлетворенность сотрудников – не менее важный фактор, чем процветание компании, а зачастую и необходимое условие этого процветания.

«Как сделать дизайнеров счастливыми» – книга, которую я писал в первую очередь для лидеров дизайн-команд в IT-индустрии, но уверен, что она будет полезна не только им. Многие описанные алгоритмы подходят для управления продуктовыми командами разработки, центрами профессиональных компетенций или креативными отделами.

А еще почитать книгу стоит самим дизайнерам и вообще всем, кто работает в команде. Это поможет им критически смотреть на процессы, происходящие у них на работе, и способствовать внедрению изменений, которые улучшают жизнь коллегам. А в перспективе – самим стать лидерами.

Об авторе и теме

Меня зовут Андрей Богданов, и я дизайн-менеджер.

Сейчас я дизайн-лидер нескольких направлений в МТС Финтех и со своими командами успел поработать над продуктами МТС Деньги, МТС Рау, МТС Флекс, накоплениями и инвестициями, а также финтех-сервисами для абонентов МТС. До этого я был лидом в ВТБ, дизайнил в Сбере, Локо-Банке и немного на фрилансе. А еще участвовал в стартапе Maniki как соучредитель и дизайнер.

В ВТБ я стоял у истоков стрима «Состоятельные клиенты», который со временем разросся до одного из самых крупных розничных стримов в банке. Там я собрал дизайн-команду с нуля и выстроил все процессы, связанные с ее работой.

А в МТС подхватил две дизайн-команды в не самый простой для них период, связанный с уходом прежних лидеров, и сформировал одну новую в рамках реорганизации структуры компании. Здесь я переосмыслил существующие процессы и церемонии, а также внедрил новые, стараясь делать это максимально безболезненно для дизайнеров, но в то же время эффективно.

Если говорить о продукте, у меня были и успехи, и неудачи. Некоторые запущенные сервисы показали отличные метрики, другие не оправдали надежд. Конечно, и то и другое не было результатом исключительно дизайнерских решений. Продуктовый дизайн неотделим от бизнеса, которому должен приносить пользу, и разделяет с ним все радостные и печальные моменты.

Поэтому я всегда мыслил дизайн-команду как, с одной стороны, обособленный коллектив специалистов, а с другой – как часть глобальной команды, в которой бизнес, IT и дизайн вместе идут к общим целям.

Но есть направление, где я считаю успешным лично себя без всяких оговорок, – это построение дизайн-команд и процессов, по которым эти команды работают сами и взаимодействуют с окружающим миром.

На старте лидовской карьеры я совершал много ошибок: отпускал контроль, не пресекал конфликты, смотрел на возникающие проблемы слишком узко. И вообще, скажу честно, не уделял своей команде должного внимания. Правда, у меня было одно извиняющее обстоятельство: в то время я сам много работал руками. Что, как я понимаю сейчас, практически несовместимо с эффективным управлением командой.

Набравшись опыта, я осознал: команда – это фундамент, без которого невозможно построить что-то по-настоящему прочное.

Такая «командоцентричность» помогла мне достичь определенных успехов, и самый главный из них – удовлетворенность дизайнеров. Это показатель, трудноизмеримый формальными средствами, но очевидный при общении с членами команды: стоит лишь поговорить с дизайнерами по душам и понаблюдать за их поведением, чтобы понять, что они чувствуют. Я разговаривал, наблюдал и пришел к выводу, что дизайнерам у меня хорошо.

А еще я горжусь показателем оттока сотрудников, который у меня традиционно ниже, чем в среднем по компании. Даже в самые турбулентные времена, когда редкая неделя проходила без новости об увольнении кого-то из коллег-недизайнеров, моя команда обходилась без кадровых потерь.

В свободное от работы время я веду блог @na_produkte в «Телеграме» и других соцсетях, где пишу короткие статьи о дизайне, продукте и, конечно, работе в команде. Рефлексируя по поводу профессии, в том числе и в своем блоге, я накопил много идей, которыми хочется поделиться с читателями.

Я убежден в том, что работа должна приносить удовольствие. Отчасти это вопрос личных установок и хитросплетений судьбы: не всем удается найти профессию по душе и сформировать правильное отношение к работе. Но часто удовольствие от работы зависит не от самого сотрудника, а от того, что его окружает.

Причем дело не в людях, которые вокруг: коллеги могут быть замечательными, а радости от работы все равно не будет. Причина дискомфорта зачастую кроется в процессах и традициях. Если процессы выстроены плохо, даже самые замечательные люди будут конфликтовать и портить друг другу нервы. А если «традиционные ценности» команды порочны, они будут отравлять жизнь всем ее участникам.

В этой книге я расскажу о практиках, которые помогают построить здоровую атмосферу в команде. Эти практики проверены мной на собственном опыте, и они реально работают в моих командах.

А еще я внимательно смотрел по сторонам и наблюдал за другими командами, ведь личный опыт в лучшем случае сомнительное доказательство, а в худшем – источник вредных заблуждений. Я убедился: выявленные мной паттерны работают и у других.

При этом, конечно, моя книга не претендует на статус сколько-нибудь серьезного исследования. «Как сделать дизайнеров счастливыми» – это в первую очередь отражение моих личных взглядов на дизайн-лидерство. И, безусловно, повод к дискуссии: мне крайне интересно обсудить идеи из книги с коллегами по цеху и узнать, насколько они им откликаются.

На этом можно было бы перейти к рассказу о полезных для команды практиках. Но, прежде чем приступить к их описанию, давайте немного поразмышляем о счастье.

Дизайн, который дарит счастье

Все началось с поста «Дизайн, который дарит счастье». В нем я рассматривал дизайн как явление, призванное приносить всем радость, и высказал довольно простую мысль:

Хороший дизайн должен делать счастливыми три категории людей: клиентов, заказчиков и разработчиков продукта.

Несмотря на всю, казалось бы, очевидность этого утверждения, подход к дизайну как источнику позитивных эмоций показался мне довольно свежим и оптимистичным. Более того, взгляд на работу через оптику счастья дал мне импульс трудиться с вдохновением, гнать прочь мысли о тщетности бытия и избегать проблем с мотивацией. Одно дело, когда ты делаешь что-то ради денег, другое – ради высокой цели. А какая цель может быть выше, чем улучшение жизни людей?

Ниже я перескажу содержание своего поста и объясню, как он привел меня к идее написать эту книгу.

Итак, дизайн воздействует на три группы людей: клиентов, заказчиков и разработчиков. Несмотря на то что эти группы не равновеликие и могут пересекаться между собой (например, ничто не мешает разработчику самому пользоваться продуктом), такое разделение кажется мне оптимальным для правильной расстановки акцентов.

Начнем с клиентов.

Важность проектирования качественного пользовательского опыта очевидна. Пользователи, получающие позитивный опыт взаимодействия с продуктом, будут использовать его активнее и с большим удовольствием.

Но я намеренно использую понятие «клиент», а не «пользователь», ведь клиентский опыт шире опыта использования цифрового продукта. Продукт должен быть не просто хорош сам по себе, но и органично встраиваться в общий С JM (Customer Journey Мар, «карту путешествия» клиента). Каким бы удобным ни был заказ готовой еды через приложение, все впечатление напрочь испортит доставщик, прибывший на пару часов позже обещанного. О том, как подружить онлайн с офлайном, должны думать все разработчики продукта.

Кардинально изменить жизнь клиента способны далеко не все продукты, но мы по крайней мере можем сделать клиента счастливым в той части его жизни, до которой дотягиваемся доступными нам средствами. Просто вспомните, когда вы в последний раз ходили в банк оплачивать счета за коммунальные услуги? Делать это дистанционно куда приятнее, согласитесь.

А в отдельных случаях продукт может иметь буквально судьбоносное значение, если помогает клиенту решить проблемы со здоровьем или, скажем, приобрести недвижимость.

Теперь о заказчиках. Или, иначе говоря, о бизнесе.

Очень важно, как работает и как сделан продукт, но еще важнее, зачем он сделан. А сделан он почти всегда для решения задач бизнеса. Исключение составляют разве что некоммерческие проекты, но и в них заложены определенные планы и критерии успешности, которые можно с некоторой натяжкой назвать бизнесовыми.

Конечно, не во всем, что делает дизайнер, есть непосредственно коммерческая составляющая. Некоторые клиентские сценарии проектируются с целью повысить лояльность клиентов или их удовлетворенность. К тому же многие сервисы не зарабатывают деньги сами по себе, а используются для продвижения других. Но в итоге цель одна – зарабатывать деньги, и если самый обожаемый клиентами продукт не решает задачи бизнеса, проект придется свернуть или совершить пивот[1].

Задачи и приоритеты бизнеса могут быть разными в зависимости от стратегии, жизненного цикла компании и ситуации на рынке. Дизайнеру полезно разбираться в таких вещах – это делает его работу более осознанной. Здорово понимать также ключевые показатели эффективности разрабатываемых сценариев, а еще лучше активно участвовать в определении и анализе этих показателей.

Если продукт показывает цифры, приятные бизнесовому взгляду, заказчик счастлив. А дизайнер может гордиться тем, что помогает бизнесу двигаться вперед.

И, наконец, дизайн должен делать счастливыми самих разработчиков.

Под разработчиками я имел в виду команду, которая трудится над проектированием и реализацией клиентских сценариев. И в первую очередь, конечно, самих дизайнеров. Иногда (например, в небольших стартапах) команда разработки может совпадать с предыдущей группой, то есть быть заказчиками у самих себя.

Если клиентам и заказчикам приносит радость результат в виде готового продукта и его метрик, то в случае с дизайнерами важен и сам процесс работы. Он тоже может и должен доставлять удовольствие. Каким бы качественным ни был результат, если он достигается путем ежедневных страданий, переработок, скандалов и интриг, о счастье не может быть и речи.

О клиентском опыте и бизнес-ориентированности пишут много и подробно, а о дизайнерском счастье – почти ничего. Все ограничивается психологическими (а чаще псевдопсихологическими) статьями о мотивации, выгорании и синдроме самозванца, да и те никак не затрагивают специфику нашей профессии.

Такие мысли посещали меня после написания поста «Дизайн, который дарит счастье», а желание раскрыть тему дизайнерского счастья шире не давало мне покоя. Я подумал, что эта тема могла бы заинтересовать дизайн-менеджеров, то есть тех, кто обладает достаточными полномочиями для улучшения жизни дизайнеров. А еще точнее – лидов дизайн-команд, поскольку они постоянно контактируют с дизайнерами и знают все их боли.

Я решил сделать лекцию о практиках «привнесения счастья» в дизайн-команду и выступить с ней на какой-нибудь конференции, но формат лекции оказался слишком узок. Материала накопилось такое количество, что после его упаковки в рамки сорокаминутного выступления повествование получилось скомканным и сложным для восприятия.

Если не лекция, то пусть будет книга, решил я.

И вот эта книга перед вами.

Зачем нам счастливые дизайнеры

Рассуждая о счастье дизайнеров, я подразумеваю, что это непременное условие здорового рабочего процесса. Но так ли это на самом деле? Возможно, эмоциональное состояние сотрудников никак не влияет на достижение целей компании? Может, наоборот, лучше не давать команде спуску – пусть работают в поте лица и страдают на благо работодателя?

У меня есть три железных аргумента против такого бесчеловечного подхода (плюс еще один, бонусный).

Аргумент 1

Счастливые дизайнеры работают продуктивно.

В прекрасном расположении духа дизайнер пребывает, если он, помимо всего прочего, эмоционально вовлечен в рабочий процесс и разделяет ценности команды, в которой работает. В такой ситуации он неизбежно будет проектировать более качественные решения, чем тот, кто пришел просто просиживать рабочее место.

Одно дело – пытаться соответствовать формальным критериям качества, необходимым для получения оклада, совсем другое – по-настоящему «гореть» своим делом. Формальный подход ведет к формальным решениям, а творческий и вдохновенный – к решениям прорывным или, как минимум, сделанным на самом высоком уровне качества, доступном дизайнеру.

Это и есть настоящая продуктивность – стабильно выдавать отличный результат, а вовсе не способность ставить рекорды по отработанным часам. Можно хоть ночевать в офисе – без должного настроя толку от этого не будет.

Аргумент 2

Счастливые дизайнеры реже увольняются.

На тех проектах, где эмоциональное состояние сотрудников оставляет желать лучшего, всегда страшная текучка кадров. Иногда руководители с этим смиряются и даже относятся к высокому оттоку как к плановой величине. На самом деле, конечно, постоянный уход сотрудников – не норма, а огромная нагрузка на компанию. Это и удар по продуктивности, и рост затрат на наем, и урон репутации.

Когда от работы нет никакого удовольствия, удержать на ней человека могут два фактора: высокая зарплата или собственная низкая квалификация.

Если бюджет проекта велик, руководители иногда пытаются залить недовольство подчиненных денежными потоками, но работает такой подход плохо: «переоцененные» кадры начинают лениться и только имитируют активную деятельность. А по-настоящему классных специалистов сложно удержать одними лишь деньгами: они смотрят в будущее и хотят развиваться, а не просто хватаются за сиюминутную выгоду.

Вот и получается, что лучшие люди уходят, а остаются либо слабые, либо не амбициозные.

Аргумент 3

Счастливые дизайнеры прокачивают бренд компании и своего лидера.

Многие компании активно вкладываются в развитие своего HR-бренда: организуют тематические мероприятия, наращивают присутствие в соцсетях и СМИ, создают различные медиаповоды и вообще работают с рынком потенциальных кандидатов, как могут. Но не последнюю роль в формировании сильного HR-бренда играют и отзывы сотрудников, которые работают или работали в компании.

Все мы знаем, что относительно многих крупных компаний есть стереотипы в дизайнерском сообществе: куда-то дизайнеры мечтают устроиться, а куда-то их не загонишь ни за какие деньги. И эти стереотипы во многом формируются благодаря тому, что говорят о компании их сотрудники, нынешние или бывшие.

То же касается и репутации отдельно взятых руководителей, в том числе дизайн-менеджеров. Конечно, я не рискну утверждать, что личный бренд отдельно взятого дизайн-лидера, у которого в подчинении шесть человек, может быть предметом активных обсуждений во всем русскоязычном дизайн-комьюнити. Но в рамках своей компании лид вполне может обрести славу, дурную или хорошую.

Я говорю об этом с полной уверенностью, потому что ко мне в команду не раз просились те дизайнеры, у которых был запрос на внутреннюю ротацию, то есть желание перейти в другую команду, не покидая компанию. Часто такие дизайнеры выбирали именно меня, потому что знали: в моей команде к дизайнерам относятся по-человечески.

Аргумент 4 (бонусный)

Это были соображения циничные или, выражаясь мягче, рациональные. Но хочется сказать и об идеологической стороне вопроса. Я уверен, что любой руководитель, будь то начальник бригады, дизайн-лид или глава транснациональной корпорации, не должен забыть о гуманистической стороне своей деятельности.

Люди проводят на работе большую часть активной жизни, и мы – менеджеры – обязаны сделать все, чтобы им там было хорошо.

К сожалению, некоторые руководители со мной не согласны и предпочитают, чтобы их сотрудники пребывали в постоянном страхе и стрессе. Иногда такая мобилизация с помощью кнута действительно дает плоды, но только в очень короткой перспективе. А дальше начинается имитация работы: все сидят в офисе до ночи, но при этом не делают ничего полезного для компании. Это неудивительно, ведь основная задача на проекте – угодить шефу, а не сделать что-то полезное.

К счастью, менеджеров-любителей ручного управления становится меньше, и мы движемся в сторону разумных человечных процессов, или «практик регулярного менеджмента» в терминологии Павла Безручко, автора одноименной книги[2]. Я, кстати, рекомендую прочитать ее всем управленцам. В ней дана хорошая база по менеджменту без привязки к отраслевой специфике.

И последнее. Я убежден, что человечество движется по пути гуманизации и снижения насилия. Этот процесс сопровождается страшными откатами назад, как показывает последнее время, но он необратим. Давайте не противиться неизбежному, а способствовать наступлению прекрасного будущего, в котором люди живут и работают с удовольствием.

Потребности и алгоритмы их закрытия

Итак, настало время перейти к основной теме. Как же нам сделать дизайнеров счастливыми?

Анализируя свой и чужой опыт, я пришел к выводу, что для этого нужно закрыть три базовые потребности дизайнеров:

1) потребность в комфорте;

2) потребность испытывать интерес к работе;

3) потребность развиваться и ощущать прогресс.

Назовем их для краткости «комфорт», «интерес» и «прогресс».

Комфорт заключается в отсутствии чрезмерного стресса. Это, пожалуй, самая базовая потребность любого сотрудника: испытывать ощущение безопасности на работе, а не идти туда каждый день как на казнь.

Если окончание выходных сопровождается тревожным предчувствием, а по вечерам хочется лечь спать позже, чтобы оттянуть наступление рабочего дня, потребность в комфорте на работе явно не закрыта.

Интерес связан с эмоциональной вовлеченностью в рабочий процесс.

Бывает, что работа в целом комфортная и не вызывает отторжения, но воспринимается исключительно как рутина, необходимая для зарабатывания денег. Для любого квалифицированного специалиста такая ситуация ненормальна и грозит выгоранием. Чтобы избежать этого, руководителю нужно прилагать усилия к закрытию соответствующей потребности.

Прогресс – это движение вперед за счет прокачки профессиональных компетенций и улучшения позиции на рынке труда.

Может показаться, что потребность в прогрессе есть только у самых целеустремленных дизайнеров. Но это не так: развиваться и расти хотят все. Я расскажу об этом подробнее в той части книги, которая посвящена этой потребности.

Все три потребности существуют постоянно, но дают о себе знать на разных этапах отношений дизайнера и компании.

Если предположить, что интерес к вакансии есть у дизайнера изначально, то первой проявляет себя потребность в комфорте. Уже на этапах общения с HR-специалистом, интервью и тестового задания дизайнер понимает, комфортно ему в этих процессах или не очень.

Поэтому не стоит забывать о том, что наем – это двусторонний процесс, в котором не только работодатель выбирает сотрудника, но и наоборот. Постарайтесь, чтобы трудоустройство стало для дизайнера не тяжким квестом, а простой и понятной процедурой. Впрочем, как и онбординг – знакомство с командой, изучение процессов и погружение в задачи.

Второй обостряется потребность в интересе. На ранних стадиях вовлечения дизайнера в новый проект с интересом обычно полный порядок: дизайнеру все в новинку и ему не терпится во всем поскорее разобраться. Но по мере того, как дизайнер глубже погружается в продукт и конкретные задачи, эта потребность должна закрываться за счет эмоционального вовлечения в продукт, что случается далеко не всегда. Если любви с продуктом не случается, это может стать серьезной проблемой.

И, наконец, прогресс. О нем дизайнер начинает серьезно задумываться, когда закрыты предыдущие, базовые, потребности. Даже если работать комфортно и интересно, возникают вопросы «А что будет дальше?», «Развиваюсь я или стою на месте?», а вместе с ними и желание двигаться вперед.

Все три потребности – в комфорте, интересе и прогрессе – нужно закрывать. Чтобы это сделать, есть ряд управленческих практик, которые я назвал алгоритмами.

Для самых дотошных читателей оговорюсь: в строгом смысле слова, конечно, эти практики не являются алгоритмами, потому что не всегда предполагают четкой последовательности действий. Но «управленческие практики» звучат сухо и бюрократично, а прекрасное слово «паттерны» застолбил за собой Юрий Ветров[3]. Так что пусть будут алгоритмы.

Всего алгоритмов у меня получилось одиннадцать, по четыре на «комфорт» и «прогресс» и три для «интереса»:

Далее я подробно разберу эти алгоритмы, и каждому из них будет посвящена отдельная глава.

Не стоит, однако, ожидать пошаговой инструкции по их реализации. То, как «приземлить» эти алгоритмы на свою команду, вам придется решать самостоятельно. Все команды и проекты по-своему уникальны, и то, что может сработать для одних, совсем не подойдет другим. Поэтому я постараюсь избежать категоричности в своих рекомендациях и буду рассматривать только самые универсальные принципы применения алгоритмов.

Любая работа – это источник эмоционального напряжения, но степень этого напряжения может быть разной. Оно достигает максимума и превращается в настоящий стресс там, где много неопределенности. Когда сегодняшние задачи непонятны, завтрашние – неизвестны, а работа напоминает безумную игру без правил, ни о каком комфорте не может быть и речи.

Задача любого руководителя – рассеять неопределенность и снять психологическое давление со своей команды. Тогда сотрудники смогут «выдохнуть» и полностью сконцентрироваться на понятных и четких рабочих задачах.

Но заниматься рассеиванием нужно не в ручном режиме, рассматривая под микроскопом каждую отдельно взятую проблему, а с помощью внедрения универсальных правил и принципов. Искоренять причины проблем – более мудрое решение, чем бороться с последствиями и тушить пожары, вспыхивающие то тут, то там.

О тех алгоритмах, которые призваны сделать работу дизайнеров комфортной и подарить им ощущение безопасности, мы и поговорим в ближайших главах.

Фреймворк

Первый алгоритм закрытия потребности в комфорте я назвал «фреймворк». Возможно, вы слышали, что так разработчики в IT называют набор инструментов, ускоряющих разработку приложений. Framework переводится с английского как «структура», «каркас» и даже «система взглядов». Фреймворком в широком смысле можно назвать любой набор инструментов, позволяющий, с одной стороны, упростить какой-либо процесс, а с другой – четко обозначить его рамки и границы.

Фреймворк работы продуктовых дизайнеров должен включать в себя три составляющие:

1) правила работы с задачами;

2) понятное распределение компетенций;

3) церемонии.

Поговорим о каждой из них подробнее.

Правила работы с задачами

Создание любого продукта – это одновременно и непрерывный процесс, и череда маленьких шагов на пути к финальному результату.

Можно, конечно, попытаться сделать все с наскока: подготовить дизайн сразу всего приложения, потом полностью написать код, протестировать его и успешно осуществить релиз на пользователей. Но в реальной жизни такой подход не только утопичный, но еще и очень опасный.

Если не разделять процесс на отдельные задачи и не сверяться с коллегами по ходу их выполнения, есть стопроцентная вероятность наделать ошибок. Причем каждая из этих ошибок повлечет за собой новые и более серьезные. Проявится эффект снежного кома, разлепить который будет намного сложнее и дороже, чем вносить корректировки по ходу процесса.

Получается, что проработка отдельных частей проекта (для дизайнера – сценариев и экранов) в виде конкретных задач – это основа здорового процесса. И от того, как построена работа над задачами, зависит успех команды. А еще, что особенно важно в контексте этой книги, понятные правила работы над задачами формируют комфортную среду для дизайнеров.

В первую очередь нужно определить, как задачи поступают к дизайнеру. Если задачи сыплются как снег на голову, их объем всегда разный, а приоритеты не расставлены, это неэффективно для проекта и дискомфортно для исполнителя. Чтобы победить хаос, нужно продумать, согласовать со всеми участниками процесса и внедрить процедуру постановки задач.

Легкий фреймворк scrum, по которому работают (или стремятся работать) компании, где я получил основной опыт работы, предполагает, что работа команд разработки идет по спринтам. Спринты – это регулярные промежутки времени, в течение которых участники команды выполняют запланированные задачи. Спринт имеет фиксированную длину и обычно длится две недели, а задачи, которые будут выполняться в спринте, определяются на планировании спринта.

Я не буду рекламировать scrum: выбор фреймворка зависит от многих факторов, в том числе зрелости процессов в организации и стратегии продукта, и «серебряной пули» для всех не существует. Да и не хотелось бы заходить на территорию специалистов по скраму – это не моя профессиональная область.

Но сама идея, что задачи планируются в рамках отдельной церемонии и по определенным правилам, заслуживает того, чтобы получить распространение и за рамками скрама. Сам я, как вы догадываетесь, горячий сторонник планирования для дизайн-команд и работы по спринтам.

Качественное планирование снимает стресс и у дизайнеров, и у заказчиков. Первым оно позволяет спокойно работать, а вторым – получить гарантию результата в виде обязательств по выполнению задач.

Чтобы планирование было эффективным, недостаточно просто назначить время и место его проведения. Нужно, чтобы задачи, которые планируется взять в работу, были понятны исполнителю и оценены по времени.

Выяснять требования по задачам проще, когда внедрены чек-листы с обязательными атрибутами задачи. Например, это могут быть поля «цель», «влияние на метрики», «результаты исследований», «сроки» и т. д. Сконструировать универсальный шаблон задачи довольно сложно, и лучше продумать его для конкретной команды или организации, учитывая специфику внутренних процессов.

Но даже и без шаблона можно повысить прозрачность задач, если договориться с заказчиками о формате передачи требований. Это может быть, например, установочная встреча для обсуждения новой задачи или та же церемония планирования, если на ней проговариваются все нюансы задач.

Предположим, задача понятна. Теперь нужно оценить время, необходимое для ее выполнения. И с оценкой должен согласиться как сам исполнитель-дизайнер, так и заказчик. Такой подход сделает работу более комфортной, исключив внезапные дедлайны, и позволит избежать манипуляций как с одной, так и с другой стороны.

Когда оговоренную работу не получается сделать в срок, стоит открыто и честно обсудить причины. Если дело окажется в неадекватной оценке, это нужно будет учесть при оценке задач в дальнейшем.

Постановкой и оценкой задач дело не ограничивается. Нужно также продумать правила, по которым будут уточняться требования, передаваться обратная связь от заказчиков, происходить ревью подготовленных макетов и другие процессы. Цель – сделать так, чтобы жизненный цикл задачи проходил по понятным правилам. Правила могут быть не зафиксированы в официальной документации, но они должны приниматься и однозначно трактоваться всеми участниками процесса.

Понятное распределение компетенций

Правила работы с задачами немыслимы без определения лиц, принимающих решения, и их полномочий. Для дизайн-команд это особенно важно.

Иногда кажется, что все вокруг считают себя экспертами в дизайне и не скупятся на советы дизайнерам. Это происходит оттого, что дизайн имеет ярко выраженную визуальную составляющую. Давать советы разработчикам и аналитикам сложно: одни пишут какой-то непонятный код, вторые – сложную документацию. То ли дело дизайн. Вот они, картинки: тут красиво, а тут не очень.

Конечно, такой подход к дизайну очень поверхностный, и это понимают даже сами комментаторы, но все равно не могут удержаться от высказывания своего мнения.

Ничего страшного в этом нет. Зачастую мнение со стороны не повредит, ведь даже непрофессионалы могут подметить недочеты или дать полезный совет. Но не каждый совет имеет силу распоряжения, и не каждая рекомендация полезна. Поэтому важно, из чьих уст исходят комментарии.

Все участники разработки продукта должны знать свои и чужие полномочия. Когда у дизайнера нет понимания, кто ответственный за согласование дизайна и ревью дизайн-макетов, ему начинает казаться, что все окружающие – его начальники, и это крайне дискомфортно.

Ликвидируйте дискомфорт, расставив точки над «i» в вопросе лиц, принимающих решение, и убедитесь, что все согласны с предложенным распределением компетенций.

Приведу пример такого распределения.

– Продакт-менеджер выставляет требования по задаче.

– Дизайн-лид команды согласовывает взятие задачи в работу и проводит предварительное ревью макетов.

– Разработчик и аналитик проводят оценку макетов на предмет технической реализации.

– Член команды ревью проводит ревью макетов.

– Продакт-менеджер принимает финальные макеты перед передачей в разработку.

Получается, что согласующих и ревьюеров все равно много. Но, во-первых, их число все-таки ограничено, а во-вторых, они направляют свои комментарии только на определенных этапах жизненного цикла задачи, а не когда им вздумается. Дизайнеру в таких условиях работать куда приятнее, чем в ситуации войны со всем миром.

Четко распределить компетенции стоит и внутри самой дизайн-команды. У каждого дизайнера должна быть своя зона ответственности и свой круг задач.

Если дизайнеры команды закреплены за разными направлениями бизнеса, крайне нежелательно перекидывать их с одного направления на другое. А когда в результате планирования задачи уже распределены между дизайнерами, нужно следовать намеченному плану и не менять исполнителей.

Подменять друг друга в случае форс-мажора допустимо, но следует помнить, что форс-мажор – это не норма. И уж точно не является форс-мажорной ситуацией чей-то отпуск. Такие вещи нужно планировать заранее.

Церемонии

Третья часть фреймворка дизайн-команды – это повторяющиеся мероприятия, встречи, или, как их еще называют, церемонии.

Эффективные церемонии должны быть регулярными, то есть происходить с одинаковой периодичностью в одно и то же время. К таким встречам проще готовиться, их повестка понятна, и прогуливать их стыдно.

Регулярные церемонии имеет смысл связать с планированием задач, синхронизацией команды, подведением итогов спринта (недели, квартала), обсуждением возникающих проблем и оценкой выполненной работы.

Я не буду приводить полный список церемоний, которые использую в своих командах. Многие из них аналогичны церемониям scrum-команд, например ежедневные стендапы или уже упомянутое планирование.

Вы без труда сможете найти их в любой статье, посвященной скраму, или подсмотреть у коллег из команд продуктовой разработки, если они работают по этому фреймворку. Главное, оцените их критически: процессы в дизайн-команде бывают специфичными, и далеко не все может вам подойти.

У различных церемоний может быть множество разных целей, но я упомяну только три функции церемоний, о которых почему-то часто забывают дизайн-лидеры.

Первая – это синхронизация.

Нужно регулярно встречаться, чтобы участники команды делились новостями, помогали друг другу и рассказывали о лучших практиках. Это особенно важно, когда команды работают над смежными (зависящими друг от друга) продуктами: так меньше шансов, что кто-то из них завернет не в ту сторону.

Вторая функция – это озвучивание и решение проблем.

Дизайнерам жизненно необходима возможность рассказать о наболевшем, быть услышанными и совместно с командой придумать, как справиться с неприятностями. Для этого мы с командой проводим дизайн-ретроспективу. На ней всплывают такие детали, представить которые у меня просто не хватило бы воображения. Например, серьезные обиды, которые копились долгое время, но никогда не проговаривались.

Ну и третья функция – создание комфортной обстановки. Это не уникальное свойство какой-то конкретной церемонии, а общее назначение всех полезных для команды мероприятий. Это кажется очевидным, но не будет лишним напомнить дизайн-лидам: церемонии существуют не только для эффективного управления командой, но и для комфортной работы ее участников.

Поддержка

Важное условие комфортной работы – ощущение поддержки. Даже самым гордым и независимым дизайнерам приятнее трудиться, когда они могут воспользоваться помощью коллег, получить от них дельный совет или просто услышать ободряющие слова. Тому, кто скромен или неопытен, поддержка помогает обрести уверенность, а бодрым и инициативным – не сбавлять уже набранный рабочий темп.

В идеальной картине мира поддержка дизайнера идет на трех уровнях:

– комьюнити,

– команды,

– и дизайн-лидера.

Поддержка на уровне комьюнити

Уровень комьюнити, или профессионального сообщества, есть в больших организациях, где несколько дизайн-команд.

Комьюнити – не просто сборище всех дизайнеров компании. Если они разобщены и никак не взаимодействуют друг с другом, это не более чем толпа, рассыпанная по разным углам офиса (или по разным городам и странам, если в компании удаленный формат работы). Чтобы дизайнеры компании стали настоящим комьюнити, им нужны общие каналы коммуникации, мероприятия и устойчивые связи друг с другом.

В дружелюбном комьюнити дизайнер легко может обратиться к коллегам из других команд с просьбой о помощи: дать ссылку на ресурс, поделиться контактами нужных людей или рассказать об удачном опыте.

Формирование отзывчивого комьюнити – это во многом задача дизайн-директоров и других руководителей дизайнерской вертикали, потому что они наделены полномочиями на выстраивание высокоуровневых процессов и определение правил в организации. Но если от начальства не видно инициативы или централизованных руководителей вообще нет, запускать процессы по сплочению дизайнеров должны лидеры дизайн-команд или даже сами дизайнеры.

Начать можно с малого – создать общие чаты для дизайнеров, где они смогут делиться экспертизой и помогать друг другу советом. Ну и, конечно, спамить свежими мемами. Кстати, если последних становится слишком много, не стоит запрещать дизайнерам веселиться. Лучше просто сделать еще один чат сугубо развлекательного характера, а основной оставить для рабочих вопросов.

А дальше нужно развивать другие каналы коммуникации: создавать новые чаты по конкретным направлениям, организовывать совместные походы на мероприятия и планировать регулярные онлайн- и офлайн-встречи.

Регулярные встречи комьюнити станут особенно полезными, если на них дизайнеры смогут:

– получать информацию об обновлениях: новых процедурах, шаблонах, изменениях в дизайн-системе и так далее;

– делиться лучшими практиками: удачными дизайн-решениями или успешным внедрением новых методов в работе;

– вносить предложения по улучшению процессов и дизайна в компании;

– открыто обсуждать существующие проблемы и искать пути их решения;

– и, наконец, просто стать видимыми друг для друга.

Я не буду пытаться подробно рассказать обо всех возможных форматах дизайнерских мероприятий – о них можно написать отдельную книгу, и не маленькую. Приведу лишь пару примеров.

Первый пример – внутреннее демо дизайна, которое проводится в МТС Финтех каждые две недели. На нем все дизайн-команды рассказывают о новых разработанных сценариях, демонстрируют макеты и делятся друг с другом обратной связью по ним. Таким образом, работа команд становится прозрачной: все дизайнеры компании знают, над чем работают их коллеги.

Второй пример – регулярные дизайн-синки продуктовых дизайнеров в ВТБ. Поскольку в банке дизайн-команды существуют в рамках разных бизнес-стримов и команд этих очень много, дизайнерам особенно важно не попасть в «информационный пузырь». Дизайн-синк решает эту проблему: на нем дизайнеры узнают обо всех касающихся дизайна новостях и о текущем статусе по самым важным вопросам.

Эти примеры, впрочем, имеют отношение не только к алгоритму «поддержка», но и к алгоритму «информированность», о котором мы поговорим в одной из следующих глав. Но мне показалось уместным привести их именно в контексте разговора о комьюнити, потому что профессиональное сообщество неполноценно без собственных мероприятий.

В комьюнити можно и нужно формировать рабочие группы.

Вероятно, у некоторых читателей понятие «рабочая группа» может ассоциироваться с чем-то бюрократическим, созданным по распоряжению руководства и состоящим из высоких начальников. Но я говорю о совсем других рабочих группах – добровольных объединениях дизайнеров из разных команд, но с общими целями.

К сожалению, этот инструмент часто недооценивается дизайн-лидерами, и совершенно зря. Далеко не все проблемы можно решить в рамках одной команды или плановых мероприятий комьюнити.

Рабочие группы – это временные объединения дизайнеров, и они существуют в период решения конкретных проблем. Например, в ВТБ рабочая группа дизайнеров прорабатывала шаблоны клиентских анкет, которые необходимы многим командам: и кредитам, и вкладам, и картам. А в МТС Финтех я таким образом организовал разработку нужного всем чек-листа для описания задач.

Сообщества убивает токсичность.

В среде дизайнеров я, признаться, не встречал откровенно токсичных сообществ. Были, конечно, отдельные неприятные индивиды, которые портили кровь окружающим, но их поведение никогда не воспринималось как норма.

А вот у разработчиков я наблюдал токсичные традиции. В одном крупном банке бедные программисты предпочитали приходить за советом (например, по поводу реализации в коде какого-то компонента) к дизайнерам, а не писать в чат коллегам по цеху – это было все равно что сунуть руку в пчелиный улей.

Не допустить формирования токсичной среды в силах дизайн-лидов, особенно если у них есть узнаваемость и авторитет среди коллег. Они должны подвергать тех, кто ведет себя по-хамски, осуждению и даже лишать их права голоса в обсуждениях за плохое поведение.

Обратная ситуация с позитивными тенденциями в комьюнити: инициативных и общительных дизайнеров нужно всячески поддерживать, чтобы они «раскачивали» комьюнити и не давали ему развалиться на атомизированные группы.

Поддержка на уровне команды

Многое из сказанного о комьюнити относится и к конкретным дизайн-командам. Им тоже нужны свои каналы коммуникации, мероприятия и встречи.

Только связи между дизайнерами внутри команды должны быть еще крепче, чем в комьюнити, а взаимодействия еще больше. Это кажется очевидным, если просто взглянуть на схему оргструктуры компании, но на практике так бывает не всегда. В некоторых командах дизайнеры скорее пойдут «на сторону», чем обратятся за советом к своим коллегам.

Дело в том, что многие команды являются таковыми только на словах. А по факту это просто механически сгруппированные люди, которым не посчастливилось быть приписанными к одному подразделению. У них нет общих целей, интересов и мероприятий – вообще ничего, кроме штатного расписания. Даже продукты, над которыми они работают, могут быть разными.

И если вопрос общих мероприятий можно решить, введя церемонии, о которых я писал в главе «Фреймворк», то подарить ощущение единства и взаимной поддержки команде может только ее лидер. Именно он должен подавать позитивный пример остальным и культивировать правильную модель поведения.

В этом также ему поможет алгоритм «очеловечивание», о котором мы поговорим в следующей главе. Как видите, все алгоритмы связаны между собой и, будучи использованными вместе, дают синергический эффект[4].

И еще одна мысль о поддержке внутри команды.

Важно понимать разницу между поддержкой и «делать задачи за других». Среди любых сотрудников – и дизайнеры не исключение – есть любители поработать чужими руками, которые воспринимают помощь других как должное и нещадно ее эксплуатируют. А есть, наоборот, безотказные ребята, которые готовы взвалить на себя непосильный объем работы, от которого рано или поздно надорвутся.

Допускать таких перегибов нельзя. Нужно помнить, что у любого дизайнера в приоритете своя зона ответственности, и не допускать злоупотреблений со стороны особенно наглых коллег.