1Этап 0. Оценка и смета (пресейл)
До старта работ идёт оценка: подрядчик разбирается в задаче и даёт понимание сроков и бюджета. Важно принять, что по описанию в две строки точную цену назвать нельзя — «личный кабинет» может означать и форму на пару экранов, и систему с ролями, оплатами и интеграциями, а это разница в разы. Поэтому на пресейле честный ответ — вилка «от и до», а не одна цифра.
Точная смета появляется после следующего этапа — аналитики. Если студия готова зафиксировать точную стоимость сложного проекта сразу по короткому описанию, это повод не обрадоваться, а насторожиться: либо в цену заложен огромный буфер «на всякий случай», либо потом начнутся споры о каждом изменении. Результат этапа — предварительная вилка и план, как перейти к точной оценке.
2Этап 1. Аналитика и ТЗ
Здесь размытая идея превращается в конкретные требования: какие роли пользователей есть, какие сценарии они проходят, что система должна делать в каждом случае. Итог оформляется в техническое задание — документ, который становится единым источником истины для обеих сторон. Часто на этом же этапе рисуют прототип или каркасные схемы (вайрфреймы), чтобы согласовать логику ещё до дизайна.
Этот этап экономит больше всего денег, хотя кажется «бумажным». Найти нестыковку в требованиях на бумаге стоит одного разговора; найти её же в готовом продукте — стоит переписывания кода. Именно дырявое ТЗ или его отсутствие — причина почти всех конфликтов «мы имели в виду другое». Результат этапа: согласованное ТЗ, прототип и уже точная оценка сроков и бюджета.
3Этап 2. Дизайн (UX и UI)
Дизайн идёт от структуры к картинке: сначала UX — как устроены экраны и переходы, чтобы пользователю было удобно дойти до цели, затем UI — визуальный стиль, цвета, типографика. На выходе — макеты всех ключевых экранов и, для крупных проектов, дизайн-система (переиспользуемые компоненты), чтобы продукт выглядел единообразно и его было дешевле развивать.
Ключевое правило этапа: всё спорное решается на макетах, а не в коде. Передвинуть блок и поменять сценарий в дизайне — минуты; переделать то же самое в уже написанном интерфейсе — часы и деньги. Поэтому макеты согласовывают до начала разработки. Результат этапа: утверждённые макеты, по которым команда будет собирать продукт.
4Этап 3. Разработка спринтами
Собственно код пишут итерациями — спринтами по одной-две недели. В каждом спринте команда берёт кусок функциональности, доводит его до работающего состояния и показывает на демо. Backend (серверная логика и база), frontend (интерфейс) и интеграции с внешними сервисами двигаются параллельно и стыкуются по ходу.
Главная ценность спринтов для заказчика — прозрачность. Вы не ждёте «100% готовности» в конце вслепую, а каждые одну-две недели видите работающий фрагмент продукта и можете скорректировать курс, пока это дёшево. Отсутствие промежуточных демо и билдов — тревожный признак: он означает, что о проблемах вы узнаете последним.
- Демо в конце каждого спринта: работающий фрагмент продукта, а не отчёт «сделано 100%».
- Параллельная работа: серверная логика, интерфейс и интеграции двигаются одновременно.
- Возможность менять приоритеты между спринтами, пока изменения ещё дёшевы.
- Промежуточные билды на тестовом контуре, которые можно пощупать самому.
5Этап 4. Тестирование и приёмка
Перед запуском продукт проверяют: тестировщики прогоняют сценарии, ищут ошибки на разных устройствах и при нестандартных действиях пользователя, команда правит найденное. Затем идёт приёмочное тестирование — уже с вашей стороны, по заранее оговорённым критериям приёмки: что именно считается «готово» и работает как надо.
Приёмка — это не только «открывается ли и не падает ли». На этом этапе заберите то, без чего продукт формально ваш, но управлять им нельзя: исходный код и права на него, доступы к домену, хостингу и репозиторию, документацию. Если есть сомнения в качестве кода после спорной разработки, отдельно проводится независимый аудит — он честно отвечает, чинить или переписывать. Результат этапа: принятый продукт и переданные доступы.
6Этап 5. Запуск и поддержка
Запуск — это перенос продукта на боевую инфраструктуру, финальные проверки и открытие доступа пользователям. Сразу после релиза обычно действует гарантийный период, когда команда бесплатно правит дефекты, всплывшие в реальной эксплуатации. Дальше продукт живёт, и ему нужна поддержка: мониторинг, бэкапы, обновления зависимостей, реакция на инциденты — это оформляется отдельным соглашением об уровне сервиса (SLA).
Отдельно про оплату: здоровый проект оплачивается по вехам (milestones), привязанным к этапам, а не «всё вперёд» и не «всё в конце». Такая схема страхует обе стороны — заказчик платит за принятый результат этапа, подрядчик получает деньги за понятный сделанный объём. Это же дисциплинирует сроки: у каждого платежа есть конкретный принятый артефакт.