коротко

Дискавери (discovery) — это этап, на котором выясняют, что и зачем делать: есть ли проблема, кому она болит, какой от решения толк и окупится ли оно. Деливери (delivery) — этап, на котором делают то, что решили: проектируют, кодят, тестируют, выкатывают. Главная ошибка — перепрыгнуть дискавери и сразу побежать делать: тогда команда качественно строит то, что никому не нужно, а это самый дорогой способ ошибиться. В dual-track agile обе дорожки идут параллельно: пока одно уже делается, следующее уже исследуется. Аналитик в дискавери — тот, кто формулирует проблему, проверяет гипотезы и считает, стоит ли игра свеч; в деливери — тот, кто превращает проверенное решение в точные требования.

Самая дорогая фича в моей памяти была сделана идеально. Чистый код, выверенный контракт API, полное покрытие тестами, ноль багов на приёмке. Через два месяца после запуска её отключили: ей пользовались полтора человека. Никто на старте не спросил, есть ли вообще проблема, которую она решает, — заказчик сказал «надо», и команда честно сделала «надо». Мы прекрасно сделали деливери и полностью пропустили дискавери. С тех пор я знаю: «сделать хорошо» и «сделать нужное» — это два разных вопроса, и второй идёт первым.

Два разных вопроса

В любой разработке спрятаны два вопроса, и их постоянно склеивают в один.

Дискавери отвечает на «что и зачем». Существует ли проблема на самом деле или её придумали? Кому она болит и насколько? Какое решение её закроет? Сколько это стоит и окупится ли? По сути дискавери проверяет одну вещь: стоит ли проблема того, чтобы её решать. Это работа с неопределённостью — здесь много вопросов и мало готовых ответов.

Деливери отвечает на «как». Решение выбрано — теперь спроектировать, написать, протестировать, выкатить и сделать это качественно. Это работа с определённостью: что делать, уже понятно, осталось сделать хорошо.

Разные вопросы требуют разного мышления. В дискавери ценится способность усомниться, отбросить плохую идею дёшево, сказать «нет». В деливери ценится исполнительность и инженерное качество. Беда начинается, когда команда в режиме «давай делать» берётся за вопрос «а надо ли» — и наоборот.

Почему пропустить дискавери дорого

Соблазн понятен: дискавери выглядит как «болтовня без кода», а деливери — как «настоящая работа». Поэтому через дискавери так легко перепрыгнуть. И именно это самая дорогая ошибка в разработке, потому что цена неправильного «что» растёт по ходу проекта лавиной.

Усомниться в идее на этапе разговора — стоит часа. Поймать, что фича не нужна, на этапе требований — стоит дня. Понять это, когда она уже написана и протестирована, — стоит недель работы команды (вспомните, сколько стоит спринт). А осознать в проде, когда фича отключена за ненадобностью, — это ещё и упущенное время, за которое можно было сделать что-то нужное. Дискавери — это не задержка перед работой, это способ не делать дорого то, что можно было не делать вовсе.

Самый дорогой код — тот, который не нужно было писать

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

Что входит в дискавери для аналитика

Дискавери — не магия и не «насмотренность продакта». Это набор конкретных вопросов, и аналитик закрывает их вместе с продактом. Минимальный список, который я держу как чек-лист.

  • Проблема. Что именно болит? Сформулировать как проблему, а не как готовое решение. «Клиенты уходят на этапе оплаты» — проблема. «Сделать оплату в один клик» — это уже навязанное решение, и оно может быть неверным.
  • Пользователи. Кому болит и в каком сценарии? Чем конкретнее, тем лучше: «новые покупатели с телефона», а не «пользователи».
  • Ценность. Что изменится, если проблему решить? И для бизнеса (деньги, удержание), и для пользователя.
  • Гипотезы. «Мы считаем, что вот это решит проблему, и узнаем это по вот такому признаку». Гипотеза — это предположение, которое можно проверить, а не вера. Самый дешёвый способ проверить её руками — собрать MVP.
  • Окупаемость. Сколько стоит решение и стоит ли проблема этих денег. Это прямая связь с деньгами задачи: дискавери без счёта окупаемости — половина дискавери.

Заметьте, что ни один из этих пунктов не про код. Все про смысл. Если на эти вопросы нет ответов, требования писать рано — вы просто красиво опишете непроверенную догадку.

Dual-track agile: две дорожки

Звучит так, будто дискавери — это длинная стадия перед деливери: сначала полгода исследуем, потом год делаем. Это водопад, и он плохо работает. На практике используют dual-track agile: две дорожки, которые едут параллельно и постоянно перекидываются результатами.

flowchart LR
  subgraph D["Дорожка Discovery: что и зачем"]
    d1["Проблема"] --> d2["Гипотезы"] --> d3["Проверка дёшево"] --> d4["Проверенное решение"]
  end
  subgraph DEL["Дорожка Delivery: как"]
    e1["Требования"] --> e2["Разработка"] --> e3["Тест"] --> e4["Прод"]
  end
  d4 -->|"готово к работе"| e1
  e4 -.->|"обратная связь из прода"| d1

На схеме две параллельные дорожки. Верхняя — discovery: проблема превращается в гипотезы, гипотезы дёшево проверяются (интервью, прототип, эксперимент), и на выходе получается проверенное решение. Нижняя — delivery: проверенное решение становится требованиями, дальше разработка, тест, прод. Сплошная стрелка между дорожками показывает главную передачу: в работу уходит только то, что прошло проверку наверху, — деливери не берёт сырые идеи. А пунктир снизу вверх — это обратная связь: то, что вскрылось в проде, рождает новые проблемы и гипотезы для следующего витка дискавери. Суть в том, что дорожки не сменяют друг друга, а крутятся одновременно: пока команда делает проверенное, исследуется следующее.

Роль аналитика в дискавери

Бытует мнение, что дискавери — целиком вотчина продакта, а аналитик подключается на деливери писать требования. На практике аналитик в дискавери незаменим, и вот чем.

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

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

Признак, что дискавери пропустили

Если на вопрос «а зачем мы это делаем и кому это поможет» в команде звучит «потому что попросили» или «product так решил» — дискавери не было, был только заказ. Это не значит, что надо бунтовать; это значит, что стоит тихо задать недостающие вопросы, пока фича ещё дёшево стоит. Иногда один вопрос «какую проблему решаем» в начале экономит спринт в конце.

Откуда это взялось

Идея, что продукт надо сначала открыть, а потом строить, выросла из продуктового движения конца 2000-х. Марти Каган (Silicon Valley Product Group) популяризировал понятие product discovery — отдельной работы по проверке, что стоит делать, до того как это делать. Термин dual-track приписывают команде, описавшей подход около 2007–2012 годов, а широко его разнесли Каган и Джефф Паттон (автор story mapping) примерно к 2012 году, переформулировав в «dual-track agile»: discovery и delivery не как две фазы, а как две непрерывные параллельные дорожки одной команды. Вырос подход как реакция на боль: команды по Scrum научились быстро делать, но всё так же быстро делали ненужное — не хватало дисциплины спросить «а то ли мы делаем».

Частые вопросы

Чем дискавери отличается от деливери?

Дискавери отвечает на вопрос «что и зачем делать»: есть ли проблема, кому она болит, какое решение её закроет и окупится ли оно — то есть стоит ли вообще это делать. Деливери отвечает на «как»: проектирование, разработка, тестирование и выкатка уже выбранного решения. Дискавери работает с неопределённостью и учит говорить «нет», деливери — с определённостью и инженерным качеством.

Почему нельзя пропускать дискавери?

Потому что цена неправильного «что» растёт по ходу проекта лавиной. Усомниться в идее на словах стоит часа, поймать ненужность на этапе требований — дня, а обнаружить, что качественно сделанная фича никому не нужна, уже в проде — это недели потраченного бюджета плюс упущенное время. Самый дорогой код — тот, который не надо было писать; дискавери отбрасывает плохую идею, пока она ещё почти ничего не стоит.

Что такое dual-track agile?

Это подход, где дискавери и деливери идут не последовательно (сначала всё исследовали, потом всё сделали), а двумя параллельными дорожками одновременно. На дорожке discovery проблема превращается в проверенные решения; на дорожке delivery проверенные решения превращаются в работающий продукт. В работу уходит только то, что прошло проверку, а обратная связь из прода рождает новые гипотезы для следующего витка дискавери.