Содержание
«Это на пару дней» — фраза, после которой проекты опаздывают на недели. Оценка задач в разработке принципиально неточна, но ей можно управлять. Разберём рабочие методы, типичные ошибки и то, как превратить оценки в реалистичные сроки.
Почему оценка так сложна
Разработка — это создание нового, а не повторение известного. Оценивая задачу, мы по сути прогнозируем то, чего ещё не делали: всплывут неизвестные требования, чужой код окажется сложнее, появятся баги и переключения контекста. Поэтому цель оценки — не «угадать точно», а снизить неопределённость и договориться об ожиданиях.
Хорошая оценка — это не точное число, а честный диапазон с понятными допущениями.
Story points против часов
Два главных подхода:
- Story points — относительная оценка сложности по шкале (часто Фибоначчи: 1, 2, 3, 5, 8, 13). Не привязана к конкретным часам, хорошо работает на дистанции: команда измеряет свою скорость (velocity) и прогнозирует, сколько points закроет за спринт.
- Часы / дни — абсолютная оценка. Понятнее заказчику и подходит для коротких конкретных задач, но провоцирует ложную точность и давление «ты же сказал, что за 4 часа».
На практике многие команды оценивают в story points внутри спринта, а сроки для бизнеса получают, переводя points через свою историческую скорость.
Покер планирования
Покер планирования (planning poker) — командная техника оценки. Каждый участник независимо выбирает оценку и показывает «карту» одновременно с остальными. Если оценки сильно разошлись — это не повод усреднять, а сигнал: кто-то видит сложность или знает деталь, которой не видят другие. Обсуждение этих расхождений и есть главная ценность метода.
Метод трёх точек
Когда неопределённость высока, одну цифру заменяют тремя: оптимистичная (O), наиболее вероятная (M) и пессимистичная (P). Итоговую оценку считают как взвешенное среднее — по формуле PERT: (O + 4·M + P) / 6.
Например, задача: оптимистично 2 дня, вероятно 4, пессимистично 9. Оценка = (2 + 16 + 9) / 6 ≈ 4,5 дня. Метод честно показывает «хвост» риска, который прячется за одной цифрой.
5 типичных ошибок оценки
- Оценивают «в вакууме». Забывают про ревью, тесты, деплой, обсуждения — а это половина времени.
- Путают оценку и обязательство. Оценка — прогноз, а не клятва уложиться любой ценой.
- Раздувают каждую задачу. Буфер в каждой оценке скрыт и съедается; лучше один буфер на проект.
- Берут слишком крупные задачи. Всё, что больше пары недель, оценивается плохо — дробите.
- Не учитывают зависимости. Сумма оценок ≠ срок проекта: его задаёт критический путь.
Буфер и переход к срокам
Оценки оптимистичны почти всегда, поэтому к сумме добавляют буфер на риски — обычно 15–30% в зависимости от неопределённости. Но даже с буфером сумма оценок не равна сроку: задачи идут не строго друг за другом, часть выполняется параллельно, часть ждёт зависимостей.
Чтобы превратить оценки в реальную дату, постройте план с зависимостями и посмотрите критический путь.
От оценок — к дате завершения
Введите оценки задач, размер команды и буфер — калькулятор посчитает реалистичный срок проекта.
Частые вопросы
Story points или часы — что лучше?
Story points оценивают относительную сложность и хороши для прогноза скорости команды на дистанции. Часы понятнее заказчику и подходят для коротких задач. Часто оценивают в points, а сроки получают через историческую скорость команды.
Что такое покер планирования?
Техника командной оценки: каждый независимо выбирает оценку (обычно по Фибоначчи), затем карты вскрываются одновременно. Расхождения обсуждаются — так находят непонятые требования и скрытую сложность.
Какой буфер закладывать на риски?
Обычно 15–30% сверху, в зависимости от неопределённости. Чем больше неизвестных, тем выше буфер. Лучше закладывать буфер на проект целиком, а не раздувать каждую задачу.