Статья
В разработке ИТ-продуктов одна ошибка повторяется удивительно часто: едва обозначив проблему, команда бросается ее решать, не разобравшись в истинных причинах. Итог предсказуем: на выходе — решения, не попадающие в цель, и бесконечный цикл исправлений, который истощает ресурсы и демотивирует команду.
Рассказываем о фреймворке, который позволяет двигаться в правильном направлении с самого начала, выдавать результат быстрее и качественнее с помощью этапов Discovery и Delivery.
Discovery (Исследование) — это этап ответа на вопросы «Что?» и «Для чего?». Мы исследуем боль пользователя, а не приступаем к разработке.
Цель этапа Discovery — найти продуктивную реализацию и доказать ее ценность до написания первой спецификации и первой строчки кода.
Delivery (Реализация) — это этап ответа на вопрос «Как?». Мы реализуем уже проверенное и согласованное решение.
Цель этапа Delivery — реализовать доработку (или проект) эффективно, предсказуемо и с высоким качеством.
Простая аналогия: планирование поездки в отпуск.
Discovery — это когда вы:
определяетесь с бюджетом и целью, например, «Отдохнуть на море с семьей за 50 тыс. рублей»;
изучаете отзывы, смотрите фото отелей, иначе говоря, проводите исследование и преданализ;
выбираете несколько вариантов и советуетесь с семьей.
Результат: У вас на руках билеты, забронирован подходящий отель, утвержден маршрут, выделен бюджет.
А Delivery — это когда вы:
едете в аэропорт, заселяетесь в отель, ходите на пляж;
не думаете «куда бы поехать» — у вас есть четкий план.
Результат: Вы с семьей отлично отдохнули и получили массу положительных впечатлений.
Если начать Delivery (поездку) без Discovery (планирования), вы рискуете оказаться в аэропорту без билетов или приехать на горнолыжный курорт в летних шортах. Разово такие курьезные путешествия, конечно, могут порадовать, но все же лучше подходить к вопросу осознанно.
Представим, что мы получили исходный запрос от заказчика: «Клиенты жалуются на сложность получения кредита. Нужно упростить процесс подачи кредитной заявки в мобильном приложении».
Что делаем:
1. Выявляем требования. Проводим интервью (опросы/анкетирование) с основными стейкхолдерами. В нашем примере:
Клиентами: выясняем их главную боль. Вполне возможно, это не сам процесс, а непонятные статусы заявки или необходимость нести документы в отделение после онлайн-подачи
Сотрудниками банка: узнаем, с какими проблемами сталкиваются работники в процессе обслуживания кредитных заявок
Юристами/Комплаенс-контролем/И прочими: уточняем дополнительные бизнес-правила и ограничения
2. Проводим анализ и документирование требований:
Проверяем наши гипотезы по доработке продукта с помощью CustDev-интервью
Составляем карту путешествия клиента (Customer Journey Map)
Анализируем продукты конкурентов
Готовим описание и визуализацию процессов AS IS и TO BE в формате BPMN-диаграммы
Готовим прототипы в Figma
Формируем BRD, описываем User Stories, Use Cases, Acceptance Criteria
Составляем матрицу трассировки и наполняем бэклог, в зависимости от приоритетов
3. Планируем скоуп работ:
Совместно с архитектором, готовим архитектурный Vision
Выделяем ресурсы для реализации доработки: для разработки в зоне ответственности нашей системы и внешних команд
Результаты:
Vision & Scope: видение — «Сократить время одобрения кредита с 3 дней до 1 часа за счет полностью дистанционного процесса с интеллектуальной проверкой документов».
Бизнес-требования: четкое описание изменения в формате BRD, с понятными KPI: конверсия из заявки в выдачу кредита +15%, снижение нагрузки на отделения на 30%.
Прототип: интерактивный макет нового процесса с пошаговой загрузкой документов и прозрачными статусами, например «Документы на проверке», «Требуется селфи с паспортом».
Сформирован верхнеуровневый бэклог, заложен необходимый ресурс.
Задачи и проект могут быть разными, сроки Discovery могут сокращаться или увеличиваться, однако, сама суть остается неизменной: по завершении этапа, мы четко знаем, что планируем реализовать и какие ресурсы нам для этого потребуются.
Что делаем:
1. Проводим технический анализ реализации:
Изучаем бизнес-требования и документацию, сформированную на этапе Discovery
Исследуем, как система работает сейчас: изучаем документацию или проводим анализ кода
Накладываем текущую реализацию на сформированный Vision: нужны ли новые интеграции со смежными системами, потребуются ли изменения
2. Готовим документацию:
Детализируем пользовательские истории и сценарии
Формируем FSD, описываем экранные формы и интеграционное взаимодействие: API-спецификации или интеграции через брокеры
Формируем требования для доработки смежных систем
Визуализируем доработку в формате UML-диаграмм:
— диаграмма последовательности (Sequence) — чтобы увидеть, в каком порядке и как обмениваются данными разные части системы;
— диаграмма классов (Class) — чтобы понять, из каких «строительных блоков» состоит код и как они связаны;
— диаграмма активности (Activity) — чтобы отследить логику выполнения бизнес-процессов, от старта до финиша.
Описываем структуру базы данных в виде логической структуры и в формате ER-диаграммы
Детализируем и дополняем нефункциональные требования к системе
Описываем реализацию с точки зрения архитектуры приложения.
Результаты:
Технические требования: доработка четко описана в формате спецификаций для фронт и бэк-разработчиков, подготовлено общее описание технического решения в формате FSD.
Сформированы задачи и требования для доработки смежных систем, определены сроки.
Описана архитектурная документация.
Этап Delivery также может быть сокращен или увеличен, в зависимости от объема и сложности проекта, количества задействованных систем. Итогами системного анализа является описание технической реализации для передачи задачи на этапы разработки, тестирования и сопровождения.
На этих этапах могут быть внесены минорые изменения в документацию. Если реализация меняется существенно, например, выявляются существенные системные ограничения, возможно, потребуется возврат на этап Discovery.
После релиза нашей задачи, аналитика данных показала, что 20% пользователей бросают заявку на этапе «селфи-идентификации». Это — вход в новый цикл Discovery для исследования причин и поиска решения.
Важно понимать, что все этапы тесно связаны между собой. Находясь на этапе Discovery, мы обращаемся к команде разработки для уточнения технических особенностей реализации и верхнеуровневой оценки. Прорабатывая этап Delivery мы обращаемся к бизнес-аналитику для уточнения бизнес и нефункциональных требований. А этап сопровождения подразумевает постоянный сбор обратной связи от пользователей для формирования бэклога и исправления ошибок.
Мы находимся в постоянном цикле доработок, перманентно улучшая систему.
После того как доработка разработана и протестирована, на большинстве проектов аналитик приступает к подготовке релизной документации и инструкций пользователя.
После релиза наступает следующий этап: Сопровождение и поддержка. Здесь, как правило, аналитик выступает в качестве эксперта в случае обращений пользователей или дефектов, а также для сбора обратной связи и метрик по доработке.
Если выявлена негативная обратная связь, технические ошибки или новые требования, происходит возврат на этапы Discovery и Delivery.
Для 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 — для описания структуры и управления БД
В зависимости от компании, проекта и задачи список может изменяться — здесь стоит ориентироваться на ваши потребности.
Для бизнеса резко снижаются риски создать ненужный продукт. Инвестиции в разработку становятся предсказуемыми и обоснованными.
Аналитик превращается из «писателя ТЗ» в стратега и исследователя. Его ценность для бизнеса растет, а количество стресса от бесконечных правок — падает.
Разработчики получают четкие, стабильные и протестированные требования. Исчезают хаотичные изменения в середине спринта.
Реальный кейс из практики:
Было: Поступила задача «Реализовать в приложении раздел "Сбережения" с 3 видами вкладов». Сделали за 2 месяца. Конверсия в открытие вклада была менее 1%.
Стало после Discovery: Потратили 3 недели на исследование. Выяснили, что клиенты не понимают разницу между вкладами и боятся «замораживать» деньги. Сделали «Копилку» с гибкими настройками целей и правил пополнения. Результат: конверсия в использование сервиса — 12%, средний срок хранения средств увеличился в 2 раза.
Discovery и Delivery — это не про замедление, а про движение в правильном направлении с самого начала. Внедряя этот подход, вы не только повышаете предсказуемость своих проектов, но и но и кратно увеличиваете их ценность и успешность.