Как проходит разработка: от заявки до запуска и поддержки

Короткий ответ: на каждом этапе должен появляться проверяемый результат

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

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

1. Заявка уточняет задачу, а не превращается в мгновенную смету

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

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

2. Discovery отделяет реальную проблему от заранее выбранного решения

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

Со стороны клиента нужны доступ к владельцу процесса, примеры реальных случаев, действующие правила, интерфейсы внешних систем и честное описание исключений. Выход — карта задачи, критические риски, границы первого результата и решение go/no-go. Остановка после discovery допустима, если исследование показывает, что разработка не окупит проблему.

3. Прототип проверяет критический путь и самые рискованные предположения

Прототип нужен не для украшения презентации. Он показывает ключевой путь пользователя, структуру данных и важные состояния до того, как команда вкладывается в production-код. GOV.UK описывает alpha как время для проверки разных решений и самых рискованных предположений с помощью ровно настолько сложных прототипов, насколько требуется для обучения.

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

4. Объём, оценка и договорённости фиксируют границу ответственности

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

В ZeroBlack после согласования объёма и условий вносится предоплата 20%. Изменения не запрещены, но новое требование сначала оценивается по влиянию на сценарий, бюджет и запуск. Это защищает обе стороны от ситуации, когда новая функция незаметно меняет весь проект.

5. Архитектура и дизайн охватывают не только идеальный экран

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

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

6. Разработка идёт короткими проверяемыми итерациями

Итерация должна завершаться работающим приращением, которое можно показать и проверить по критериям готовности. Официальное руководство Scrum связывает Increment с Definition of Done, а обзор итерации — с проверкой результата и дальнейшей адаптацией. Поэтому отчёт о процентах выполнения не заменяет демонстрацию реального сценария.

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

7. Тестирование доказывает готовность, а не отсутствие заметных ошибок

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

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

8. Запуск включает план возврата, наблюдаемость и ответственного

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

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

9. Передача продукта означает реальное владение, а не только ссылку

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

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

10. Поддержка отделяет дефекты от развития и продолжает измерение

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

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

Что должен увидеть клиент до старта следующего этапа

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

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

Источники

GOV.UK Service Manual: как проходит discovery

GOV.UK Service Manual: как проходит alpha и проверка прототипов

GOV.UK Service Manual: основные принципы итеративной разработки

Официальное руководство Scrum 2020

W3C: краткий справочник WCAG 2.2

Как работает ZeroBlack