Привет, Хабр! Меня зовут Таисия Брезгина, я Enterprise Agile coach в МТС Web Services. У нас в компании выстроена система поддержки команд, и ее важная часть — регулярная диагностика. Мы используем много разных инструментов, для того чтобы выявлять слабые места и дисфункции и за счет их решения растить эффективность команд. Хочу поделиться инсайтами в работе своей небольшой команды скрам-мастеров и аджайл-коучей. Какие инструменты у нас действительно работают и почему важен комплексный и кастомизированный подход, а не бездумное внедрение инструментов и методов.
Инсайт 1. Все начинается с опросов, но они субъективны
Первый и самый очевидный инструмент для оценки командной «температуры» — это опросники. Agile-радары, health-check’и и другие их вариации. Их можно проводить анонимно, если в команде низкий уровень доверия, или открыто, если атмосфера позволяет. Это простой способ получить срез мнений.
Однако, как мы выяснили, у этого подхода есть фундаментальное ограничение. Опросники основаны на опросах, то есть могут быть недостаточно объективны. Чтобы прояснить, мы приносим результаты опроса на командную встречу и уточняем детали. Таким образом мы собираем фактуру, которая мешает командам работать.
Любой опрос — это повод начать диалог, а не истина в последней инстанции. Слепое доверие таким данным ведет к тому, что вместо реальных причин вы будете лечить только симптомы.
Инсайт 2. Наблюдения и анализ артефактов
Со временем мы выработали другой подход, который дополняет опросы. Начали системно смотреть командные встречи, сместив фокус с простого участия на фиксацию и анализ происходящего. Это дает гораздо больше объективной информации.
Наблюдение стоит начать с взаимодействий внутри команды: как люди общаются между собой, как принимают решения, на какие темы реагируют с напряжением, а что предпочитают обходить стороной.
Со временем у нас сформировался внутренний чек-лист, который помогает трезво оценить, как на самом деле живет команда. Туда вошли следующие вопросы:
Все ли в порядке с бэклогом? Актуален ли он, осмысленные ли в нем задачи и понимает ли команда, зачем делает каждую из них? Ответ «нет» на любой из этих вопросов — первый сигнал, что с целеполаганием беда.
Как реально проходят встречи? В одном кейсе команда уверенно ставила себе пятерки за церемонии, но дейли превращались в часовые отчеты перед тимлидом. Ни о какой синхронизации речи не шло — скорее о симптоме глубинной проблемы.
Что творится в таск-трекере и как выглядят производственные метрики? Для нас это ключ к командной гигиене. Если в Jira бардак, статусы обновляются по инерции, а задачи неделями висят в одном столбце — ни один график метрик не покажет правду.
Сюда же можно добавить анализ артефактов: есть ли в наличии Product Vision, стратегия продукта, измерение метрик продукта. Что происходит в бэклоге, связана ли приоритезация с реализацией стратегии продукта. Есть ли сформулированные гипотезы или фичи создаются на глазок, прокатит / не прокатит. Есть ли понимание у всех участников команды, что за продукт и для кого мы создаем.
Такой подход вскрывает реальное положение дел, а не то, как команде хотелось бы об этом думать.
Инсайт 3. Слабые места можно увидеть с помощью Value Stream Mapping
Когда метрики показывают наличие проблемы, возникает вопрос: а где именно процесс буксует? Например, в одном из наших кейсов Lead Time задачи растянулся на 79 дней, и стало очевидно, что без дополнительной диагностики не обойтись. В таких случаях поможет Value Stream Mapping (VSM) — схема, на которой виден весь путь задачи от идеи до релиза.
На нее накладываем реальные данные из Jira и смотрим, сколько дней задача в среднем проводит в каждом статусе. Уже на этом этапе становятся видны «заторы».
Далее мы с командой обсуждаем этапы. И смотрим, какие проблемы возникают, почему задачи так долго висят в ревью и что мешает тестированию. Это позволяет собрать качественную обратную связь и найти корень проблемы.
В некоторых случаях усложняем карту, разбивая ее на дорожки по типам задач: баги, техдолг и новые фичи. Тут часто выясняется, что затык происходит только с одним конкретным типом запросов, потому что для него не выстроены коммуникации или процесс согласования.
Инсайт 4. Нужно работать с аномалиями и всплесками
Когда у нас на руках все данные — опросы, наблюдения, метрики из Jira и карта потока, — получается вроде бы целостная картинка. Но сами по себе цифры ничего не меняют, поэтому важно понять, что с ними делать. Здесь помогает работа с аномалиями и всплесками.
Общий фон может выглядеть вполне прилично, но если копнуть глубже, там обязательно найдется что-то интересное. В одном из опросов, например, мы выяснили, что одному участнику команды со скрам-мастером работать было совершенно некомфортно, а другой, наоборот, поставил этому же взаимодействию максимальный балл. Такая полярность — повод поговорить с каждым отдельно и разобраться, откуда разница в восприятии.
Точно так же работают и позитивные всплески. Если вся команда выгорает, а кто-то один сохраняет высокий уровень мотивации, это ресурс, который нельзя игнорировать. Стоит выяснить, что именно поддерживает этого человека. Возможно, его опыт поможет найти решение для всей команды.
Любой всплеск — положительный или отрицательный — это точка роста. На такие сигналы можно реагировать двумя способами: устранить проблему до того, как она заденет всех, или масштабировать успешный опыт.
Инсайт 5. Визуализация причинно-следственных связей дает очень многое
Все, что происходит в команде и организации, имеет взаимосвязи, как в любой системе. Разные факторы переплетаются, влияют один на другой и приводят. Если вы находите закономерности — визуализируйте взаимосвязи, рисуйте историю на таймлайне и через это находите решения. Среди инструментов системного мышления есть целый набор инструментов, которые позволяют это делать: Cause loop diagramm, Айсберг, Behavior-over-time diagramm и прочее. Подойдет любой, главное не ограничиваться поверхностным анализом, это позволит найти наиболее ценное решение
По итогам одного или нескольких инструментов находим проблемы, из них находим точки роста и пишем план действий. Порой получается огромный майдмап и работа на полгода вперед. Это дает понимание, какие изменения мы планируем и зачем они нужны команде.
Рабочий подход к командной диагностике
На основе всех этих инсайтов у нас постепенно выработался свой подход. Он состоит из нескольких этапов, каждый из которых дополняет друг друга:
Опросы помогают запустить честный разговор.
Наблюдение, изучение артефактов и метрик показывает, как все устроено на самом деле.
Value Stream Mapping подсвечивает те места, где процесс буксует сильнее всего.
Работа с аномалиями и всплесками позволяет найти решение для всей команды.
Визуализация и выгрузка своих мыслей «на бумагу» дает больше, чем кажется на первый взгляд.
Каждый этап важен сам по себе, но в одиночку он мало что дает. Опрос без наблюдения легко уводит в сторону. Метрики без контекста превращаются в красивые графики, которые ничего не меняют. Только комбинация инструментов дает объемное понимание происходящего и позволяет принимать решения на основе фактов.
В конечном счете любая диагностика нужна не для того, чтобы сказать, как все плохо, а для поиска точек роста. И чем раньше сможем их найти, тем меньше потерь понесет команда и бизнес.
А какими инструментами для диагностики команд пользуетесь вы? Делитесь опытом в комментариях.