Project Discovery: руководство основателя 2026 — как запустить ИТ-проект без переплат

Зачем Фора Софт написала этот гайд

Фора Софт занимается разработкой видео-, AI- и мультимедийного ПО с 2005 года. Мы провели сотни project discovery, в том числе те, что привели к запуску Scholarly (универсальная австралийская образовательная платформа, которая сейчас проводит онлайн-классы до 2 000 участников), Alve Live (стриминговая платформа на WebRTC) и Vodeo (нативное iOS-приложение для стриминга). Мы также не раз принимали проекты у других подрядчиков, где discovery пропускали, и первый месяц уходил на то, чтобы провести его заново.

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

Что такое project discovery (и чем он не является)

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

1. Что мы вообще строим? Не версию из питч-дека, а версию на уровне функций. Каждый экран, каждая роль, каждая сторонняя интеграция.

2. Для кого это? Какие пользователи платят, какие пользуются бесплатно и какое поведение отличает активного пользователя от того, кто уйдёт.

3. Какая самая дешёвая версия, которая всё ещё доказывает гипотезу? «Шагающий скелет» или MVP. Срезать 40% запланированных функций на этом этапе — это типично и здорово.

4. Где самые большие риски? Технические (это вообще реализуемо?), регуляторные (GDPR, HIPAA, COPPA, правила app-store), рыночные (это кому-то нужно?) и коммерческие (выйдем ли мы на самоокупаемость?).

5. Сколько это примерно стоит? Ориентировочный диапазон с явными допущениями, а не одна цифра, замаскированная под точность.

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

Почему пропустить discovery — самая дорогая ошибка в разработке

Отчёты CHAOS от Standish Group отслеживают результаты ИТ-проектов уже три десятилетия. Цифры почти не меняются: только около 31% проектов сдаются успешно, 50% попадают в категорию «проблемные» (опаздывают, выходят за бюджет или теряют функционал), 19% — провальные. Нечёткие требования — причина №1, опережает техническую сложность и проблемы в команде.

Исследование CB Insights, разобравшее 100+ закрытых стартапов, приходит к тому же выводу со стороны бизнеса: «нет спроса на рынке» и «не та команда» — две главные причины. И то, и другое можно обнаружить — подчеркнём, обнаружить — за двухнедельный discovery.

Математика затрат жёсткая. Ошибка, пойманная на discovery, стоит примерно 1x на исправление. Та же ошибка, пойманная в ходе разработки, стоит 10x. Пойманная после запуска, с живыми пользователями и реальными данными, обычно стоит 100x и больше. Это модель IBM по стоимости дефектов, и она работает везде — от потоков аутентификации до полного разворота функций. Невозможно «вытянуть инженерией» расплывчатое ТЗ, и попытки сделать вид, что можно, — это причина, по которой так много основателей чувствуют, что переплачивают разработчикам.

Три этапа discovery в Фора Софт

Каждая команда проводит discovery немного по-своему. У нас три этапа, потому что каждый отвечает на свой набор вопросов и даёт свой артефакт.

Весь цикл обычно занимает 2–3 календарные недели. Если подрядчик предлагает вам трёхмесячный discovery — уточните, что именно он производит. Честный ответ обычно такой: он проводит дизайн-спринты и называет их discovery, а это совсем другая услуга, в 3–5 раз дороже.

Почему первый звонок — живой, а не форма

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

Discovery для существующего продукта — это другой зверь

Если у вас уже есть работающий продукт, discovery меньше про «что строить» и больше про «что у нас есть». На месте этапа ideation у нас аудит кода:

• Проверка кода. Архитектура, покрытие тестами, состояние зависимостей, известные CVE, пайплайн деплоя, наблюдаемость.

• UX-аудит. Ключевые потоки прошагиваются от начала до конца. Отмечаем тупики, путаные состояния, проблемы с доступностью.

• Аудит инфраструктуры. Модель стоимости, потолок масштабирования, vendor lock-in, требования к локализации данных, готовность к комплаенсу.

• Разбор legacy. Что нужно переписать сейчас, что можно оставить и что лучше отделить за новым сервисом.

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

С чем вы должны выйти из discovery

Полезный итог discovery достаточно тонкий, чтобы прочитать за один присест, и достаточно конкретный, чтобы передать другому подрядчику для встречного предложения. Всё, что тяжелее, — обычно маркетинговый материал, выданный за план.

Сколько discovery должен стоить и сколько длиться

Поскольку Фора Софт использует agent-assisted разработку — опытные инженеры плюс LLM-инструменты для кода и анализа — наши discovery обычно короче и дешевле, чем типовые расценки агентств. Диапазоны ниже отражают недавние проекты, а не отраслевые бенчмарки.

Первая консультация всегда бесплатна. Оплачиваемый discovery начинается только после того, как обе стороны согласились, что проект реальный, а объём оправдывает работу. Тот, кто берёт пятизначные суммы за часовой звонок про продажу, делает другой бизнес.

Тревожные сигналы — как распознать discovery, который на самом деле презентация продаж

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

1. На звонке нет технического человека. Если ваш discovery ведёт продажник с презентацией — возражайте. Хороший discovery требует опытного инженера, который реагирует на ограничения вживую. Discovery, который ведут продажи, выдаёт списки функций — оптимистичные по трудозатратам и скромные по рискам.

2. Оценки одним числом. «10 650 000 ₽» в качестве итога — это не оценка, это цель по продажам. Легитимный discovery выдаёт диапазон с явными допущениями. Подробнее — почему оценки сроков у разработчиков не сходятся.

3. Discovery длится дольше, чем сам MVP. Трёхмесячный discovery под двухмесячную сборку означает, что вы финансируете чьё-то дизайн-упражнение. Discovery — это топливо для разработки, а не её замена.

4. В результате нет реестра рисков. Если в артефактах нет топ 5–10 вещей, которые могут пойти не так, команда не подумала достаточно глубоко. Или не хочет, чтобы подумали вы.

5. Результат завязан на подрядчика. Хороший discovery можно передать любому компетентному подрядчику для встречного предложения. Если артефакты требуют проприетарных инструментов или приватного доступа, вас привязывают.

Как основателю подготовиться к discovery

Хороший discovery даёт подрядчику 80% картины. Задача основателя — принести оставшиеся 20%, то, что живёт у него в голове и больше нигде. Четыре конкретных документа экономят время и деньги обеим сторонам:

1. Одностраничный «что и зачем». Не презентация. Страница. Что вы строите, для кого и почему думаете, что они заплатят. Если вы не можете уместить это в одну страницу, вы пока не знаете свой продукт.

2. Список 3–5 конкурентов. Названия и ссылки. Какие ближе всего, какие вы хотите превзойти по функционалу, какие явно не хотите копировать.

3. Короткий список «без вариантов». Регуляторные (HIPAA, GDPR, COPPA), технические (должно работать on-prem; обязательная интеграция с Salesforce), коммерческие (должно быть запущено до раунда финансирования).

4. Потолок бюджета. Не обязательно финальное число, но то, за которое вы не пойдёте. Зная его, подрядчик спроектирует правильный MVP, а не оценит неправильный.

Мини-кейс — discovery, который срезал объём на 45%

Основатель EdTech-стартапа пришёл к нам с идеей «учебная платформа с AI-репетиторами, видеоклассами, генерацией домашек, родительским кабинетом, аналитикой и маркетплейсом». Изначальная оценка другого подрядчика — восемь месяцев и сумма в высокий шестизначный диапазон в долларах. Они хотели второе мнение.

Наш двухнедельный discovery дал таблицу функций с MoSCoW-приоритетами. Около 45% изначального объёма ушло в «потом» — не потому что плохо, а потому что не доказывало ключевую гипотезу: «будут ли платящие родители реально подписываться на AI-репетиторство?». Мы предложили MVP с видеоклассами, одним потоком AI-репетитора и оплатой через Stripe; всё остальное — в очередь.

Урезанный MVP запустился за двенадцать недель примерно за половину изначального бюджета. Когда основатель вернулся через девять месяцев достраивать остальное, он делал это уже с реальными данными об использовании, а не предположениями — и две из исходных must-have-функций превратились в «не строим». Хотите похожее упражнение? Позвоните нам — и мы разберём ваш объём вживую.

Discovery vs дизайн-спринт vs полное техническое ТЗ — выберите правильный инструмент

Три формата работы постоянно путают. Они отвечают на разные вопросы и стоят очень разных денег.

Для большинства основателей discovery — правильная отправная точка. Дизайн-спринты помогают, когда вы не уверены, работает ли сама идея. Полное техническое ТЗ обычно преждевременно — оно уместно после discovery, когда объём зафиксирован, или для регулируемых либо контрактных передач между командами.

Пять ловушек, которые делают discovery бесполезным

1. Discovery без реального разговора о сборке. Если команда, проводящая discovery, не будет строить продукт, цифры и риски — спекуляция. Сначала договоритесь с командой, потом проводите discovery.

2. Старт с идеально отрисованных макетов. Полированный UI дорогой и преждевременно фиксирует объём. Вайрфреймы и схемы потоков достаточны для оценки. Hi-fi-дизайн — задача этапа разработки.

3. Пропуск разговора «срезаем 40%». Если на scoping не срезают функции агрессивно, основатель срежет их позже — в 10 раз дороже, когда закончится бюджет. Режьте рано и часто.

4. Нет явных допущений. Каждая оценка стоит на допущениях («3 роли пользователей», «только Stripe», «только английский»). Запишите их в результат. Когда реальность отличается, разрыв виден и его можно перезаключить.

5. Игнорирование стоимости эксплуатации. Discovery, который оценивает только часы разработки и пропускает хостинг, сторонние API, комплаенс и поддержку, может ошибиться на 30–50% по совокупной стоимости первого года. Всегда оценивайте операционные расходы, а не только разработку. Подробнее — как сократить расходы на ИТ-проект.

Фреймворк решения — нужен ли вам discovery и насколько глубокий

В1. Вы подписываете контракт на разработку с фиксированной ценой? Да → discovery обязателен; без него никто не оценит фиксированную цену. Нет → discovery всё равно рекомендуем, но в облегчённом виде.

В2. Это регулируемая область (медицина, финансы, образование, пользователи младше 13)? Да → формальный discovery с проверкой комплаенса — без вариантов. Нет → лёгкого discovery может хватить.

В3. У вас есть существующая кодовая база? Да → замените ideation аудитом кода. Нет → полный поток discovery нового продукта.

В4. Потолок вашего бюджета меньше 1,8 млн ₽? Да → одной недели облегчённого discovery достаточно; более долгий съест бюджет разработки. Нет → инвестируйте 2–3 недели; окупится.

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

KPI — как понять, что ваш discovery был хорош

KPI точности. Уложилась ли финальная сборка в верхнюю оценку discovery (цель — да)? Остался ли процент изменений объёма во время разработки ниже 20%? Сработал ли хоть один риск из реестра — и помогли ли меры?

KPI решения. Принял ли основатель чёткое «да / нет» после прочтения результата (цель — в ту же неделю)? Использовал ли он результат, чтобы получить хотя бы одно встречное предложение (хороший признак)? Почувствовал ли он, что понял компромиссы (если нет — discovery не дотянул)?

KPI скорости. Стартовала ли разработка в течение 2–4 недель после закрытия discovery (цель — да)? Сдалась ли первая рабочая часть в сроки первого этапа (цель — в пределах 10%)? Удалось ли команде не возвращаться к вопросам discovery после второй недели разработки (цель — да; если нет, discovery был слишком поверхностным)?

Когда можно пропустить полноценный discovery

Discovery — инструмент, а не религия. Пропустите или сократите его, когда:

• Сборка крошечная. Двухнедельный лендинг не требует трёхнедельного discovery. Хватит 30-минутного звонка и одностраничного брифа.

• Вы работаете по time-and-materials с командой, которой доверяете. Артефакты discovery значат меньше, потому что вы можете корректировать курс на ходу.

• Это одноразовый прототип. Демо для инвестора, спайк, проверка дизайна. Сначала запустите, потом, если выживет, проведите discovery.

• У вас уже есть валидированное ТЗ и нужны только руки. Это редкость, но бывает. Сразу к SoW.

Что происходит после discovery

Завершённый discovery напрямую переходит в этап аналитики: user stories, критерии приёмки, дизайн-система, API-контракты, спринт-план. Каждый артефакт развивается, а не изобретается заново. Список функций становится бэклогом; набросок архитектуры — системным дизайном; реестр рисков — чек-листом нулевого спринта.

Основатели, которые относятся к discovery как к концу планирования и началу выполнения, возвращают вложения в 3–5 раз уже в первом этапе разработки. Те, кто видят в нём галочку перед подписанием фиксированного SoW, обычно перезаключают контракт на полпути. Избежать этого можно, реагируя на отклонения от графика заранее, а не на ретроспективе спринта.

FAQ

Сколько времени занимает discovery ИТ-проекта?

Типовой discovery нового продукта — 1–3 недели от начала до конца. Небольшие MVP укладываются в 5–8 дней; средние продукты — 8–12 дней; сложные или регулируемые — 2–4 недели. Всё, что дольше, обычно уже другой формат работы (дизайн-спринт или полное техническое ТЗ).

Сколько должен стоить discovery?

В Фора Софт платные discovery обычно занимают 8–80 оплачиваемых часов в зависимости от объёма. Первая консультация всегда бесплатна. Остерегайтесь тех, кто называет огромные фиксированные ценники за «discovery workshop», не умея в деталях описать, что именно вы получите.

Можно ли пропустить discovery, если у меня уже есть детальное ТЗ?

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

Каких результатов ожидать?

Шесть вещей: список функций с MoSCoW-приоритетами, одностраничный набросок архитектуры с 2–3 компромиссами, диапазон бюджета «минимум / вероятный / максимум», поэтапные сроки, реестр топ-10 рисков и 2–3 рекомендации по стеку. Меньше — неполно; больше — обычно лишнее.

Discovery — это то же самое, что написание технического ТЗ?

Нет. Техническое ТЗ — это детальный документ по реализации, обычно 30–100 страниц, который пишут после фиксации объёма. Discovery — это 1–3-недельный этап планирования, на котором решают, какой объём фиксировать. ТЗ без discovery обычно переинженеривает не тот продукт.

Что делать, если discovery покажет, что идея нежизнеспособна?

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

Можно ли передать результат discovery другому подрядчику?

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

В чём разница между discovery и дизайн-спринтом?

Дизайн-спринт отвечает на «стоит ли вообще строить эту идею?» — прототипом и пользовательскими тестами. Discovery отвечает на «какая самая дешёвая полезная сборка?» — списком функций и оценками. Они дополняют друг друга: спринт — когда концепция не доказана, discovery — когда концепция задана, а план сборки — нет.

Что читать дальше

Готовы начать проект правильно?

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

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