За 12 лет работы с ИТ-командами я часто видела одну повторяющуюся ситуацию: команды зачастую бросаются решать проблему, не поняв её сути. Результат — продукты, которые не решают боли пользователей, и вечные переделки.

Меня зовут Анастасия Солдатова, я техлид системной аналитики и один из авторов канала Sprint аналитика. Сегодня хочу поделиться framework-ом, который изменил мою работу и работу моих команд: осознанное разделение процессов на Discovery (Исследование) и Delivery (Реализация). Это не бюрократия, а способ выдавать результат быстрее и качественнее.

1. Что такое Discovery и Delivery? Философия двух этапов.

Discovery — это этап ответа на вопросы «Что?» и «Для чего?». Мы исследуем боль пользователя, а не приступаем к разработке. 
Цель этапа Discovery — найти продуктивную реализацию и доказать её ценность до написания первой спецификации и первой строчки кода.

Delivery — это этап ответа на вопрос «Как?». Мы реализуем уже проверенное и согласованное решение. 
Цель этапа Delivery — реализовать доработку (или проект) эффективно, предсказуемо и с высоким качеством.

Простая аналогия: Планирование поездки в отпуск. 

Discovery — это когда вы:

• определяетесь с бюджетом и целью (“Отдохнуть на море с семьей за 50 тыс. рублей”);

• изучаете отзывы, смотрите фото отелей (проводите исследование и преданализ);

• выбираете несколько вариантов и советуетесь с семьей.

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

Delivery — это когда вы:

• едете в аэропорт, заселяетесь в отель, ходите на пляж;

• не думаете “куда бы поехать” — у вас есть четкий план.

Результат: Вы с семьей отлично отдохнули и получили массу положительных впечатлений.

Если начать Delivery (поездку) без Discovery (планирования), вы рискуете оказаться в аэропорту без билетов или приехать на горнолыжный курорт в летних шортах. Разово такие курьезные путешествия, конечно, могут порадовать, но лучше подходить к таким вещам последовательно

2. Как этапы работают на практике

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

Представим, что мы получили исходный запрос от заказчика: «Клиенты жалуются на сложность получения кредита. Нужно упростить процесс подачи кредитной заявки в мобильном приложении.»

ШАГ 1: Этап Discovery (Длительность: 2 спринта)

Что делаем:

1. Выявляем требования. Проводим интервью (опросы/анкетирование) с основными стейкхолдерами. В нашем примере:

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

   • Сотрудниками банка: Узнаем, с какими проблемами сталкиваются работники в процессе обслуживания кредитных заявок.

   • Юристами/Комплаенс-контролем/И т.д.: Уточняем дополнительные бизнес-правила и ограничения.

2. Проводим анализ и документирование требований:

   1. Проверяем наши гипотезы по доработке продукта с помощью CustDev-интервью,

   2. Составляем карту путешествия клиента (Customer Journey Map),

   3. Анализируем продукты конкурентов,

   4. Готовим описание и визуализацию процессов AS IS и TO BE в формате BPMN-диаграммы;

   5. Готовим прототипы в Figma;

   6. Формируем BRD, описываем User Stories, Use Cases, Acceptance Criteria;

   7. Составляем матрицу трассировки и наполняем бэклог, в зависимости от приоритетов.

3. Планируем скоуп работ:

   1. Совместно с архитектором, готовим архитектурный Vision;

   2. Выделяем ресурсы для реализации доработки: для разработки в зоне ответственности нашей системы и внешних команд.

Результаты:

• Vision & Scope: Видение — «Сократить время одобрения кредита с 3 дней до 1 часа за счет полностью дистанционного процесса с интеллектуальной проверкой документов».

• Бизнес-требования: Четкое описание изменения в формате BRD, с понятными KPI: конверсия из заявки в выдачу кредита +15%, снижение нагрузки на отделения на 30%.

• Прототип: Интерактивный макет нового процесса с пошаговой загрузкой документов и прозрачными статусами («Документы на проверке», «Требуется селфи с паспортом» и т.д.).

• Сформирован верхнеуровневый бэклог, заложен необходимый ресурс.

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

ШАГ 2: Этап Delivery, Системный анализ (Длительность: 3 спринта)

Что делаем: 

1. Проводим технический анализ реализации:

   1. Изучаем бизнес-требования и документацию, сформированную на этапе Discovery;

   2. Исследуем, как система работает сейчас: изучаем документацию или проводим анализ кода;

   3. “Накладываем” текущую реализацию на сформированный Vision: нужны ли новые интеграции со смежными системами, потребуются ли изменения.

2. Готовим документацию:

   1. Детализируем пользовательские истории и сценарии;

   2. Формируем FSD, описываем экранные формы и интеграционное взаимодействие: api-спецификации или интеграции через брокеры;

   3. Формируем требования для доработки смежных систем;

   4. Визуализируем доработку в формате UML-диаграмм:

      • Диаграмма последовательности (Sequence) — чтобы увидеть, в каком порядке и как обмениваются данными разные части системы.

      • Диаграмма классов (Class) — чтобы понять, из каких "строительных блоков" состоит код и как они связаны.

      • Диаграмма активности (Activity) — чтобы отследить логику выполнения бизнес-процессов, от старта до финиша;

   5. Описываем структуру базы данных в виде логической структуры и в формате ER-диаграммы;

   6. Детализируем и дополняем нефункциональные требования к системе;

   7. Описываем реализацию с точки зрения архитектуры приложения.

Результаты:

• Технические требования: Доработка четко описана в формате спецификаций для фронт и бэк-разработчиков, подготовлено общее описание технического решения в формате FSD.

• Сформированы задачи и требования для доработки смежных систем, определены сроки;

• Описана архитектурная документация.

Этап Delivery также может быть сокращен или увеличен, в зависимости от объема и сложности проекта, количества задействованных систем и т.д. Итогами системного анализа является описание технической реализации для передачи задачи на этапы разработки, тестирования и сопровождения. На этих этапах могут быть внесены минорые изменения в документацию. Если реализация меняется существенно (например, выявляются существенные системные ограничения), возможно, потребуется возврат на этап Discovery.

ШАГ 3 (Опционально): Новый виток Discovery

После релиза нашей задачи, аналитика данных показала, что 20% пользователей бросают заявку на этапе «селфи-идентификации». Это — вход в новый цикл Discovery для исследования причин и поиска решения.

Важно понимать, что все этапы тесно связаны между собой:

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

• Прорабатывая этап Delivery мы обращаемся к бизнес-аналитику для уточнения бизнес и нефункциональных требований;

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

Мы находимся в постоянном цикле доработок, перманентно улучшая систему.

ШАГ 4: Завершение Delivery, передача доработки в сопровождение и поддержку

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

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

Если выявлена негативная обратная связь, технические ошибки или новые требования, происходит возврат на этапы Discovery и Delivery.

3. Типичные ошибки аналитиков и как их избежать

4. Инструменты и техники для каждого этапа

Для Discovery:

• CustDev-интервью: Глубинные беседы с пользователями для выявления истинных болей.

• Event Storming: Совместный воркшоп для анализа сложных бизнес-процессов.

• Impact Mapping: Визуализация пути от бизнес-цели к конкретным функциональностям.

• Прототипы в Figma: Быстрая и дешевая валидация идей.

• User Stories, Use Cases, Acceptance Criteria (Given/When/Then): Четкая и однозначная формализация требований.

• BPMN: Для моделирования бизнес-процессов.

Для Delivery:

• Диаграммы UML: Для описания сложной логики реализации доработки.

• Swagger, OpenAPI, AsyncAPI : Для однозначного описания синхронных интеграций (например, REST и SOAP) и взаимодействия через асинхронные интеграции или брокеры (например, gRpc, Kafka, Rabbit).

• ER-диаграммы и DBeaver: Для описания структуры и управления БД.

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

5. Почему это выгодно вам и вашей команде?

• Для аналитика: Вы превращаетесь из «писателя ТЗ» в стратега и исследователя. Ваша ценность для бизнеса растет, а количество стресса от бесконечных правок — падает.

• Для разработчиков: Они получают четкие, стабильные и протестированные требования. Исчезают хаотичные изменения в середине спринта.

• Для бизнеса: Резко снижаются риски создать ненужный продукт. Инвестиции в разработку становятся предсказуемыми и обоснованными.

Реальный кейс из моей практики:

• Было (только Delivery): Поступила задача «Реализовать в приложении раздел "Сбережения" с 3 видами вкладов». Сделали за 2 месяца. Конверсия в открытие вклада была менее 1%.

• Стало (с Discovery): Потратили 3 недели на исследование. Выяснили, что клиенты не понимают разницу между вкладами и боятся «замораживать» деньги. Сделали «Копилку» с гибкими настройками целей и правил пополнения. Результат: Конверсия в использование сервиса — 12%, средний срок хранения средств увеличился в 2 раза.

Ваш план по внедрению на ближайший месяц

1. Диагностика: Проанализируйте текущий проект. Где вы сейчас: в Discovery или Delivery? Есть ли смешение?

2. Эксперимент: Выберите одну небольшую задачу в бэклоге. Перед передачей в разработку проведите для нее мини-Discovery: 2-3 интервью с пользователями и набросок решения на салфетке или в Figma/Miro.

3. Разговор: Покажите эту статью и результаты своего эксперимента тимлиду или продакт-менеджеру. Обсудите, как можно пилотировать такой подход в вашей команде.

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

Больше полезного читайте в нашем Telegram-канале. До встречи в новых публикациях!