Эту страницу открывают, когда нужно понять, сколько усилий стоит работа, прежде чем переводить её в сроки, стоимость и загрузку. Ошибка PM здесь часто в том, что трудозатраты и календарная длительность начинают восприниматься как одно число.
Что это такое
Трудозатраты — это объём усилий, который потребуется для выполнения работы. Они могут измеряться в часах, днях, story points или иных внутренних единицах, но их смысл один: показать масштаб усилия, а не календарную дату завершения.
Как использовать
- для сравнения вариантов решения;
- для расчёта стоимости и ресурса;
- для перевода в оценку загрузки;
- для разговора о компромиссах по объёму.
Как считать лучше
1. Оценивайте на основе достаточно ясной декомпозиции. 2. Учитывайте не только производство, но и координацию, тестирование, согласования. 3. Не смешивайте чистое effort с ожиданием доступности людей. 4. Сверяйте оценку с типовыми кейсами из прошлых проектов. 5. Обновляйте её при изменении требований или решений.
Практический шаблон
Для базовой оценки трудозатрат полезно считать работу слоями:
- основная реализация;
- аналитика и уточнение;
- тестирование и исправления;
- координация, синки, демонстрации, согласования;
- резерв на ожидаемую неопределённость.
Так PM быстрее видит, не превратилась ли оценка в число только «на разработку», которое потом ошибочно переводят в срок и стоимость.
Что полезно проверять отдельно
- одинаково ли понимают объём исполнители и PM;
- учтены ли интеграции, приёмка, доработки по обратной связи;
- не забыты ли внешние зависимости и ожидание решений;
- отделён ли effort от реальной доступности людей из capacity planning.
Типовой сбой в расчёте
Частая ошибка выглядит так: команда даёт 10 человеко-дней на реализацию, PM превращает это в две календарные недели и считает вопрос закрытым. Но затем всплывают уточнения, тестирование, демонстрация, исправления и неполная доступность людей. В итоге проблема не в том, что команда «ошиблась», а в том, что исходно не была собрана полная структура трудозатрат.
Типовые ошибки
- считать только работу разработки;
- путать идеальное усилие с реальной нагрузкой команды;
- не учитывать проектную координацию;
- использовать трудозатраты как обещание срока.