Сколько в среднем человек было на проекте?

Оценка среднего размера команды в IT-проектах

Вопрос о среднем количестве участников проекта — один из самых частых, и ответ на него красноречиво говорит об опыте и зрелости кандидата. Прямого универсального ответа не существует, так как размер команды — это производная от множества факторов. В среднем, за 10+ лет в индустрии, я руководил командами от 5 до 50 человек, но типичный диапазон для коммерческих продуктовых или интеграционных проектов — 8–15 специалистов.

Ключевые факторы, определяющие размер команды:

1. Методология и жизненный цикл проекта

• Agile/Scrum: Идеальный размер одной скрам-команды — 5–9 человек (Product Owner, Scrum Master, разработчики, QA). Крупные проекты масштабируются через Scrum of Scrums или SAFe, объединяя несколько таких команд.
• Waterfall (Каскадная модель): Команды могут быть больше (15–25 человек), так как фазы (анализ, разработка, тестирование) часто четко разделены, и на каждом этапе задействованы разные группы специалистов.
• Hybrid (Гибридная модель): Размер варьируется, часто в рамках 10–20 человек, сочетая предсказуемость планирования с гибкостью исполнения.

2. Сложность, масштаб и длительность проекта

• MVP или небольшой модуль: 3–7 человек (full-stack разработчики, совмещающие роли).
• Корпоративная система (ERP, CRM) или сложный цифровой продукт: 20–40+ человек, включая несколько суб-команд (бэкенд, фронтенд, мобильная разработка, DevOps, тестирование, аналитика).

3. Распределение ролей

Средняя команда — это не просто разработчики. Это экосистема ролей:

• Ядро команды: Разработчики (Backend, Frontend, Mobile), QA-инженеры.
• Управление и анализ: Project Manager/Scrum Master, Product Owner, Бизнес- или Системный аналитик.
• Сопутствующие эксперты: DevOps/SRE, UX/UI дизайнер, Технический писатель.
• Внешние участники: Архитектор (может быть на несколько команд), представители заказчика, специалисты по безопасности — часто участвуют частично.

4. Практический пример и расчет

Рассмотрим гипотетический проект разработки веб-приложения средней сложности (12 месяцев, гибридная модель):

# Пример структуры команды и расчета FTE (Full-Time Equivalent)
core_dev_team = {
    "backend_developers": 3,
    "frontend_developers": 2,
    "qa_engineers": 2,
    "devops_engineer": 0.5  # Частичная занятость на проекте
}

management_analytics = {
    "project_manager": 1,
    "business_analyst": 1,
    "product_owner": 0.5  # Может совмещать роль с аналитиком
}

auxiliary_roles = {
    "ux_ui_designer": 0.3,
    "tech_lead": 1  # Один из senior-разработчиков
}

# Рассчет общей численности (в FTE)
total_team_size = sum(core_dev_team.values()) + sum(management_analytics.values()) + sum(auxiliary_roles.values())
print(f"Средняя численность команды в течение проекта: {total_team_size} FTE")

Вывод: Средняя численность команды в течение проекта: 11.3 FTE

Этот расчет показывает ~11 человек как постоянное ядро. Пиковая нагрузка (нагрузочное тестирование, релиз) может временно привлекать дополнительных специалистов.

5. Ключевые метрики и выводы

Важно не просто назвать цифру, а объяснить логику:

• Контрольный диапазон: Управляемость напрямую связана с количеством каналов коммуникации. В команде из N человек количество потенциальных связей растет по формуле N*(N-1)/2. Для 5 человек — 10 связей, для 15 — уже 105. Это напрямую влияет на сложность координации.
• Тенденции: Современная практика движется к меньшим, кросс-функциональным и автономным командам (6-10 человек), которым можно поставить четкую цель и дать максимальную самостоятельность (см. Two-Pizza Team принцип от Amazon).
• Мой опыт: В финале я бы привел конкретный пример: "На моем последнем проекте по разработке fintech-платформы постоянное ядро составляло 12 человек (2 аналитика, 5 dev, 2 QA, 1 DevOps, 1 дизайнер, 1 PM). На этапе интеграции с банковскими системами мы временно расширялись до 18 человек за счет экспертов по безопасности и дополнительных разработчиков. Таким образом, среднее значение за 14 месяцев проекта было около 14 FTE."

Итог: Средний размер команды — 8-15 человек. Но главное для Project Manager’а — не запомнить цифру, а понимать, как методика, scope и ролевая модель формируют эту цифру, и уметь аргументированно подбирать и масштабировать команду под конкретные задачи проекта.