Настоящая цена пропущенного этапа Discovery

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

Это самый дорогой срез угла в разработке. Не потому, что планирование свято, а потому, что вопросы, на которые отвечает discovery, не исчезают, когда вы его пропускаете. Просто ответы на них приходят позже — в продакшене, под нагрузкой, на глазах у клиентов и на кодовой базе, уже построенной вокруг неверных допущений. Именно тогда вопрос за $500 превращается в ответ за $50 000.

Что такое этап discovery на самом деле

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

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

Результат — Architecture Blueprint: карта, которая позволяет команде двигаться быстро, потому что дорогие решения уже приняты. Обычно это одна-две недели, а не месяцы.

Математика $500 против $50 000

Вот размен, который основатели совершают, не осознавая этого. Сфокусированный Discovery-спринт стоит фиксированные $500 и неделю-две. Пропуск стоит не ноль — он стоит того, сколько потом понадобится, чтобы развернуть неверные решения назад. А «потом» — самое дорогое место во всём жизненном цикле, чтобы что-либо менять.

Почему «потом» стоит настолько дороже

Решение, принятое на доске, меняется за полдня. То же решение, когда оно уже фундамент вашей модели данных, вашего API и полугода фич поверх, стоит переписывания — плюс миграция, плюс простой, плюс фичи, которые вы не выпустили, пока команда всё это распутывала.

Числа несимметричны. Discovery дёшев, потому что вы меняете идеи. Переписывание дорого, потому что вы меняете работающую систему, от которой зависят клиенты. Пропуск discovery не убирает стоимость «сделать архитектуру правильно» — он умножает её и переносит на худший из возможных моментов.

Где пропущенный discovery бьёт на самом деле

Ущерб редко проявляется одним драматичным сбоем. Он проявляется четырьмя более тихими и более дорогими.

Неверная модель данных

Модель данных — решение, которое наследует всё остальное. Ошибитесь в ней без discovery — и вы не узнаете об этом, пока не построите поверх десятки фич. Исправить её тогда — не рефакторинг, а миграция живых данных, обычно прямо во время использования продукта. Это самый частый триггер шестизначного переписывания.

Объём, которого вы не видели

Без discovery «сделать систему бронирования» звучит как один проект. А потом выясняется, что нужны платежи, возвраты, работа с часовыми поясами, политики отмены и уведомления — каждый сам по себе проект. Этот объём существовал всё это время. Discovery находит его, пока он ещё строка в дорожной карте, а не сюрприз посреди спринта.

Сюрпризы интеграций

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

Разговор о переписывании

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

Вы никогда не пропускаете стоимость «сделать архитектуру правильно». Вы лишь выбираете, платить за неё $500 или $50 000.

«Но мы уже знаем, что строим»

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

Чем яснее ваше видение, тем быстрее идёт discovery — потому что меньше нужно распутывать. Ясность в том, что вы строите, — ровно то, что делает решение как быстрым и дешёвым. Это не повод пропускать discovery; это причина, по которой discovery проходит легко.

Что вы реально уносите с собой

Хороший discovery-спринт намеренно малорисковый: фиксированная цена, фиксированный срок и конкретный результат в вашей полной собственности. В Reacto это одна-две недели, фиксированные $500 и Architecture Blueprint плюс дорожная карта, которые принадлежат вам — строите вы с нами, со своей командой или с кем угодно. Один раунд правок включён, так что Blueprint дорабатывается по вашим замечаниям, пока не станет действительно полезным.

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

Сколько discovery достаточно?

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

Для большинства продуктов ранней стадии это одна-две недели. На фоне стоимости переписывания — самая рентабельная неделя за весь проект.

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

Discovery — это не способ взять с меня денег до настоящей работы?

Справедливое опасение — поэтому хороший discovery-спринт фиксирован по цене, короток и производит то, что принадлежит вам независимо от следующих шагов. Если Blueprint полезен, только пока вы продолжаете платить тому же подрядчику, это был не discovery. Весь смысл в том, что дорожную карту можно отнести любой команде.

У нас жёсткий бюджет. Нельзя ли делать discovery по ходу разработки?

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

Чем это отличается от того, чтобы просто написать ТЗ?

ТЗ перечисляет, что продукт должен делать. Discovery решает, как его строить — архитектуру, модель данных, компромиссы — и проверяет ТЗ на прочность реальными техническими ограничениями. ТЗ говорит разработчикам, что строить; discovery говорит, как строить, чтобы не пришлось пересобирать.