Участие команды в принятии решений
В июле я вышел техлидом в команду, которая "выгнала" прошлого техлида через месяц работы. Конечно, я об этом узнал еще на собеседовании, и, конечно, для меня это стало звоночком. Причин того инцидента было много, но основная — это стиль руководства. Товарищ единолично принимал решения и транслировал их команде: "Делать будем так." А команда была не согласна. То ли сам стиль вызывал такое отторжение, то ли решения были реально фиговыми, мы уже не узнаем. В общем, ко мне был запрос на самом старте: помогать принимать решения командой, но не решать за команду.
Консенсус.
Слово звучит классно, но стоит очень дорого. Чтобы принять решение, которое устроит всех и каждого, нужно проделать много работы. Затронуть все аспекты темы, поговорить о мотивах всех участников, в том числе вскрыть неявные и потом найти такое решение, которое всем подойдет. Scrum ставит высшей ценностью принятие консенсусных решений всеми участниками. Проблема в том, что если в обсуждении участвует вся команда, то это реально может затянуться.
Идеальная слаженная команда, где все друг другу доверяют, принимает решения быстро и качественно. Команда на этапе становления может утонуть во встречах, бесконечно дискутируя об одном и том же. Встречи затягиваются в том числе потому, что участники не доверяют друг другу, имеют скрытые мотивы и боятся их озвучить.
Я раньше писал, что встречи отнимают много времени у разработчиков и что для продуктивной работы нужен баланс. Баланс участия в принятии решений. В продукте все время что-то происходит и принимаются какие-то решения. Часть из них выносится на встречи. Чем больше запрос на совместное принятие решений — тем больше встреч.
Можно ходить на все-все-все встречи, беситься, что их много, что они долгие, что на них одно и то же по десять раз перетирают и что не хватает времени покодить. А можно не ходить ни на какие встречи и тупо сидеть кодить что дают. Обе крайности имеют хреновые последствия. В первом случае разработка не движется. Во втором случае разработчик может быть тотально не согласен с решением и из-за этого накодить не то или не так.
Как вариант — можно пропускать некоторые встречи. По сути, пропуская какую-то встречу, человек позволяет принять решение без него. И здесь нужно либо доверие, либо пофигизм. Потому что иначе, если кто-то не согласен с принятым решением, то это может аукнуться очень больно и очень поздно. А когда аукнется, это обесценивает работу группы на встрече и потраченное время.
Идеального универсального решения нет. В любом случае учиться договариваться друг с другом придется. Как учиться договариваться? Тоже нет рецепта, но есть отрезвляющий чеклист:
1️⃣ — Держать в голове, что на первом месте польза для продукта. Приводить аргументы в первую очередь, отталкиваясь от этого.
2️⃣ — Думать о степени важности решения. Можно ли проверить гипотезу, выкинуть и с помощью полученной информации принять новое, более качественное решение.
3️⃣ — Ставить целью принять решение всей командой, а не продавить своё мнение. Иногда даже поступиться своим мнением, и дать команде ошибиться (см. п. 2). Впоследствии может оказаться что это и не ошибка вовсе.
Если каждый пришел на встречу, чтобы продавить свою уникальную точку зрения, то принять консенсусное решение почти невозможно. Если все участники понимают эти три простых пункта и пришли на встречу, чтобы договориться, то встреча пройдет быстро и не вызовет недовольства. Со временем некоторые вопросы можно будет просто и быстро решать "по ходу", не вынося на отдельные встречи. Получается, что страдания на встречах сейчас == меньше встреч потом. Ну, при условии прогресса в умении договариваться 🙂
В июле я вышел техлидом в команду, которая "выгнала" прошлого техлида через месяц работы. Конечно, я об этом узнал еще на собеседовании, и, конечно, для меня это стало звоночком. Причин того инцидента было много, но основная — это стиль руководства. Товарищ единолично принимал решения и транслировал их команде: "Делать будем так." А команда была не согласна. То ли сам стиль вызывал такое отторжение, то ли решения были реально фиговыми, мы уже не узнаем. В общем, ко мне был запрос на самом старте: помогать принимать решения командой, но не решать за команду.
Консенсус.
Слово звучит классно, но стоит очень дорого. Чтобы принять решение, которое устроит всех и каждого, нужно проделать много работы. Затронуть все аспекты темы, поговорить о мотивах всех участников, в том числе вскрыть неявные и потом найти такое решение, которое всем подойдет. Scrum ставит высшей ценностью принятие консенсусных решений всеми участниками. Проблема в том, что если в обсуждении участвует вся команда, то это реально может затянуться.
Идеальная слаженная команда, где все друг другу доверяют, принимает решения быстро и качественно. Команда на этапе становления может утонуть во встречах, бесконечно дискутируя об одном и том же. Встречи затягиваются в том числе потому, что участники не доверяют друг другу, имеют скрытые мотивы и боятся их озвучить.
Я раньше писал, что встречи отнимают много времени у разработчиков и что для продуктивной работы нужен баланс. Баланс участия в принятии решений. В продукте все время что-то происходит и принимаются какие-то решения. Часть из них выносится на встречи. Чем больше запрос на совместное принятие решений — тем больше встреч.
Можно ходить на все-все-все встречи, беситься, что их много, что они долгие, что на них одно и то же по десять раз перетирают и что не хватает времени покодить. А можно не ходить ни на какие встречи и тупо сидеть кодить что дают. Обе крайности имеют хреновые последствия. В первом случае разработка не движется. Во втором случае разработчик может быть тотально не согласен с решением и из-за этого накодить не то или не так.
Как вариант — можно пропускать некоторые встречи. По сути, пропуская какую-то встречу, человек позволяет принять решение без него. И здесь нужно либо доверие, либо пофигизм. Потому что иначе, если кто-то не согласен с принятым решением, то это может аукнуться очень больно и очень поздно. А когда аукнется, это обесценивает работу группы на встрече и потраченное время.
Идеального универсального решения нет. В любом случае учиться договариваться друг с другом придется. Как учиться договариваться? Тоже нет рецепта, но есть отрезвляющий чеклист:
1️⃣ — Держать в голове, что на первом месте польза для продукта. Приводить аргументы в первую очередь, отталкиваясь от этого.
2️⃣ — Думать о степени важности решения. Можно ли проверить гипотезу, выкинуть и с помощью полученной информации принять новое, более качественное решение.
3️⃣ — Ставить целью принять решение всей командой, а не продавить своё мнение. Иногда даже поступиться своим мнением, и дать команде ошибиться (см. п. 2). Впоследствии может оказаться что это и не ошибка вовсе.
Если каждый пришел на встречу, чтобы продавить свою уникальную точку зрения, то принять консенсусное решение почти невозможно. Если все участники понимают эти три простых пункта и пришли на встречу, чтобы договориться, то встреча пройдет быстро и не вызовет недовольства. Со временем некоторые вопросы можно будет просто и быстро решать "по ходу", не вынося на отдельные встречи. Получается, что страдания на встречах сейчас == меньше встреч потом. Ну, при условии прогресса в умении договариваться 🙂