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

В ноябре 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: от момента, когда человек приходит на сайт, до получения денежных средств. Именно на таких задачах локальная эффективность отдельных специалистов перестаёт хорошо отражать скорость поставки целиком.

Монстр №1: 519 дней

Первую такую функциональность мы поставили через: 519 дней. Почти полтора года с момента, когда взяли работу в To Do и приняли обязательство её сделать.

Внутри этих 519 дней команда, конечно, не сидела без дела. Шла аналитика, появлялись подзадачи, писался код, проводилось тестирование. Но с точки зрения клиента и бизнеса готовой ценности всё это время не существовало.

После завершения функциональности мы решили провести отдельную ретроспективу. К этому моменту команда уже стала больше: появился frontend-лид, добавились тестировщик и бизнес-аналитик, появился Product Manager.

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

Первая ошибка: мы уже «декомпозировали»

Формально декомпозиция у нас и так была. Большая задача делилась примерно так:

• аналитика;

• backend;

• frontend;

• тестирование.

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

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

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

В идеальном случае каждая такая часть должна пройти собственный путь: анализ → разработка → тестирование → поставка. Не ждать завершения всего монстра, а постепенно выпускать законченные части.

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

Чтобы ускориться, пришлось вернуться назад

Аналитика второго монстра к тому моменту уже была готова. Большая конструкция фактически существовала: были требования, макеты, связи между блоками и уже принятые решения.

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

Например, какие-то редизайны, которые за время проработки успели присоединиться к большой задаче. Дополнительно усложнилась история с аналитикой: специалист, который изначально готовил решение, перешёл в другую команду.

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

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

Параллельно система продолжала меняться

Это был конец 2023-го - начало 2024 года. Команда к этому времени выросла примерно до:

• 3 аналитиков;

• 3 backend-разработчиков;

• 2 frontend-разработчиков;

• 3 QA;

• нескольких продуктовых ролей.

Мы продолжали экспериментировать с процессами, пробовали делать их гибче, вводили дополнительные ограничения и даже проходили через STATIK. Последний заслуживает отдельной статьи, поэтому здесь подробно останавливаться на нём не буду.

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

Мы попробовали разрешить Product Manager самостоятельно прорабатывать небольшие задачи, если там не требовалась сложная бизнес-логика или серьёзная техническая проработка. Такие задачи проходили ревью Product Owner, а перед разработкой мы сохраняли встречи формата 3 Amigos.

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

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

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

Монстр №2: 666 дней

В марте 2025 года второй монстр наконец дошёл до полностью рабочего состояния. Его Lead Time составил 666 дней.

Мы начали со 519 дней, провели ретроспективу, поменяли процесс, начали декомпозировать большие задачи - и получили ещё более длинную поставку. Но неприятнее была даже не цифра.

Готовую функциональность включили на нужной выборке клиентов, проверили и убедились, что технически она работает. После этого её выключили уже навсегда.

За время разработки изменились обстоятельства, в том числе регуляторные, и бизнесу эта функциональность больше не была нужна.

Это для меня один из самых показательных моментов всей истории.

Можно качественно реализовать всё, что было задумано. Но если ценность приезжает через 666 дней, к этому моменту может перестать существовать сама потребность в ней.

Именно здесь разговор о Lead Time перестаёт быть только разговором об эффективности разработки. Длинный Lead Time - это ещё и риск того, что мы идеально реализуем устаревшее решение.

Можно было решить, что декомпозиция не работает

На поверхности вывод выглядел очевидно: первый монстр занял 519 дней, после попытки декомпозиции второй - 666. Но когда мы посмотрели на происходящее внимательнее, проблема оказалась не в самой идее.

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

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

Монстр №3: декомпозиция на этапе аналитики

На этот раз большая функциональность была подробно разделена аналитиком до начала основной разработки. Отдельные части могли двигаться дальше относительно независимо друг от друга.

Мы всё ещё работали над одной большой функциональностью, но уже не требовали, чтобы практически весь объём дошёл до финиша одновременно. Результат составил примерно 240 дней.

Это всё ещё долго, но относительно 519 и 666 дней мы впервые получили заметное изменение. Главное для нас было даже не конкретное число, а подтверждение гипотезы: чем раньше появляется декомпозиция, тем дешевле использовать её как реальный инструмент поставки, а не как попытку разрезать уже готовую конструкцию.

После этого мы решили двигать точку декомпозиции ещё левее.

Монстр №4: подключили Product Manager и разработку

На следующей большой функциональности в декомпозиции участвовал уже не только аналитик. К ней подключились Product Manager и разработчики.

И здесь обнаружился ещё один важный момент: техническая возможность разделить систему не означает, что её правильно разделять именно так с точки зрения продукта.

Разработчик может сказать, что два блока технически независимы, но только из этого ещё не следует, что каждый из них создаёт самостоятельную ценность. Product Manager, в свою очередь, понимает, какой пользовательский или бизнесовый результат нужен в первую очередь.

Поэтому декомпозиция стала совместной работой:

• продукт определяет ценность и приоритет;

• аналитик уточняет границы бизнес-логики и зависимости;

• разработка говорит, где разделение технически возможно, а где оно создаст больше проблем;

• QA заранее помогает увидеть риски и проверяемость отдельных частей.

Но и это оказалось не конечной точкой.

Монстры №5 и №6: декомпозиция начинается ещё до аналитики

На следующих больших задачах мы перенесли декомпозицию на этап продуктовой проработки. Product Manager сначала раскладывал будущую функциональность с точки зрения ценности и связей между частями.

Не до уровня «эта задача для backend, эта для frontend», а на уровне вопросов:

• какие самостоятельные части существуют внутри большой функциональности;

• какая из них действительно нужна первой;

• что обязательно должно попасть в MVP;

• что можно отложить;

• какие зависимости есть между частями.

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

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

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

Но здесь быстро возник следующий риск.

Параллельность легко превращается в слишком большой WIP

После хорошей декомпозиции вместо одного монстра появляется много небольших частей. Первая естественная реакция - начать их все одновременно.

Только в этом случае очень быстро растёт WIP - Work in Progress, количество начатой, но ещё не завершённой работы. Карточек в In Progress становится всё больше: одна ждёт аналитика, вторая - тестирования, третья заблокирована зависимостью, четвёртая требует уточнения, а разработчики переключаются между контекстами.

При этом визуально кажется, что система работает очень активно. Проблема только в том, что много начатого не означает много законченного.

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

Освободили мощность - берём следующую часть. Без этого легко превратить одного огромного монстра в двадцать маленьких монстров, которые теперь просто одновременно стоят на доске.

MVP оказался не менее важен, чем сама декомпозиция

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

Раз уж меняем экран - давайте обновим дизайн. Раз уж трогаем процесс - добавим ещё один сценарий. Раз уж аналитик сейчас этим занимается - пусть сразу проработает ещё вот это.

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

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

Под MVP здесь я не подразумеваю «сделать кое-как». Это законченная часть продукта, которая уже решает конкретную задачу.

Дополнительные улучшения не исчезают из бэклога. Они просто перестают быть условием для первой поставки ценности.

Синхронизация всей команды

Можно придумать правильную декомпозицию, ввести WIP-limit и красиво перестроить доску. Но если смысл происходящего понимают только Product Manager и Delivery Manager, устойчивого эффекта может не получиться.

Вся команда должна понимать общую цель: мы не пытаемся локально ускорить аналитику, разработку или QA. Мы пытаемся быстрее доставлять законченный результат.

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

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

Что получилось в цифрах

Если очень грубо собрать путь по крупным функциональностям:

• монстр №1 - 519 дней;

• монстр №2 - 666 дней;

• монстр №3 - около 240 дней;

• следующие большие задачи - примерно 90-120 дней.

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

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

Что именно, на мой взгляд, сработало

Если сократить весь кейс до совета «декомпозируйте большие задачи», он потеряет половину смысла. Мы декомпозировали второй монстр и получили 666 дней.

Для нашей системы понадобилась комбинация нескольких изменений.

1. Декомпозиция начинается раньше

Чем больше решений и зависимостей уже зафиксировано, тем дороже потом разделять функциональность. В нашем случае точка начала декомпозиции постепенно сдвинулась:

перед разработкой → аналитика → продуктовая проработка.

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

2. Декомпозиция происходит на нескольких уровнях

Product Manager не заменяет аналитика, а аналитик не заменяет разработчика. Продуктовая декомпозиция отвечает на вопрос о ценности, аналитическая - о бизнес-логике и зависимостях, техническая - о возможности действительно реализовать и поставить части независимо.

Каждый следующий уровень может изменить первоначальное разделение.

3. Параллельная работа появляется только после нормальных границ

Само желание «работать параллельно» не создаёт параллельность. Если все части большой функциональности жёстко зависят друг от друга, команда всё равно будет ждать.

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

4. Первый релиз нужно защищать от разрастания

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

5. Декомпозиция без WIP-limit может сделать систему ещё хуже

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

6. Изменение должно быть понятно всей команде

Локальная оптимизация отдельного этапа не гарантирует уменьшение Lead Time всей системы. Наша цель была не «ускорить аналитиков» или «заставить разработку делать больше задач», а уменьшить время до поставки законченной ценности.

Но есть важная оговорка

Это не универсальная инструкция. Я не утверждаю, что если завтра в любой команде перенести декомпозицию на продуктовый этап, добавить WIP-limit и назвать первый релиз MVP, Lead Time уменьшится до 90-120 дней.

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

Мы взяли вполне разумную практику - декомпозицию. Попробовали её и получили 666 дней вместо 519.

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

То есть практика была не ответом. Она была гипотезой.

Волшебной таблетки всё-таки нет

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

Поэтому я бы не сводил этот кейс к фразе «декомпозиция сокращает Lead Time».

Для меня вывод немного другой:

Чтобы быстрее поставлять большие функциональности, нам пришлось перестать пытаться быстрее делать огромные задачи и научиться делать сами задачи меньше.

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