🟣 «Просто не мешай команде работать»

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

Вот есть у нас большая команда: продакт, проджект, бекенд, фронтенд, дизайн, QA. Решили мы командой сделать большую фичу. Ну, как решили. Продакт нагенерил идей, руководство принесло фичу сверху, конкуренты сделали классное и нам тоже надо — мы решили сделать фичу.

🔷Дизайнер собирает макеты. И велик соблазн сразу сказать ему, как делать. Чуть ли не нарисовать за него, чтобы он просто раскрасил красиво и по гайдлайнам. Но вообще-то дизайн — это не просто кнопки красить. Это про смыслы, удобство, консистентность. И какая бы ни была у меня насмотренность, какое бы ни было сильное мнение — пока дизайнер не спросит его, терпеть. «Просто не мешай команде работать».

🔷Разработка реализует макеты. Грумим, убеждаемся, что все участники процесса понимают задачу одинаково, доуточняем тикеты. Разработка забирает задачу на декомпозицию, начинает обсуждать, как это нужно делать технически. А у меня ж опыт, 16 лет в профессии, я ещё на таблицах верстал и БД в phpMyAdmin настраивал! И так хочется советами поделиться! Терпеть. Перестал ходить на декомпозицию в принципе. А если моё мнение надо будет — спросят. Что приятно: и правда иногда спрашивают. «Просто не мешай команде работать».

🔷QA тестирует фичу. Последний рубеж перед выкаткой релиза. И снова хочется обратить внимание, что вот тут можно вот так сломать, а тут вот это надо проверить. А ещё в DevTools есть вот такая вкладка, она поможет проверить вот такой кейс… Терпеть. Надо обратить внимание — допиши в тикет, уточни требования ещё до взятия задачи в работу. Спросят — уточнишь. «Просто не мешай команде работать».

Мне кажется, это про доверие. И про перфекционизм, местами нездоровый. Если хочется влезть в каждый шаг реализации фичи, то зачем я шёл работать в команде, зачем помогал собирать эту команду из профессионалов, которые так-то отбор проходили? Если хочется чему-то научить, то надо учить, а не указывать, как сделать. Не указывать, а предлагать варианты и спрашивать, почему решили сделать по-другому. Если я хочу, чтобы моим решениям в роли продакта доверяли, надо доверять в ответ.

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

А если фичи катятся, метрики приятно меняются, бизнес-ценность растёт, а качество не снижается, то нечего мешать команде работать. Микроменеджмент — для микроменеджеров.