Оригинальная статья: Squad Health Check model – visualizing what to improve.
Перевод с английского выполнен Дарьей Алымовой.
Примечание:В оригинальной статье используется термин “отряд” (англ.: squad). Spotify применяет этот термин как синоним к "команде" - небольшой, многофункциональной, самоорганизующейся единице устройства компании. В данной статье мы используем привычный термин "команда". См. о модели Spotify и их терминологии.
Что такое модель проверки здоровья команды?
Многие компании экспериментируют с методами измерения и визуализации здоровья своих команд. Такие методы обычно называются «моделями зрелости» и предполагают некоторую прогрессию путем прохождения различных уровней.
Данные типы моделей обычно имеют благое намерение. Например, руководители или коучи в крупных организациях хотят понять, где они должны сосредоточить свои усилия по улучшению, как выявить системные проблемы и помочь командам стать более сознательными, чтобы последние тоже могли сфокусироваться на улучшении.
Мы предпочитаем использовать другие термины, такие как «модель проверки здоровья», потому что «зрелость» звучит немного ... ну .... высокомерно. Кроме того, большинство наших моделей не связаны с прохождением различных уровней, а основная аудитория - это сама команда, а не менеджмент.
Работа по улучшению организационной деятельности - это во многом игра в угадывание (откуда вы знаете, что нужно улучшить, и как вы узнаете, происходит ли улучшение?). Системный подход с четкой визуализацией может уменьшить количество догадок.
Хорошо, но действительно ли такие модели работают?
Как когда. Иногда такая модель может быть очень полезной. Иногда это скорее «ну так»: люди послушно проводят воркшопы, опросы или что-нибудь еще, а затем данные игнорируются.
Остерегайтесь! В некоторых компаниях мы видели, как такие модели превращаются в монстра, системный инструмент угнетения, вызывающий субоптимизацию и страх, поскольку менеджеры используют «модель зрелости», чтобы судить команды и настраивать их друг против друга, а команды скрывают свои проблемы, чтобы хорошо выглядеть. Некрасивая картина!
Вот радикально обобщенная круговая диаграмма «шанс на успех», основанная на том, что мы видели до сих пор в разных компаниях:
Однако, хотя потенциальный ущерб хуже потенциального выигрыша, потенциальный выигрыш СУЩЕСТВУЕТ, и есть способы избежать сценария бедствия.
В Spotify мы тщательно экспериментировали с этим в течение нескольких лет и нашли несколько способов, которые работают достаточно хорошо (т.е. приносят больше выгоды, чем боли). В лучшем случае они приносят пользу, в худшем случае - ну так, и до сих пор никогда не приводили к катастрофе. Мы представили эту модель проверки здоровья нескольким другим компаниям и услышали об их аналогичных результатах, поэтому мы решили, что пришло время написать статью.
Для кого создана модель проверки здоровья?
При проверке здоровья команды есть две заинтересованных стороны:
Сама команда. Обсуждая различные показатели здоровья, команда осознает, что работает, а что нет. Широкий диапазон вопросов помогает расширить перспективы. Возможно, они хорошо понимали проблемы с качеством кода, но совсем не думали о ценности для клиента или о том, насколько быстро они учатся. Это также обеспечивает сбалансированный подход, показывающий как хорошие вещи, так и болевые точки.
Люди, поддерживающие команду. Менеджеры и тренеры, которые работают вне (или частично за пределами) команды, получают краткий обзор, что работает, а что нет. Они также могут видеть шаблоны по нескольким командам. Если у вас десятки команд и вы не можете говорить со всеми обо всем, визуальное резюме, подобное этому, поможет вам разобраться, как потратить свое время, с кем вам поговорить и о чем.
Первым шагом в решении проблемы является ее осознание. И этот вид визуализации затрудняет для всех игнорирование проблемы.
Как мы это делаем в Spotify
В общем-то мы делаем три вещи:
Проводим воркшопы, в которых члены команды обсуждают и оценивают текущую ситуацию с разных точек зрения (качество, удовольствие, ценность и т. д.).
Создаем графическое резюме результата.
Используем данные, чтобы помочь командам улучшиться.
У нас есть несколько вариантов, один из которых просто называется «Модель проверки здоровья команды», у других названия вроде «Свободная Agile игра» и «Ежеквартальная рефлексия» (возможно, позже будет статья на эту тему). Модель проверки здоровья является улучшенной версией старых квартальных опросов «автономных команд», упомянутых в статье 2012 года «Масштабирование Agile @ Spotify» (англ.).
Вот реальный пример результата проверки здоровья для одного племени:
Это показывает, как 7 разных команд в племени видят свою собственную ситуацию. Цвет - текущее состояние (зеленый = хорошо, желтый = некоторые проблемы, красный = очень плохо). Стрелка - это тенденция (данный аспект вообще улучшается или ухудшается?).
Посмотрите на это минутку, и вы начнете видеть интересные вещи:
Если просканировать каждый столбец, видно некоторые существенные различия между командами. Команда 4 почти всем довольна. У команды 2 есть много проблем, но большинство аспектов улучшается.
Если просканировать каждую строку, видно системные шаблоны. Каждая команда получает удовольствие (и это даже улучшается)! Мотивация, по-видимому, не является проблемой. Но процесс релиза является проблематичным, а база кода в целом плоха. Со временем это, вероятно, также уменьшит уровень удовлетворения.
Если просканировать общий снимок, видно, что почти каждая стрелка устремлена вверх, на всем рисунке только две стрелки направлены вниз. Это означает, что процесс улучшения (самый важный процесс из всех), кажется, работает.
Это, конечно, просто аппроксимация реальности («Все модели ошибочны, но некоторые из них полезны» - Джордж Бокс). Поэтому перед тем, как принимать меры, стоит дважды перепроверить факты.
Действительно ли команда 4 в такой отличной форме, или они просто излишне оптимистичны и не видят своих проблем? Большинство команд считают, что они приносят пользу своим клиентам, но откуда они знают? Это основано на принятии желаемого за действительное или реальной обратной связи с клиентами?
В этом конкретном случае команда 4 была фактически сформирована всего за неделю до проверки здоровья, и они были определенно на этапе формирования («в медовом месяце»). Поэтому и команда 2, и команда 4 нуждались в большой поддержке.
Аспект «Легко релизить», безусловно, таил серьезную проблему, и это привело к большей сфокусированности на таких вещах, как непрерывная поставка, и впоследствии мы увидели там хороший прогресс.
Обратите внимание, что это модель самооценки, основанная на честности и субъективных мнениях людей в командах. Таким образом, она работает только в среде с высоким доверием, где люди доверяют своим менеджерам и коллегам действовать в своих интересах. С данными легко играть, поэтому ключевой является уверенность, что для этого нет никаких стимулов.
К счастью, Spotify – среда с достаточно высоким доверием, где менеджеры и тренеры с осторожностью показывают, что это инструмент поддержки, а не инструмент оценки.
Как мы собираем данные
Мы обнаружили, что онлайн-опросы отстойно работают для данного типа проблем. В основном потому, что они прерывают разговор, а в нем заключена главная ценность. Члены команды получают озарения во время обсуждения, и тренер получает озарения, как эффективно помочь командам. Чистые данные приоткрывают лишь кусочек общей картины, который может ввести в заблуждение.
Таким образом, мы (обычно Agile коучи) организуем воркшопы с командами, способствуя разговору лицом к лицу о различных показателях здоровья команды. Обычно достаточно одного или двух часов.
Чтобы облегчить задачу, у нас есть физическая колода «Великолепных Карт», в которой каждая карта - один индикатор здоровья с «Примером великолепия» и «Примером отстоя».
Колода обычно состоит из 10 карт, вот пример полной колоды:
| Аспект | Пример великолепия | Пример отстоя |
| :----- |:----- | :-----|
| Легко релизить | Релизить продукт просто, безопасно, безболезненно, и большая часть активностей автоматизирована. | Релизить продукт рискованно, болезненно, требует большого количества ручной работы, и это длится вечно. |
| Приемлемый процесс | Наш способ работы идеально нам подходит | Наш способ работы - отстой || Техническое качество (состояние базы кода) | Мы гордимся качеством нашего кода! Он чист, легко читается и отлично покрыт тестами. | Наш код - куча навоза, а технический долг вышел из-под контроля |
| Ценность | Мы поставляем крутые штуки! Мы гордимся этим, и заинтересованные стороны действительно счастливы. | Мы поставляем дерьмо. Нам стыдно поставлять это. Заинтересованные стороны ненавидят нас. |
| Скорость | Мы делаем вещи очень быстро. Никакого ожидания, никаких задержек. | Ощущение, что мы никогда ничего не заканчиваем. Мы продолжаем застревать или прерываться. Истории продолжают стопориться из-за зависимостей. |
| Миссия | Мы четко осознаем, почему мы здесь, и мы от этого в восторге! | Мы понятия не имеем, почему мы здесь, нет ни общей картины, ни фокуса. Наша так называемая миссия совершенно неясна и скучна. |
| Весело | Мы любим работать, и нам очень нравится работать вместе | КОШМААААР |
| Обучение | Мы все время изучаем много интересного! | У нас никогда нет времени учиться |
| Поддержка | Мы всегда получаем огромную поддержку и помощь, когда мы просим об этом! | Мы продолжаем застревать, потому что мы не можем получить поддержку и помощь, о которых мы просим. |
| Пешки или игроки | Мы контролируем нашу судьбу! Мы решаем, что строить и как это строить. | Мы просто пешки в шахматной игре, мы не имеем влияния на то, что мы строим, и на то, как мы это строим. |
По каждому вопросу команде предлагается обсудить, находятся ли они ближе к «великолепию» или ближе к «отстою», и мы используем базовые методы воркшопов (голосование точками и т. д.), чтобы помочь им достичь консенсуса относительно того, какой цвет выбрать для этого индикатора, и какова тенденция (стабильная, улучшающаяся или ухудшающаяся).
Нам нравится сохранять три уровня (зеленый / желтый / красный), чтобы сохранить простоту. Точное определение цветов будет отличаться, но что-то вроде этого:
Зеленый цвет не обязательно означает, что все идеально. Это просто означает, что команда довольна этим и не видит существенной необходимости в улучшении прямо сейчас.
Желтый означает, что есть некоторые важные проблемы, которые требуют решения, но это не катастрофа.
Красный означает, что в данном аспекте все действительно отстойно и нуждается в улучшении.
Да, это субъективные данные. Теоретически команда может выбрать достоверные данные (время цикла, количество дефектов, скорость и т. д.), но мало кто это делает. Потому что даже достоверные данные команда должна интерпретировать и решать, означают ли они, что есть проблема, или нет. Так что в конце концов все субъективно. Если что-то похоже на проблему, это само по себе является проблемой.
Иногда мы объединяем это с ретроспективами, например, голосуем на одной карте и принимаем решение о действиях по улучшению этого аспекта.
Какие вопросы задать?
Если вы посмотрите на различные примеры выше, вы увидите, что на практике вопросы немного меняются.
Основные принципы:
Вопросы предназначены для того, чтобы покрыть широкий спектр различных точек зрения.
Эти вопросы - всего лишь отправная точка, выбор по умолчанию. Команды могут свободно удалять, добавлять или изменять вопросы в соответствии с тем, что, по их мнению, имеет значение.
Попытайтесь ограничиться 10 вопросами или около того. Если у нас есть больше вопросов, некоторые из них, вероятно, слишком перекликаются и могут быть удалены.
Мы задаем вопросы об окружении, в котором работает команда, а не о конкретном результате (например, скорости). Это делает опрос менее угрожающим и укрепляет мнение, что опрос делается для поддержки и улучшения, а не для вынесения приговора.
Наше предположение (истинное или нет) состоит в том, что по своей природе команда хочет преуспеть и будет действовать настолько хорошо, насколько позволяют обстоятельства.
Как часто мы измеряем здоровье команды?
Как уже упоминалось, в игре есть несколько разных моделей, варианты сильно разнятся. Мы действительно не сходились ни на одном конкретном «идеальном временном интервале» для данных активностей (и, вероятно, никогда этого не сделаем).
Однако раз в квартал кажется хорошей отправной точкой. Кажется, раз в месяц - это слишком часто (люди устают от этого, и данные не изменяются достаточно быстро, чтобы оправдать подобную опцию). Раз в 2 года - это, кажется, слишком редко (слишком много происходит за этот период). Но, опять же, варианты разнятся.
Подведем итоги - все, что нужно иметь в виду, если вы собираетесь это делать.
Модель, подобная этой, МОЖЕТ помочь повысить эффективность ваших усилий по улучшению. Но это может также полностью испортить вашу культуру, если использовать ее ненадлежащим образом! Так что будьте осторожны.
Вот несколько рекомендаций, как повысить вероятность успеха:
Четко осознайте свои мотивы внедрения модели. Мотивом должно быть улучшение, а не вынесение приговора.
Собирайте данные прежде всего через личную связь, а не путем онлайн-опросов. Процесс сбора данных должен быть интересным и весёлым.
Привлекайте команды, чтобы решить, как применять модель, и позволяйте им изменять ее по своему усмотрению.
Принятие командой имеет большее значение, чем согласованность данных. Если команда A выбирает немного другой набор вопросов, чем команда Б, это нормально (хотя сводная картина будет немного беспорядочной).
Убедитесь, что нет никакого стимула, чтобы играть с данными. Не должно быть причин, по которым команда захочет «хорошо выглядеть».
Найдите простой способ визуализации данных. Чем более очевидной и интуитивно понятной будет визуализация, тем вероятнее она будет использоваться.
Опасайтесь сравнения команд. Если команда A в основном зеленая, а команда Б в основном красная, это не означает, что команда A «лучше». Это также может означать, что команда A имеет более простой контекст или более оптимистичные прогнозы, или что команда Б более честна в своей борьбе. В любом случае, вероятно, команда Б нуждается в некоторой поддержке. Отношение менеджера должно быть «Как я могу помочь?», а не «Почему вы, ребята, хуже других?».
Отслеживайте прогресс. Задайте людям такие вопросы, как «Помогает ли вам эта модель?», «Если мы перестанем проводить проверки здоровья, вы будете по ним скучать?», «Как мы могли бы сделать эту модель более полезной?». Сама модель (и ваш способ ее применения) должны постоянно улучшаться.
Comments