Planning Accuracy: как узнать, переоценивает или недооценивает задачи ваша команда
«Это должно занять два дня.» Три недели спустя фича всё ещё в работе.
Стив Макконнелл в книге Software Estimation: Demystifying the Black Art обнаружил, что программные проекты обычно превышают первоначальные оценки на 28–85%. Закон Брукса из Мифического человеко-месяца объясняет часть причины: сложность растёт нелинейно с объёмом, а добавление людей в опаздывающий проект делает его ещё более опаздывающим. PM расстроен. Разработчик чувствует вину. Дорожная карта — фикция. И вся организация молчаливо приняла, что инженерные оценки ненадёжны.
Это не проблема людей. Это проблема измерения. И она решаема.
Проблема оценок, которую никто не хочет признавать
Каждая инженерная команда оценивает задачи. Story points, размеры футболок, часы, дни — формат различается, но результат удивительно единообразен: оценки неточны.
Вопрос не в том, неточны ли оценки. А в том, ошибочны ли они в предсказуемом, корректируемом направлении.
Именно это измеряет Planning Accuracy: не идеально ли ваша команда оценивает (никто не оценивает), а достаточно ли стабильна их систематическая ошибка оценки для компенсации — и улучшается ли она со временем.
Два типа провала оценки
| Тип ошибки | Как выглядит | Влияние на бизнес |
|---|---|---|
| Хроническая недооценка | Задачи стабильно занимают в 2–3 раза дольше, чем оценено | Сорванные дедлайны, подорванное доверие стейкхолдеров, спринты-марши смерти |
| Хроническая переоценка | Задачи завершаются раньше, но буферное время тратится впустую | Низкая воспринимаемая скорость, заниженные обязательства, недоиспользованные мощности |
Большинство команд страдает от недооценки. Исследование Стива Макконнелла (автора Software Estimation: Demystifying the Black Art) показало, что программные проекты обычно превышают начальные оценки на 28–85% в зависимости от того, насколько рано была сделана оценка.
Но некоторые команды — особенно те, кто обжёгся на прошлых срывах дедлайнов — качнулись в другую сторону. Они закладывают запас в 50–100%, доставляя в срок, но с темпом, который раздражает продуктовые команды.
Оба паттерна — проблемы. Оба решаемы с помощью данных.
Как выглядит Planning Accuracy на практике
Planning Accuracy в PanDev Metrics сравнивает оценочные усилия (часы, story points или дни — что использует ваша команда) с фактическими усилиями (измеренными через данные активности IDE и временные метки завершения задач).
Формула проста:
Planning Accuracy = 1 − |Оценка − Факт| / Оценка
Балл 1.0 означает идеальную оценку. Балл 0.5 означает ошибку на 50%. Отрицательный балл означает, что ваши оценки хуже случайных.
Пример: разбор реального спринта
| Задача | Оценка (дни) | Факт (дни) | Planning Accuracy |
|---|---|---|---|
| Рефакторинг авторизации | 3 | 5 | 0,33 |
| Эндпоинт API поиска | 2 | 2,5 | 0,75 |
| Виджет дашборда | 1 | 0,5 | 0,50 |
| Экспорт CSV | 2 | 2 | 1,00 |
| Интеграция платежей | 5 | 8 | 0,40 |
| Пакет багфиксов | 1 | 1 | 1,00 |
| Итого спринт | 14 | 19 | 0,64 |
Planning Accuracy этого спринта — 0,64. Не ужасно, но с явным уклоном в недооценку. Две крупнейшие задачи (рефакторинг авторизации и интеграция платежей) определили большую часть промаха. Это типичный паттерн: крупные задачи оцениваются хуже мелких.
Почему разработчики не умеют оценивать (и это не их вина)
Ошибка планирования
Даниэль Канеман и Амос Тверски выделили «ошибку планирования» в 1979 году: люди систематически недооценивают время, необходимое для выполнения будущих задач, даже зная, что аналогичные задачи занимали больше времени в прошлом.
Для разработчиков это проявляется так:
- Помнят время на кодирование, но забывают время на отладку
- Предполагают happy path, не учитывая пограничные случаи
- Не закладывают циклы код-ревью, проблемы деплоя или задержки из-за зависимостей
- Оценивают исходя из «сколько займёт, если всё пойдёт хорошо»
Неизвестные неизвестные
Оценка ПО фундаментально сложнее оценки физических задач, потому что объём неизвестного — неизвестен. Столяр может оценить книжную полку, потому что сделал сотни. Разработчик, создающий новый микросервис, имеет переменные, которые буквально невозможно предвидеть: причуды API, баги библиотек, инфраструктурные проблемы, требования безопасности, возникающие в процессе разработки.
Эффект якоря
На планировании спринта первая озвученная оценка якорит всё последующее обсуждение. Если сениор-разработчик говорит «это на 3 поинта», джуниоры не решаются возразить, даже если интуиция подсказывает — это 8. Planning Poker был создан для предотвращения этого, но на практике многие команды отказались от него в пользу «быстрых» устных оценок, которые сильно привязаны к якорю.
Паттерны, которые мы видим в инженерных командах
Анализ данных Planning Accuracy из PanDev Metrics по B2B-инженерным командам выявляет стабильные паттерны — паттерны, отражающие то, что Канеман описал как «ошибку планирования» в действии:
Паттерн 1: Мелкие задачи оцениваются хорошо, крупные — нет
| Размер задачи | Ср. Planning Accuracy | Направление ошибки |
|---|---|---|
| < 4 часов | 0,82 | Лёгкая переоценка |
| 4–8 часов (1 день) | 0,71 | Лёгкая недооценка |
| 1–3 дня | 0,58 | Недооценка ~40% |
| 3–5 дней | 0,45 | Недооценка ~55% |
| 5+ дней | 0,31 | Недооценка в 2–3 раза |
Урок ясен: разбивайте задачи на части менее одного дня, где это возможно. Задача на 5 дней, оценённая как пять подзадач по 1 дню, будет точнее, чем одна оценка на 5 дней, хотя общий объём идентичен.
Паттерн 2: Точность оценки улучшается с обратной связью
Команды, которые анализируют данные Planning Accuracy после каждого спринта, показывают измеримое улучшение:
| Спринт № | Ср. Planning Accuracy (без ревью) | Ср. Planning Accuracy (с ревью) |
|---|---|---|
| 1 | 0,52 | 0,51 |
| 2 | 0,49 | 0,56 |
| 3 | 0,53 | 0,61 |
| 4 | 0,50 | 0,65 |
| 5 | 0,51 | 0,68 |
| 6 | 0,48 | 0,72 |
Без обратной связи команды болтаются около 0,50 бесконечно — по сути, точность подбрасывания монеты. С регулярным ревью они улучшаются до 0,70+ за 6 спринтов. Разницу делают данные, а не талант.
Паттерн 3: Продуктивность вторника предсказывает успех спринта
Наши данные показывают, что вторник — пиковый день кодирования в датасете. Команды, которые фронтально загружают сложные задачи на понедельник-вторник, имеют лучшие показатели завершения спринтов, чем команды с равномерным распределением. Причина: когда вторник проходит хорошо, остаток спринта получает инерцию. Когда самые сложные задачи откладываются на четверг-пятницу, риски накапливаются.
Паттерн 4: Язык и фреймворк влияют на точность оценки
| Основной язык | Ср. Planning Accuracy | Вероятная причина |
|---|---|---|
| Python | 0,68 | Быстрое прототипирование, меньше сюрпризов |
| TypeScript | 0,62 | Сложность фронтенда, итерации дизайна |
| Java | 0,57 | Избыточный шаблонный код, корпоративная сложность |
| Мультиязычные проекты | 0,48 | Переключение контекста, проблемы интеграции |
Java-проекты (2 107 часов в нашем датасете — больше всех) обычно имеют более низкую Planning Accuracy. Это отражает многословность языка и корпоративные среды, где Java доминирует — больше стейкхолдеров, больше требований compliance, больше «сюрпризов» при реализации.
Как улучшить Planning Accuracy: фреймворк для CPO и PM
Шаг 1: Начните отслеживать расхождение
Прежде чем улучшать, нужна базовая линия. Для каждой задачи записывайте:
- Оценочные усилия (в любых единицах вашей команды)
- Фактические усилия (измеренные, не самоотчётные)
- Дата оценки, дата начала, дата завершения
- Менялся ли скоуп в процессе
PanDev Metrics автоматизирует часть «фактические усилия» через отслеживание IDE. Когда разработчик работает над задачей, привязанной к конкретному тикету, система фиксирует, сколько активного времени кодирования ушло на неё.
Шаг 2: Определите направление смещения
После 2–3 спринтов рассчитайте среднюю Planning Accuracy и направление смещения вашей команды. Большинство команд обнаружит стабильную недооценку. Это нормально.
| Направление смещения | Что делать |
|---|---|
| Стабильная недооценка на 20–40% | Применяйте множитель 1,3x к оценкам как начальную коррекцию |
| Стабильная недооценка на 50%+ | Задачи слишком крупные — декомпозируйте перед оценкой |
| Стабильная переоценка на 20%+ | Снижайте запас — команда «подстраховывается» (возможно, неосознанно) |
| Случайно — то переоценка, то недооценка | Процесс оценки сломан — попробуйте другую гранулярность или методы оценки |
Шаг 3: Внедрите прогнозирование по классу-аналогу
Вместо оценки с нуля сравнивайте новые задачи с завершёнными аналогичными задачами и используйте их фактическую длительность как базу. PanDev Metrics ведёт историю длительностей задач по типам, что делает прогнозирование по классу-аналогу практичным.
Пример: «Последние три API-эндпоинта заняли 1,5, 2 и 2,5 дня. Этот похож по сложности. Оценка: 2 дня.»
Такой подход, рекомендованный Канеманом, резко снижает ошибку планирования, потому что он привязывается к фактическим результатам, а не к оптимистичным проекциям.
Шаг 4: Сделайте Planning Accuracy метрикой спринта
Добавьте её на дашборд ретроспективы спринта вместе с velocity и burndown. Когда команда видит свой балл точности, она естественным образом начинает калибровку.
Не используйте её для наказания. Planning Accuracy — это не балл, определяющий бонусы или оценку эффективности. Это инструмент калибровки. Если точность команды упала из-за новой технической задачи — это ожидаемо и нормально.
Шаг 5: Сообщайте неопределённость, а не даты
Вместо «это выйдет 15 марта» говорите «наша Planning Accuracy — 0,65 с уклоном в недооценку. Исходя из оценки в 10 дней, вероятный диапазон — 10–16 дней.» Стейкхолдеры могут работать с неопределённостью — с чем они не могут работать, так это с неожиданностями.
Цена плохих оценок
Плохая Planning Accuracy имеет кумулятивные последствия:
| Область влияния | Стоимость |
|---|---|
| Нарушенные обязательства | Подорванное доверие клиентов, продаж и руководства |
| Переработки/кранч | Выгорание, отток — наши данные показывают всплески времени кодирования перед дедлайнами с последующим спадом |
| Подстраховка | Снижение пропускной способности из-за завышения оценок для самозащиты |
| Неверные решения о найме | «Нам нужно больше разработчиков», когда реальная проблема — оценки и процессы |
| Задержки продукта | Обещанные клиентам фичи приходят с опозданием, влияя на выручку |
Это в точности отражает закон Брукса: «добавление рабочей силы в опаздывающий проект делает его ещё более опаздывающим.» Один VP of Engineering, с которым мы общались, подытожил: «Мы наняли двух разработчиков, чтобы решить проблему скорости. Не помогло, потому что проблема была не в мощностях — наши оценки были в 2 раза неточными, и мы всегда отставали независимо от количества людей.»
Planning Accuracy как опережающий индикатор
Planning Accuracy — один из немногих опережающих индикаторов, доступных инженерному руководству. К тому времени, когда DORA Metrics покажут ухудшение, ущерб уже нанесён. Но тренды Planning Accuracy дают недели предупреждения:
- Падение точности → команда берёт незнакомую работу или имеет скрытые блокеры
- Нарастание смещения в сторону недооценки → расползание скоупа или растущий технический долг
- Внезапное улучшение точности → команда может подстраховываться ради красивых цифр
Когда вы сочетаете Planning Accuracy с данными Activity Time (наша медиана в 78 мин/день показывает, что реалистично), можно строить дорожные карты, основанные на том, что ваша команда реально делает, а не на том, что вы хотели бы.
На основе агрегированных данных PanDev Metrics Cloud (апрель 2026). Паттерны оценки наблюдались в B2B-инженерных командах. Ссылки: Steve McConnell, "Software Estimation: Demystifying the Black Art" (2006); Daniel Kahneman, "Thinking, Fast and Slow" (2011); Fred Brooks, "The Mythical Man-Month" (1975).
Хотите отслеживать Planning Accuracy вашей команды автоматически? PanDev Metrics связывает активность IDE с вашим трекером задач, измеряя фактические усилия относительно оценок — без ручных табелей.