Почему продуктовые метрики не отвечают на главный вопрос руководителя продукта

Привет! Меня зовут Регина, я руковожу направлением Discovery в команде Лемана Тех, и мы отвечаем за все продукты Лемана ПРО для b2b-клиентов, начиная от их запроса к нам, документооборота, того, что мы им продаем, как продаем, как исполняем свои обещания и работаем по удержанию этих клиентов и привлечению новых. Иными словами, в нашей зоне ответственности — весь скоуп клиентской ценности по всему пути клиента.

В Лемана Тех я работаю 2,5 года, предыдущие 8 лет моя работа была больше связана с экспертизой в Логистике. Моя текущая команда — первая в Лемана Тех, работающая по-новому: без привязки к конкретному продукту (или к цифровым компонентам), за изменения в которых мы бы отвечали. Наша работа всегда связана с увеличением GMV (общий денежный объем проданных товаров и услуг) без потери RO (рентабельность) и улучшением опыта клиента независимо от того про какой шаг работы с клиентом мы говорим, будь то Исполнение заказов (сборка и доставка), или этап Продажи.

1,5 года назад, выстраивая новую продуктовую команду в Лемана Тех, я обнаружила, что при каждом изменении приоритетов или перераспределении ресурсов возникает один и тот же вопрос: сможет ли вся система поставки IT-ценности выполнить нужные инициативы в срок? Проблема оказалась структурной: стандартные метрики описывают, как работает конкретная команда или этап, но не говорят, где именно замедляется вся система и что с этим делать. Разобраться помог фреймворк, разработанный для производства, но применимый к управлению потоком IT-разработки. В статье расскажу, как мы его адаптировали и что изменилось.

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

1. Проблема: метрик много, ответов нет

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

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

2. Главный вопрос, на который никто не отвечает

В какой-то момент я поймала себя на одном повторяющемся вопросе:

Сможет ли вся система доставки IT-ценности выполнить нужные инициативы в нужный срок при текущих ограничениях?

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

3. Почему локальная эффективность не работает

Большинство метрик устроены локально:

• скорость команды 

• загрузка аналитиков

• пропускная способность конкретного этапа

• количество задач в работе

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

Мы наблюдали это на практике: очереди у бизнес-аналитиков, архитекторов, дата-аналитиков — при этом отдельные команды демонстрировали высокую загрузку и хорошую производительность. А сроки инициатив при этом росли.

Два наблюдения из практики

Мы столкнулись с эффектом, который сложно увидеть через локальные метрики.

Первое наблюдение: мы ускоряли одну часть процесса (Delivery) за счет высоких темпов стандартизации работ, но общее время работы над инициативами почти не изменилось.

Система не стала быстрее, потому что ограничение находилось в другом месте.

Второе наблюдение: после оптимизации этапа Discovery время ожидания в следующем этапе (мы его называем Hand-off Discovery-Delivery) выросло на ~25-30%.

То есть локальное улучшение не ускорило поток, а просто перераспределило очереди внутри системы.

Именно здесь стало очевидно: оптимизация частей системы не равна улучшению системы в целом.

4. Теория ограничений как недостающая модель

Эффект давно описан в Теории ограничений Элияху Голдратта.

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

Это означает, что:

• ускорение неограниченных частей системы не увеличивает общий результат

• локальная оптимизация может создавать очереди

• управление должно быть сфокусировано на ограничении потока

5. Что такое «здоровье IT-потока»

Мы начали описывать систему через метафору — здоровье потока.

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

Проще говоря — это не про скорость отдельных команд. Это про управляемость всей системы.

6. Как мы начали смотреть на систему иначе

Мы синхронизировали понимание руководителей Discovery, Реализации и этапа Внедрение в единую систему поставки ценности — Experience Team. И поменяли базовый вопрос управления:

Было: «насколько эффективно работает каждая команда?».

Стало: «как работа каждой части влияет на поток через ограничение?».

Это полностью изменило подход к управлению.

7. Практика: как выглядит ограничение в системе

Рассмотрим типичные ситуации:

Случай 1: ограничение в Discovery

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

Диагностика: 

Допускаем, что одна фича дает бизнесу одну единицу ценности. Тогда общий поток за 3 месяца принес лишь четыре единицы ценности (ровно столько Discovery загружает в Реализацию). 

Разработка могла бы сделать восемь фич от Discovery, но фактически делает только четыре: фактически мы могли бы увидеть ее недозагруженной на 50%, но не видим, так как Разработка занята решением иных вопросов. 

С первого взгляда казалось, что Delivery работает хорошо, поэтому продолжаем инвестировать в Delivery, а с Discovery что-то не так, и об инвестициях в команду Discovery стоит задуматься. Мы же понимаем, что если бы Discovery выдавал подтвержденных 8 гипотез/мес, бизнес-результат вырос бы до 8 ед./мес (при том же T2M).

Разобрали, почему:
Throughput Discovery зависит от качества менеджмента на данном этапе, экспертизы команды и зрелости процессов. У нас низкого уровня было все, так как команда была новая. Мы пошли через упрощение и допустили, что весомым фактором является именно качество менеджмента. 

Куда уходит время руководителя?  

1. анализ входящего потока запросов на Discovery занимает 50% времени руководителя Discovery (из-за нецелевых запросов и нарушений процесса подачи идей и запросов 

2. дизайн и стандартизация процессов на стыке Discovery, инициированные со стороны руководителя Delivery и руководителя Внедрения, занимают еще 30% времени. 

Итого на целевые действия у руководителя Discovery остается лишь 20% его ресурса. 

Помимо этого мы посмотрели на загрузку бэклога Discovery: что в него попадает и в каком количестве, — и оказалось, что постоянная перегрузка Discovery-команды «идеями» привела к перегрузу Discovery команды, в итоге WIP высокий, а фактически завершенных (velocity) — четыре штуки в месяц.

Поэтому первое, что мы сделали:

1. ограничили поток входящих запросов в бэклог Discovery

2. ограничили поток входящих запросов в адрес ресурса руководителя Discovery со стороны других руководителей. Все изменения процессов, стандартизации на стыке с командой Discovery были приостановлены. 

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

4. Сдали в «аренду» на месяц системных аналитиков из команды Реализации другому домену с целью повышения их экспертизы в других процессах.

Через 3 мес мы наблюдали картину:

Диагностика: 

Это измененная за 3 мес упрощенная модель показателей потока в разрезе

Случай 2: ограничение в архитектуре

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

Случай 3: внешние согласования

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

Ключевой вывод: улучшать нужно не всё подряд, а то, что ограничивает систему прямо сейчас.

8. На какие вопросы должна отвечать система управления потоком

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

• что сейчас происходит в потоке?

• где находится ограничение?

• что нужно изменить прямо сейчас?

• что будет, если мы изменим условия?

Если система не отвечает на эти вопросы — это не система управления потоком, а набор разрозненных метрик.

9. What-if анализ как следующий уровень управления

После того как появляется прозрачность текущего состояния, следующий шаг — управление будущим.

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

Что будет с системой, если изменится нагрузка, ресурсы или приоритеты?

Это и есть переход к what-if анализу в управлении потоком.

10. Вывод: от управления командами к управлению потоком

За последние годы стало очевидно:

мы постепенно переходим от управления командами и задачами к управлению системой доставки IT-ценности как единого потока.

И здесь ключевой сдвиг не в инструментах, а в модели мышления:

• не эффективность частей, а ограничение системы

• не локальная скорость, а пропускная способность всего потока

Финальный вопрос, с которого всё только начинается (и который стоит обязательно задать себе и команде):

Если завтра объем задач вырастет на 30%, мы сможем объяснить, где именно система сломается первой? И если ответ — «нет», самое время присмотреться к теории ограничений.