Аналитика команды. Какие метрики используют наши продакты для планирования релизов (Игорь Филипьев)

Игорь Филипьев, Agile Coach, S7 Group

Друзья, всем привет!

Меня зовут Игорь Филипьев, я Agile Coach в группе компаний S7. В мои обязанности входит повышение эффективности продуктовых команд всей группы компаний S7. Я работаю в двух направлениях:

1. Повышение эффективности и профессионализма владельцев продуктов.
2. Повышение результативности команд разработки.

Еще у меня есть небольшой тренинговый бизнес. Я основатель и тренер в Школе Канбана Игоря Филипьева, провожу открытые тренинги по Канбану, повышения скиллы Скрам-мастеров, Agile-коучей, менеджеров проектов и менеджеров сервисов поставки.

Сегодня я расскажу вам, какие метрики используют владельцы продуктов для планирования сроков релизов и оценки продуктивности команд.

Две истории из жизни 

Как-то раз, примерно год назад, я наткнулся на дорожную карту одного из продуктов. Мне стало интересно, как владелец продукта прогнозировал сроки готовности фичей в этой карте. Я обратился к нему с этим вопросом и выяснил, что расчеты были произведены на основании его ощущений, когда и что будет готово. Это были не человеко-часы и даже не стори-поинты, а некий коммитмент веры, что мы успеем. “А что будет, если вы не успеете?” — спросил я. “В этом случае мы сдвинем сроки на следующий квартал” — был примерный ответ. 

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

Формулируем проблему 

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

Типичное решение 

Как обычно решается эта проблема? Когда владельцу продукта нужно составить дорожную карту продукта на год и спланировать релизы, он открывает свой любимый инструмент (обычно это диаграмма Гантта или поквартальная дорожная карта со списками фич) и использует следующие подходы:

1. Если он использует Скрам-фреймворк, то это может быть диаграмма сгорания с предварительной оценкой всего скоупа релиза в стори поинтах.
2. Если он менеджер проекта старой закалки, то это может быть оценка всего скоупа (например на квартал) в человеко-часах и планирование релизов исходя из количества рабочих дней в квартале.
3. Если он начинает квартал с новой командой и новым продуктом, то здесь обычно работает подход «Давайте начнем работать, поймем, какая у нас скорость, а там уже что-нибудь запланируем в релиз». То есть мы говорим о так называемой средней скорости команды, выраженной в каких-то единицах.  

Как вы уже заметили, во всех этих подходах для планирования долгосрочных релизов менеджеру продукта приходится опираться на точность оценки в условных единицах или человеко-часах, наличие выделенной кросс-функциональной команды (в идеальном случае), а также удачу и невероятный скилл переговорщика.

Недостатки типичного решения

Какие же недостатки типичного решения? 

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

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

Поэтому многие менеджеры используют некий упрощенный микс или наложение спринтов на диаграмму Гантта. Причем уже не так важно, завершаются ли задачи за спринт или нет (скорее всего нет). Сам подход дает некоторое чувство контроля — не успели в этом, зато продвинулись к цели и к концу спринта понимаем, сколько еще осталось работы. А дальше от этого перестраиваем диаграмму Гантта и получаем новый (!) прогноз релиза.

Ваше решение 

Я предлагаю другое решение. Для оценки результативности команд, построения дорожной карты и планирования релизов можно использовать целый ряд других метрик, позволяющих оценить возможности вашей команды и использовать их максимально результативно. И именно об этом мы сегодня и поговорим. 

Системное и клиентское время выполнения

Довольно понятная метрика. Основная сложность в ней — это понять, где у вас начинается отсчет времени выполнения и где заканчивается. Но как только вы с этим разберетесь (а вы обязательно разберетесь), дальше работе с метрикой становится делом техники. Собираем статистику по среднему времени выполнения конкретного типа работ (например, пользовательская история, хоть я их и не люблю), а также более рискованному сценарию времени выполнения (вероятность 85%) и получаем более надежный прогноз, когда ваши фичи будут готовы в команде и для клиента в среднем по времени и с более высокой вероятностью. 

Доказательство

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

Пропускная способность

Еще одна очень полезная метрика, которой пользуются наши владельцы продуктов. Она позволяет оценить возможности поставки вашей команды и понять, какое количество работы каждого типа ваша команда поставляет за неделю, месяц или квартал. Она очень похожа на скорость команды (то есть велосити), но есть одно маленькое отличие. Мы не привязываемся к спринту, а смотрим пропускную способность на любом отрезке времени.

Доказательство 

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

Накопительная диаграмма потока

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

Доказательство 

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

Другие полезные метрики

Кроме трех этих основных метрик есть еще несколько, которые тоже могут быть вам полезны:

• Ложный спрос
• Изначальное качество
• Блокеры и их влияние
• Соотношение количества приходящей работы к поставленной
• Эффективность потока
• И показатель отказа  

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

Зачем это вам

Вы наверно сейчас сидите и спрашиваете себя: “Зачем это мне? У меня есть скрам-мастер/проджект менеджер/тимлид. Пусть он занимается всеми этими метриками, а я буду развивать продукт!” 

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

Вывод о решении, мораль

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

Первое. Данные метрики помогают нашим продактам планировать более точные даты релизов и понимать возможности команды.

Второе. Не владеть знаниями о возможностях вашей команды — это всё равно что ехать на автомобиле или лететь на самолете без приборов. Вроде бы едет и летит, но ты не знаешь, можно ли обгонять и есть ли запас мощности? Данные метрики – это ваша приборная панель, которой вам так давно не хватало. 

Третье. Давать обещания на основе данных — подход прагматичного менеджера. Вы отвечаете за ваши слова, потому что они подкреплены статистикой, а не чувством веры, что всё получится. 

Четвертое. Использование этих метрик не требует от вас отказа от вашего подхода к разработке. Вы можете использовать Скрам, можете использовать любой другой подход – это ваше дело. Данные метрики отлично ложатся поверх любого подхода и дополняют вашу картину знаний о вашей команде.

Лирическая привязка к истории из п.1.

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

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

А владелец продукта из второй истории понял, что ему нужно сократить количество задач в работе минимум в два раза и выделить команде прозрачные 20% ресурсов под технические задачи, чтобы повысить скорость поставки, сфокусировать команду на задачах по разработке нового продукта и вернуться в «дорожную карту».

Понимание возможностей команды позволит и вам прогнозировать более точные даты релизов и давать максимально честные обещания пользователям, заказчикам и стейкхолдерам.   

А что думаете об этом? Насколько легко или наоборот сложно будет применить данные метрики в ваших командах? 

Задавайте вопросы, обсудим здесь на сцене и потом в кулуарах.

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

Обычно после того, как мы научились всё считать, возникает следующая проблема: как нам улучшить показатели?

Это — тема следующего выступления в рамках ProductSence. Приходите, продолжение следует.