Павел Кондратьев

Руководитель проектов в ГК Юзтех

Всем привет, на связи снова Павел Кондратьев из ГК Юзтех. Я продолжаю работать в продуктовой команде по разработке b2b-приложений, и на горизонте прошедшего полугода мы с Заказчиком пришли к вопросам — как измерить производительность нашей команды и выявить слабые места в процессах, чтобы сделать разработку более эффективной?

Предлагаю познакомиться с нашим опытом по внедрению метрик измерения продуктивности команды.

1. Суть проблемы или отличия между продуктовой и заказной разработкой

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

В случае с Проектом, сделал проект — проект закрыт. Да, возможна сервисная поддержка, создание нового функционала, и тд. Но вне зависимости от типа оплаты, Fix Price или Time Material, которые применяются исходя из проектных условий, это так и остается в рамках сервисной поддержки либо других проектов в рамках реализованного функционала. И, что самое главное, основное решение о том, что же все-таки будет в продукте — видение только Заказчика.

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

Любая новая функциональность в Продукте не просто должна решать какую-то задачу, она должна нести в себе Ценность, которая будет генерировать финансовые улучшения, и должна благоприятно влиять на финансовую модель тем или иным способом. 

Таким образом, у Продукта нет конечной цели.

Что еще важно, продуктовая команда сама чаще всего является источником планируемых изменений. Да, это должно быть построено на гипотезах, иметь финансовое обоснование и вот это всё. У планируемых изменений могут быть внешние для продуктовой команды бизнес-заказчики, тем не менее это игра вдолгую и с бесконечными, пока это оправдано финансовой моделью, изменениями. Для этого в продуктовой команде даже есть отдельная роль и человек, который отвечает за то, чтобы формировать гипотезы, которые лягут в основу будущей разработки — это Product Owner. Человек, находящийся на стыке бизнеса, рынка и разработки.

Если в Проекте успешность конечной цели решается укладыванием в классический проектный треугольник, в основе которого лежат Объем, Ресурсы и Время, то в Продукте многое будет зависеть от успешности улучшения характеристик Финансовой модели. Это не значит, что проектный треугольник не важен, но считать его становится невыносимо трудоемким процессом, а это автоматически приводит к замедлению темпов доставки новых функций, что явно не будет влиять благотворно на путь Продукта и его финансовую модель. Классический Waterfall с существующим обязательным этапом сбора и формализации всех требований на начальном этапе, отъест слишком много драгоценного времени. Требования в итоге, с большой долей вероятности, поменяются, поэтому Waterfall сюда подходит плохо. Только итерации, проверки гипотез до старта разработки и после выпуска Feature, и новые пачки гипотез с целью понять, на правильном ли пути Продукт, позволяют разрабатывать продукт достаточно гибко, отвечая на возникающие вызовы и развороты в целях разработки.

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

2. Time to Market

Это метрика, которая пришла в IT из бизнеса. Впервые конференция по Time2Market была проведена Бартом Холлом в октябре 1995 года.

Time to Market — это ключевой показатель, используемый для оценки эффективности и скорости выхода нового продукта, услуги или функциональности на рынок. Она измеряет временной интервал с момента фиксации идеи до момента запуска продукта на рынке или доступа к нему для конечных пользователей.

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

3. Lead Time

Это часть Time2Market, который исключает из цикла Discovery исследования и проверку гипотез. Исключительно трудозатраты команды — Discovery + Delivery:

4. Cycle Time

Эта метрика является частью и Lead Time и, соответственно, Time to Market, и показывает только временные затраты на Delivery-фазу от старта разработки до выпуска в релиз:

5. Так как отслеживать и интерпретировать метрики?

Любая разработка будет требовать отчетности, а это значит, что продуктовая команда неизбежно будет использовать какой-либо трекер задач. Чтобы синхронизироваться внутри команды, у задач будет набор статусов, иначе невозможно понять, на каком этапе сейчас идут работы. Будет это просто изменение статусов или движение карточек по Канбан-доске? Для расчета метрики не имеет значения, какую методологию вы используете — SCRUM или Kanban — важно только одно. Скорость движения по статусам. 

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

Давайте пойдем снизу вверх и посмотрим на Cycle Time. Статус задачи в производственном процессе неизбежно будет привязан к ответственности определенных участников команды, чтобы выполнить свою работу и двинуть задачу дальше в сторону завершения работ. Соответственно, собирая статистику по движению задач между статусами, мы можем увидеть, какие тенденции на текущий момент происходят в команде.

Во-первых — укладываемся ли мы в свою оценку.

Во-вторых — есть ли узкие места в нашей команде.

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

На примере ниже мы видим, если задачи слишком долго висят в нескольких статусах. И если повлиять на сроки нахождения задач в процессе работы невозможно, то вот с промежуточными статусами типа “Готово к разработке”, “On Hold” или “QA Done” вполне можно и нужно что-то делать. 

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

Обсудите это с командой и вы удивитесь, сколько нового можете узнать.

В любом случае, отслеживание Cycle Time позволит проработать узкие места, которые требуют внимания. Сокращение даже по несколько часов в каждом статусе может ускорить выпуск задач на один или несколько дней, а значит, сделать больше задач за тот же объем времени.

Профит ????

Lead Time позволяет увидеть, нет ли аналогичных просадок на стыке Discovery/Delivery фаз. Во-первых, при поднятии на уровень вверх (см. пирамидку выше) появляется контрольный vision на работу аналитиков/архитекторов. Дополнительным бонусом вы можете засечь проблемы с теми же статусами и потерей времени в ситуациях, когда задача давно готова к разработке, но Delivery-команда в работу её не берет. Может, так и должно быть, а может и нет. Тем не менее, исправление процессов и устранение простоя также скажутся на объеме выпускаемого функционала в лучшую сторону. Если это невозможно, обратите внимание хотя бы на стабильность этого тренда.

Профит x2!

Ну и наконец, Time to market. Это Helicopter view над всеми этапами. Посмотрите на этапы доставки ценности сверху, оцените весь процесс. Даже если вы видите, что до Discovery ничего не исправить, отслеживание Time to market и всех остальных метрик на длительном горизонте позволяет увидеть волатильность работы команды. Есть ли скачки? Стабильны ли процессы в команде?

Выводы

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

Что еще дают нам эти метрики. 

В самом начале их внедрения сбор метрик покажет вам текущее положение дел. Достаточно ли декомпозируются задачи в объем поставки (если вы используете SCRUM). С течением времени, если этого еще не произошло, вы накопите статистическую информацию о компетенциях команды и о наличии/отсутствии ресурсного голода. В конце концов, представление команды о том, что их работа измеряется цифрами, очень неплохо стимулирует команду подтянуть внутреннюю дисциплину, а страдающим “синдромом Студента” взбодриться и задуматься о том, что это небезопасно для карьеры.

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

Пишите в комментариях, полезна ли была статья.

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