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

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

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

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

1. Задача и границы продукта

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

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

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

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

2. Discovery и уточнение сценариев

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

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

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

Paladin Engineering может подключиться на этапе discovery или подготовки веб-сервиса: в направлении веб-разработки важно связать бизнес-процесс с проверяемым объёмом.

3. Архитектура и технические решения

Архитектура отвечает не на вопрос «какой стек моднее», а на вопросы о данных, интеграциях, ролях, нагрузке, отказах и поддержке. Для небольшого сервиса часто разумен простой монолит с ясными границами. Для API-first, сложного real-time или независимых потоков может понадобиться другой подход. Универсального победителя нет.

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

• границы модулей и ответственности
• модель данных и правила доступа
• внешние API и повторные попытки
• фоновые задачи и уведомления
• резервное копирование и восстановление
• условия пересмотра архитектуры

OWASP ASVS можно использовать как основу проверяемых требований безопасности веб-приложения, а NIST SSDF — как ориентир для практик безопасной разработки. Эти документы не заменяют проектное решение: набор проверок выбирают по риску.

4. Прототип и дизайн ключевого пути

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

1. выбрать один сценарий с высокой ценой ошибки
2. показать успех, ошибку, пустые данные и ожидание
3. проверить путь с представителями ролей
4. зафиксировать замечания и решения
5. перенести подтверждённое в требования и приёмку

WCAG 2.2 помогает формулировать требования доступности проверяемо: подписи, клавиатурное управление, сообщения об ошибках и различимость элементов. «Сделать удобно» — слишком расплывчатый критерий.

5. Разработка короткими инкрементами

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

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

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

6. Тестирование, безопасность и приёмка

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

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

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

OWASP ASVS рассматривает стандарт как основу тестирования технических контролей и требований при закупке. Это полезный переход от доверия к проверяемым условиям договора.

7. Релиз и поддержка

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

• кто подтверждает готовность
• как проверяется перенос данных
• где хранятся исходники и доступы
• как обнаружить ошибку и вернуть рабочую версию
• что входит в поддержку

Как Paladin Engineering может помочь. Мы проводим предпроектный разбор, готовим сценарии и критерии, разрабатываем веб-сервисы по инкрементам и помогаем организовать техническую приёмку. Подробнее — веб-разработка или контакты.

FAQ: процесс разработки ПО

Сколько этапов нужно?

Фиксированного числа нет. Обычно нужны постановка задачи, уточнение сценариев, проектирование, разработка, проверка, релиз и поддержка. Небольшой проект объединяет этапы, сложный — делит на циклы.

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

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

Нужен ли отдельный менеджер?

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

Когда нужен прототип?

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

Как понять, что этап принят?

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

Что делать при изменении требований?

Оценить влияние на объём, срок, стоимость, тесты и зависимости, затем обновить план и критерии.