У дизайнера найдется десяток людей, которые «пытаются помочь»<\/b> ему делать свою работу. И это одна из первых ловушек, в которую попадает начинающий тимлид.<\/p>\n
Типовая ситуация: дизайнер приносит макет, вокруг собираются разработчики, менеджеры, подруга жены босса — и каждый начинает накидывать. Дизайнер погружает новых людей в задачу и доказывает, что сценарий решается интерфейсом. Бонусом идут редкие сценарии, которые «нужно обязательно учесть».<\/p>\n
После этого интерфейс превращается в компромисс, пытающийся учесть всё и сразу.<\/p>\n
Оговорюсь — я не против фидбека от команды<\/b>, но он должен быть в формате рекомендаций, а финальное решение остаётся за дизайнером.<\/p>\n
У нас тоже были часовые общие синки: куча мнений, бесконечные согласования. Силы уходят не на продукт, а на отстаивание решений<\/b>.<\/p>\n
Нашёл для себя триггер: если команде не хочется идти на эту встречу, потому что «сейчас накидают на вентилятор» — это сигнал, что проблема есть.<\/p>\n
Самое простое и при этом рабочее решение — выписать списком всех, кто влияет на дизайн: убрать лишних и чётко зафиксировать роли остальных. Нужно обсудить с каждым его роль и участие в процессе и в дальнейшем проследить, чтобы они выполняли договорённости.<\/p>\n
В идеале ответственными должны быть два человека: продакт<\/b>, который ставит задачу и принимает решение, и дизайнер<\/b>, который решает эту задачу, создавая решение. Остальные могут просто быть в курсе и давать рекомендации.<\/p>\nКак построить матрицу<\/b><\/h2>\n
Удобнее всего вести её в виде таблицы.<\/p>\n
В ней фиксируются:<\/p>\n
— Роль \/ должность;
\n— Заинтересованность — насколько человеку важна ваша работа и её результат (низкая, средняя или высокая);
\n— Мотивация — что человек получает от участия. Она может быть честная (результат), а может быть человеческая (самоутверждение, влияние);
\n— Насколько может повлиять? — от 1 до 5, где 1 — влияние минимально, а 5 — последнее слово;
\n— Текущий уровень доверия — низкий, нейтральный, средний, высокий. Есть ли напряжение в общении и затягивание согласования, или это «свой» человек;
\n— Заметки и риски — что важно помнить;
\n— Нужный уровень вовлечения по RACI<\/b> — подробнее ниже.<\/p>\nГде тут наука<\/b><\/h2>\n
Если хотите копнуть глубже, то в проектном менеджменте есть множество крутых моделей — я лишь адаптировал их под себя.<\/p>\n
RACI-матрица<\/b> помогает разделить роли:
\nResponsible — кто делает;
\nAccountable — кто принимает финальное решение;
\nConsulted — с кем консультируемся;
\nInformed — кого информируем.<\/p>\n
Power—Interest Grid<\/b> показывает, кого вовлекать глубже, а кого просто держать в курсе.
\nSalience Model<\/b> учитывает влияние, легитимность и срочность требований.<\/p>\n
По сути, матрица согласований<\/b> — это локальная адаптация этих моделей под продуктовый дизайн. Возможно, вы учтёте другие пункты и адаптируете под себя.<\/p>\n Для каждого участника нужен свой подход:<\/p>\n R<\/b> — отвечает за выполнение (обычно дизайнер или тимлид).Алгоритм по сборке<\/b><\/h2>\n
\n
\nСократите круг влияющих: оставьте ключевых A<\/b>, остальным — C<\/b> или I<\/b>.<\/li>\n<\/ol>\n
\nA<\/b> — участвует в согласовании с самого начала, ранние черновики, мини-синки, финальный апрув.
\nC<\/b> — короткое информирование, ранний показ черновиков (например, для оценки реализуемости).
\nI<\/b> — короткое информирование, регулярные демо.<\/p>\n