Всем привет! На связи Даня из Ресейла — технический руководитель команды Wildberries, которая развивает продукт для покупки и продажи вещей между физическими лицами.

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

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

Коротко: для сложных и рискованных задач мы перенесли исследование кода до финализации ТЗ, дизайна и оценки. Tech Discovery занимает до трёх рабочих дней календарного срока. На нашей выборке TTM средних и сложных задач сместился с диапазона 1,5–3 месяца к 1–2 месяцам, а количество профильных багов на эпик — с 6–12 до 4–9.

Почему обычного груминга оказалось недостаточно

Груминг в Scrum — это процесс проработки, приоритизации и актуализации бэклога. Для многих команд его достаточно, чтобы из спринта в спринт сохранять понятные приоритеты, а бизнес и разработка одинаково понимали сроки.

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

Покупательский опыт Ресейла работает на базе основных модулей Wildberries: каталога, поиска, карточки товара, корзины, заказов, платёжных методов и других. Всего мы взаимодействуем примерно с 15 модулями, у каждого из которых своя архитектура, история развития и подводные камни.

Кроме того, команды регулярно проводят A/B-тесты. Поэтому один и тот же экран может существовать сразу в нескольких реализациях, а изменение иногда необходимо вносить в каждую из них. Пока не заглянешь в код, реальный объём работ определить сложно.

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

Что обнаруживалось уже после старта разработки

Мы регулярно сталкивались как с системными ограничениями, так и с особенностями отдельных модулей.

1. Несколько реализаций одного экрана

Экран или фича, в которые мы хотели встроиться, могли существовать в двух версиях — например, из-за активного A/B-теста. В результате изменение требовалось реализовать дважды, хотя на этапе оценки задача выглядела как одна.

2. Макеты не совпадали с компонентами в коде

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

3. Переиспользуемость оказывалась не на том уровне

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

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

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

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

4. У каждой команды были свои архитектурные правила

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

5. Не сразу был виден полный список затронутых команд

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

Значит, менялся не только объём разработки. Нужно было заранее подключить владельцев других экранов и запланировать кросс-командное тестирование. Если узнать об этом поздно, увеличивается общий time to market (TTM) фичи.

6. Более простое решение находилось слишком поздно

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

В итоге мы экономили время на разработке, но теряли его на поздней итерации Discovery.

Как выглядел процесс раньше

Изначально проработка задачи шла последовательно:

1. Дизайнер готовил макеты, а системный аналитик — техническое задание.

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

3. Сроки фиксировались для бизнеса, задача попадала в ближайший спринт.

4. Во время разработки проявлялась одна или несколько проблем из списка выше.

5. Начиналась повторная итерация требований и дизайна, урезалась функциональность или существенно расходились план и факт.

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

Главная проблема оказалась в последовательности действий

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

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

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

Для каких задач мы запускаем Tech Discovery

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

Мы запускаем Tech Discovery в двух случаях:

1. Предварительная оценка сложности задачи — от 5 из 10 по нашей внутренней шкале.

2. Разработчик, системный аналитик или технический руководитель видит риск скрытой сложности — независимо от первоначальной оценки.

Второй сигнал обычно звучит просто: «Чувствую, здесь будет много подводных камней. Давайте на всякий случай поисследуем полдня». Это страхует нас от ситуации, когда задача выглядит как 3 из 10 только потому, что команда ещё не знает о скрытой сложности.

Как процесс выглядит сейчас

Шаг 1. Дизайнер готовит прототип

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

Шаг 2. Аналитик формирует основу технического задания

ТЗ тоже пока не считается финальным. Оно фиксирует цель, ожидаемое поведение и основные ограничения, но допускает изменения по результатам технического Discovery.

Шаг 3. Команда асинхронно изучает материалы

Мы выделяем несколько часов на ревью прототипа и основы ТЗ. Разработчики и тестировщики знакомятся с задачей и собирают первые вопросы.

Шаг 4. Проводим стартовую встречу и исследуем код

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

После встречи команда получает от половины до двух рабочих дней на исследование кода — срок зависит от размера эпика. За это время участники:

• находят реальные точки интеграции;

• проверяют наличие A/B-реализаций;

• определяют затронутые модули, экраны и команды;

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

• изучают архитектурные ограничения;

• продумывают примерный алгоритм реализации;

• фиксируют технические риски и оставшиеся неизвестные;

• формулируют дополнительные вопросы к требованиям и дизайну.

Шаг 5. Финализируем дизайн и ТЗ

Макеты и требования дорабатываются с учётом обратной связи от команды и фактического устройства кода. Благодаря этому технические ограничения влияют на решение до начала разработки, а не во время неё.

Шаг 6. Подтверждаем решение и оцениваем задачу

На финальной встрече команда утверждает ТЗ и макеты, ещё раз синхронизирует ожидания, после чего декомпозирует и оценивает работу. Не все неизвестные можно устранить за один-два дня, поэтому оставшиеся риски явно фиксируются и закладываются в оценку. Для задач с особенно высокой неопределённостью команда сначала готовит Proof of Concept и только после него подтверждает основной вариант реализации.

Только теперь задача считается готовой к разработке.

Что должно получиться на выходе

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

1. Финальная оценка с учётом выявленных технических рисков.

2. Декомпозиция, в которой размер одной задачи не превышает двух рабочих дней.

3. Список затронутых модулей, экранов и команд.

4. Финальный вариант реализации.

5. Техническая спецификация, подготовленная разработкой и сохранённая в вики проекта.

6. Proof of Concept — для задач с высоким уровнем неопределённости.

7. Заполненный чек-лист Definition of Ready.

8. Финализированные тест-кейсы.

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

Техническая спецификация, Proof of Concept и наш чек-лист Definition of Ready заслуживают отдельного разбора. Подробнее о них расскажу в следующей статье.

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

Сколько стоит такой процесс

Tech Discovery не бесплатен. Мы отдельно оценили верхнюю границу времени, которое участники тратят на весь процесс — от первого знакомства с прототипом до готовности задачи к разработке.

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

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

Что изменилось в результате

Как считали TTM

Для оценки эффекта мы сравнили задачи за два последних месяца до внедрения процесса и два месяца сразу после. В первую выборку вошли две средние и одна сложная задача, во вторую — три средние и одна сложная. Таким образом, сокращение TTM не сопровождалось падением потока: за тот же период команда выпустила на одну среднюю задачу больше.

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

Как изменился TTM

До внедрения процесса средний TTM по этим группам находился в диапазоне от полутора до трёх месяцев, после — от одного до двух месяцев. На каждой платформе разница составляла примерно 10–20 рабочих дней в зависимости от сложности задачи.

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

Что ещё могло повлиять

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

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

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

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

Снизилось количество багов

В этом расчёте один эпик соответствует одной платформе. До изменения процесса на эпик приходилось в среднем от 6 до 12 багов, связанных с несоответствием требований реальному поведению и ограничениям модулей. После внедрения Tech Discovery диапазон снизился до 4–9 багов на эпик.

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

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

Сроки стали прозрачнее для бизнеса

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

Это не обычный spike?

Этап исследования кода действительно похож на классический time-boxed technical spike: мы ограничиваем его по времени и используем для снижения технической неопределённости. Для задач с особенно высоким риском результатом исследования может стать Proof of Concept.

Но весь Tech Discovery шире spike. Он заканчивается не только техническим выводом, но и финальными требованиями, технической спецификацией, декомпозицией, тест-кейсами и заполненным Definition of Ready.

Вместо вывода

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

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

Казалось бы, на этом можно остановиться: средний TTM по разным платформам сместился с диапазона в полтора-три месяца к одному-двум месяцам, диапазон профильных багов на платформу — с 6–12 до 4–9, а сроки стали прозрачнее. Но это оказалось не финальной версией процесса. Следующая итерация принесла дополнительные результаты — о ней расскажу во второй части.

Буду рад обратной связи и рассказам о том, как технический Discovery устроен в ваших командах. На связи был Даня из Ресейла. До встречи!