519 → 666 → 90-120 дней: как мы сокращали Lead Time больших задач и сначала сделали только хуже

Значимый прорыв формирует отрасль ИИ: nik-l26 57 минут назад 519 → 666 → 90-120 дней: как мы сокращали Lead Time больших задач и сначала сделали только хуже Средний 11 мин 2. 2K Управление разработкой * Управление проектами * Управление продуктом * Agile * Кейс В ноябре 2022 года я пришёл Delivery Manager в финтех-продукт. Через некоторое время мы начали внимательнее смотреть на Lead Time и обнаружили довольно неприятную картину: одна из крупных функциональностей ехала от принятия обязательства до поставки 519 дней.

Мы провели ретроспективу, решили, что проблема в декомпозиции, изменили подход и попробовали снова. Следующий большой кейс занял уже 666 дней. То есть после того, как мы осознанно начали «ускорять процесс», результат стал ещё хуже.

Технические детали

Только после нескольких итераций мы пришли к подходу, при котором похожие крупные функциональности стали укладываться примерно в 90-120 дней. Эта статья не про волшебную практику, которая уменьшила Lead Time в несколько раз. Скорее про то, почему вполне разумная идея сначала не сработала вообще, что именно мы меняли дальше и почему декомпозиции на уровне разработки оказалось недостаточно.

Контекст: маленькая команда и большой бэклогНа старте команда выглядела так:1 бизнес-аналитик;1 frontend-разработчик;2 backend-разработчика;1 QA. Отдельного Product Manager тогда не было. Со стороны бизнеса был руководитель департамента, от которого приходили идеи, а дальше команде нужно было превращать их в конкретные решения.

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

Отраслевые последствия

В компании использовали практики Канбан-метода. После обучения я постепенно начал внимательнее смотреть на Lead Time, Cycle Time и пропускную способность команды. В этой статье под Lead Time я буду иметь в виду наш рабочий интервал: от момента, когда задача попадала в To Do и мы фактически принимали обязательство её сделать, до поставки готовой функциональности.

Именно на этом уровне цифры начали выглядеть особенно неприятно. «Монстры»К тому моменту у нас уже была в работе крупная функциональность, связанная с изменением условий открытого займа. Позже подобные задачи мы внутри команды начали называть монстрами.

Под монстром здесь я понимаю не просто крупную Jira-карточку, а большую end-to-end функциональность, которая меняет значительную часть клиентского пути. Для её реализации требуется продуктовая проработка, аналитика, backend, frontend, тестирование и набор зависимостей между ними. Например, это может быть изменение полного клиентского flow: от момента, когда человек приходит на сайт, до получения денежных средств.

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.