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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Церемонии

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

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

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

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

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

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

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

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

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

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

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

Поддержка

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

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

– комьюнити,

– команды,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

Примечания

1

Pivot – изменение стратегии компании.

2

Практики регулярного менеджмента: Управление исполнением. Управление командой ⁄ Павел Безручко. – Альпина Паблишер, 2021 г.

3

Юрий Ветров – один из самых уважаемых мной людей в российском дизайн-менеджменте и, помимо всего прочего, автор онлайн-курса и книги «Паттерны дизайн-менеджмента».

4

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