Как выглядит нормальный процесс разработки ПО: этапы, контрольные точки и результат

Короткий ответ: нормальная разработка ПО начинается с проверяемого результата, а не с набора экранов. Команда фиксирует сценарии и ограничения, проверяет идею прототипом, собирает первую версию небольшими поставками, тестирует не только happy path и заранее договаривается о приёмке. Так заказчик видит, что именно сделано, что осталось и почему меняется оценка.

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

1. Discovery: сначала задача, потом интерфейс

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

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

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

2. Прототип: проверяем логику до дорогого кода

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

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

3. Разработка: поставка небольшими проверяемыми частями

После прототипа команда разбивает работу на вертикальные срезы: маленькие куски, в которых есть интерфейс, логика, данные и проверка результата. Такой подход лучше показывает прогресс, чем отчёт «backend готов на 80%».

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

4. Тестирование: не только «страница открывается»

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

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

5. Запуск и поддержка: работа не заканчивается релизом

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

Как проверить процесс подрядчика за один разговор

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

Как Paladin Engineering может помочь

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

Что должно остаться в рабочем комплекте

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

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

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

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

Можно ли начать без полного ТЗ?

Да, если сначала провести discovery и зафиксировать первый проверяемый сценарий, ограничения и открытые вопросы.

Нужен ли прототип для небольшого проекта?

Не всегда, но спорные сценарии и роли обычно дешевле проверить прототипом до разработки.

Как понять, что этап завершён?

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

Что входит в приёмку?

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

Кто должен принимать решение о релизе?

Назначенный владелец продукта совместно с техническим ответственным по заранее согласованным критериям.