Структура процесса разработки: от ТЗ и MVP до тестирования и поддержки

1. Короткий ответ: процесс разработки превращает неизвестные в решения

Разработка начинается не с экранов и не с выбора технологии. Она начинается с вопроса: какую проблему, для кого и ради какого результата мы решаем? Пока ответа нет, подробная смета выглядит точной только внешне.

Хороший процесс уменьшает неопределенность поэтапно. Сначала команда проверяет постановку задачи и ограничения. Затем выбирает самый дешевый способ проверить риск: интервью, схему процесса, прототип или технический эксперимент. После этого появляются границы первой рабочей версии, требования, оценка, реализация и критерии выпуска.

2. Можно начать с одной идеи — без готового ТЗ

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

Для первой беседы достаточно трех вещей:

• Идея или наблюдаемая проблема. Например: «менеджеры теряют заявки между мессенджерами и таблицами».
• Предположение о пользователе. Кто столкнулся с проблемой и что он делает сейчас.
• Реальные ограничения. Срок события, доступный диапазон вложений, обязательная система, закон или внутренний процесс.

Даже эти ответы могут быть неполными. На первом этапе 13FOX задает вопросы, разбирает текущий путь пользователя, выявляет риски и предлагает варианты проверки. Мы не просим клиента заранее выполнить работу аналитика — но и не притворяемся, что одну фразу уже можно честно превратить в окончательную смету.

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

3. Как появляется рабочее ТЗ — и почему число страниц не главное

Техническое задание нужно не для того, чтобы документ выглядел солидно. Оно нужно, чтобы бизнес, дизайнер, разработчик и тестировщик одинаково понимали результат. NASA относит к сильным требованиям ясность, однозначность, выполнимость и проверяемость. Международный стандарт ISO/IEC/IEEE 29148:2018 рассматривает работу с требованиями на всем жизненном цикле, а не только перед стартом.

Для цифрового продукта рабочий набор обычно включает:

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

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

4. Не путайте бриф, прототип, технический эксперимент, ТЗ и MVP

Эти результаты отвечают на разные вопросы. Если смешать их, проект либо переплачивает за лишнюю реализацию, либо принимает красивую демонстрацию за готовый продукт.

5. Прототип и MVP: сначала проверяем самое рискованное допущение

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

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

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

Отдельно разобрать решение «делать MVP или сразу полноценный продукт» поможет наша статья о разработке MVP и критериях старта.

6. Оценка, план и договоренности: когда диапазон становится сметой

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

Надежность оценки растет вместе с определенностью:

1. До исследования: диапазон и список допущений.
2. После сценариев и прототипа: оценка первой версии по крупным блокам и рискам.
3. После требований и технических проверок: подробный состав этапа, команда, зависимости и критерии приемки.
4. Во время разработки: уточнение остатка по фактической скорости и открытым решениям.

Управляемый план фиксирует не только функции. В нем есть ответственные, последовательность работ, зависимости, точки демонстрации, порядок приемки и резерв на известные риски. Если меняется объем, заказчик видит влияние до выполнения работы, а не в счете постфактум.

7. Дизайн, архитектура и разработка идут малыми проверяемыми частями

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

Разработку полезно делить на законченные части, которые можно показать и проверить. Не «сделали половину серверной части», а «пользователь создает заявку, менеджер ее получает, статус сохраняется, событие попадает в аналитику». Такая часть дает бизнесу наблюдаемый результат и обнаруживает ошибки понимания раньше.

Рабочий ритм выглядит так:

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

Это не отменяет общего ТЗ и архитектуры. Наоборот, общая карта удерживает направление, а малые части не позволяют месяцами строить неверно понятую систему.

8. Тестирование начинается до кода, а не за день до релиза

Первое испытание требования простое: можно ли однозначно проверить результат? Формулировка «сделать удобный личный кабинет» непроверяема. Формулировка «клиент видит свои активные заявки, открывает детали и загружает документ до 10 МБ в разрешенных форматах» уже задает сценарий и границы проверки.

Дальше качество сопровождает весь процесс:

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

Рекомендации NIST по безопасной разработке (SSDF) предлагают встраивать защиту в используемый жизненный цикл. Она начинается с модели данных и прав, продолжается проверкой кода и зависимостей и не заканчивается после публикации. Автоматические проверки ускоряют обратную связь, но не заменяют исследовательское тестирование, оценку удобства и профессиональное решение о готовности.

Для приложения подробная карта проверок есть в материале о видах тестирования и приоритетах риска.

9. Приемка и релиз: продукт должен быть готов не только технически

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

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

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

10. Поддержка продолжает разработку по реальным данным

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

Зрелая система поддержки включает:

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

Инженерное руководство Google по надежности сервисов (SRE) советует начинать показатели с того, что важно пользователю, а не с того, что проще измерить. Для одного продукта важнее успешная оплата, для другого — своевременная доставка сообщения, корректность расчета или доступ к документу. Техническая панель без бизнес-смысла не показывает здоровье продукта.

11. Сводная карта: что получает заказчик на каждом этапе

Используйте эту карту при согласовании договора, результатов этапов и порядка приемки.

12. Кто за что отвечает — и как не потерять контроль

Заказчик приносит смысл и принимает бизнес-решения

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

13FOX переводит задачу на язык продукта и разработки

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

Совместно определяются границы и точки решений

Приоритеты, состав MVP, компромиссы срока и объема, критерии выпуска и следующий цикл невозможно «передать на сторону» полностью. Их обсуждают на фактах и фиксируют так, чтобы решение можно было восстановить позже.

13. Красные флаги процесса подрядчика

• Команда отказывается обсуждать задачу без полного ТЗ. Продуктовую работу перекладывают на клиента, который пришел именно за этой компетенцией.
• Фиксированная цена нестандартного продукта после короткого разговора. Рядом нет состава, допущений и исключений, которые объясняют цифру.
• Код начинается раньше проблемы и критериев. Скорость старта маскирует стоимость будущего уточнения.
• MVP означает низкое качество. У первой версии может быть меньше функций, но критический путь, целостность данных и обязательные меры безопасности должны иметь проверяемые критерии.
• Тестирование планируется только как последний этап. Значит, требования и архитектура могли долго жить без проверки.
• Нет демонстраций на рабочей сборке. Заказчик узнает о расхождении ожиданий слишком поздно.
• Неясно, кому принадлежат код, домен, учетные записи и ключи. После релиза контроль остается у подрядчика.
• Поддержка начинается после первого сбоя. До запуска никто не спроектировал наблюдение, восстановление и ответственность.

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

14. Иллюстративный пример: одна фраза проходит весь процесс

Представим обращение: «Хотим сервис, который не дает менеджерам терять заявки». Это не ТЗ — и этого достаточно для старта разговора.

1. Разбор идеи. Выясняем, откуда приходят заявки, где они теряются, кто отвечает и как бизнес измеряет потерю.
2. Исследование процесса. Находим роли, исключения, дубли, обязательные поля, текущие системы и ограничения доступа.
3. Прототип. Проверяем путь: новая заявка, назначение ответственного, статус, напоминание, контроль руководителя.
4. Технический эксперимент. Если главный риск — нестабильная интеграция с мессенджером или CRM, проверяем ее отдельно.
5. Границы MVP. Берем один канал заявок, один рабочий процесс, обязательные статусы, журнал действий и аналитику результата.
6. Требования и оценка. Фиксируем роли, правила, ошибки, критерии приемки, данные, безопасность и план выпуска.
7. Разработка и тесты. Выпускаем законченные части, показываем рабочую сборку, проверяем интеграции и крайние случаи.
8. Запуск и поддержка. Наблюдаем, сколько заявок дошло до ответа, где процесс тормозит и что обоснованно добавить дальше.

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

15. Что подготовить к первой встрече с 13FOX

Не пишите профессиональное ТЗ специально для знакомства. Лучше принесите факты:

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

16. Источники и методология

Статья опирается на официальные руководства и первичные инженерные источники. Мы не использовали универсальные «проценты провала», обещания фиксированного срока MVP и популярный тезис о стократной цене поздней ошибки: без контекста такие цифры создают ложную точность.

• Справочник NASA по системной инженерии: процессы проектирования системы — издание 2016 года, веб-версия 2023 года.
• NASA: критерии качества требований и различие проверок.
• ISO/IEC/IEEE 29148:2018 — стандарт инженерии требований, подтвержден в 2024 году.
• GOV.UK: как работает этап исследования задачи — обновлено 21 июня 2021 года.
• GOV.UK: прототипы и проверка рискованных идей.
• DORA: работа малыми партиями — обновлено 8 декабря 2025 года.
• DORA: автоматизация тестирования на протяжении жизненного цикла.
• NIST SP 800-218: рекомендации по безопасной разработке (SSDF) 1.1 — финальная версия от 3 февраля 2022 года.
• OWASP ASVS 5.0.0 — проверяемый набор требований к защите веб-приложений, 30 мая 2025 года.
• W3C WCAG 2.2 — рекомендация от 12 декабря 2024 года.
• GOV.UK: надежная эксплуатация сервиса — обновлено 29 января 2026 года.
• GOV.UK: поддержка и развитие после запуска — обновлено 8 мая 2019 года.
• Google SRE: цели надежности и пользовательские показатели.

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

Можно ли обратиться в 13FOX, если есть только идея и нет ТЗ?

Да. Для первого разговора достаточно описать идею, предполагаемых пользователей и задачу обычными словами. Команда поможет проверить постановку, определить ограничения, выбрать формат первой проверки и собрать требования. Готовое ТЗ на входе не требуется.

Как оценить разработку, если ТЗ еще нет?

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

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

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

Когда начинается тестирование продукта?

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

Можно ли менять требования во время разработки?

Да, если изменения управляемы. Команда фиксирует причину, влияние на объем, срок, бюджет, архитектуру и тесты, после чего заказчик принимает решение: заменить приоритет, расширить этап или перенести идею в следующую версию.

Зачем поддержка, если продукт уже запущен?

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

Приходите с одной идеей — структуру проекта выстроим вместе

Не нужны готовое ТЗ, список экранов и угаданный бюджет. Опишите, для кого продукт и какую задачу он должен решить. Команда 13FOX поможет выбрать следующий разумный шаг: исследование, прототип, MVP или развитие существующей системы.

Обсудить идею без готового ТЗ