129 часов против 49: анатомия ошибки в оценке трудоёмкости
В нашем архиве лежит один сезонный лендинг. По нему выставлено 49 часов. Фактически на него ушло 129. Проект сдан, клиент доволен, деньги получены — и это единственный случай, где я точно знаю обе цифры, потому что обе сохранились в документах.
Разрыв в 2,6 раза — не рекорд и не исключение. В полевом обследовании 52 проектов перерасход трудозатрат встречался в 76% случаев, а средняя величина перерасхода составила 41%. Вопрос, который стоит задавать при оценке трудоёмкости проекта, звучит не «сколько часов», а «в какой момент и на каком основании названо это число».
Оценка ошибается не потому, что кто-то плохо считает часы. Она ошибается потому, что её называют раньше, чем зафиксированы требования, и после этого первое названное число работает якорем для всех последующих пересчётов. Лечится это не точностью расчёта, а переносом оценки в отдельную стадию процесса — после описания объёма и до подписания.
Куда ушли 80 непредвиденных часов
Ответ «недооценили сложность» ничего не объясняет и ничего не чинит. Полезно другое: разложить разрыв на события, каждое из которых можно назвать и датировать. В этом проекте таких событий было пять, и ни одно из них не выглядело в момент возникновения как проблема.
Оценка названа до описания объёма. Число прозвучало на первом созвоне, в ответ на вопрос «примерно сколько это». Примерная цифра нужна была для того, чтобы клиент понял порядок затрат, — а стала цифрой в договорённости. Между «примерно» и «согласовано» не было ни одного документа.
Каждое уточнение приходило по одному. Добавить блок с программой. Показать цены в двух валютах. Сделать отдельную версию для рассылки. По отдельности каждое уточнение — полчаса-час, и отказывать в нём выглядит мелочностью. Сумма этих получасов и составила основную часть разрыва.
Согласование считалось бесплатным. В оценку вошла работа дизайнера и верстальщика. Не вошли: переписка, три круга правок текста, ожидание материалов, повторная сборка после того, как клиент показал макет коллеге. Это часы менеджера и часы исполнителя, и они существуют независимо от того, посчитали их или нет.
Сезонность съела резерв. Проект новогодний, дата запуска не двигается. Когда работа опаздывает, а дата фиксирована, единственный доступный ресурс — часы людей вечером и в выходные. Резерв, который в обычном проекте выражается в сдвиге срока, здесь сразу выражался в трудозатратах.
Никто не пересчитывал на ходу. Сигнал о перерасходе появился примерно на середине — и не превратился в разговор. Разговор о деньгах в момент, когда работа наполовину сделана, всегда неудобнее, чем в начале, и его откладывают до конца, где он уже не имеет смысла.
| Событие | Что теряется | Кто это замечает |
|---|---|---|
| Оценка названа до описания объёма | Право пересмотреть цифру без потери лица | Никто — цифра кажется удачей |
| Уточнения приходят поштучно | Часы исполнителей, по часу за раз | Исполнитель — и молчит |
| Согласование не входит в оценку | Время менеджера целиком | Никто — эти часы нигде не учитываются |
| Фиксированная дата без резерва | Вечера и выходные команды | Команда — в виде усталости, а не цифры |
| Нет пересчёта на середине | Возможность договориться | Руководитель — в конце месяца |
Обратите внимание на третий столбец. Три события из пяти не видит внутри компании никто: у них нет ни отчёта, ни ответственного, ни момента, в который они должны всплыть. Именно поэтому они повторяются.
Почему первая названная цифра определяет все следующие
Разрыв в оценке — не свойство конкретной команды. Это устойчивая закономерность, воспроизведённая в разных выборках и в разных странах. И у неё есть механизм, который описан отдельно.
В обследовании реальных программных проектов перерасход трудозатрат встречался в 76% случаев, а средняя величина перерасхода составила 41%. Обобщая более ранние международные обзоры, автор приводит типичный диапазон недооценки в 30–40%.
Ограничение этих данных стоит назвать самому: выборка норвежская, двадцатилетней давности, и фактические часы собраны со слов руководителей проектов, а не из системы учёта времени. Ценность не в точности процента, а в устойчивости самого факта — перерасход оказывается нормой, а не отклонением.
Дальше начинается интересное. Обзор эмпирических работ по экспертной оценке показывает, что дело не в арифметике, а в порядке появления чисел.
Экспертные оценки трудозатрат систематически смещаются к первому названному числу — «якорю». Ранняя грубая прикидка, сделанная при минимуме информации, продолжает влиять на последующие пересчёты даже после того, как появились уточнённые требования.
Это обзорная работа, обобщающая чужие эксперименты, часть из которых лабораторные, — и точной доли случаев, в которых якорение срабатывает, в ней нет. Но качественный вывод объясняет наш случай точнее любой цифры: «примерно 49» на первом созвоне не было оценкой. Это был якорь, к которому потом подтягивались все расчёты, включая те, что делались уже с полным пониманием объёма.
Что изменилось после этого проекта
Вывод, который мы сделали, касался не методики расчёта, а устройства процесса. Оценка перестала быть репликой в разговоре и стала отдельной стадией с собственным входом и выходом. Порядок стал такой: заявка, уточнение задачи, техническое задание, оценка трудозатрат, согласование, выполнение, сдача, три дня на приёмку.
Принципиальны в этом порядке две вещи. Первая: оценка стоит после ТЗ, а не до него, — считать можно только то, что описано. Вторая: между оценкой и выполнением стоит согласование, то есть явная точка, в которой обе стороны видят одно и то же число и подтверждают его.
Вторая часть решения — денежная. В обслуживании появились абонентские тарифы с прямо названным объёмом и отдельная ставка за часы сверх него. Не потому, что так выгоднее, а потому, что при таком устройстве разговор о дополнительных часах происходит по правилу, а не по настроению.
Насколько велик типичный разрыв
За пределами этого сравнения остаётся главное: средние значения обманчивы. Распределение перерасходов несимметрично — основная часть риска сидит не в середине, а в хвосте, и именно поэтому планирование по среднему не защищает.
На выборке 1 471 ИТ-проекта средний перерасход бюджета составил 27%. При этом каждый шестой проект оказался «чёрным лебедем»: перерасход бюджета в среднем 200% и превышение сроков почти на 70%.
Ограничение здесь существенное: это крупные корпоративные и государственные инициативы, а не сезонный лендинг. Переносится не масштаб, а форма распределения. Один проект из шести уходит в разнос, и он оплачивается прибылью остальных пяти.
Что изменилось в 2026 году и что не изменилось
Изменилось то, что часть работ действительно ускорилась. Прототип, черновик текста, разбор требований, первая версия схемы — всё это теперь делается заметно быстрее, и соблазн уменьшить оценку на этом основании велик. Не изменилось то, откуда берётся разрыв: он берётся из объёма, а не из скорости исполнения.
52% проектов, завершённых за предшествующие 12 месяцев, столкнулись с неконтролируемым разрастанием объёма работ. Пятью годами ранее этот показатель составлял 43%.
Отчёт основан на самоотчётах практиков и выпущен профессиональной ассоциацией, которая заинтересована в продвижении собственных стандартов, — это надо держать в уме. Но направление изменения показательно: доля проектов с разрастанием объёма растёт, а не падает, несмотря на два десятилетия развития методологий.
Практический вывод из этого простой. Если инструмент ускорил исполнение вдвое, но объём по-прежнему уточняется поштучно и молча, разрыв между оценкой и фактом сохранится — просто он будет выражен в других единицах.
Четыре правила, которые убирают большую часть разрыва
Не называть число до описания объёма
На вопрос «примерно сколько» есть один безопасный ответ: диапазон порядка величины и срок, к которому будет названа оценка. Всё остальное станет якорем.
Считать не только производство
Согласование, ожидание материалов, круги правок и повторная сборка — это часы. Если их нет в оценке, они всё равно есть в факте.
Писать, что не входит
Перечень исключений короче перечня работ и работает лучше него. Именно он превращает уточнение в отдельный разговор, а не в бесплатное дополнение.
Пересчитывать на середине
Назначьте точку, в которой факт сравнивается с оценкой, и сделайте её обязательной. Неудобный разговор в середине проекта дешевле молчаливого списания в конце.
Если оценка появляется в переписке раньше, чем описан объём, вы уже не оцениваете проект — вы торгуетесь о числе, которое назвали случайно.
Вопросы, которые задают чаще всего
Как правильно оценить трудоёмкость проекта, если требования ещё не готовы?
Никак — и это честный ответ. До описания объёма оценивается не проект, а стадия: сколько времени займёт разбор требований и подготовка технического задания. Эту стадию можно оценить точно, потому что её содержание известно. Оценка всего проекта даётся после неё, и клиент получает не одно число в начале, а два в известные моменты.
Что делать, если клиент требует цифру немедленно?
Дать диапазон порядка величины и назвать срок, к которому будет дана оценка. Диапазон должен быть достаточно широким, чтобы не стать якорем: «от двух до шести недель, точнее — после ТЗ». Узкий диапазон, названный из желания выглядеть уверенно, работает как точное число и создаёт ту же проблему.
Какой резерв закладывать в оценку?
Резерв в процентах не решает проблему, потому что разрыв возникает от изменения объёма, а не от неточности расчёта. Работает другое: отдельная строка бюджета на требования, которые появятся после первого показа результата, с собственным владельцем и правилом расходования. Если такой строки нет, эти требования всё равно будут выполнены — за счёт исполнителя.
Насколько показателен разрыв 129 против 49?
Это один проект одной компании, а не отраслевой ориентир. Показательно в нём не соотношение, а то, что обе цифры сохранились: фактические часы были записаны, а не восстановлены по памяти. В большинстве компаний такого сравнения просто нельзя сделать, потому что фактические трудозатраты нигде не фиксируются.
Цифры «129 часов фактически» и «49 часов выставлено» — из внутренней сметы по проекту сезонного лендинга в архиве Alego.Digital. Порядок стадий (заявка → уточнение → техническое задание → оценка трудозатрат → согласование → выполнение → сдача → три дня приёмки) и абонентская модель с отдельной ставкой за дополнительные часы — из регламента взаимодействия с клиентами того же периода. Это внутренние документы компании автора; они не проверялись независимой стороной и приводятся как иллюстрация механики, а не как отраслевой ориентир. Перечень пяти событий, на которые разложен разрыв, реконструирован по документам проекта и переписке.
- Moløkken-Østvold K. J. Effort and Schedule Estimation of Software Development Projects. University of Oslo, PhD thesis, август 2004. simula.no
- Jørgensen M. A Review of Studies on Expert Estimation of Software Development Effort. Journal of Systems and Software, 2004. simula.no
- Flyvbjerg B., Budzier A. Why Your IT Project May Be Riskier Than You Think. Harvard Business Review, сентябрь 2011. hbr.org
- Project Management Institute. Pulse of the Profession 2018 (опрос 5 402 респондентов). pmi.org