Как создаётся ПО: гид по семи фазам разработки продукта в 2026 году

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

С 2005 года мы выпустили 625+ программных продуктов — от инди-приложений одного автора до мультитенантных SaaS-платформ вроде BrainCert (750 млн ₽ годовой выручки) и платформ для live-стриминга, таких как TradeCaster (46 000+ пользователей). Наши команды работают двухнедельными спринтами, деплоят каждые несколько дней и объединяют senior-инженеров с AI-инструментами для написания кода, что сократило типовые сроки проектов на 20–35% по сравнению с 2022 годом.

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

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

Семь фаз разработки ПО в одной таблице

Любое грамотное агентство ведёт проект по одному и тому же конвейеру. Названия фаз могут отличаться — «inception» вместо «discovery», «build» вместо «development» — но сами фазы остаются.

Для быстро очерченного MVP эти фазы сжимаются в 3–5 календарных месяцев. Для корпоративной платформы с накладными расходами на комплаенс растягиваются на 9–14 месяцев. Мы распределяем недельные доли при планировании; пропорции редко бывают 1/1/1/1.

Фаза 1 — Discovery: превращаем идею на салфетке в план

Discovery — самое дешёвое снижение рисков, которое вообще можно купить. Здесь «мы думаем, пользователям нужно X» превращается в «мы измерили, что эти пять пользовательских сценариев имеют значение, и вот их оценённая стоимость». Standish CHAOS говорит об одном и том же уже 30 лет: чёткие требования — фактор успеха №1.

Фора Софт предлагает два формата: Первичную аналитику (бесплатно, 4–7 дней, ориентировочная оценка ±30%) для быстрых решений «да/нет», и Комплексную аналитику (2–4 недели, платно, вайрфреймы + пользовательские истории + оценка с точностью ±15%) для фиксации скоупа перед контрактом с фиксированной ценой. На странице нашего процесса скоупинга есть более подробный разбор.

Результаты, на которых стоит настаивать: одностраничное описание продукта, матрица приоритетов «must/should/nice», журнал топ-5 рисков, кликабельный прототип, если нужны материалы для инвесторов, и ориентировочная оценка с указанным диапазоном. Всё, что размытее — это сторителлинг, а не discovery.

Фаза 2 — Планирование и формирование команды: нужны правильные исполнители

Когда скоуп зафиксирован, мы собираем команду. Для типовой потребительской SaaS-MVP это 1 PM, 1 BA, 2–3 fullstack-разработчика, 1 QA, 1 дизайнер (частичная занятость) и 1 DevOps (на доли ставки). Boston Consulting Group обнаружил, что команды с разнообразием выше среднего получают на 19 процентных пунктов больше выручки от инноваций, чем однородные команды — мы укомплектовываем команды с учётом этого.

Шесть ролей, которые нужны каждому проекту

1. Менеджер проекта (PM). Отвечает за сроки, стендапы и коммуникацию со стейкхолдерами. Для вас — единая точка контакта. Что хороший PM делает на самом деле, мы разбираем в гиде о том, что делает технический менеджер проекта.

2. Бизнес-аналитик (BA). Несёт требования с фазы discovery дальше. Следит, чтобы реализовалась история, а не мечта.

3. Разработчики. 2–5 человек в зависимости от скоупа. Пары «senior + middle» выигрывают у чисто сеньорских по соотношению стоимости и менторинга.

4. Инженер по контролю качества (QA). Планирование тестирования, ручные прогоны и автоматизация. QA включается с первого спринта, а не в финале.

5. Дизайнер. UX/UI для новых сценариев, доработки существующих. После первых двух месяцев часто на доли ставки.

6. DevOps. CI/CD, инфраструктура, мониторинг. На MVP — частичная занятость; на масштабе — выделенный.

Фаза 3 — Дизайн: почему UX идёт раньше архитектуры

Проекты, ведомые дизайном, выпускаются на 85% быстрее и стоят на 75% меньше, чем проекты, где дизайн идёт постфактум (Forrester). Причина простая: проработка взаимодействия вскрывает решения по данным и потокам, которые тихо меняют архитектуру. Если строить архитектуру первой, каждый дизайн-сюрприз превращается в переделку.

Наш дизайн-этап даёт сначала вайрфреймы (20–40 экранов в зависимости от скоупа), потом кликабельный прототип, затем визуальную дизайн-систему в Figma. Доступность (WCAG 2.2) проверяется на стадии прототипа, а не после запуска. Дизайнеры участвуют в планировании каждого спринта на протяжении всего проекта.

Фаза 4 — Архитектура: решение, которое работает на годы вперёд

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

Выбор стека. Мы тяготеем к скучному, но проверенному: TypeScript + React / React Native на клиенте, Node.js или Python на сервере, PostgreSQL как основная база данных, Redis для кэша, S3-совместимое объектное хранилище. Для AI-функций — сервис на FastAPI поверх open-source моделей (Llama, Whisper) или тонкая обёртка над OpenAI/Anthropic.

Инфраструктура. Docker-контейнеры под управлением Kubernetes для stateful-платформ; serverless (AWS Lambda, Google Cloud Run) для скачкообразных нагрузок. Большинство MVP стартуют на одном managed-хосте (Hetzner, DigitalOcean) и переезжают в мультирегиональную среду по мере роста трафика.

Нефункциональные требования. Определяем бюджеты производительности, целевую доступность (99,5% или 99,9%), требования к локализации данных и класс комплаенса (GDPR, HIPAA, PCI, SOC 2). Дописывать всё это в уже работающую систему больно — фаза архитектуры это место, где они закладываются дёшево.

Фаза 5 — Разработка спринтами: ритм, в котором продукты доходят до релиза

Разработка — это не монолит; это ритм двухнедельных спринтов (по Atlassian, так работают 59% команд в индустрии). Каждый спринт начинается с планирования, заканчивается демо и сохраняет фиксированный бэклог между ними — чтобы команда действительно могла закрыть то, что взяла на себя.

Двухнедельный спринт у нас

День 1 — Планирование. Уточнение бэклога, оценка задач, проверка ёмкости. Команда фиксирует скоуп спринта.

Дни 2–9 — Сборка. Ежедневный 15-минутный стендап, ветки под фичи, ревью пул-реквестов коллегой и обычно AI-ревьюером, автотесты в CI, QA исследует фичи по мере их появления.

День 10 — Демо и ретро. Готовые фичи демонстрируются клиенту в 30–45-минутном звонке. Ретроспектива фокусируется на том, что изменить в следующем спринте. Коротко, конкретно и без обвинений.

Этот ритм существует не ради ритуала. Именно он создаёт предсказуемую динамику поставки, которую и измеряют метрики DORA (lead time, частота деплоев, change failure rate, время восстановления).

Agile, Waterfall и правда о гибридных подходах

В 2026 году Agile доминирует: 75% американских команд, 70%+ в мире. 87% Agile-команд используют Scrum; 56% применяют Kanban для эксплуатации и поддержки; 31,5% работают по явному гибриду. Agile-проекты дают 70% успешных против 50% у Waterfall — не потому что Agile волшебен, а потому что он принуждает к разговору и обратной связи.

Чистый Scrum. Фиксированные двухнедельные спринты, ежедневные стендапы, ритм демо/ретро. Лучший выбор для продуктовых команд, разрабатывающих новые фичи по дорожной карте.

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

Shape-Up. 6-недельные циклы со скоупом, ограниченным «аппетитом». Нишевой подход, но набирающий популярность в стартапах, где руководство хочет меньше статус-отчётов.

Когда Waterfall всё ещё выигрывает. Регулируемые отрасли (сертификация медицинских устройств, сертифицированное финансовое ПО), интеграции с железом, контракты с фиксированной ценой и комплаенс-подписями. Даже там мы запускаем Agile внутри waterfall-фаз — это дешевле, чем кажется.

Фаза 6 — Контроль качества: непрерывный, а не приклеенный сбоку

QA сместился с финальных ворот конвейера в непрерывную дисциплину. Современный CI запускает юнит-, интеграционные и end-to-end тесты на каждом пул-реквесте; ветки под фичи получают превью в эфемерных окружениях; сканирование безопасности (SAST, DAST) и проверки доступности крутятся в той же пайплайне.

Наши целевые показатели: 70%+ покрытия кода на критических путях, change-failure rate ниже 0,5%, среднее время восстановления после инцидента в продакшене менее часа. Это соответствует уровню «elite performer» DORA и достижимо дисциплинированными спринтами, а не героизмом.

Если хочется глубже погрузиться в тему, в нашем гиде по тестированию ПО разобрана пирамида тестирования и ROI автоматизации.

Фаза 7 — Релиз и поддержка: выпускайте раньше, выпускайте чаще

Рынок DevOps в 2025 году оценивается в 1,1 трлн ₽ и растёт на 25,6% до 1,4 трлн ₽ в 2026 году (Microsoft / отчёт по рынку DevOps). Причина: частота релизов теперь конкурентное преимущество. Элитные команды деплоят несколько раз в день; топ-исполнители вроде Etsy выкатывают 50+ деплоев в сутки. Здоровая продуктовая команда среднего размера в режиме спринтов целится хотя бы в один деплой в неделю.

Паттерны деплоя, которыми мы пользуемся

Blue-green. Два идентичных окружения; трафик мгновенно переключается с blue на green; откат за секунды. Используется для наших релизов без простоя.

Canary / постепенный. Релиз на 5–10% трафика, наблюдение за частотой ошибок в течение 5–30 минут, расширение по этапам. Стандарт для высоконагруженных потребительских продуктов.

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

Наблюдаемость. Метрики, логи, трассировки и отслеживание ошибок (Sentry, Datadog, Grafana). Без них сбои в продакшене становятся молчаливыми.

Разработка с AI — новая база 2026 года

Главная перемена со времён 2022 года — не методология; теперь инженеры работают вместе с AI-помощниками для написания кода, AI-ревьюерами и spec-driven агентами. По исследованию McKinsey/GitHub, команды с хорошим внедрением AI выполняют задачи на 55% быстрее и сокращают time-to-market на 30%. DORA 2025 подтверждает ускорение и добавляет оговорку: AI повышает и частоту деплоев, и change-failure rate, если QA и наблюдаемость не масштабируются вместе с ним.

Как мы это используем. AI-парнёр прямо в IDE для шаблонного кода и рефакторингов; spec-to-code агенты для крупных переписываний; AI-ревьюер на каждом ПР, ловящий пробелы в тестах; автоматическая генерация тестов по спецификациям. Результат у нас: на 20–35% более короткая поставка по сравнению со сроками 2022 года и более плотные циклы обратной связи на каждом пул-реквесте.

Чем это не является. Не автономный релиз. Не замена senior-ревью. Не лицензия пропускать фазы дизайна или QA. Команды, ушедшие в «пусть AI решает», по Thoughtworks Radar v34 (апрель 2026) показывают более высокий уровень переделок. Мы держим человека в петле принятия каждого решения, которое касается продакшена.

Мини-кейс — BrainCert: от MVP до 750 млн ₽ ARR

Ситуация. BrainCert стартовал как компактный MVP приложения для виртуальных классов. Основателю нужны были мультитенантный SaaS, классы на 100 участников на WebRTC, интеграции LTI и self-serve биллинг — ничего из этого в MVP не было.

План на 12 месяцев. Мы провели фазу Комплексной аналитики (3 недели), укомплектовали выделенную команду из семи человек и перешли на двухнедельные спринты с демо по пятницам. Архитектуру пересобрали под мультитенантную изоляцию с row-level security; легаси SFU заменили на WebRTC; CI/CD перешёл с еженедельного на ежедневный с blue-green деплоями; система фича-флагов позволила отделу продаж выкатывать фичи конкретным школам без инженерных тикетов.

Итог. BrainCert преодолел отметку 750 млн ₽ годовой выручки. Процесс не выглядел экзотическим — он выглядел как те самые семь фаз выше, проведённые без пропусков. В нашем портфолио есть ещё две сотни коротких кейсов, идущих по той же схеме. Хотите такую же оценку? Свяжитесь с нами для разговора по скоупу.

Ваша роль как нетехнического основателя — пять конкретных привычек

1. Посещайте демо спринтов. Каждые две недели, 30–45 минут. Приходите с тремя вопросами, одним кусочком обратной связи и одним апдейтом о бизнесе. Пропускаете демо — теряете петлю обратной связи, на которой держится Agile.

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

3. Читайте метрики DORA раз в месяц. Lead time, частота деплоев, change-failure rate, время восстановления. Их не обязательно считать самим — достаточно понимать, в какую сторону каждая из них движется.

4. Раз в квартал просматривайте журнал рисков. У каждого проекта есть живой список топ-5 рисков. Если он не меняется — PM не делает свою работу; если меняется слишком часто — скоуп нестабилен.

5. Оставайтесь близко к пользователям. Проводите пользовательские интервью раз в шесть недель. Инженерная команда строит только то, что вы ей озадачили; без свежего сигнала от пользователей она будет строить прошлогодний план.

Пять подводных камней, которые губят проекты

1. «Давайте просто начнём кодить». Самый сильный предиктор провала. 7-дневный заход на discovery экономит месяцы. Standish CHAOS говорит об этом три десятилетия подряд, и каждый год данные повторяются.

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

3. QA в конце. Тестирование, добавленное постфактум, находит в 10× больше дефектов и в 10× позже. Включайте QA с первого спринта, даже если у продукта пока нет пользователей.

4. Нет наблюдаемости в продакшене. Если вы не видите ошибки, задержки и нагрузку, вы летите вслепую. Sentry и базовый дашборд стоят меньше недели работы инженера и окупаются ежемесячно.

5. Расползание скоупа без матрицы. Изменения — это нормально; изменения без размена по матрице приоритетов — яд. Каждый новый запрос должен либо вытолкнуть что-то из спринта, либо ждать следующего. В нашей статье о сокращении расходов разобраны паттерны, которые действительно экономят деньги.

KPI, которые действительно отличают элитные команды от средних

KPI качества (DORA). Lead time от коммита до продакшена — менее 24 часов; частота деплоев — не реже раза в неделю (в идеале ежедневно); change-failure rate — ниже 5%; среднее время восстановления — менее часа. Элитные команды дотягивают все четыре.

Бизнес-KPI. Соотношение взятых и выполненных задач спринта — выше 85%; точность оценки — в пределах 15% после discovery; здоровье бэклога (нет залежей старше 90 дней) — выше 90%; стоимость фичи остаётся плоской или снижается квартал к кварталу.

KPI надёжности. p95 задержки API — ниже 500 мс; доля сессий без сбоев — выше 99,5%; нагрузка CPU базы данных — ниже 70% на пике; соблюдение бюджета ошибок (нарушения SLO отслеживаются). Эти цифры хорошо стареют — команды, дотянувшиеся до них в первый год, редко проседают на третий.

Когда не стоит писать ПО с нуля

Не каждая задача — программный проект. Если рабочий процесс укладывается в шаблон Airtable, Notion или no-code платформу — используйте их. Если интеграция живёт внутри существующего SaaS-продукта (HubSpot, Salesforce, Shopify) — настраивайте, а не пишите.

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

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

Сколько обычно длится разработка ПО?

Компактный MVP — 3–5 месяцев. Кроссплатформенный MVP с подписками и админкой — 5–8 месяцев. Продукт, готовый к масштабу, — 9–14 месяцев. Всё короче — обычно прототип; всё длиннее — расползание скоупа. За последние три года разработка с AI ужала эти диапазоны на 20–35%.

Выбирать фиксированную цену или time-and-materials?

Фиксированная цена работает только после того, как Комплексная аналитика зафиксировала скоуп. До этого вы просите подрядчика оценить неизвестное, и он закладывает запас 30–50%. Time-and-materials с лимитом по спринтам обычно дешевле и быстрее на ранней стадии разработки.

Нужен ли CTO до того, как нанимать агентство?

Нет. Нужен PM, способный переводить инженерные апдейты на язык бизнеса. Технического советника на 2–4 часа в месяц обычно достаточно на первый год. Полноценный CTO имеет смысл, когда штат переваливает за 10 инженеров или появляется институциональный инвестор.

Чем MVP отличается от прототипа?

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

Как понять, что моё агентство нормальное?

Пять признаков: они проводят настоящий discovery (а не «продажный»), демо каждый спринт, дают метрики DORA раз в месяц, у них есть отдельный человек на QA, и журнал рисков меняется со временем. Отсутствие двух пунктов — жёлтый флаг; отсутствие четырёх — пора собеседовать замену.

Насколько точны оценки разработки на самом деле?

После быстрого скоупинга — ±30%. После полной Комплексной аналитики — ±15%. Без скоупинга оценки превышаются в среднем на 200–300%. В нашем гиде по оценке трудозатрат цифры разобраны подробнее.

Заменяет ли AI senior-инженеров?

Пока нет, и в ближайшее время не заменит. AI-помощники поднимают производительность на шаблонном коде, рефакторингах и генерации тестов. Они же повышают change-failure rate, если никто из старших не ревьюит результат. DORA 2025 и Thoughtworks Radar v34 указывают на один и тот же риск. Senior-инженеры остаются и узким местом, и страховочной сеткой.

Что происходит после релиза?

Поддержка, итерации и доработки силами меньшей команды. Заложите 15–25% от изначальной стоимости разработки в год на обслуживание, патчи безопасности и небольшие фичи. Подробнее о форматах ретейнера — на странице услуги поддержки продукта.

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

Готовы создавать ПО дисциплинированно?

ПО создаётся в семь фаз. Пропустите любую — и статистика догонит вас: 66% частичных или полных провалов, перерасход бюджета в 200–300%, мёртвые кодовые базы, которые никто не хочет поддерживать. Пройдите их по порядку — сначала discovery, QA с первого дня, ранние и частые релизы, AI-ускорение с ревью человеком — и цифры начнут работать в вашу пользу.

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