Андрей Богданов – Как сделать дизайнеров счастливыми (страница 4)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Церемонии

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

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

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

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

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

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

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

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

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

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

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

Поддержка

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

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

– комьюнити,

– команды,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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