Начнем с экспозиции. В нашей компании продуктовая структура представляет из себя 9 продуктовых end-to-end команд общей численностью ~130 человек, работающих над развитием одного продукта.  Каждая из команд укомплектована всеми необходимыми компетенциями. Все они живут в одном релизном процессе, делают задачи из одного бэклога (и проекта в Jira) и следят за одним набором метрик в Amplitude. В условиях такого тесного взаимодействия естественным образом возникает вопрос: а как оценивать их эффективность? Об этом мы и поговорим.  Перед тем, как определить критерии оценки, давайте разберемся с тем, что же такое эффективная продуктовая команда. Все просто:  Эффективная продуктовая команда — та, которая выпускает классные (коммерчески успешные) продукты. Чтобы сделать классный продукт, нужно быстро поставлять качественные решения пользователям. То есть эффективность продуктовой структуры или команды можно оценить по двум факторам:  Как быстро бежит команда? (Time to market) А туда ли она бежит? (Value) Для начала нужно понять, а что, собственно, мы хотим измерить в скорости работы команды. Время от идеи до релиза? Время от "взяли в работу" до "выпустили"? Давайте разложим основные этапы разработки любой крупной задачи на временную шкалу: Генерация идеи — кто-то придумал что нужно сделать классную фичу.  Создана задача — об этой классной фиче впервые появился цифровой след, ее завели в Jira, Kaiten или Trello. Взята в работу — та самая точка взятия обязательств командой. До этого момента работа над классной фичей по сути не велась. Разработка закончена (Ready for Release) — все работы сделаны, фича готова к выпуску. Релиз — релиз. Аналитика & Обратная связь - этап, о котором многие забывают или игнорируют. Мало просто выпустить классную фичу, нужно обязательно собрать аналитику/данные/метрики и ответить на вопрос "а что она нам дала?". Может, вы ее зря делали :) Теперь пойдем от обратного и поговорим о метриках на основе этой шкалы: Dev Time — самая базовая единица измерения в нашей шкале. Показывает, сколько времени уходит на разработку/тестирование и подготовку фичи к релизу. Это самая честная и понятная метрика для команды, т.к. она на 100% находится в зоне ее влияния.  Release Time — сколько времени занимает выпуск готового функционала. Метрика больше для корпораций и крупных компаний. В истории, когда у тебя десятки или сотни команд, время выпуска релизов может достигать недель, и за этим показателем есть смысл следить и как-то его улучшать. В небольших командах или компаниях с низкой бюрократией и/или низким техническим легаси этой метрики может вообще не быть, т.к. время на релиз несущественно.  Cycle Time — от "взяли в работу" до "выпустили в прод". Первая из перечисленных метрик, которую можно ставить в KPI команды и мониторить ее на дашбордах. По ней видно, как быстро работает каждая из ваших команд.  Начинаем усложнять. Допустим с метрикой Cycle Time вы разобрались и даже улучшили до нужных значений.  Lead Time — следующий уровень. Сколько времени проходит от того, как мы завели задачу в бэклог до ее фактического выпуска? По опыту, Lead Time обычно кратно больше Cycle Time. И причина этому — долгое время ожидания очереди в бэклоге.  Time to Market — та самая фраза, которую вы слышите на митапах и конференциях. Научиться ее измерять — дело уже высшего пилотажа и мало кому действительно удается. Вся сложность кроется в измерении самого первого этапа — генерации идеи. Как оцифровать тот самый момент, когда вы на совещании или по пути на работу придумали классную фичу и решили ее делать? Сколько дней или недель прошло до того момента, как эта фича появилась в бэклоге в Jira? Time to Learn — сколько времени проходит от момента, когда классную фичу кто-то придумал до момента, когда по ней появились цифры в Amplitude. Показатель в большей степени характеризует с какой скоростью работает ваш бизнес/продукт в целом. Как быстро вы выпускаете новые продукты или проводите эксперименты?. Как быстро вы обрабатываете результаты этих запусков и делаете из них выводы? Как быстро вы потом можете обновить свои приоритеты и поменять свой курс? Этот показатель комплексно отвечает на вопрос "как быстро работает ваша компания". И разумеется, тот, кто работает быстрее — тот обычно и побеждает.  Справедливости ради отмечу, когда мы начинаем внедрять оценку эффективности команд в организации, то первым делом определяем приоритетные метрики. В нашем случае это — Lead Time, Cycle Time и Release Frequency.  Мы сразу и честно себе признаем, что все что больше этого (Time to Market, Time To Learn), мы нормально посчитать сейчас не сможем, да и вряд ли сможем на них в ближайшей перспективе повлиять. Поэтому сразу убираем их из фокуса. Далее, как технически измерить эти показатели? Очень просто — timestamp в Jira. Для того, чтобы собрать статистику по всем нашим командам, нам достаточно настроить автоматическую выгрузку из Jira нескольких временных кодов:  Дата создания задачи. Автоматически создается Jira в любой задаче. Дата перевода задачи в статус In Progress. Также автоматически создается самой Jira. Дата выпуска задачи в релиз. Сильно зависит от вашего релизного процесса. В нашем случае — в каждую задачу проставляется fix version. По нему определяем дату релиза и проставляем ее в выгрузке.  Тип задачи. Важно не забывать разделять метрики по типам задач и следить за ними отдельно. Ведь Cycle Time по багу нельзя сравнивать с Cycle Time новой фичи. Итого, если настроить автоматическую выгрузку по всем этим параметрам и положить в простенький дашборд в том же Power BI, то получаем простой, но результативный инструмент по отслеживанию эффективности ваших команд: Если возиться с Jira и считать метрики не хочется или не можется — есть альтернативный вариант. Считаем скорость сжигания бэклога продуктовыми командами. Метод до жути простой, но рабочий. Как говорится — "keep it simple, stupid" (принцип дизайн проектирования, принятый ВМС США).  Что делаем: Вводим в командах любую систему оценки задач. В сторипоинтах, в часах, в штуках — как вам нравится.  В конце каждого спринта/итерации/месяца собираем два показателя: сколько планировали единиц в работу, сколько по факту выполнили. Строим из этих данных несложную таблицу или дашборд. Наглядно видим слабые места в системе, получаем массу фактуры для работы над улучшениями. В нашем примере мы собираем статистику по закрытым сторипоинтам в спринт каждой команды. "Сжигаются" сторипоинты в момент, когда задача доезжает до статуса Ready for Release, то есть она оттестирована и готова, осталось только выложить в прод.  Здесь важно сказать, что любую систему можно довольно таки легко обмануть. И история с оценкой метрик не является исключением. Рано или поздно ваши команды найдут способ читерить с оценками, это неизбежно. Но. Как правило, первыми способами обойти систему будут положительные под предлогами — "а давайте нарезать таски на более мелкие", "а давайте меньше брать в спринт", "а давайте оставлять временной резерв на непредвиденные задачи и вбросы". Это приводит к положительному эффекту процесса разработки. Ведь действительно, нужно лучше декомпозировать задачи, не брать в работу то, что "не лезет", и оставлять время на исправление багов.  В первой части мы разобрались с вопросом «как быстро мы бежим?». А это - только вершина айсберга. Можно бежать очень быстро, но бежать не туда или вообще бежать в стену.  Во второй части расскажу как оценивать качество того, что создают продуктовые команды (и ответить на вопрос "а куда мы бежим?"), как правильно мотивировать их на достижение коммерчески успешных результатов в продукте.