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

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

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

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

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

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

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

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

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

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

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

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

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

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

Церемонии

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

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

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

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

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

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

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

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