Сколько PM взял на работу?

Оценка трудоемкости проекта: процесс и методологии

Когда Project Manager (PM) оценивает количество ресурсов, необходимых для проекта, он не просто "берет на работу" людей — это сложный процесс планирования и расчёта трудоёмкости, основанный на множестве факторов. Ключевой термин здесь — resource allocation (распределение ресурсов), который включает человеческие ресурсы (HR), финансовые, материальные и временные. Ответ на вопрос "сколько PM взял на работу" является результатом комплексного анализа.

Факторы, влияющие на расчёт необходимых ресурсов

• Scope & Requirements (Объём и требования проекта): Чёткое понимание функциональных и технических требований — основа. PM анализирует WBS (Work Breakdown Structure — структура разбиения работ), чтобы определить все задачи.
• Project Timeline (Временные рамки): Жёсткие deadlines часто требуют большего количества параллельно работающих специалистов, что увеличивает команду. Используется метод time boxing.
• Skill Set & Expertise (Набор навыков и экспертиза): Проект может требовать разных специалистов: разработчики (backend/frontend), дизайнеры, тестировщики (QA), аналитики, DevOps. PM составляет матрицу компетенций.
• Budget Constraints (Бюджетные ограничения): Финансы — основной лимитирующий фактор. PM балансирует между оптимальным размером команды и бюджетом, часто используя cost-benefit analysis.
• Historical Data & Metrics (Исторические данные и метрики): Опытные PM используют данные прошлых проектов (например, velocity в Agile или productivity metrics) для более точного прогнозирования.

Методологии расчёта трудоёмкости и размера команды

PM применяет несколько методик для количественного определения потребности в персонале.

1. Метод на основе задач (Task-Based Estimation)

PM детализирует проект в WBS, затем оценивает время на каждую задачу и суммирует человеко-часы. После этого рассчитывается необходимое количество специалистов, учитывая их занятость (например, 80% на проект).

# Примерный алгоритм для высокоуровневого расчёта (упрощённо)
def calculate_team_size(total_man_hours, project_duration_months, avg_employee_utilization=0.8):
    """
    Рассчитывает приблизительное количество сотрудников.
    total_man_hours: общая оценка трудоёмкости в человеко-часах.
    project_duration_months: срок проекта в месяцах.
    avg_employee_utilization: средняя загрузка сотрудника на проект (например, 80%).
    """
    working_hours_per_month = 160  # Пример: 40 часов * 4 недели
    total_months_hours = project_duration_months * working_hours_per_month
    # Корректируем на загрузку (utilization)
    effective_hours = total_months_hours * avg_employee_utilization
    required_team_size = total_man_hours / effective_hours
    return round(required_team_size, 1)

# Пример: проект 1000 человеко-часов за 2 месяца при 80% загрузке
team_size = calculate_team_size(1000, 2, 0.8)
print(f"Приблизительный размер команды: {team_size} человек")

2. Использование аналогий и экспертных оценок (Analogous & Expert Judgment)

Для проектов в известной области PM может использовать данные из прошлых аналогичных проектов ("проект похож на X, где было 5 разработчиков и 2 QA") или опираться на мнение ведущих технических экспертов (subject matter experts).

3. Agile/Scrum подходы

В Agile-практиках размер команды часто определяется итерационно. Scrum Team обычно состоит из 5-9 человек (включая Scrum Master и Product Owner). PM (или Agile Coach) формирует устойчивые (stable) кросс-функциональные команды, а потребность в дополнительных ресурсах оценивается на основе backlog и скорости команды (sprint velocity).

-- Пример запроса для анализа нагрузки в Agile (концептуально)
-- В реальности данные хранятся в Jira, Asana и др.
SELECT
    sprint_id,
    SUM(task_estimate_hours) AS total_sprint_load,
    COUNT(DISTINCT assignee_id) AS current_team_size,
    -- Коэффициент загрузки
    SUM(task_estimate_hours) / (COUNT(DISTINCT assignee_id) * 40) AS load_factor
FROM sprint_tasks
WHERE sprint_status = 'planned'
GROUP BY sprint_id;
-- Load_factor > 1 указывает на потенциальную нехватку ресурсов в спринте.

Процесс формирования команды (Team Formation Process)

После расчёта PM не "берёт" людей напрямую — он взаимодействует с HR-департаментом, линейными менеджерами (line managers) и, возможно, с вендором (vendor) для привлечения внешних специалистов. Процесс включает:

1. Создание запроса на ресурсы (Resource Request Form) с указанием должностей, требуемых навыков и сроков.
2. Подбор (Recruitment) или внутреннее выделение (internal allocation) сотрудников.
3. Оценку рисков (Risk Assessment): понимание, что расширение команды увеличивает коммуникационные накладные расходы (communication overhead) и требует больше усилий на координацию (coordination effort).

Пример из практики

Для проекта по разработке новой SaaS-платформы PM провёл следующую оценку:

• WBS показала необходимость в 4 модулях: авторизация, основной функционал, админ-панель, интеграция с API.
• Expert judgment технического лида определило: каждый модуль — ~400 человеко-часов.
• Budget ограничивал общие затраты на команду.
• Timeline был фиксированным — 6 месяцев.

Используя метод аналогий и расчёты, PM определил, что оптимальная команда — 6 человек: 2 backend, 2 frontend, 1 QA, 1 DevOps. Это решение было оформлено в Resource Plan, согласовано с спонсором проекта (project sponsor) и передано в HR для запуска процесса подбора.

Итог: Количество людей, которое PM "берёт на работу", — это не случайное число, а результат тщательного процесса планирования ресурсов (resource planning process), основанного на анализе объёма работ, сроков, бюджета и доступных компетенций. Эффективный PM стремится найти баланс между достаточным размером команды для выполнения задач и минимизацией избыточности, которая ведёт к росту затрат и сложности управления.