Груминг со звёздочкой: как раннее погружение в код изменило сроки выхода функций
Всем привет! Я Даня, технический руководитель команды Wildberries, которая развивает продукт для покупки и продажи вещей между физическими лицами. Наши функции работают не изолированно: они встраиваются в каталог, поиск, карточку товара, корзину, заказы, оплату и другие модули платформы.
Именно поэтому стандартного груминга нам оказалось недостаточно. Чтобы реалистично оценить задачу, мало обсудить бизнес-требования и посмотреть макеты. Нужно заранее понять, как устроен код, какие реализации уже существуют, какие команды придётся подключить и где могут скрываться технические ограничения.
В результате мы перенесли исследование кода на более ранний этап - до финализации технического задания, дизайна и оценки. Этот этап назвали Tech Discovery. Он занимает до трёх рабочих дней календарного срока, но помогает заметно повысить предсказуемость разработки. Подробнее о подходе можно узнать в материале о том, как груминг разработчиков связан с ранним изучением кода.
Почему обычного груминга оказалось мало
Scrum-груминг обычно используют для проработки, актуализации и приоритизации бэклога. Для многих команд этого достаточно: участники синхронизируются по требованиям, уточняют объём работ и получают основу для планирования спринта.
Но у нас одна и та же функция могла затрагивать около 15 модулей. У каждого из них - собственная архитектура, история изменений, набор технических компромиссов и правила взаимодействия с соседними компонентами. Дополнительную сложность создавали A/B-тесты: один экран иногда существовал сразу в нескольких вариантах.
До начала разработки обнаруживались проблемы, которые невозможно было заметить только по описанию задачи:
- один экран требовал изменений в двух или трёх реализациях;
- компоненты в макете не совпадали с теми, что фактически использовались в продукте;
- существующая архитектура не всегда позволяла переиспользовать готовое решение;
- разные команды придерживались собственных подходов к построению модулей;
- полный список затронутых команд становился понятен слишком поздно;
- более простой и безопасный вариант реализации находился уже после старта работ.
Например, команда-владелец экрана могла ещё не перейти на новую дизайн-систему. Тогда к разработке добавлялись адаптация макетов, техническая миграция или поиск компромисса между старым и новым набором компонентов. Формально это выглядело как небольшая доработка, но фактический объём оказывался значительно больше.
В другом случае требовалось изменить логику выбора товаров в отдельной вкладке корзины. Безопаснее было скопировать существующую вкладку и адаптировать её под новый сценарий, чем вмешиваться в общий код корзины. Такое решение увеличивало объём работ, зато снижало риск повредить критически важный пользовательский путь.
Как процесс выглядел раньше
Ранее команда сначала получала задачу, затем уточняла требования, согласовывала макеты, проводила груминг и оценивала разработку. Исследование кода часто начиналось уже после того, как сроки были озвучены бизнесу.
Главная проблема заключалась не в отсутствии компетенций, а в последовательности действий. Оценка формировалась до того, как команда видела реальную техническую картину. Поэтому первоначальные прогнозы часто получались слишком оптимистичными, а сроки выхода функции могли заметно сдвигаться.
Это напрямую влияло на ускорение Time to Market в разработке: попытка быстрее перейти к реализации не всегда приводила к более раннему релизу. Иногда несколько часов предварительного анализа позволили бы избежать недель переделок.
Для каких задач нужен Tech Discovery
Мы не стали добавлять новый этап абсолютно для всех задач. Такой подход был бы избыточным и замедлял бы простые изменения. Tech Discovery запускаем, когда задача:
- затрагивает несколько продуктовых модулей;
- встраивается в уже существующий экран;
- связана с несколькими вариантами реализации;
- требует взаимодействия с другими командами;
- имеет высокий риск архитектурных ограничений;
- предполагает создание универсального или переиспользуемого решения.
Для небольших локальных изменений достаточно обычного груминга. Но если функциональность проходит через границы команд и систем, раннее погружение в код обучение программированию в рамках конкретной задачи становится важной частью подготовки. Разработчики не просто читают документацию, а связывают требования с реальным устройством продукта.
Как устроен процесс сейчас
Шаг 1. Дизайнер готовит прототип.
На этом этапе фиксируется пользовательский сценарий и предполагаемая структура интерфейса. Макет ещё может меняться, но уже понятно, в какие зоны продукта планируется интеграция.
Шаг 2. Аналитик формирует основу технического задания.
В документе описываются бизнес-логика, ограничения, варианты поведения и ожидаемый результат. Это не финальная версия ТЗ, а рабочая база для технического исследования.
Шаг 3. Команда изучает материалы асинхронно.
Разработчики, аналитики и дизайнеры заранее знакомятся с задачей, оставляют вопросы и отмечают потенциальные риски. Благодаря этому стартовая встреча проходит предметнее и не превращается в чтение документа вслух.
Шаг 4. Проводится встреча с исследованием кода.
Команда вместе проверяет, как устроены затрагиваемые модули, где расположены нужные компоненты, какие существуют версии экранов и какие команды владеют соответствующими участками.
Шаг 5. Финализируются дизайн и ТЗ.
После проверки технических ограничений макеты и требования корректируются. На этом этапе можно отказаться от рискованного решения, заменить его более простым или заранее заложить миграционные работы.
Шаг 6. Решение подтверждается, задача оценивается.
Когда команда понимает фактический объём, формируется оценка, список участников и план дальнейшей реализации. Бизнес получает не предварительную догадку, а прогноз, основанный на проверенной технической информации.
Что должно быть на выходе
Результатом Tech Discovery становится не формальный документ, а согласованное понимание задачи. В нём должны быть отражены:
- затрагиваемые модули и команды;
- найденные версии экранов и компонентов;
- ограничения текущей архитектуры;
- необходимые изменения в дизайне;
- риски и зависимости;
- выбранный вариант реализации;
- предварительная оценка сроков и трудозатрат.
Такой результат улучшает процесс разработки программного обеспечения в целом. Команда раньше замечает противоречия, бизнес получает более прозрачный прогноз, а смежные участники подключаются до начала активной фазы работ.
Сколько это стоит
Tech Discovery занимает до трёх рабочих дней календарного срока. Это не означает, что несколько разработчиков всё это время работают только над одной задачей: часть анализа выполняется асинхронно, а встречи используются для обсуждения конкретных вопросов.
Стоимость этапа оправдана, если он помогает избежать переработки архитектуры, повторной оценки и задержки релиза. Особенно заметен эффект в задачах, где ошибка на старте приводит к переделке сразу нескольких модулей.
На нашей выборке средних и сложных задач диапазон TTM сократился примерно с 1,5-3 месяцев до 1-2 месяцев. При этом количество профильных багов на эпик снизилось с 6-12 до 4-9. Это не означает, что все изменения вызваны только новым процессом: на результат могли повлиять улучшение архитектуры, опыт команды и изменения в организации работы.
Тем не менее тенденция оказалась устойчивой. Чем раньше команда видит ограничения и зависимости, тем меньше вероятность, что они появятся неожиданно уже на стадии реализации или тестирования. Это положительно влияет и на эффективность команды разработки, поскольку специалисты тратят меньше времени на срочные уточнения и исправление неверных предположений.
Что изменилось для бизнеса и команды
Для бизнеса сроки стали понятнее. Если раньше оценка могла заметно измениться после начала работ, то теперь основные причины возможного увеличения объёма выявляются заранее. Это упрощает планирование релизов и позволяет своевременно менять приоритеты.
Команда получила возможность обсуждать архитектурные решения до того, как они превратились в дорогие обязательства. Кроме того, снизилось количество ситуаций, когда разработчики узнавали о существовании параллельной реализации экрана или внешней зависимости в последний момент.
Важно, что Tech Discovery - не обычный spike и не попытка заранее реализовать часть функции. Его задача - снизить неопределённость, проверить техническую реализуемость и выбрать подходящий путь. На выходе не обязательно появляется готовый код; гораздо важнее, что команда понимает, какой код нужно будет написать и почему именно так.
Раннее исследование также помогает формировать более качественные технические решения на будущее. Если одна и та же проблема регулярно возникает в разных задачах, её можно вынести на уровень платформенной доработки: улучшить компонент, унифицировать API или договориться о единых архитектурных правилах.
В итоге груминг становится не разовой встречей перед спринтом, а частью управляемого процесса подготовки. Он соединяет бизнес-контекст, дизайн, аналитику и техническую реальность. Для сложных продуктов это позволяет не просто быстрее начинать работу, а чаще приходить к релизу без неожиданных задержек и критических переделок.
Именно такой подход мы рассматриваем как практичный способ сделать разработку предсказуемее: сначала понять, куда и как встраивается функция, затем согласовать решение и только после этого переходить к полноценной оценке. This позволяет сокращать TTM без формального ускорения отдельных этапов за счёт качества и устойчивости всей системы.
