Полтора года назад мы в RuStore собрали новую команду, чтобы с нуля разработать собственное платёжное решение. Тогда всё началось с одной фичи. Казалось бы, «просто запилить», чего тут сложного. Но на деле это обернулось целым кварталом разработки, бесконечными доделками и болью на финальном этапе интеграции. Тогда мы столкнулись с типичным набором проблем — от отсутствия документации и слабой декомпозиции до невозможности предсказать сроки. Да, в конечном итоге всё как-то заработало, но по ощущениям исключительно на энтузиазме.
С тех пор мы прошли длинный путь: от хаоса — к чёткой структуре. За последний год команда выстроила полноценный процесс доставки фичей, который помогает запускать новые возможности быстрее (мы ускорились с 1 до 5 фич в квартал), качественнее и без нервных срывов. Мы много раз ошибались, переосмысляли, допиливали, выпиливали — и в итоге собрали систему, которая реально работает.
Этот текст — первая часть из серии из трёх постов, где я, Григорий Рябов, техлид backend-команды Rustore, и руководитель команды разработки RuStore: направление платежей, Александр Котельников @Alexander_Kotelnikov, делимся нашим опытом. Он пригодится тем, кто хочет навести порядок в разработке, а также тимлидам и менеджерам, которые стремятся к предсказуемости, и командам, которым нужен практичный и подробный алгоритм действий — от идеи до продакшена.
Дисклеймер: этот гайд основан на практическом опыте работы в кросс-функциональной команде, включающей backend- и frontend-разработчиков, QA-инженеров, продакт-менеджера и тимлида.
Зачем мы пишем этот пост?
Для того чтобы вам не пришлось набивать те же шишки. Мы собрали весь наш опыт в виде подробного гайда — с этапами и конкретными действиями на каждом шаге. Это не «идеальный процесс», а живая, проверенная на практике структура, которая поможет:
минимизировать хаос;
ускорить time-to-market;
не забыть важные шаги;
выстроить общее понимание между командой и бизнесом.
Можно использовать этот материал как основу для построения или адаптации процесса под вашу команду и контекст.
Ниже разберёмся, с чего начинается работа над фичей и как не застрять на этапе аналитики и сомнений. Мы выделили 5 шагов, с которых стоит начать — расскажем про каждый подробно и по делу.
1. Kick-off: Начало работы над фичей
Зачем нужен этот этап?
Kick-off — это стартовая точка работы над фичей, на которой команда получает общее представление о целях, бизнес-ценности и ключевых требованиях. Здесь формируются ожидания от результата, обсуждаются ограничения и риски, а также намечается первичное видение будущей реализации.
Цель этапа — сформировать единое понимание фичи внутри команды, определить её ценность, ключевые требования и ограничения, а также задать вектор для дальнейшей архитектурной и технической проработки.
Подготовка к встрече
Для эффективного обсуждения перед встречей собираются:
карточка фичи (что делаем, зачем, ключевые метрики успеха);
бизнес-требования (ожидаемый результат);
дизайн-макеты, если фича затрагивает UI;
результаты исследований / POC, если проводились предварительные проверки.
Как проходит встреча
1. Презентация фичи
PO/PjM рассказывает команде:
какую проблему решает фича;
какие изменения затронут пользователей / продукт;
как будет измеряться успех (ключевые метрики);
какие ключевые события должны происходить в системе;
как взаимодействуют системы и пользователи.
2. Детализация и анализ
Пробуя разные подходы, мы остановились на комбинации Event Storming и User Story. Здесь выбор методологии, конечно, остаётся за вами — всё зависит от задач и контекста.
Если фича сложная и затрагивает несколько систем, лучше всего подойдёт Event Storming — он позволяет визуализировать потоки данных и понять, как компоненты взаимодействуют друг с другом. Для более локальных изменений достаточно использовать User Story с декомпозицией сценариев.
Если применяется Event Storming
Определяются ключевые события (Domain Events) — какие изменения происходят в системе.
Выявляются акторы (Actors) — кто инициирует события и кто на них реагирует.
Рисуется поток событий (Event Flow) — визуализация того, как информация проходит через систему.
Определяются ограничения и возможные сложности.
Анализируются зависимости между событиями и их влияние на архитектуру.
Если применяется User Story
Формулируется основная User Story и разбивается на подзадачи.
Определяются основные сценарии использования (happy path, edge cases).
Выявляются ограничения в бизнес-логике и технические риски.
Фиксируются метрики успеха и критерии готовности.
Как выбор подхода поможет на следующих этапах
Event Storming
Оставляет артефакт с визуализацией потоков событий, который можно использовать для архитектурного ревью и технического дизайна.
Чёткое понимание событий и акторов помогает согласовать границы контекста (Bounded Contexts) при проектировании сервисов.
На этапах тестирования и отладки проще сверяться с изначальным потоком событий, чтобы контролировать соответствие фичи исходной логике.
User Story
Декомпозиция задач позволяет точнее оценить объём работы и спланировать спринты.
Сценарии использования можно перенести в тест-кейсы и автоматизировать тестирование.
Ясные критерии успеха упрощают процесс приёмки и проверки готовности фичи.
3. Фиксация результатов
Создаётся чат фичи для обсуждений.
Дается предварительная оценка трудозатрат.
Намечаются ключевые шаги разработки и тестирования.
Создаётся wiki по фиче (например, в Confluence) с собранными артефактами.
Итоги этапа
Команда получает чёткое понимание фичи.
Выявлены потенциальные риски и узкие места.
Определены первые шаги реализации.
Создана карта событий (при использовании Event Storming).
Формируется первичное понимание архитектурных изменений.
Наш опыт
Ранее у нас не было полноценного Kick-off в том виде, который описан выше. Обычно мы собирались в ограниченном составе — PO, тимлид и техлид — и сразу переходили к планированию. В результате на протяжении всей разработки, тестирования и релиза приходилось постоянно «догонять» команду по контексту. Участники подключались к работе на разных этапах и не всегда имели полное представление о целях и нюансах фичи. Из-за этого возникали разночтения: кто-то по-своему трактовал логику, кто-то не знал о важном сценарии, который в итоге просто не был протестирован.
После внедрения полноценного Kick-off с участием всей команды, общая картина стала намного яснее. Мы начали фиксировать ключевые события, уточнять ограничения и риски заранее, что значительно сократило количество недоразумений в процессе. Такой формат позволил всем сразу быть «в одной лодке» и эффективнее двигаться к результату.
2. Верхнеуровневая архитектура: формируем фундамент фичи
Зачем нужен этот этап?
На этом этапе мы закладываем архитектурную основу фичи: определяем, как она будет встроена в систему, какие компоненты задействуем и как они будут взаимодействовать. Это помогает минимизировать технические риски, избежать дублирования кода и обеспечить отказоустойчивость.
Цель этапа — определить архитектурные изменения, спроектировать интеграции и инфраструктурные процессы, а также зафиксировать ключевые технические решения.
Этот этап занимает 1–2 дня и завершается оформлением архитектурного документа (например, ADR — Architectural Decision Record).
DDD как инструмент для проектирования архитектуры
Если на предыдущем этапе применялся Event Storming, логично развить его в Domain-Driven Design (DDD). Это поможет:
разделить систему на логически изолированные контексты, упрощая поддержку и масштабируемость;
определить агрегаты, доменные сущности и их взаимодействия;
обеспечить единое понимание модели между разработчиками, аналитиками и бизнесом;
избежать размытия ответственности и дублирования логики между сервисами.
Если DDD кажется избыточным, можно использовать его частично — например, выделить ключевые сущности и агрегаты без детального моделирования.
Как проходит работа
На этом этапе у нас уже есть все необходимые вводные данные, поэтому мы фокусируемся на формировании технического решения.
1. Разрабатываем архитектурное решение
Фиксируем все выявленные изменения в ADR и визуализируем в диаграммах взаимодействий (C4, Sequence, API контрактах):
Какие компоненты изменяются? Какие создаются?
Как организовать взаимодействие между компонентами?
Какие API-интеграции потребуются?
Есть ли необходимость в рефакторинге текущих компонентов?
Как будет реализовано управление событиями (Event Sourcing, CQRS)?
Какие механизмы обеспечат консистентность данных в распределённой среде?
2. Документируем архитектурное решение
C4 диаграммы (уровни 1 и 2) — системная архитектура и взаимодействие компонентов.
Sequence-диаграммы — детализация взаимодействий.
Примерная схема БД и API-интеграций.
Этапы развертывания фичи (без жёстких сроков, но с пониманием ключевых шагов).
ADR (Architectural Decision Record) — фиксируем ключевые архитектурные решения и отправляем на ревью.
Совет: если за 5 минут нельзя объяснить, как фича встроится в архитектуру — значит, её нужно упростить.
Итоги этапа
Чёткая структура системы — определены границы взаимодействий, компоненты и API-интеграции.
Формализованное архитектурное решение — оформленный ADR и диаграммы.
Выбранные технологии и паттерны — согласованы всей командой.
Определены механизмы взаимодействия компонентов и событий — минимизированы архитектурные риски.
Наш опыт
Ранее у нас не было отдельного этапа проработки верхнеуровневой архитектуры — его задачи были объединены с техническим дизайном, и весь процесс мог занимать до двух недель. На это время остальная команда зачастую находилась в ожидании, не включаясь активно в работу. Такой подход мешал гибкому управлению сроками и затруднял параллельную проработку задач.
После разделения этих этапов ситуация изменилась. Верхнеуровневая архитектура теперь фиксируется на раннем этапе и позволяет синхронизировать команду по ключевым архитектурным решениям. Это дало возможность запустить параллельную работу: разработка уходит в детализацию реализации, а тестирование — в составление верхнеуровнего тест-плана. Такой подход значительно ускорил цикл разработки и повысил прозрачность процесса.
3. Архитектурное ревью: утверждаем решение
Зачем нужен этот этап?
Перед началом разработки важно убедиться, что выбранное архитектурное решение соответствует техническим и бизнес-требованиям, а также не создаёт критических рисков для системы.
Цель этапа — выявить узкие места, оценить масштабируемость и отказоустойчивость, а также убедиться в соответствии стандартам безопасности и комплаенса.
Как проходит работа
1. Проводим ревью
В обсуждении участвуют:
Архитекторы — оценивают масштабируемость.
SRE (Site Reliability Engineering) — проверяют отказоустойчивость и нагрузку.
Информационная безопасность — оценивают риски.
Лиды практик — проверяют соответствие стандартам разработки.
PO — защищает продуктовое решение.
Ключевые вопросы:
Соответствует ли архитектура целям бизнеса и техническим требованиям?
Не создаёт ли она узкие места или точки отказа?
Можно ли сделать её проще, надёжнее и эффективнее?
2. Фиксируем результаты
Формируется протокол ревью, фиксируются замечания и предложения.
Определяются доработки (minor/major) и сроки их реализации.
При необходимости назначается повторное ревью.
После согласования архитектуры команда получает «зелёный свет» на разработку.
Итоги этапа
Финализированное архитектурное решение, подтверждённое ключевыми участниками.
Учтены все замечания и риски, определены доработки и их приоритет.
4. Technical Design: детализация реализации
Зачем нужен этот этап?
Этот этап переводит архитектурное решение на уровень конкретных технических деталей. Он минимизирует риски разночтений, делает разработку предсказуемой и упрощает взаимодействие внутри команды.
Цель этапа — формализовать внутреннюю структуру системы, определить взаимодействие компонентов, способы обработки данных и ошибок, а также зафиксировать API-контракты, стратегии тестирования, мониторинга и сбора метрик.
Technical Design — это не просто документация, а рабочий инструмент, который обеспечивает согласованность реализации и помогает избежать неопределённости.
Этап проходит параллельно с подготовкой тест-стратегии. Пока разработчики детализируют архитектуру, QA определяет подходы к тестированию.
Как проходит работа
1. Дорабатываем технические детали на основе артефактов архитектурного ревью
Структуры данных — БД, модели межкомпонентного взаимодействия.
Контракты API — внутренние и внешние, их версии и backward-совместимость.
Логирование и обработка ошибок — какие события фиксируются, какие метрики используются.
Сиквенс-диаграммы ключевых сценариев — визуализация взаимодействий между компонентами.
Ограничения и потенциальные проблемы — выявление возможных узких мест и рисков.
Метрики и аналитика — определяем, какие технические и бизнес-показатели будем отслеживать.
2. Декомпозируем задачи
Разбиваем работу на задачи и добавляем в бэклог.
Определяем отдельные задачи на разработку компонентов, аналитику, тестирование и деплой.
Закладываем сбор необходимых метрик (бизнес, технические, перформанс).
Настраиваем механизмы мониторинга и алертов по ключевым показателям.
Учитываем зависимости между задачами и этапами, чтобы избежать блокировок.
Важно: если на этом этапе не заложить метрики и аналитику — потом будет поздно.
Итоги этапа
Финальный Technical Design — детализированное описание реализации.
Утверждённые API-контракты — понятные и согласованные.
Готовый бэклог — задачи по разработке, аналитике, тестированию и деплою.
Все данные, API и структуры согласованы.
Разработчики готовы к началу работы.
Проверка: если другой разработчик может взять созданный документ и сразу начать писать код — значит, всё готово.
Наш опыт
После внедрения отдельного этапа Technical Design нам удалось значительно сократить риски «раздувания» скоупа и появления неожиданных технических сложностей в процессе реализации. Раньше многие детали обсуждались уже «на ходу», что приводило к разночтениям и изменению планов прямо во время спринта.
Особенно остро мы столкнулись с проблемой метрик. В одной из фич у нас реализован асинхронный поток данных, который проходит через несколько компонентов системы в зашифрованном виде. На этапе технического дизайна мы не заложили нужные бизнес-метрики, и позже оказалось, что невозможно корректно идентифицировать сообщения. Это потребовало внести доработки во все ключевые точки обработки данных, что вылилось в довольно трудоёмкий и громоздкий рефакторинг.
С логированием тоже были кейсы: ошибку мы фиксировали, но без достаточного контекста — что происходило в системе, в каком она была состоянии, какие данные участвовали. Сейчас мы уделяем больше внимания логам и метрикам уже на этапе технического дизайна: заранее определяем, какие события критичны для отладки и анализа, и где именно они должны фиксироваться.
5. Верхнеуровневый тест-план: определяем стратегию тестирования
Зачем нужен этот этап?
Фича проанализирована, архитектурные решения утверждены, а технический дизайн детализирован. Осталось определить ключевое — как мы будем её тестировать. Этот этап помогает определить, какие аспекты фичи необходимо проверить, какими методами и на каком уровне это сделать, чтобы минимизировать риски появления багов, как эффективно распределить ресурсы команды и заложить основу для тест-дизайна и автоматизации тестирования.
Цель этапа — выстроить стратегию тестирования, которая обеспечит оптимальное покрытие, интеграцию тестирования в процесс разработки и контроль качества на каждом этапе.
Этот этап проходит параллельно с разработкой Technical Design, чтобы тестирование было встроено в процесс разработки, а не шло отдельно.
Как проходит работа
1. Определяем объекты тестирования
Компоненты и API — какие методы и интерфейсы нужно проверить?
Фронт/UI — какие страницы и пользовательские сценарии затронуты?
Бизнес-логика — как должны работать ключевые сценарии?
2. Выбираем подход к тестированию
После определения объектов тестирования выбираем оптимальные методы и инструменты проверки. Проектируем пирамиду тестирования и определяем оптимальный набор проверок для каждого уровня.
Что нужно автоматизировать — API-тесты, автотесты UI, unit-тесты.
Где нужны скриншотные тесты — изменения в дизайне.
Что будем проверять вручную — сложные пользовательские сценарии.
3. Декомпозируем задачи
Разбиваем тестирование на этапы и добавляем задачи в бэклог.
Определяем отдельные задачи на тест-дизайн, автоматизацию тестов и ручное тестирование, приемку фичи и разработку результирующей тестовой документации.
Закладываем мониторинг ключевых показателей качества тестирования.
Итоги этапа
Перечень компонентов, API, UI и логики для тестирования.
Приоритеты тестирования и объём работ.
Понимание, что будет автоматизировано, а что протестировано вручную.
Разбитые по этапам задачи на тест-дизайн и автоматизацию.
Готовность переходить к тест-дизайну.
Быстрый тест: если QA-команда сразу понимает, как тестировать фичу — значит, тест-план хороший.
Наш опыт
До появления отдельного этапа верхнеуровневого тест-плана у нас регулярно возникали сложности с планированием: тестировщики не могли оценить сроки на подготовку тест-дизайна и автоматизации из-за отсутствия целостного понимания архитектуры и объема фичи.
Мы часто сталкивались с задержками на этапе вывода фичи: разработка уже была завершена, а тестирование всё ещё находилось в процессе составления тест-плана. Эта проблема во многом была связана с тем, что архитектурные решения принимались поздно, и тестовая стратегия откладывалась на потом. В результате страдали сроки и стабильность релизов.
Сейчас, когда тест-план формируется параллельно с Technical Design, а архитектура фиксируется заранее, команда тестирования может своевременно определить приоритеты, оценить трудозатраты и приступить к автоматизации до завершения разработки. Это заметно ускоряет вывод фич в прод и делает процесс более предсказуемым.
Что дальше?
В этом посте мы разобрали первые пять шагов, которые помогают команде начать работу над фичей с минимальным хаосом и максимальной ясностью: от первичного обсуждения и архитектурного планирования до технического дизайна и стратегии тестирования. Это тот самый фундамент, без которого любая разработка рискует превратиться в бесконечную доработку на проде.
В следующих частях мы расскажем:
как организовать сам процесс разработки так, чтобы не потерять ни одну задачу (и нервы команды),
как выстроить качественный релизный процесс,
как анализировать запуск и делать выводы, которые реально улучшают процесс.
Если у вас уже есть опыт построения процесса поставки фичей — будем рады услышать, что у вас сработало, а что — нет. Делитесь в комментариях! Ну а если вы только в начале пути — сохраняйте статью, пробуйте наш подход и пишите, если останутся вопросы.
