Когда нужен discovery перед разработкой

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

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

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

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

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

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

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

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

Discovery нужен, когда неясны пользовательская ценность, проблема, аудитория, сценарии и границы первого результата. НИОКР/R&D нужен, когда главный риск уже технический или продуктово-технологический: неизвестно, сработает ли подход, интеграция, алгоритм, архитектура или прототип. Если нужно сначала разобраться в терминах, смотрите НИОКР и R&D простыми словами; если исследование уже подтверждено как формат, переходите к материалу как устроен R&D-проект.