Когда оговоренную работу не получается сделать в срок, стоит открыто и честно обсудить причины. Если дело окажется в неадекватной оценке, это нужно будет учесть при оценке задач в дальнейшем.
Постановкой и оценкой задач дело не ограничивается. Нужно также продумать правила, по которым будут уточняться требования, передаваться обратная связь от заказчиков, происходить ревью подготовленных макетов и другие процессы. Цель – сделать так, чтобы жизненный цикл задачи проходил по понятным правилам. Правила могут быть не зафиксированы в официальной документации, но они должны приниматься и однозначно трактоваться всеми участниками процесса.
Понятное распределение компетенций
Правила работы с задачами немыслимы без определения лиц, принимающих решения, и их полномочий. Для дизайн-команд это особенно важно.
Иногда кажется, что все вокруг считают себя экспертами в дизайне и не скупятся на советы дизайнерам. Это происходит оттого, что дизайн имеет ярко выраженную визуальную составляющую. Давать советы разработчикам и аналитикам сложно: одни пишут какой-то непонятный код, вторые – сложную документацию. То ли дело дизайн. Вот они, картинки: тут красиво, а тут не очень.
Конечно, такой подход к дизайну очень поверхностный, и это понимают даже сами комментаторы, но все равно не могут удержаться от высказывания своего мнения.
Ничего страшного в этом нет. Зачастую мнение со стороны не повредит, ведь даже непрофессионалы могут подметить недочеты или дать полезный совет. Но не каждый совет имеет силу распоряжения, и не каждая рекомендация полезна. Поэтому важно, из чьих уст исходят комментарии.
Все участники разработки продукта должны знать свои и чужие полномочия. Когда у дизайнера нет понимания, кто ответственный за согласование дизайна и ревью дизайн-макетов, ему начинает казаться, что все окружающие – его начальники, и это крайне дискомфортно.
Ликвидируйте дискомфорт, расставив точки над «i» в вопросе лиц, принимающих решение, и убедитесь, что все согласны с предложенным распределением компетенций.
Приведу пример такого распределения.
– Продакт-менеджер выставляет требования по задаче.
– Дизайн-лид команды согласовывает взятие задачи в работу и проводит предварительное ревью макетов.
– Разработчик и аналитик проводят оценку макетов на предмет технической реализации.