Как прошла Tinkoff Agile Conference 2021

22 октября прошла Tinkoff Agile Conference 2021 — ежегодная конференция про развитие команд и инженерные подходы к управлению. Онлайн ее посмотрели 6000 зрителей, офлайн участвовали еще 250. Главное условие очного присутствия — пожертвование в фонд борьбы с лейкемией. Благодаря участникам мы собрали и отправили на благотворительность 500 тысяч рублей.

Все выступления о методах управления работой, метриках эффективности и привлечении талантов можно посмотреть в записи трансляции на «Ютубе».

А в этой статье расскажем о двух докладах. Из них вы узнаете, как спикеру удалось ускорить движение задач по доске в 2,5 раза без лишних усилий. А также почему метрики могут обмануть и что значимо в анализе эффективности работы.

Исходные данные. 4 команды, 54 человека. Это четыре разные бизнес-линии, объединенные только мобильным приложением — каналом, через который они поставляют свои решения.

В процессах все по классике:

— доска с задачами в Jira со статусами;

— статусы Staged и Hold — «помойка», куда скидываются заблокированные или забытые задачи;

— отсутствие визуализации блокеров;

— движение задач вправо-влево по доске;

— митинг с фокусом на людях — каждый рассказывал, что делал вчера, сегодня и что будет делать завтра.

Какие были проблемы в командах

1. Перегрузка на некоторых этапах. Например, тестирование зашивается, а разработка ничего не делает, и наоборот, разработка загружена, а тестирование отдыхает.
2. Длительный Lead Time (LT).
3. Как следствие, недовольство бизнеса всей этой ситуацией.
4. Фокус на локальной функции. Например, тестировщики занимались только тестированием, и их не волновали проблемы разработки, системного и бизнес-анализа — и наоборот.

Если смотреть на метрики, то в начале пути они выглядели так:

Что изменили

1. Начали визуализировать блокеры на доске не за счет статусов Staged/Hold, а с помощью флажка. Также добавили отображение количества дней, которое задача провела в статусе.

2. Поменяли подход к митингам, сместив фокус с людей на задачи. На встречах задавали вопрос: что должно произойти, чтобы задача перешла на следующий этап? При обсуждении шли по доске справа налево и сверху вниз.

3. Изменили восприятие доски. Изначально ее воспринимали как отражение текущего состояния задачи: на ревью, в разработке, тестировании, процессе ожидания.

Я предложил командам относиться к доске как к прогрессу и визуализации по накоплению знаний. Пока задача в левой части доски, мы знаем о ней немного. Но чем дальше вправо она движется, тем больше знаний о ней накапливается. Это легко объясняет, почему не нужно двигать задачу назад: нельзя внезапно забыть все, что мы о ней знаем.

Поэтому при блокировке задачи на нее вешается флажок, а статус остается тем же. Так мы сохраняем прогресс накопленных знаний, но в то же время показываем, что с задачей что-то не так.

4. Избавились от статусов Staged/Hold, убрав возможность для команды следовать старым привычкам.

5. Ввели циклы обратной связи. У команд появились две обязательные встречи в рамках обратной связи: обзор поставки и стандартная ретроспектива. На обзоре поставки мы обсуждаем не вообще все проблемы команды, а только конкретные задачи и возникшие аномалии. Например, почему задача была в работе 150 дней или почему она имела 25 багов при приемочном тестировании.

Результаты. Митинг с фокусом на задачи, визуализация и циклы обратной связи привели к тому, что в среднем задачи стали двигаться по доске быстрее в 2—2,5 раза. При этом мы не меняли контекст команды, количество разработчиков и подход к декомпозиции задач, а к изменениям приложили минимальные усилия.

Также мы ввели WIP-лимиты. Они помогли сделать поставку более предсказуемой, а поток работы — равномерным. В результате 95-й перцентиль стал ближе к среднему значению, как в примере ниже:

Это говорит о том, что команда стала работать предсказуемее: с вероятностью 95% мы можем сказать заказчику, что его задачу мы сделаем за 48 дней. Кажется, что много, но раньше было 105.

Итоги и планы на будущее

1. Нагрузка стала равномерной.
2. Lead Time сократился.
3. Недовольство бизнеса уменьшилось.
4. Команда стала фокусироваться на ценности продукта, а не на своей отдельной функции.
5. Система стала самоподдерживающейся — команды проводят встречи самостоятельно, а я только иногда о них напоминаю и поддерживаю активность.

В будущем планируем визуализировать весь E2E-процесс, используя такие же практики, те же правила и в других бизнес-направлениях.Посмотреть выступление полностью можно в записи на «Ютубе».

В какой-то момент в процессе разработки ПО появляются менеджеры разных ролей, которые задаются вопросом: как оценить эффективность команд разработки? Они решают сделать дашборд с метриками процесса и качества. Первые — это время и периодичность поставки. Вторые — наличие ошибок.Создается дашборд с метриками, где есть зеленые, желтые и красные сигналы светофора:

С этого момента начинается гонка за зеленым сигналом как признаком хорошей работы. Но он не всегда означает высокий результат: метрики процесса могут обмануть — покажу дальше на примерах.

Пример 1. Lead Time — время поставки. Оно рассчитывается от момента взятия запроса в работу до поставки готового решения. Менеджеры ставят цель: время поставки — не более 30 дней.На этом скриншоте видно, что оно сократилось почти в два раза. Значит, цель выполнена:

Но если рассмотреть одну конкретную задачу, окажется, что она 20 недель пролежала в статусе бизнес-анализа, а затем ее за 20 секунд прогнали по остальным:

Из этого нельзя сделать вывод, хорошо или плохо работала команда: метрика некорректная. И таких данных в выборке на предыдущем графике — 50%.

Вывод: любая метрика строится на данных. База данных — это система ведения задач. Для корректного расчета нужны правила и культура ведения задач в системе.

Пример 2. Реперные точки. Для Lead Time реперные точки — это момент взятия запроса в работу и поставка готового решения.

Со второй точкой обычно проблем не бывает, а с первой возникают сложности: либо ее нет, либо она не явная. Разберемся, в какой момент появляется точка принятия обязательств.После того как формируется запрос, аналитики изучают его и описывают требования. Затем требования верифицируются: собирается команда разработки с продактами и решают, что требований достаточно. Когда команда разработки выбирает задачу в бэклог и формирует ожидания по поставке, появляется точка принятия обязательств, или Commitment Point от ИТ.

Явный Commitment Point — это когда заказчик и команда знают, что при выполнении определенных условий обязательства по поставке приняты. Если это потоковое ведение задач, то в трекере должен появиться статус, если скрам-команда — начаться спринт.

Вывод: для корректного расчета метрик нужно понять, что мы хотим считать, какие будут реперные точки для этих метрик, а затем занести реперные точки в систему ведения задач.

Пример 3. Время поставки и пропускная способность. Время поставки — это то, как долго разрабатывается решение. Пропускная способность — частота, с которой команда их выпускает. Мы хотим, чтобы разработка шла быстрее, — нужно сократить время поставки. Когда хотим чаще поставлять готовые решения, нужно увеличить пропускную способность.

Посмотрим на график динамики пропускной способности одной из команд:

Цель от менеджера: пропускная способность — более 45 задач в месяц. Смотрим на июль и август: команда стала производить больше.

Кажется, что цель выполнена, но на деле команда изменила подход к декомпозиции задач. Где раньше была одна задача, их стало от 2 до 4. А с точки зрения ценности и перформинга команды ничего не поменялось.

Вывод: одна метрика в вакууме не показательна. Нужно анализировать соотношение метрик.

Что делать, чтобы не быть обманутым

1. Настроить систему ведения задач и отметить там реперные точки.
2. Договориться о правилах работы и соблюдать их.
3. Анализировать каждое изменение метрики на дашборде, в том числе относительно друг друга.
4. Смотреть метрики в динамике.
5. Не гнаться за зеленым сигналом. Это индикатор здоровья команды, но не нужно ставить цели по снижению и росту тех или иных метрик.

Почему метрики процесса не показывают эффективность работы. Представим, что наши команды поставляют все быстро и качественно. Теперь сместим внимание на конечных пользователей и зададим вопрос: готовое решение удовлетворяет потребности ваших клиентов?

Первый сценарий: команды работают эффективно, но пользователи быстро и качественно получают не то, что им нужно.

Менеджеры довольны работой команды, но смотрят на метрики процесса без привязки к контексту. Но зачем контролировать процесс создания решения, если оно никому не нужно?

Второй сценарий: поставка решения не быстрая и с ошибками, менеджеры недовольны работой команды. Но пользователи получают то, в чем они заинтересованы, — их потребность удовлетворяется.

Конечно же, идеальный сценарий — это быстро и качественно поставлять то, что нужно пользователям.

Где реальная эффективность работы. Метрики процесса и качества — это индикатор здоровья команды. Они помогают выявить узкие места процесса, проверить гипотезы решения проблем. С ними работают скрам-мастера, тимлиды, руководители разработки.

Но когда мы говорим об эффективности работы, нужно смотреть не на то, как происходит разработка, а на то, что и кому мы поставляем. А это уже метрики продукта и бизнес-показатели. С этими данными работают владельцы продуктов, менеджеры продуктов, бизнес-заказчики.

Сначала мы смотрим на поставляемое решение и думаем: востребовано ли оно, будут ли его покупать? Это про поиск и поддержку Product Market Fit — продукта, обладающего ценностью для ЦА. Задача любого продукта — привлечь аудиторию, которая согласится купить предлагаемое решение ее проблемы. Если оно не будет соответствовать потребности клиента, то не будет продаж, а значит, и прибыли.

Общие выводы

1. Не гонитесь за зеленым сигналом.
2. Процессные метрики без контекста не имеют ценности.
3. Эффективность — это довольный клиент.

Проверьте себя: кто ваш клиент, какая у него проблема, удовлетворяет ли решение его потребностям и готов ли он за него платить. И только после этого улучшайте процесс поставки.

Посмотреть выступление полностью можно в записи на «Ютубе».