Павел Кондратьев
Руководитель проектов в ГК Юзтех
Всем привет, на связи снова Павел Кондратьев из ГК Юзтех. Я продолжаю работать в продуктовой команде по разработке 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 позволит проработать узкие места, которые требуют внимания. Сокращение даже по несколько часов в каждом статусе может ускорить выпуск задач на один или несколько дней, а значит, сделать больше задач за тот же объем времени.
Профит
Интересные статьи
Интересные статьи
