Все статьи
Пять пороков команды: Agile-кейс
Дата: 27.08.2025
Разбираем дисфункции команды по Патрику Ленсиони и показываем, как Скрам-мастер Agile-команды исцелил их шаг за шагом.
Содержание
Команды стриминговых сервисов конкурируют не количеством фич, а глубиной персональных рекомендаций. Когда пороки команды затормаживают людей, даже самая изящная нейросеть теряет силу. Ниже — краткая теория пяти дисфункций Патрика Ленсиони и реальный кейс одного стриминг-сервиса, где Scrum-мастер за квартал вывел Agile-команду из пике.
Этот кейс рассказал мне за бокалом кофе один из участников сообщества, пожелавший остаться неизвестным.
Если вы захотите поделиться своим кейсом, анонимно или гласно, то напиши мне в Telegram. Мы с вами встретимся в удобном для вас формате, и я помогу вам собрать статью. От вашего имени, что предпочтительнее, или от моего, если NDA или другие причины не позволяют вам публиковаться самостоятельно.
Что такое пять пороков команды?
Патрик Ленсиони, автор книги Пять пороков команды, выделяет пять главных проблем, которые мешают командам добиваться высоких результатов:
- Отсутствие доверия. Когда люди боятся признать ошибки, предпочитая скрывать слабые места, страдает прозрачность, и команда перестаёт развиваться.
- Страх конфликтов. Если в команде нет открытого обсуждения, то решения принимаются за спинами, а команда теряет способность находить эффективные решения.
- Отсутствие вовлечённости. Когда участники формально относятся к общим целям и не чувствуют их своими, команда теряет энергию и мотивацию.
- Уклонение от ответственности. Команда перестаёт отвечать за общие результаты, перекидывая ответственность за неудачи друг на друга.
- Невнимание к результатам. Команда сосредоточена на внутренних показателях вместо реальных результатов для клиентов.
Как пороки проявлялись в команде?
Agile-команда, о которой идёт речь — часть большой ИТ-команды, создающей стриминговый сервис, который будем называть NeNetflix. Задача команды – развивать рекомендательные алгоритмы для пользователей сервиса.
Ситуация была напряжённой: разработка новых функций буксовала, сроки затягивались, показатели эффективности, главным из которых было время просмотра рекомендаций, не росли. Скрам-мастер на протяжении спринта наблюдал за работой команды и вот, что он смог увидеть.
1. Отсутствие доверия
Формально команда пользовалась общими репозиториями и весь код был виден всем. При этом, Merge Request (MR) появлялись только под конец спринта, когда было «уже поздно что-то менять», MR всегда проводил только тимлид, а общих встреч по обзору кода и обмену хорошими практиками не было. Коммуникации между участниками были натянутыми — разработчики избегали обсуждения своих решений.
Скрам-мастер заметил, что при обсуждении задач коллеги не просили уточнений и не высказывали сомнений. Ни на одном дейли никто не спрашивал: «А что там с той задачей, которую делает Петя?» Было ощущение, что каждый работает «в своей коробочке».
В команде ценили «самостоятельность» и «автономность» — но это привело не к ответственности, а к изоляции. Люди привыкли не лезть друг к другу, даже когда надо.
2. Страх конфликта
При передаче задачи от аналитиков к дизайнерам, а от дизайнеров к разработчикам возникали несостыковки — и никто не поднимал их открыто. Например, дизайн включал сложные интерактивы, которые были трудозатратны, но об изменениях не договаривались — просто делали «как получится».
Скрам-мастер услышал, как на обзоре один разработчик пошутил, что «нарисовать можно, что угодно». В ответ — тишина. На ретро участники говорили об общих темах, но избегали обсуждения конкретных кейсов. На один из вопросов Скрам-мастера дизайнер сказал: «Ну, это же ни к чему не приведёт».
В команде было несколько затяжных споров в прошлом, и теперь люди опасались открытых обсуждений, чтобы не «душнить» и не «разводить драму». Лучше молчать, чем спорить.
3. Отсутствие вовлечённости
Планирование выглядело как раздача — тимлид готовил индивидуальные задачи, раздавал их исполнителям, а коммитмент на спринт принимал сам. Остальные просто брали, что дают. Цель спринта не обсуждалась вообще.
Никто не задавал вопросов о том, зачем эта задача или как она повлияет на пользователей. При этом во внутренних чатах велись активные обсуждения множества других тем, очевидно, нейтральных — команда была жива, просто не включалась в планирование продукта.
Люди не чувствовали, что их мнение что-то решает. Scrum был только внешне — без включённости команды в решение. Из трёх ключевых топиков: почему этот спринт ценен, что должно быть сделано и как это делать, оставался только вопрос: «Как?» — и тот наполовину продиктованный тимлидом.
4. Уклонение от ответственности
5. Невнимание к результату
Если вы дочитали до этого места, значит, вам интересен полезный контент о современных методах управления. Чтобы узнавать про новые статьи, видео и бесплатные мероприятия, подписывайтесь на Telegram-канал ProAgile.
Как Scrum-мастер помог команде избавиться от пороков?
Скрам-мастер действовал поэтапно, устраняя каждый из пяти пороков.
Шаг 1. Как построить доверие?
Проблему недоверия начали решать через серию встреч «Карьерные вехи». На них каждый член команды рассказал о своём пути, достижениях и неудачах. Люди открылись друг другу, увидели, что ошибки – это нормально.
Затем Скрам-мастер предложил команде внедрить регулярную практику взаимной проверки кода. MR от тимлида никуда не делся, раз надо, значит, надо. Но добавился второй ревьювер, который смотрел код не для контроля. А для того, чтобы обменяться видением решения с автором.
В результате исчезла закрытость, повысилась общая уверенность. В качестве побочного явления, появились редкие, но инициированные самими разработчиками, встречи по разбору самых интересных кейсов.
Шаг 2. Как перестать бояться конфликтов?
Команда боялась открытых споров, что совершенно естественно для любого человека.
Скрам-мастер внедрил правило «Одноминутного спора». Суть в том, что каждое обсуждение новой задачи начиналось с коротких дебатов: один член команды задачи защищает идею, коллега её критикует. Важно, чтобы дебатеры подбирались без жесткой привязки к их реальному мнению. Сложнее всего было преодолеть первые дебаты, на которых регулярно повисает неловкое молчание. Это сняло напряжение, позволило людям научиться конструктивно спорить.
Также на ретроспективах команда начала использовать метод «пять почему», чтобы понять настоящие причины неудач, не обвиняя друг друга, а разбираясь в сути проблемы. Опять же, надо обратить особенное внимание на фасилитацию этой техники.
Шаг 3. Как повысить вовлечённость команды?
Команда не чувствовала важность целей спринта. И, как следствие, даже не пыталась ими пользоваться. Скрам-мастер начал вести журнал принятых решений, где фиксировал, какие задачи и почему выбрали именно сейчас. Затем он попросил продакта коммуницировать главную продуктовую метрику – увеличить количество часов, которые новые пользователи смотрят по рекомендациям и сформировать дорожную карту по достижению целевого значения. Дорожную карту роста метрики, а не задач.
Вовлечённость выросла, когда каждый понял, зачем делает свою работу. И даже понял, как оценить свой успех или его отсутствие.
Шаг 4. Как повысить ответственность команды?
Команда долго игнорировала ошибки, считая, что это проблема коллег. Скрам-мастер вместе с командой сформулировали Definition of Done, критерии готовности. Например, новый код не считался готовым, пока он не проходил автоматические тесты и проверку коллегами. А регулярные демонстрации заинтересованным лицам и соседним командам помогли выявлять ошибки на ранних стадиях.
Шаг 5. Как вернуть фокус на результат?
Команда ранее отслеживала лишь внутренние: процессные и LLM-метрики. Скрам-мастер после коммуникации продуктовых целей предложил команде добавить в дашборд команды метрики, напрямую связанный с опытом пользователей, например, часы просмотра рекомендаций. Его динамику стали транслировать на общий экран в офисе и рассматривать на обзорах и планированиях спринта. Теперь люди видели, что их работа влияет на реальный успех продукта, и это вернуло мотивацию.
Результаты работы не заставили себя ждать.
Итоги квартала в команде
За три месяца показатели заметно улучшились.
|
Показатель
|
Было в Q1
|
Стало в Q2
|
|---|---|---|
|
Среднее время от идеи до релиза
|
27 дней
|
19 дней
|
|
Часы просмотра по рекомендациям
|
3,2
|
3,6
|
|
eNPS
|
–38%
|
11%
|
Как повторить успех: практический чек-лист
Хотите избавиться от пороков вашей команды? Вот проверенные, но не единственные, шаги.
- Проведите встречу для личного знакомства и обсуждения сильных сторон каждого участника.
- Сделайте регулярной практику взаимных проверок рабочих результатов (кода, дизайна, гипотез).
- Используйте короткие структурированные дебаты на обсуждениях задач.
- Свяжите цели и задачи команды с важными для клиентов метриками.
- Сформулируйте и регулярно проверяйте чёткие критерии готовности задач.
- Организуйте регулярные демонстрации результатов другим командам.
- Сделайте клиентские метрики прозрачными и общедоступными, показывайте их динамику всей команде.
Эти простые действия помогут вашей команде не просто улучшить показатели, но и стать местом, где хочется работать и добиваться результатов.
