Матрица согласований У дизайнера найдется десяток людей, которые «пытаются помочь» ему делать свою работу. И это одна из первых ловушек, в которую попадает начинающий тимлид. Типовая ситуация: дизайнер приносит макет, вокруг собираются разработчики, менеджеры, подруга жены босса и каждый начинает «накидывать». Дизайнер погружает новых людей в задачу и доказывает, что сценарий решается интерфейсом. Бонусом идут редкие сценарии, которые «нужно обязательно учесть». После этого интерфейс превращается в компромисс, пытающийся учесть все и сразу. Оговорюсь — я не против фидбека от команды, но он должен быть в формате рекомендаций, а финальное решение остается за дизайнером. У меня были такие же общие синки: куча мнений и бесконечные согласования. По ощущениям, такие встречи затягивали процесс. Нашел для себя триггер: если команде не хочется идти на эту встречу, потому что «сейчас накидают на вентилятор» — это сигнал, что проблема есть. Решение — поделить участников по категориям: — кто реально принимает решения, — кого просто держим в курсе, — кого стоит исключить из процесса. Это я назвал матрицей согласований. Матрица экономит время на синках и помогает строить отношения внутри команды: так проще понять, хорошая ли связка дизайнер+продакт или нет. А еще матрица увеличивает эффективность и ответственность: отвечать за решения будут конкретные люди, а не вся команда по чуть-чуть. В блоге я оставил пошаговый разбор и ссылку на шаблон, чтобы вы могли использовать матрицу для себя. P.S. Этот пост — начало серии заметок для начинающих тимлидов. Пишите, какие темы еще разобрать.