Эту тему открывают, когда команда смешивает поиск решения и обязательство по поставке. Пока что-то ещё исследуется, уже звучат обещания по срокам; пока идея не собрана, её считают готовой к delivery; discovery спорит с execution за один и тот же ресурс. В таких условиях PM быстро теряет ясность по статусу и ожиданиям.
Что это за подход
Разделение discovery / delivery полезно как управленческая рамка между исследованием и поставкой. Для PM это способ не путать этап, где ещё ищут и уточняют, с этапом, где команда уже обязуется поставить конкретный результат.
Сильная версия этого подхода держится не на красивом названии двух контуров, а на понятной точке перехода между ними. До этой точки команда исследует, уточняет и спорит с неопределённостью. После неё уже появляется commitment на объём, критерии готовности и ожидания по поставке. Если переход не определён, discovery легко растягивается бесконечно, а delivery получает сырые вводные.
Когда он нужен
- в продуктовых и неопределённых контурах;
- когда идеи и задачи слишком рано попадают в delivery;
- если ожидания по срокам формируются до достаточной ясности;
- при сильной зависимости от product/discovery-части.
Когда он не нужен
- если работа очень линейна и discovery почти отсутствует;
- если разделение создаёт лишнюю стену между ролями;
- если под этим ярлыком просто прячут затянутое принятие решений.
Что из него реально применимо для PM
- различать исследование и обязательство;
- яснее коммуницировать статус и готовность работы;
- отделять roadmap of ideas от committed delivery plan;
- уменьшать конфликт между «хотим понять» и «обещали сделать».
- явно договариваться, что считается выходом из discovery: достаточная формулировка проблемы, согласованное решение, подготовленный дизайн или схема, понятные acceptance expectations и owner перехода.
Какие артефакты, ритуалы и правила важны
- критерии выхода из discovery;
- явная передача в delivery;
- разные статусы и ожидания для двух контуров;
- синхронизация product, design, analysis и delivery.
- короткий discovery summary или ready-for-delivery note: что проверили, что решили, что остаётся открытым и на каком основании задача теперь считается готовой к commitment.
Какие ошибки чаще всего делают при внедрении
- создают жёсткую стену между discovery и delivery;
- не определяют критерии перехода;
- обещают сроки на уровне сырых гипотез;
- называют discovery всё, что просто не хочется коммитить.
- позволяют discovery тянуться бесконечно, потому что никто не определил, какое качество решения и какой пакет вводных считаются достаточными для перехода в delivery.
Чем можно заменить или упростить
- более лёгким upstream / ready-for-delivery контуром;
- рефайнментом, если нужен только подготовительный слой;
- ясными статусами backlog без отдельной сложной модели;
- kanban-подходом с явными правилами входа в committed work, если команда уже живёт через поток.