Что происходит после составления требований?

Построение процесса после фиксации требований

После того как требования собраны, согласованы с ключевыми стейкхолдерами и формализованы (например, в виде PRD — Product Requirements Document или SRS — Software Requirements Specification), начинается критически важный этап трансформации этих требований в рабочий продукт. Этот этап — не единовременное событие, а комплексный, многогранный процесс, который я разделяю на несколько ключевых потоков.

1. Архитектурный и технический дизайн

На основе сформулированных требований (особенно функциональных и системных) технические лиды и архитекторы начинают работу над high-level design (HLD).

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

class UserRatingCalculatorDesign:
    def __init__(self, requirements):
        self.input_sources = requirements['activity_sources']  # e.g., ['posts', 'comments', 'likes']
        self.algorithm_type = requirements['algorithm']        # e.g., 'weighted_sum'
        self.performance_constraints = requirements['max_calc_time']  # e.g., '< 100ms'

Этап включает:

• Декомпозицию системы: Разбиение на модули, сервисы или микросервисы.
• Выбор технологий и стеков: Определение языков, фреймворков, баз данных, инфраструктурных решений.
• Проектирование API и интеграций: Если система взаимодействует с внешними сервисами.
• Рассмотрение нефункциональных требований: Планирование масштабируемости (scalability), безопасности (security), надежности (reliability).
• Создание диаграмм: Архитектурных схем, схем потоков данных (data flow).

Результатом является Technical Specification или Architecture Document, который становится основой для разработки.

2. Планирование проекта и декомпозиция работ

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

• Создание дорожной карты (Roadmap): Определение высокоуровневых этапов, майлстоунов и последовательности реализации крупных блоков функциональности.
• Декомпозиция на задачи: Преобразование эпиков (Epics) и фич (Features) в конкретные задачи (Tasks) в инструментах управления (Jira, Asana). Это часто делается методом Story Mapping или просто в ходе сессии планирования с командой.
• Оценка сроков и ресурсов: На основе декомпозиции происходит оценка времени (часто методом bottom-up estimation от разработчиков) и распределение ресурсов. Формируется проектный план (Gantt chart, план-график).
• Определение методологии работы: Четкое планирование итераций (спринтов в Scrum), циклов релизов, процедуры приемки задач.

# Пример процесса в инструменте (концептуально):
# 1. Эпик -> Разбивается на Фичи
EPIC-101: "Реализация системы рейтинга пользователей"
-> FEATURE-101: "Модуль расчета рейтинга"
-> FEATURE-102: "API для получения рейтинга"
-> FEATURE103: "ВебИнтерфейс для отображения рейтинга"

# 2. Фича -> Разбивается на Технические Таски
FEATURE-101: "Модуль расчета рейтинга"
-> TASK-1011: "Проектирование алгоритма и формулы"
-> TASK-1012: "Разработка core-класса Calculator"
-> TASK-1013: "Интеграция с базой данных активности"
-> TASK-1014: "Написание unit-тестов"

3. Создание среды для разработки и начало реализации

Параллельно или сразу после планирования начинается практическая подготовка к работе:

• Настройка инфраструктуры: Создание или подготовка репозиториев кода (Git), CI/CD pipelines (Jenkins, GitLab CI), тестовых и staging-окружений.
• Формирование детальных критериев приемки (Acceptance Criteria): Для каждой задачи или пользовательской истории (User Story) на основе требований формулируются четкие, проверяемые условия, при выполнении которых задача считается завершенной. Это прямой мост от требований к разработке.
• Начало разработки (Development): Команда начинает выполнение задач согласно плану и выбранной методологии (спринты, канбан). Требования здесь служат постоянным референсом и эталоном. Процесс управления качеством (QA) также запускается на основе требований — пишутся тест-планы и тест-кейсы.

4. Управление изменениями и коммуникация

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

• Процесс управления изменениями требований (Change Control): Устанавливается четкий порядок (часто через Change Request Board) для внесения изменений в уже согласованные требования. Это предотвращает хаос и scope creep (неконтролируемый рост объема проекта).
• Регулярная коммуникация со стейкхолдерами: Планирование регулярных встреч для демонстрации прогресса, валидации промежуточных результатов против первоначальных требований и получения обратной связи. Требования — это живой документ, но изменения в него должны вноситься управляемо.

Таким образом, после составления требований происходит их "перевод" в технический дизайн, рабочий план и конкретные задачи. Этот этап соединяет мир бизнес-ожиданий с реальностью разработки и требует от проект-менеджера постоянного контроля за соответствием (traceability) между исходными требованиями, техническим дизайном, выполняемыми задачами и конечным продуктом.