Как спланировать IT-проект в 2026 году: руководство для основателя

Почему Фора Софт написала этот гайд по планированию IT-проектов

Фора Софт выпустила более 625 IT-продуктов за 20+ лет работы, и фазу discovery мы прошли в каждом из них. Гайд ниже отражает то, что реально работает для основателей: что мы делаем в первый день работы с новым клиентом, в каком порядке, с какими артефактами и по какой стоимости. Это не аспирация — это наш рабочий чек-лист.

Несколько конкретных проектов, на которых основан этот опыт: BrainCert, обучающая платформа, которую мы планируем и развиваем больше десяти лет, выросла из идеи с одной функцией в продукт с годовой выручкой 750 млн ₽, обслуживающий более 100 000 клиентов и 500 млн+ минут живых занятий. AppyBee прошла путь от вайрфреймов до 800+ фитнес-центров с приростом удержания на 20% после запуска запланированного MVP. VALT запустился на 770+ организаций в правоохранительной и медицинской сферах поверх фазы планирования, на которой мы разобрали каждый крайний случай по комплаенсу до того, как была написана первая строка production-кода.

Эти результаты построены на дисциплине на этапе планирования, а не на героизме на этапе разработки. Эта статья упаковывает эту дисциплину. Если вы хотите сразу перейти к применению её к своему проекту, наша услуга по планированию продукта предполагает структурированный discovery за 3–5 недель с участием старшего продуктового стратега, архитектора решений и пары Agent Engineering.

Почему IT-проекты проваливаются — и почему планирование решает большую часть этих проблем

Цифры неумолимы. Отчёт Standish Group CHAOS из года в год показывает, что только около 31% IT-проектов завершаются полностью успешно (в срок, в бюджет и в обещанном объёме). Половина — «проблемные»: с задержками, перерасходом или урезанным объёмом, а примерно 19% отменяются вовсе. Проекты дороже 750 млн ₽ примерно в 10 раз чаще отменяются, чем проекты до 75 млн ₽. Масштабное исследование McKinsey по IT добавляет: корпоративные проекты в среднем превышают бюджет на 45%, сроки на 7% и приносят на 56% меньше ценности, чем планировалось.

Когда исследователи копают корневую причину, ответ обычно один: плохие требования. Project Management Institute сообщает, что около 71% проектов встраиваемого ПО проваливается из-за плохого управления требованиями. Infotech фиксирует ту же закономерность в IT в целом: неясные требования провоцируют около 70% провалов, а примерно половина всех проектов требует доработки по этой же причине. Это не баг отрасли — это самый мощный рычаг, который есть у основателя.

Арифметика расходов вытекает напрямую. Бенчмарк IBM Systems Sciences Institute — широко цитируемый и до сих пор актуальный — показывает: исправление дефекта на этапе требований стоит 1x, на этапе реализации — около 6,5x, на этапе тестирования — около 15x, а в production — 60–100x. Консорциум по качеству ПО (CISQ) оценивает общие потери США от плохого качества кода примерно в 180 трлн ₽ в год, и большая часть этих потерь восходит к решениям, принятым на этапе планирования. Именно поэтому планирование — не «приятное дополнение», а самое высокорентабельное действие во всём проекте.

Дуга планирования — от наброска на салфетке до согласованного MVP

Полная дуга планирования выглядит одинаково, стоит проект 3,7 млн ₽ или 37 млн ₽ — меняется только глубина каждого шага. Ниже — как мы выстраиваем её в Фора Софт, с типичными временными рамками для работы с основателями.

Итого: обычно 4–8 недель end-to-end, на уровне 10–15% от итогового бюджета сборки. Если кто-то предлагает пропустить этапы 2–4, чтобы «быстрее начать кодить» — вам продают будущую доработку. Эта структура дополняет наш более широкий пошаговый процесс разработки продукта, который описывает, что происходит после завершения планирования.

Discovery — самые рентабельные две недели в проекте

Discovery — это этап, на котором туманное «Uber для X» превращается в проработанный продукт. Он занимает ~10–15% стоимости проекта и регулярно экономит в 3–5 раз больше за счёт предотвращённой доработки. Пропускать его — самая частая самонаведённая рана у основателей, обжёгшихся на прошлом подрядчике.

Что происходит во время discovery

1. Интервью со стейкхолдерами. По 30–60 минут с каждым: основатель, 3–5 целевых пользователей, любой отраслевой эксперт (медицина, право, финансы), любой операционный владелец, который будет вести продукт изо дня в день. На выходе — сведённая карта болей.

2. Конкурентный скан. Топ 5–7 прямых конкурентов плюс 2–3 смежных продукта, разобранные по функциям, ценам, пробелам и жалобам в отзывах. На выходе: матрица паритета функций и список «так не делать».

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

4. Оценка возможностей. Реалистичные цифры по размеру рынка, ценообразованию, модели выручки, юнит-экономике. Мы опираемся на публичные бенчмарки, где это возможно — наш гайд по выручке приложений содержит распределения по рынку.

5. Поиск скрытых требований. Негативные сценарии, обработка ошибок, регуляторные требования (GDPR, HIPAA, WCAG 2.2), допущения по масштабируемости, i18n/локализация, аналитика, потоки поддержки. Около 30% требований, которые мы в итоге пишем, рождаются именно на этом этапе.

PRD, пользовательские истории и искусство писать хорошие требования

Требования — это то, на чём проекты живут или умирают. Основной артефакт — Product Requirements Document (PRD): единый источник правды, в котором фиксируются проблема, аудитория, объём, функции, критерии приёмки, ограничения, метрики успеха и явно вынесенные не-цели. Современные PRD лёгкие (10–30 страниц, не 150) и версионируются в том же инструменте, которым команда пользуется ежедневно (Notion, Confluence, Linear docs).

Пользовательские истории, по которым разработчик действительно может строить

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

STORY: Guest checkout for the storefront
As a first-time visitor
I want to check out without creating an account
So that I can buy quickly and decide later whether to register

ACCEPTANCE CRITERIA:
- [ ] User can complete a purchase with email + shipping only (no password)
- [ ] After payment, user sees a one-click "Save my info" CTA
- [ ] If user abandons at payment, email is captured for recovery flow
- [ ] Order is linkable to a created account later via email match
- [ ] Feature can be toggled off per-store via a feature flag
- [ ] Analytics event "guest_checkout_completed" fires with order_id

OUT OF SCOPE:
- Guest wishlists (v1.1)
- Guest order tracking dashboard (v1.1)

MoSCoW — рамка приоритизации, о которой основатели забывают

MoSCoW делит каждое требование на Must, Should, Could и Won’t. Критичный пункт — «Won’t»: он фиксирует функции, которые вы осознанно решили не делать, чтобы разговор не возвращался к ним посреди спринта. У здорового MVP примерно 60% Must, 20% Should, 15% Could и явный список Won’t.

Расползание объёма (scope creep), главный убийца сроков, — это просто то, что происходит, когда ваш список Must растёт посреди сборки без соответствующего расширения бюджета или сроков. Заморозьте список после планирования; пропускайте каждую новую идею через формальный change-control. Подробнее о том, что происходит, когда оценка начинает плыть, — в нашем гайде почему оценки разработчиков промахиваются.

Вайрфреймы, макеты и прототипы — для чего нужен каждый

Эти три слова часто путают. А не следовало бы. Каждый отвечает на свой вопрос, делается с разной скоростью и используется на разной фазе.

Наш подробный гайд по вайрфреймам разбирает трейд-оффы в деталях; короткая версия — кликабельный прототип, даже низкодетализированный, — самый ценный артефакт всей фазы планирования. Он ловит дизайн-проблемы там, где их исправление почти бесплатно, и снимает 80% будущих запросов на изменения вида «стойте, я думал, это работает иначе».

Объём MVP — что включать и что отрезать

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

Бюджетные коридоры и что они покупают

Lean MVP (8–12 недель). Одна платформа (веб или мобильная), базовая аутентификация, 3–5 ключевых сценариев, одна-две сторонние интеграции, минимальная админка, без AI, без регулируемых функций. Цель — «могут ли пользователи пройти сценарий целиком», а не «тянет ли это миллион».

Validated MVP (16–24 недели). Две платформы (адаптивный веб + iOS или Android), управление пользователями, 2–4 интеграции, лёгкая аналитика, базовая админ-панель, поток онбординга. Достаточная поверхность, чтобы запустить настоящую бету на 100–1000 пользователей.

Scale-ready MVP (24–36 недель). Полный веб + нативная мобильная разработка, ролевой доступ, мультитенантная архитектура, каркас под комплаенс (GDPR или HIPAA), реальная аналитика, платежи, админ-инструменты, локализованный контент. Это то, что мы строили для продуктов вроде AppyBee и Vodeo перед их платным запуском.

Конкретные диапазоны стоимости и то, как они соотносятся с функционалом, разобраны в нашем гайде по стоимости мобильной разработки на 2026 год — там тот же спектр для мобильной части. Поскольку мы используем Agent Engineering для черновиков спецификаций, генерации шаблонного кода и тестового покрытия, оценки Фора Софт на сопоставимый объём обычно выходят быстрее и ниже, чем у традиционных агентств — и эту экономию мы транслируем клиенту, а не оставляем себе в маржу.

Оценка — почему любая честная оценка — это диапазон

Любой, кто называет вам одно число до завершения планирования, либо обманывает, либо вот-вот потеряет деньги. Оценки — это распределения вероятностей, а не точки. Профессиональный способ цитировать — доверительный интервал (P50/P90), который сужается по мере прохождения планирования.

На этапе предварительного объёма (до discovery): диапазон порядка ±100%. Пример: «от 6 до 15 млн ₽». Что-то более узкое — иллюзия точности.

После discovery: ±50%. Пример: «от 9 до 13 млн ₽». На этом этапе мы понимаем форму работы и основные риски.

После вайрфреймов + техспецификации: ±20–30%. Пример: «от 10 до 12 млн ₽, плюс резерв 750 тыс. ₽». Здесь уже подписывается настоящий контракт.

Для оценки на уровне отдельных историй внутри сборки большинство Agile-команд используют относительные story points (числа Фибоначчи 1, 2, 3, 5, 8, 13) или размеры маек (XS/S/M/L/XL) с калибровкой по Planning Poker. Абсолютные оценки в часах для отдельных историй почти всегда ошибочны; относительные оценки в среднем верны и сходятся к корректной скорости за 2–3 спринта.

Agile, Waterfall или гибрид — выбирайте по ограничениям

Лучший процесс — тот, что соответствует тому, насколько вы уверены в объёме.

Waterfall уместен, когда требования действительно зафиксированы (регулируемые медицинские устройства, аэрокосмическая отрасль, встраиваемая прошивка, миграции инфраструктуры) и стоимость поздних изменений катастрофична. Полноценный waterfall-проект требует 20–40% всех усилий на планирование. Для большинства потребительского и B2B-софта это перебор.

Agile (Scrum, Kanban, ShapeUp) — стандарт для новых продуктов. Он предполагает, что вы учитесь по ходу, и встраивает это обучение в 1–2-недельные циклы. Планирование непрерывное: тяжёлый discovery на старте, затем лёгкое планирование внутри каждого спринта, пока проект идёт. 85% проектов, которые выпускает Фора Софт, используют ту или иную разновидность Agile.

Гибрид (зафиксированная архитектура с гибкой надстройкой) подходит, когда часть системы действительно жёстко зафиксирована — железо, сертифицированный бэкенд, юридически предписанный процесс, — а UX сверху должен эволюционировать. Планируйте фиксированную часть по waterfall, остальное ведите по Agile.

Пять рисков, убивающих IT-проекты — и митигации на этапе планирования

1. Расползание объёма (scope creep). Самый частый убийца. Митигация: заморозить объём MVP после планирования, использовать MoSCoW и пропускать каждый запрос на изменение через формальную записку об изменении с оценкой стоимости и сроков. Наш гайд что делать, если ожидания расходятся с реальностью описывает типичные сценарии провалов.

2. Размытые требования. У каждой истории должны быть критерии приёмки и один владелец; каждое требование должно прослеживаться до пользовательской потребности. Одно это устраняет около половины риска доработок.

3. Слишком оптимистичные оценки. Используйте 3-точечный PERT или размеры маек с явными доверительными интервалами; добавляйте 10–20% резерва на всё новое. Подкладывайте подушку на кривую обучения, если технология незнакома.

4. Единичные точки отказа. Проблема «автобусного фактора» — всё знает один человек. Митигация: парное программирование, документация в письменном виде и обязательный 30-минутный еженедельный слот обмена знаниями. У хорошего подрядчика это уже встроено.

5. Отложенное тестирование. «Протестируем в конце» — классический убийца. Тестирование начинается на этапе вайрфреймов (проверка адекватности потока), идёт через юнит-тесты в сборке и включает юзабилити-тестирование прототипа. Наш гайд по тестированию на каждом этапе разработки даёт развёрнутую версию.

Как выбрать правильного партнёра — красные и зелёные флаги

Хороший партнёр по планированию стоит того, чтобы платить. Вот как отличить одного от другого за 45-минутный звонок с продавцом.

Красные флаги

1. Фиксированная цена до discovery. Они либо не понимают риска, либо ценятся под выигрыш сделки и потом перевыставят счёт через change-orders.

2. «Мы умеем всё». Зрелый подрядчик отказывается от части проектов, потому что видит объём, который не сделает хорошо. Универсальная компетентность — это маркетинговый питч, а не способность.

3. Никакой фазы discovery в предложении. Если они называют цену сборки без плана на проработку объёма — они планируют учиться за ваш счёт.

4. Нет портфолио или поимённых референсов. Кейсы должны быть конкретными и проверяемыми: реальные клиенты, реальные метрики, реальные результаты. Универсальное «NDA запрещает называть имена» на каждом проекте — это сигнал.

5. Отсутствующие строки в оценке. Нет бюджета на тестирование, нет discovery, нет DevOps, нет резерва — вы за это заплатите позже, просто в исходной цене этого не будет.

Зелёные флаги

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

Модели сотрудничества — in-house, агентство, выделенная команда или фрилансер

Фрилансер. На 30–50% дешевле агентства на одной задаче, быстрее всех запускается, нулевые накладные расходы. Цена: вы становитесь project-менеджером, «автобусный фактор» равен единице, последующая поддержка на вас. Правильный выбор для хорошо проработанной функции или спайка на 2–3 недели.

Агентство (фиксированный объём). Полная команда, гарантированная сдача, формальный контракт. Подходит, когда нужно 5+ специалистов под проработанную сборку и вы не ищете долгосрочного партнёрства. Цена: премия 30–60% к прямой инженерной стоимости.

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

Staff augmentation. Добавление 1–3 специалистов в существующую in-house команду. Хорошо, когда у вас есть руководство, но не хватает мощности; плохо, когда нужна end-to-end ответственность.

In-house. Долгосрочные, глубокоэкспертные продукты со стабильным финансированием. Медленно нанимать, дорого масштабировать, лучшие результаты — когда продукт и есть компания.

Как AI и Agent Engineering меняют фазу планирования

2025–2026 годы — первый цикл, в котором AI-инструменты материально сжимают фазу планирования. Чистый эффект для проекта Фора Софт — примерно 30–40% сокращения времени discovery при сопоставимом или лучшем качестве. Откуда именно идёт экономия:

1. Черновики PRD. Инструменты вроде Figma AI PRD, Miro AI, Beam.ai и специализированных AI-агентов превращают сырые заметки исследований, транскрипты и наброски в структурированный черновик PRD за часы, а не дни. Черновик всё равно требует редактирования человеком, но вы начинаете разговор с версии 2, а не с версии 0.

2. Синтез исследований. AI-ассистированный синтез интервью кластеризует 20 транскриптов пользовательских интервью по темам за минуты. Аналитик всё ещё валидирует кластеризацию, но рутина чтения и разметки сокращается на порядок.

3. Конкурентный анализ. Агент может пройти 20 сайтов конкурентов, собрать ценообразование, матрицы функций и темы отзывов и за ночь вернуть структурированное сравнение. Аналитик валидирует; рутина исчезает.

4. Первый прогон вайрфреймов. AI-сгенерированные вайрфреймы по текстовому описанию или скриншоту теперь годятся как стартовая точка. Ожидайте, что переделаете 60–70% из них, но вы редактируете, а не изобретаете.

5. Стресс-тест оценок. AI-ассистированная оценка может проверить распределение story points против исторической скорости похожих проектов, отлавливая оптимистичные выбросы до того, как они попадут в коммерческое предложение.

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

Сравнение моделей сотрудничества с одного взгляда

Мини-кейс — как 4-недельный спринт планирования спас сборку на 13 млн ₽

Ситуация. К нам пришёл основатель с одностраничной идеей продукта для телемедицинского планирования и трёхстрочной офертой конкурента: «соберём за 10 недель за 7 млн ₽, фикс-цена». Другое агентство предлагало 12 млн ₽ за 16 недель. Основатель склонялся к более дешёвому варианту.

4-недельный спринт планирования. Наша команда провела интервью со стейкхолдерами: с основателем, тремя потенциальными клиниками и одним специалистом по комплаенсу HIPAA. Конкурентный анализ выявил 14 функций у лидеров рынка и 9 функций, которые активно убирались, потому что ими никто не пользовался. Техническая проверка реализуемости выделила две критичные интеграции (Stripe для депозитов, Twilio для SMS-напоминаний) и один реальный риск (HIPAA-уровень аудит-логов, которого в предложении на 7 млн ₽ не было). Кликабельный прототип прогнали через пять пользователей; два потока переделали целиком.

Результат. Стоимость планирования: 1,6 млн ₽. Оценка сборки после плана: 10 млн ₽ ± 20% за 18 недель, с комплаенсом HIPAA, встроенным в основу, и чистым объёмом MVP. Дешёвое предложение за 7 млн ₽ привело бы к продукту, не соответствующему требованиям, который пришлось бы переделывать за 4,5–6,7 млн ₽ до того, как он сможет обслуживать реальных клиентов — консервативная оценка на основе наших проектов по доработке. Основатель запустил продукт по плану, и за первый квартал к нему подключились 42 клиники.

Фреймворк решений — планирование IT-проекта в пяти вопросах

В1. У вас есть письменный однострочник с описанием проблемы, целевого пользователя и основной гипотезы? Если нет — остановитесь и напишите его до общения с любым подрядчиком. Это сэкономит 2–3 недели недопонимания.

В2. Пытался ли кто-то извне вашей команды разнести идею в пух и прах? Пригласите скептика в discovery. Основатели, которые не могут назвать свои три главных риска, вот-вот оплатят чужое обучение.

В3. Сформулирован ли ваш MVP как гипотеза, а не как список функций? «Если мы построим X, пользователи сделают Y за Z дней» — если так сформулировать не получается, у вас не MVP, у вас вишлист.

В4. Вы посчитали стоимость всего стека, а не только сборки? Тестирование (обычно 20–30% сборки), DevOps (~10%), discovery (~10–15%), резерв (~10–20%), последующая поддержка (~15–20% в год от сборки). Если что-то из этого упущено — проект на 11 млн ₽ превращается в 18 млн ₽.

В5. Есть ли план того, что произойдёт после запуска MVP? Запланированные v1.1 и v1.2 заставляют честно подходить к объёму MVP — легче оставить функцию за бортом, когда вы точно знаете, когда именно она появится.

Пять ловушек планирования, которых стоит избегать

1. «Мы и так знаем, что нужно пользователям». Нет, не знаете. Даже если вы правы по сути, вы неправы на краях. Проведите discovery всё равно — ROI слишком высокая, чтобы пропускать.

2. Замораживать план на первой оценке. Ранние числа имеют точность порядка; планирование должно сужать их данными, а не фиксировать. Основатели, которые требуют одно число вперёд, получают либо ложь, либо «запас на всё».

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

4. Гнаться за самой дешёвой ценой. Цена на 40% ниже рынка либо означает непонимание задачи, либо вернётся к вам налогом на change-orders. Сравнивайте предложения по паритету объёма, а не по ярлыку с ценой.

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

KPI — как измерить качество планирования

KPI качества. Отклонение оценки (факт против плана по времени сборки, цель ±20%), выход дефектов (баги, найденные после запуска, на 1000 строк кода, цель < 0,5), доля переоткрытий (истории, переоткрытые после согласования, цель < 10%). Они говорят, насколько план соответствовал реальности.

KPI бизнеса. Время до первого клиента (недели от запуска MVP до первого платящего пользователя, цель < 8), доля активации (% зарегистрировавшихся, дошедших до момента «ага!», цель > 30%), стоимость одной проверенной гипотезы (расходы планирования + сборки на одну подтверждённую гипотезу). Они говорят, является ли проект на самом деле бизнесом.

KPI процесса. Длительность discovery (цель 2–4 недели), доля планирования в общем бюджете (цель 10–15%), объём change-order на спринт (цель < 2), доля спринтов, закрытых в срок (цель > 80%). Они говорят, насколько хорошо команда исполняет.

Когда тяжёлое планирование НЕ нужно

Интенсивность планирования должна соответствовать риску проекта. Несколько сценариев, в которых обычный совет неверен:

1. Настоящий выбрасываемый прототип. Если цель — просто показать 10-минутное демо инвестору и потом удалить код, напишите полстраницы спецификации и выпустите прототип на Bubble/Retool за неделю. PRD для одноразового прототипа не нужен.

2. Внутренний инструмент дешевле 1,5 млн ₽. Один пользователь, один процесс, известные ограничения. Достаточно полудня на проработку объёма и чёткого чек-листа приёмки.

3. Инкрементальные функции в зрелом продукте. Если платформа, аудитория и дизайн-система устоялись, планирование сжимается до пользовательских историй + критериев приёмки + плана выкатки. Полная дуга discovery — перебор.

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

FAQ

Сколько должно стоить планирование IT-проекта в процентах от общего бюджета?

Закладывайте 10–15% от итоговой стоимости сборки на планирование. На проекте за 11 млн ₽ это 1,1–1,6 млн ₽. Агентства, которые называют цену без строки на планирование, прячут эту стоимость и потом выставляют её обратно через change-orders. Планирование регулярно экономит в 3–5 раз больше за счёт предотвращённой доработки.

Сколько должна занимать фаза discovery?

Обычно 2–6 недель. Простые одноплатформенные продукты: 2–3 недели. Средняя сложность с несколькими интеграциями: 4–6 недель. Регулируемые или корпоративные: 6–8 недель. С AI-ассистированным синтезом исследований и черновиками PRD проекты средней сложности теперь закрывают discovery за 3–4 недели.

В чём разница между вайрфреймом и прототипом?

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

Что должно быть в MVP?

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

Может ли AI написать PRD за меня?

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

Когда выбирать Agile, а когда Waterfall?

Используйте Agile для новых продуктов, в которых вы ожидаете учиться по ходу — это почти любой потребительский и B2B-проект. Используйте Waterfall только когда объём действительно зафиксирован, а стоимость поздних изменений катастрофична (регулируемые медицинские устройства, аэрокосмос, встраиваемая прошивка). Гибрид подходит, когда железо или комплаенс жёстко зафиксированы, но UX должен эволюционировать.

Как оценить партнёра по разработке?

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

Какой резерв закладывать?

10–20% от бюджета сборки — стандарт. Ближе к 10% для хорошо проработанной инкрементальной работы на зрелом продукте; ближе к 20% для нового продукта, новых интеграций или всего, что касается регулируемых данных. Не соглашайтесь на контракт с нулевым резервом — это просто значит, что подрядчик будет выставлять каждый крайний случай как change-order.

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

Готовы спланировать IT-проект, который сдастся в срок и в бюджет?

Грамотно проведённая фаза планирования — не накладные расходы, а самая дешёвая страховка, которую вы когда-либо купите против заложенной в отрасль доли провалов в 50–70%. Десять-пятнадцать процентов бюджета проекта, вложенные на старте в discovery, требования, вайрфреймы и кликабельный прототип, возвращаются три-пять раз в виде предотвращённых доработок и тупиков.

Приёмы не меняются: структурированный discovery, письменный PRD, карта пользовательских историй с критериями приёмки, кликабельный прототип, объём, упорядоченный по MoSCoW, оценка-диапазон, поимённая команда и процесс заморозки с change-control. Agent Engineering делает каждый из этих шагов быстрее и дешевле, чем раньше; но не делает их необязательными. Если вы хотите партнёра, который относится к планированию как к самой высокорентабельной работе в проекте, — это то, что делала Фора Софт на 625+ продуктах и продолжает делать.