В любой команде наступает момент, когда становится слишком много метрик. Delivery, качество, ретроспективы, отчеты — данных хватает, дашборды заполнены, встречи идут регулярно. Но при этом все сложнее ответить на вопрос: мы управляем процессом или просто измеряем его? Этот вопрос встал и перед нами, когда мы задумались об оценке здоровья команды. Оказалось, что операционные метрики описывают процесс, но не дают понимания реального состояния взаимодействия и доверия внутри команды.
Я Светлана Болсуновская, стратегический коуч-консультант в YADRO с 13-летним опытом в IT, помогаю командам и лидерам развиваться. В статье расскажу, зачем мы занялись темой здоровья команд, почему готовые Agile-опросники нам не подошли и поделюсь чек-листом для самостоятельной диагностики.
Как выглядела команда до изменений
В департаменте телекома были команды по 7–12 человек. Они самостоятельно выстраивали процессы оценки: одни собирали фреймворк, подобный Scrum, другие работали без фреймворков. Ролевая модель в командах была выстроена в виде «триады» лидерский ролей — Agile team lead (aka Scrum master для Scrum фреймворка), component product owner и линейный руководитель.
Команды организовали в департаменте по каждому компоненту ролевой модели, конечная продуктовая ценность создавалась через интегрированные усилия многих команд, координация которых происходила в «виртуальном» стриме.
В течение трех лет компания быстро росла: количество команд увеличилось примерно с 20 до 100+. Команды делились, создавались новые, состав постоянно менялся.
На уровне всего дивизиона мы выстраивали единое целеполагание, квартальную каденцию и релизы, итеративно-инкрементальный подход к созданию продукта, единые механизмы инспекции и адаптации на уровне команд и стримов. В конце каждого квартала вместе подводили итоги и обсуждали результаты. При этом каждая команда шла к общему результату своим способом.
Какую задачу мы решали
Совместно с руководителями дивизиона мы задались вопросом — как в нашем контексте мы будем оценивать состояние и здоровье команд, чтобы оперативно понимать, где сейчас красные области, которые требуют внимания. А также какой отклик в командах получают внедряемые системные процессные изменения.
Когда команды растут, появляются новые, реорганизуются, очень легко потерять ощущение реального положения дел. Мне хотелось найти такой формат, который позволил бы одновременно:
сохранить голос команды,
не превратить оценку в формальную отчетность,
получить обобщенное понимание, что с нами происходит.
Отдельной задачей со звездочкой в этом треке было вытащить команды из рутины. Большая часть командной жизни обычно проходит в режиме «срочно», «к следующему релизу», «надо успеть». В этом потоке редко появляется возможность отрефлексировать свою работу. Ретроспективы частично закрывали эту потребность, но в большей степени были привязаны к конкретному периоду и проектам. Я видела необходимость дать командам время, чтобы увидеть свою работы как бы с высоты птичьего полета.
Мы пришли к выводу, что не сможем использовать готовые Agile-опросники: они рассчитаны на кросс-функциональные команды, а у нас большинство команд состоит из специалистов одного профиля. Их структура определяется не ролями, а уровнями и компонентами архитектуры продукта. В итоге значительная часть стандартных вопросов для нас не имела смысла.
Так появилась идея попробовать собрать наш собственный инструмент оценки здоровья команд — health check, как способ осознанного разговора.
Health check — это модель оценки команд, позволяющая понять положение дел в команде (по сути здоровье команды), в формате общей встречи с голосованием по определенному набору индикаторов. В этом подходе команда самостоятельно оценивает себя в безопасной и комфортной среде.
По каким признакам оценивать здоровье команды
Первый же вопрос в создании собственной модели оказался не самым простым: по каким критериям мы определяем здоровье команды.
Мы начали с широкого взгляда без привязки к конкретным фреймворкам или ролям. Так мы сделали первую версию модели из 11 областей, которые казались нам базовыми:
командная коммуникация и встречи,
качество,
непр��рывное улучшение,
end-to-end результат,
ответственность,
инженерная культура,
атмосфера в команде,
работа с продуктом,
поддержка и ресурсы,
роли и компетенции,
взаимодействие внутри команды и с внешним контуром.
Для каждой области мы описали простые индикаторы состояния — утверждения, с которыми команда могла согласиться или нет.
Для оценки мы выбрали максимально простой формат — светофор:
зеленый — все хорошо,
желтый — есть вопросы,
красный — явная проблема.
Важно: это не индивидуальный опрос. Для определения здоровья команды нужна не сумма личных мнений, а общая позиция, к которой команда приходит в обсуждении.
Уже в первых запусках стало понятно, что 11 областей — это слишком много: темы пересекались, фокус терялся. Мы сократили модель до 8 областей, оставив только то, что давало реальный сигнал.
Как может проходить сессия оценки здоровья команды
Команды сами выбирали удобное время, формат (онлайн или офлайн), договаривались с фасилитатором и проводили сессию. Ниже — план действий, на который можно ориентироваться.
1. Начинайте с рамки и ожиданий.
Сразу проговаривайте, что health check — это не ретроспектива спринта, не оценка эффективности людей и не способ сравнивать команды между собой. Сделайте фокус на разговоре о состоянии команды на более длительную перспективу и договоритесь о безопасном пространстве для обсуждения.
2. Проводите health check как отдельную сессию.
Лучше выделять под health check отдельную встречу, а не пытаться встроить его в повторяющиеся митинги. Оптимальная длительность — до двух часов. Меньше — не хватает глубины, больше — сложно удерживать фокус.
3. Используйте внешнего фасилитатора.
Если есть возможность, сессию лучше проводить с внешним фасилитатором — человеком не из команды (например, лидером другой команды). Это позволяет снять нагрузку управления процессом с участников и избежать смешения ролей. Если фасилитатор — член команды, важно заранее договориться, в какой момент он ведет процесс, а в какой участвует в обсуждение наравне с остальными.
4. Подготовьте материалы.
Параллельно подготовьте и актуализируйте все материалы: шаблоны, чек-листы, инструкции, примеры заполнения. Нужно, чтобы у фасилитаторов и команд не возникало вопросов уровня «куда это писать» или «в каком виде сдавать результат».
5. Начинайте с индивидуальной оценки.
Давайте участникам возможность сначала самостоятельно оценить состояние по каждому индикатору. Формат не принципиален — онлайн-доска, опрос или стикеры на флипчарте. Важно, чтобы высказался каждый член команды, а не только самые активные.
6. Обсуждайте расхождения, а не средние значения.
Не стремитесь посчитать «средний цвет». Самая большая ценность health check — в обсуждении различий восприятия. Фокусируйтесь на вопросах: почему мы видим это по-разному и к какой общей позиции готовы прийти как команда.
7. Давайте команде выбрать глубину обсуждения.
Не навязывайте единый сценарий. В одних случаях полезно пройтись по всем областям, в других — сфокусироваться только на желтых и красных зонах. Команда лучше понимает, где сейчас нужен разговор.
8. Фиксируйте фокусы внимания, а не список проблем.
Health check сам по себе ничего не чинит. Его задача — подсветить состояние. В финале сессии команда должна договориться, с чем она готова работать дальше и что возьмет в фокус на следующий период — до следующей оценки через полгода.
9. Завершайте сессию короткой рефлексией формата.
Выделите несколько минут на обратную связь: что было полезно, что можно улучшить. Это помогает адаптировать формат под команду и не превращать health check в «неживую» процедуру.
После каждой сессии результаты необходимо зафиксировать в шаблонах и сформировать в двух видах: подробный отчет для самой команды и агрегированная, обезличенная картина по всем командам.
ROTI — это Return on Time Invested, то есть отдача от вложенного времени. В контексте health check (ретроспектив, встреч, процессов в команде) ROTI используют как быстрый индикатор полезности.
Результаты агрегируются каждые шесть месяцев и анализируются на уровне дивизиона, чтобы увидеть повторяющиеся зоны роста и системные проблемы. Команды забирают свои фокусы в операционную работу, а через полгода health check повторяется для оценки динамики.
Мы подготовили чек-лист для внедрения health check в ваших компаниях.
Недостатки первой версии health check
После двух–трех запусков стало понятно, что первая версия health check начала упираться в ограничения:
Разная интерпретация светофора. Команды по-разному понимали, что считать «зеленым», «желтым» и «красным», из-за чего результаты теряли сопоставимость.
Эффект «позеленения» самооценки. При неизменной планке со временем команды начинали оценивать себя все выше, и инструмент переставал подсвечивать зоны роста.
Отсутствие картины по системным паттернам и проблемам. Светофор фиксировал наличие проблем на уровне команд, но не помогал понять их причины и также не показывал системные паттерны на уровне организации.
Слабая масштабируемость. Формат требовал значительных временных затрат на проведение и агрегацию, что делало его дорогим на бол��шом количестве команд.
Падающая ценность повторных запусков. С каждым новым циклом инструмент приносил все меньше новых инсайтов и все больше повторял уже известную картину.
В итоге стало ясно, что проблема в самой модели: она больше не отражает реальность и требует пересборки, а не косметических правок.
Дисклеймер
Важно сказать, что классический health check сам по себе не плохой инструмент. В ряде случаев он может быть вполне полезен и достаточен. Например, если вы:
Только начинаете работать с командной рефлексией и хотите создать безопасное пространство для разговора.
Запускаете новые команды и вам важно быстро снять общее ощущение состояния.
Работаете с небольшим количеством команд и не нуждаетесь в глубокой аналитике.
Хотите сфокусироваться прежде всего на взаимодействии, договоренностях и базовой командной гигиене.
В таком контексте health check может дать ценность и стать хорошей точкой входа.
Однако есть и другие ситуации:
Организация растет и команд становится много.
Важно связать ощущения команды с реальными результатами delivery и качества.
Требуется регулярный, повторяющийся формат, встроенный в рабочую каденцию.
Необходимо видеть динамику и системные проблемы на уровне всей организации, а не только отдельных команд.
От инструмента ожидаются управленческие решения, а не просто «срез настроения».
В них я рекомендую опираться не на отдельный health check, а на практику, в которой оценка состояния команды становится частью более широкого разговора о результатах и способе работы.
Что делать, когда health check не работает
Для нового инструмента стало критично связать субъективную оценку команд с фактическими данными по поставке (delivery) и качеству — то есть с тем, насколько команда выполняет взятые на себя обязательства по срокам и объему работ и как это влияет на результат: стабильность, количество дефектов и необходимость переделок. При этом сам инструмент перестали рассматривать как самоцель, он стал лишь одним из источников данных для принятия решений.
Так произошел сдвиг от health check как отдельного опроса к практике регулярной инспекции и адаптации.
На старте мы зафиксировали новое целеполагание. Мы договорились, что:
инструмент должен быть связан с результатами и delivery,
он должен встраиваться в существующую командную рутину,
он должен быть понятен и применим для разных типов команд,
он должен помогать поднимать системные проблемы, а не только командные.
В начале 2025 года мы честно сказали коллегам: «Давайте жить по-другому, с опорой на текущую реальность и потребность». Мы не называли это улучшенной версией health check. Мы говорили, что это новый формат работы — квартальная инспекция и адаптация, в которой оценка здоровья команды становится не целью, а частью более широкого разговора о результатах и методах работы.
Квартальный Inspect & Adapt
В новой версии мы встроили оценку состояния команды в квартальные ретроспективы. Мы зафиксировали, что такие ретроспективы — обязательная часть командной жизни, и договорились о двух связанных частях встречи:
заполнение и анализ командного радара,
оценка результатов команды за квартал и адаптация (Inspect & Adapt).
Главным вопросом стало совпадение ощущений команды с фактическими результатами и обсуждение расхождений без поиска виноватых.
Командный Радар (Team Radar)
Радар сохранил идею самооценки и превратился в инструмент навигации, помогающий выбрать фокус встречи: либо углубиться в тему поставки, либо в качество взаимодействия и сотрудничества в команде.
Если health check был самостоятельным инструментом оценки состояния команды и заканчивался фиксацией проблем и фокусов, то радар стал лишь первым шагом более широкой практики Inspect & Adapt.
Вместо светофора перешли к шкале 1–10 с явными расшифровками, что снизило разночтения и добавило общие ориентиры. Появилась и опция not applicable, позволившая честно отмечать вопросы, которые не относятся к типу команды или находятся вне зоны ее ответственности. В итоге модель стала компактнее, гибче и практичнее — инструментом для разговора не абстрактно о «здоровье», а о способности команды планировать, выполнять и достигать результата.
Что измеряем в Team Radar
Пересобирая модель, мы сознательно отказались от попытки «измерять все» и сузили фокус до четырех ключевых блоков, отражающих способность команды стабильно да��ать результат:
Планирование (Planning) выделили как отдельный фокус — про цели, связку с ценностью и реалистичность планов.
Реализация (Execution) — про движение по плану и управляемость работы.
Поставка (Delivery) — про качество, объем и предсказуемость результата с опорой на факты.
Блок Люди (People) упростили, оставив только то, что действительно влияет на работу команды: продуктивность и настрой команды, ответственность за результат, качество принятия решений.
Работа с данными и аналитикой
В новой версии мы сразу сделали ставку на цифры и динамику, а не на разовые срезы. Результаты оцифровали: вместо цветов команды ставят оценки по шкале 1–10, которые автоматически визуализируются и позволяют считать средние значения, смотреть динамику и искать отклонения.
Мы также перешли к единому цифровому хранилищу в простом табличном формате, что убрало ручную агрегацию и дало возможность анализировать данные на уровне команд, департаментов и всей организации. Главным инсайтом стала динамика: она показала, где есть развитие, а где команды застревают.
По результатам радара мы искали не только зоны для улучшения, но и те сильные стороны, которые важно зафиксировать и масштабировать.
Самые высокие оценки команда дала блоку People, а также направлениям Execution. Это говорит о том, что у нас сильная командная атмосфера, высокий уровень доверия и качественная коммуникация, а также умение доводить задачи до результата и видеть ценность своей работы. У нас сформировалась безопасная среда, где можно обсуждать сложности, предлагать инициативы и вместе искать решения.
Дополнительно мы начали группировать командные action-планы и системные проблемы, что позволило увидеть повторяющиеся паттерны и реальные организационные узкие места.
Action-планы и уровни ответственности
В новой модели стало принципиально важно, чтобы Inspect & Adapt заканчивался не оценкой, а конкретными решениями. Поэтому по итогам каждой сессии команды формируют action-планы и сразу разделяют их по уровням ответственности.
Командный уровень включает то, на что команда может повлиять сама, и эти действия сразу уходят в операционную работу. Межкомандный уровень покрывает вопросы зависимостей и договоренностей с соседними командами и фиксируется в виде конкретных шагов. Департаментский и дивизионный уровни собирают системные проблемы, которые команды не могут решить самостоятельно, но формулируют их как четкие запросы, а не абстрактные жалобы.
В результате появился прозрачный бэклог системных проблем, сформированный самими командами. Он приоритизируется, отслеживается и даже в случае отказа от изменений дает командам ясность. На уровне команды этим занимается Agile team leader, на уровне департамента — линейный руководитель.
Action-планы стали механизмом распределения ответственности, а Inspect & Adapt — инструментом реальных изменений, а не разговора про ощущения. О том, как принимать решения в команде, я писала в этой статье.
Что в итоге получилось
После нескольких кварталов работы новой модели Inspect & Adapt стало видно, что изменения произошли не только на бумаге. За счет встраивания в существующую каденцию и отказа от обязательных внешних фасилитаторов заметно снизилась стоимость процесса, что было критично на большом масштабе.
Качество разговоров выросло: обсуждения стали более приземленными, с опорой и на ощущения, и на цифры, а команды лучше начали видеть связь между способом работы и результатом. Прояснились зоны ответственности — команды либо брали проблемы в свою работу, либо осознанно выносили их выше.
На уровне организации появилась прозрачная картина реальных командных фокусов и системных ограничений, а сами команды стали честнее в оценках, спокойнее в признании проблем и внимательнее к причинам, а не симптомам.
В итоге мы перешли к комбинированной модели: Inspect & Adapt сохранили на квартальной основе, а радар стали провод��ть раз в полгода. Параллельно мы зафиксировали, что инструмент не является законченным, он должен регулярно эволюционировать. Если подход перестает давать новую информацию, не влияет на фокус обсуждений, его нужно упрощать или убирать.
Мои рекомендации для тех, кто хочет внедрить эти практики себе в команду:
Начинать стоит с цели, а не с инструмента: без понимания, какие решения вы хотите принимать, любой формат быстро станет формальностью.
Начинать с минимально достаточной версии и развивать ее итеративно, а не пытаться измерить все сразу.
Давать инструменту время: несколько циклов нужны, чтобы он начал работать по-настоящему.
Заранее готовить чек-листы, правила и инфраструктуру, чтобы процесс мог самоорганизоваться.
Не бояться системных проблем и уметь с ними работать.
И наконец, не пытаться вылечить все сразу, укрепление здоровья команд — это процесс. Если инструмент помогает повышать осознанность и качество решений шаг за шагом, значит, он выполняет свою задачу.
Оглядываясь на весь путь, хочу отметить, что итоговый результат стал не следствием правильного инструмента, а результатом долгого эволюционного процесса с пробами, ошибками и пересмотрами. Командам и дивизиону в целом понадобилось несколько лет, чтобы научиться говорить о своей работе и воспринимать обратную связь без угрозы.
