Пять пороков команды
— это концепция пирамиды из книги Патрика Ленсиони Five Dysfunctions of a Team. Мне кажется, что cлово «порок» — не совсем корректная локализация, поэтому буду писать «дисфункция».
Пост получился объёмным, поэтому я его разделил на две части: здесь обзор и примеры, а в следующем — о методах «лечения».
Дисфункции идут по пирамиде — одна вытекает из другой, создавая систему взаимозависимых проблем. Я сталкивался с ними в больших командах, когда личный вклад размывается, и можно «затеряться».
Итак, вот они, слева-направо, люблю их снизу-вверх:
1️⃣ Отсутствие доверия — члены команды боятся ошибиться, т.к. предполагают, что за ошибку их сначала публично отчитают, а потом и вовсе уволят (и из-за этого они умрут от голода).
Например, разработчик неделю не признается в проблемах по задаче, боясь показаться некомпетентным. В результате цель спринта провалена, а осознание этого приходит в последний день, когда уже ничего нельзя сделать.
Это базовая дисфункция, лежащая в корне всех остальных проблем. Поэтому «лечение» команды нужно начинать именно с неё.
2️⃣ Боязнь конфликтов — команда избегает конструктивных споров: либо поверхностно соглашается с решением, либо быстро идет на компромисс, который в итоге никому не выгоден. Лишь бы не вступать в конфликт
Правильно — незачем раскачивать лодку. Сиди тихо и не высовывайся, всем лучше будет.
Например, при проработке нового сервиса разработчик предлагает новую технологию и никто не высказывает альтернативное мнение, хотя у многих есть сомнения. Потом приходится переделывать большие куски кода.
3️⃣ Отсутствие обязательств — команда не берет на себя ответственность за решения и договоренности.
Кто не принимает решений, тот не ошибается — Удобно.
Например, когда на ретроспективе возникает экшен-айтем, никто не вызывается взять его на себя. А командные соглашения забываются сразу после выходных.
Или другой пример — при выборе архитектуры разработчики не могут принять ответственность за решение и всегда привлекают тимлида.
4️⃣ Уклонение от ответственности — члены команды не призывают друг друга к ответу за действия и результаты.
Пока сидишь тихо и не привлекаешь внимание — всё хорошо. А если начнешь от кого-то чего-то требовать, то и от тебя начнут требовать. А оно тебе надо?
Например, никто не обращает внимания на то, что коллега постоянно нарушает код-стайл, аргументируя это спешкой. Техдолг растет, но все молчат.
Другой пример — один из разработчиков слишком часто берет дейоффы и «болеет». При этом никто из команды этого не замечает.
5️⃣ Невнимание к результатам — личные цели ставятся выше командных.
Какая нафиг цель спринта? Какие такие продуктовые метрики? Вот если я в резюме напишу, что работал с CockroachDB — вот это да, это понятно зачем нужно.
…
В итоге, это всё про страх потерять работу. Сиди на попе ровно, получай зарплату, не делай много / не высовывайся, не требуй много с других / не докапывайся.
И всё будет хорошо.
Нет, не будет.
В такой атмосфере нет ни удовольствия от работы, ни роста и развития. Люди увольняются, а проект загнивает.
Поэтому с дисфункциями нужно бороться.
Ключевое отличие команды от рабочей группы — наличие общей цели и взаимной поддержки. Но не достаточно просто формально обозначить «цель спринта». Нужно выстраивать доверительные отношения и атмосферу взаимопомощи.
Друзья, для следующего поста мне нужна ваша помощь: поделитесь в комментариях, с какими из этих дисфункций вы сталкивались? Как боролись? Как поняли, что ситуация улучшилась?
— это концепция пирамиды из книги Патрика Ленсиони Five Dysfunctions of a Team. Мне кажется, что cлово «порок» — не совсем корректная локализация, поэтому буду писать «дисфункция».
Пост получился объёмным, поэтому я его разделил на две части: здесь обзор и примеры, а в следующем — о методах «лечения».
Дисфункции идут по пирамиде — одна вытекает из другой, создавая систему взаимозависимых проблем. Я сталкивался с ними в больших командах, когда личный вклад размывается, и можно «затеряться».
Итак, вот они, слева-направо, люблю их снизу-вверх:
1️⃣ Отсутствие доверия — члены команды боятся ошибиться, т.к. предполагают, что за ошибку их сначала публично отчитают, а потом и вовсе уволят (и из-за этого они умрут от голода).
Например, разработчик неделю не признается в проблемах по задаче, боясь показаться некомпетентным. В результате цель спринта провалена, а осознание этого приходит в последний день, когда уже ничего нельзя сделать.
Это базовая дисфункция, лежащая в корне всех остальных проблем. Поэтому «лечение» команды нужно начинать именно с неё.
2️⃣ Боязнь конфликтов — команда избегает конструктивных споров: либо поверхностно соглашается с решением, либо быстро идет на компромисс, который в итоге никому не выгоден. Лишь бы не вступать в конфликт
Правильно — незачем раскачивать лодку. Сиди тихо и не высовывайся, всем лучше будет.
Например, при проработке нового сервиса разработчик предлагает новую технологию и никто не высказывает альтернативное мнение, хотя у многих есть сомнения. Потом приходится переделывать большие куски кода.
3️⃣ Отсутствие обязательств — команда не берет на себя ответственность за решения и договоренности.
Кто не принимает решений, тот не ошибается — Удобно.
Например, когда на ретроспективе возникает экшен-айтем, никто не вызывается взять его на себя. А командные соглашения забываются сразу после выходных.
Или другой пример — при выборе архитектуры разработчики не могут принять ответственность за решение и всегда привлекают тимлида.
4️⃣ Уклонение от ответственности — члены команды не призывают друг друга к ответу за действия и результаты.
Пока сидишь тихо и не привлекаешь внимание — всё хорошо. А если начнешь от кого-то чего-то требовать, то и от тебя начнут требовать. А оно тебе надо?
Например, никто не обращает внимания на то, что коллега постоянно нарушает код-стайл, аргументируя это спешкой. Техдолг растет, но все молчат.
Другой пример — один из разработчиков слишком часто берет дейоффы и «болеет». При этом никто из команды этого не замечает.
5️⃣ Невнимание к результатам — личные цели ставятся выше командных.
Какая нафиг цель спринта? Какие такие продуктовые метрики? Вот если я в резюме напишу, что работал с CockroachDB — вот это да, это понятно зачем нужно.
…
В итоге, это всё про страх потерять работу. Сиди на попе ровно, получай зарплату, не делай много / не высовывайся, не требуй много с других / не докапывайся.
И всё будет хорошо.
Нет, не будет.
В такой атмосфере нет ни удовольствия от работы, ни роста и развития. Люди увольняются, а проект загнивает.
Поэтому с дисфункциями нужно бороться.
Ключевое отличие команды от рабочей группы — наличие общей цели и взаимной поддержки. Но не достаточно просто формально обозначить «цель спринта». Нужно выстраивать доверительные отношения и атмосферу взаимопомощи.
Друзья, для следующего поста мне нужна ваша помощь: поделитесь в комментариях, с какими из этих дисфункций вы сталкивались? Как боролись? Как поняли, что ситуация улучшилась?