Сколько времени нужно чтобы собрать требования?

Время на сбор требований в IT-проекте

Однозначно ответить на вопрос «сколько времени нужно, чтобы собрать требования?» нельзя — это как спросить «сколько стоит дом?». Сроки напрямую зависят от масштаба проекта (Scope), сложности предметной области (Domain Complexity), зрелости заказчика (Stakeholder Maturity) и выбранной методологии разработки (Agile/Waterfall). Однако, исходя из практики, можно выделить ориентиры.

Ориентировочные сроки в зависимости от типа проекта

• Небольшой проект / MVP (Minimum Viable Product): 2-4 недели. Фокус на user stories, ключевых пользовательских сценариях и ограниченном наборе функций.
• Средний бизнес-проект (например, корпоративный портал или CRM-модуль): 1-2.5 месяца. Требует глубокого анализа бизнес-процессов, интервью с несколькими группами пользователей, проработки интеграций.
• Крупный комплексный проект (новая банковская система, платформа e-commerce): 3-6 месяцев и более. Часто проходит в несколько итераций (этапов), включает создание детальных спецификаций (Software Requirements Specification, SRS), прототипов (Mockups/Wireframes) и технических заданий (Technical Assignment).

Ключевые факторы, влияющие на сроки

1. Доступность и согласованность стейкхолдеров. Если ключевые эксперты и лица, принимающие решения (Decision Makers), доступны раз в неделю, процесс затянется. Хаос в видении целей у разных отделов также требует времени на консенсус.
2. Наличие аналогичных решений и legacy-систем. Работа с унаследованными системами (Legacy Systems) или интеграция с ними увеличивает сроки из-за необходимости реверс-инжиниринга и анализа рисков.
3. Выбор методологии. В гибких методологиях (Agile, Scrum) сбор требований — непрерывный процесс в рамках каждой итерации (спринта). В каскадной модели (Waterfall) это отдельная, подробная и длительная фаза перед началом разработки.

# Пример псевдокода для оценки effort
def estimate_req_gathering_time(project_scope, stakeholder_availability, complexity):
    base_time_weeks = 2  # Базовый минимум для формализации
    
    if project_scope == "large":
        base_time_weeks *= 4  # Умножаем для крупного проекта
    elif project_scope == "medium":
        base_time_weeks *= 2
    
    # Коэффициент доступности стейкхолдеров (0.8 - хорошая, 1.5 - плохая)
    availability_factor = 1.5 if stakeholder_availability == "low" else 0.8
    # Коэффициент сложности домена (финансы, телеком - высокие)
    complexity_factor = 1.8 if complexity == "high" else 1.0
    
    total_weeks = base_time_weeks * availability_factor * complexity_factor
    return f"Ориентировочно: {round(total_weeks, 1)} недель"

# Пример вызова
print(estimate_req_gathering_time("large", "low", "high"))
# Вывод: Ориентировочно: 21.6 недель (~5 месяцев)

Почему нельзя сжать сроки до минимума?

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

Практический совет по планированию

Я рекомендую разбивать процесс на фазы с точками контроля (Checkpoints):

• Фаза 1: Высокоуровневое видение (Vision & Scope) – 1-2 недели. Документ, описывающий цели, основные стейкхолдеры и границы проекта.
• Фаза 2: Детализация (Elicitation & Analysis) – 2-8 недель. Сессии интервью, воркшопы, создание пользовательских историй, диаграмм процессов (BPMN), прототипов.
• Фаза 3: Спецификация и валидация (Specification & Validation) – 1-3 недели. Формализация требований, приоритизация (MoSCoW, RICE), согласование с заказчиком.

Итог: Вместо того чтобы спрашивать «сколько времени нужно», правильнее ставить вопрос: «Какой объем информации нам необходим для принятия обоснованного решения о начале проектирования или разработки первой итерации, и какие риски мы готовы нести?». Для первого инкремента может хватить 2-3 недель, но для полной картины по всему проекту нужно закладывать от 1 до 6 месяцев. Главное — не стремиться описать «всё и сразу», а выявлять требования итеративно, начиная с самого ценного для бизнеса.