Граница завершения разработки первой версии

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

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

Вернитесь к обещанию первой версии

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

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

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

Отделите готовность к использованию от полноты замысла

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

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

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

Проверьте, что уже можно узнать только в работе

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

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

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

Выберите один из трёх режимов

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

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

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

Режимы

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

Уже потраченное время само по себе не обосновывает следующий расход.

Передайте ответственность за следующий этап

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

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

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

Практическое задание

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