Как понять какое количество ресурсов нужно?

Как понять какое количество ресурсов нужно

Декомпозиция работ и трудозатраты

Первый шаг — разбить проект на конкретные задачи. Я использую методологию WBS (Work Breakdown Structure), которая позволяет представить весь объём работ в виде иерархической структуры. Каждая задача оценивается в часах или story points, с учётом сложности и рисков. На этом этапе важно вовлечь техническую команду — они лучше понимают, сколько времени займёт реальная реализация.

Анализ навыков и компетенций

Нужны не просто люди, а люди с нужными навыками. Для проекта на React нужен опытный React-разработчик, а не просто "девелопер". Я составляю матрицу компетенций, определяю, какие специалисты необходимы (senior, middle, junior), и анализирую, есть ли они в команде или нужно привлекать со стороны. Иногда дешевле обучить имеющегося специалиста, чем нанимать нового.

Учёт производительности и пропускной способности

Нельзя предполагать, что люди работают 8 часов в день в полную мощь. Я учитываю:

• Встречи и административная работа (примерно 25-30% времени)
• Переключение контекста между проектами
• Обучение и адаптация новых членов команды (senior тратит время на ревью и наставничество)
• Выполнение нетехнических задач (документация, планирование)

На практике эффективная производительность разработчика — это 4-5 часов полезного кода в день, не 8.

Буферизация рисков и непредвиденные обстоятельства

Я всегда добавляю буфер на риски. Если команда оценила задачу в 40 часов, я добавляю 20-30% на:

• Неожиданные технические проблемы
• Болезни и отпуска сотрудников
• Изменения требований
• Интеграцию и тестирование

Обычно я использую методику трёхточечной оценки (оптимистичная, реальная, пессимистичная).

Параллелизм и зависимости

Не все задачи можно делать параллельно. Я анализирую критический путь проекта — какие задачи блокируют друг друга. Это помогает понять, нужно ли нанимать людей на ранние стадии или можно добавить их позже.

Анализ бюджета и доступных ресурсов

Количество людей зависит от денег. Я готовлю несколько сценариев:

• Оптимальный (проект готов в срок с нормальной нагрузкой)
• Экономный (минимальный бюджет, сроки сдвигаются)
• Ускоренный (максимум людей, но не более, чем эффективно)

Отслеживание и корректировка

Ресурсность плана — это не статичная цифра. После первого спринта я смотрю на реальную скорость и корректирую. Если команда стабильно завершает по 50 story points в спринт, я её пропускную способность рассчитываю именно на эти 50, а не на "должны" 60.