Перейти к содержимому

129 часов против 49: анатомия ошибки в оценке трудоёмкости

129 часов против 49: анатомия ошибки в оценке трудоёмкости

В нашем архиве лежит один сезонный лендинг. По нему выставлено 49 часов. Фактически на него ушло 129. Проект сдан, клиент доволен, деньги получены — и это единственный случай, где я точно знаю обе цифры, потому что обе сохранились в документах.

Разрыв в 2,6 раза — не рекорд и не исключение. В полевом обследовании 52 проектов перерасход трудозатрат встречался в 76% случаев, а средняя величина перерасхода составила 41%. Вопрос, который стоит задавать при оценке трудоёмкости проекта, звучит не «сколько часов», а «в какой момент и на каком основании названо это число».

Коротко

Оценка ошибается не потому, что кто-то плохо считает часы. Она ошибается потому, что её называют раньше, чем зафиксированы требования, и после этого первое названное число работает якорем для всех последующих пересчётов. Лечится это не точностью расчёта, а переносом оценки в отдельную стадию процесса — после описания объёма и до подписания.

129 чфактические трудозатраты по проекту
49 чвыставлено клиенту по договорённости
×2,6разрыв между фактом и оценкой

Куда ушли 80 непредвиденных часов

Ответ «недооценили сложность» ничего не объясняет и ничего не чинит. Полезно другое: разложить разрыв на события, каждое из которых можно назвать и датировать. В этом проекте таких событий было пять, и ни одно из них не выглядело в момент возникновения как проблема.

Оценка названа до описания объёма. Число прозвучало на первом созвоне, в ответ на вопрос «примерно сколько это». Примерная цифра нужна была для того, чтобы клиент понял порядок затрат, — а стала цифрой в договорённости. Между «примерно» и «согласовано» не было ни одного документа.

Каждое уточнение приходило по одному. Добавить блок с программой. Показать цены в двух валютах. Сделать отдельную версию для рассылки. По отдельности каждое уточнение — полчаса-час, и отказывать в нём выглядит мелочностью. Сумма этих получасов и составила основную часть разрыва.

Согласование считалось бесплатным. В оценку вошла работа дизайнера и верстальщика. Не вошли: переписка, три круга правок текста, ожидание материалов, повторная сборка после того, как клиент показал макет коллеге. Это часы менеджера и часы исполнителя, и они существуют независимо от того, посчитали их или нет.

Сезонность съела резерв. Проект новогодний, дата запуска не двигается. Когда работа опаздывает, а дата фиксирована, единственный доступный ресурс — часы людей вечером и в выходные. Резерв, который в обычном проекте выражается в сдвиге срока, здесь сразу выражался в трудозатратах.

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

СобытиеЧто теряетсяКто это замечает
Оценка названа до описания объёмаПраво пересмотреть цифру без потери лицаНикто — цифра кажется удачей
Уточнения приходят поштучноЧасы исполнителей, по часу за разИсполнитель — и молчит
Согласование не входит в оценкуВремя менеджера целикомНикто — эти часы нигде не учитываются
Фиксированная дата без резерваВечера и выходные командыКоманда — в виде усталости, а не цифры
Нет пересчёта на серединеВозможность договоритьсяРуководитель — в конце месяца

Обратите внимание на третий столбец. Три события из пяти не видит внутри компании никто: у них нет ни отчёта, ни ответственного, ни момента, в который они должны всплыть. Именно поэтому они повторяются.

Почему первая названная цифра определяет все следующие

Разрыв в оценке — не свойство конкретной команды. Это устойчивая закономерность, воспроизведённая в разных выборках и в разных странах. И у неё есть механизм, который описан отдельно.

Исследование

В обследовании реальных программных проектов перерасход трудозатрат встречался в 76% случаев, а средняя величина перерасхода составила 41%. Обобщая более ранние международные обзоры, автор приводит типичный диапазон недооценки в 30–40%.

Kjetil Johan Moløkken-Østvold, Университет Осло, докторская диссертация, август 2004. Структурированные интервью с руководителями проектов в 18 компаниях, 52 проекта, сбор данных февраль–ноябрь 2003, Норвегия · simula.no (PDF)

Ограничение этих данных стоит назвать самому: выборка норвежская, двадцатилетней давности, и фактические часы собраны со слов руководителей проектов, а не из системы учёта времени. Ценность не в точности процента, а в устойчивости самого факта — перерасход оказывается нормой, а не отклонением.

Дальше начинается интересное. Обзор эмпирических работ по экспертной оценке показывает, что дело не в арифметике, а в порядке появления чисел.

Исследование

Экспертные оценки трудозатрат систематически смещаются к первому названному числу — «якорю». Ранняя грубая прикидка, сделанная при минимуме информации, продолжает влиять на последующие пересчёты даже после того, как появились уточнённые требования.

Magne Jørgensen. «A Review of Studies on Expert Estimation of Software Development Effort», Journal of Systems and Software, 2004. Аналитический обзор 15 сравнительных эмпирических исследований экспертной оценки · simula.no (PDF)

Это обзорная работа, обобщающая чужие эксперименты, часть из которых лабораторные, — и точной доли случаев, в которых якорение срабатывает, в ней нет. Но качественный вывод объясняет наш случай точнее любой цифры: «примерно 49» на первом созвоне не было оценкой. Это был якорь, к которому потом подтягивались все расчёты, включая те, что делались уже с полным пониманием объёма.

Оценка, названная до описания объёма, — это переговорная позиция, а не оценка.

Что изменилось после этого проекта

Вывод, который мы сделали, касался не методики расчёта, а устройства процесса. Оценка перестала быть репликой в разговоре и стала отдельной стадией с собственным входом и выходом. Порядок стал такой: заявка, уточнение задачи, техническое задание, оценка трудозатрат, согласование, выполнение, сдача, три дня на приёмку.

Принципиальны в этом порядке две вещи. Первая: оценка стоит после ТЗ, а не до него, — считать можно только то, что описано. Вторая: между оценкой и выполнением стоит согласование, то есть явная точка, в которой обе стороны видят одно и то же число и подтверждают его.

Оценка как отдельная стадия: между описанием объёма и началом работ стоит явная точка согласования числа.
01Заявка и уточнение задачи
02Техническое задание: что входит и что не входит
03Оценка трудозатрат
04Согласование числа
05Выполнение и сдача
любое изменение объёма возвращает процесс на стадию 02, а не добавляется молча к стадии 05

Вторая часть решения — денежная. В обслуживании появились абонентские тарифы с прямо названным объёмом и отдельная ставка за часы сверх него. Не потому, что так выгоднее, а потому, что при таком устройстве разговор о дополнительных часах происходит по правилу, а не по настроению.

Насколько велик типичный разрыв

Какую долю фактических трудозатрат покрывала исходная оценка. Дорожка — фактические трудозатраты, принятые за 100%.

За пределами этого сравнения остаётся главное: средние значения обманчивы. Распределение перерасходов несимметрично — основная часть риска сидит не в середине, а в хвосте, и именно поэтому планирование по среднему не защищает.

Исследование

На выборке 1 471 ИТ-проекта средний перерасход бюджета составил 27%. При этом каждый шестой проект оказался «чёрным лебедем»: перерасход бюджета в среднем 200% и превышение сроков почти на 70%.

Bent Flyvbjerg (Saïd Business School, Оксфорд), Alexander Budzier. «Why Your IT Project May Be Riskier Than You Think», Harvard Business Review, сентябрь 2011. Сравнение плановых бюджетов и выгод с фактическими по 1 471 инициативе; выборка смещена к государственным организациям и США · hbr.org

Ограничение здесь существенное: это крупные корпоративные и государственные инициативы, а не сезонный лендинг. Переносится не масштаб, а форма распределения. Один проект из шести уходит в разнос, и он оплачивается прибылью остальных пяти.

Что изменилось в 2026 году и что не изменилось

Изменилось то, что часть работ действительно ускорилась. Прототип, черновик текста, разбор требований, первая версия схемы — всё это теперь делается заметно быстрее, и соблазн уменьшить оценку на этом основании велик. Не изменилось то, откуда берётся разрыв: он берётся из объёма, а не из скорости исполнения.

Исследование

52% проектов, завершённых за предшествующие 12 месяцев, столкнулись с неконтролируемым разрастанием объёма работ. Пятью годами ранее этот показатель составлял 43%.

Project Management Institute, «Pulse of the Profession» 2018. Глобальный опрос 5 402 респондентов: 4 455 практиков проектного управления, 447 руководителей высшего звена, 800 руководителей проектных офисов · pmi.org (PDF)

Отчёт основан на самоотчётах практиков и выпущен профессиональной ассоциацией, которая заинтересована в продвижении собственных стандартов, — это надо держать в уме. Но направление изменения показательно: доля проектов с разрастанием объёма растёт, а не падает, несмотря на два десятилетия развития методологий.

Практический вывод из этого простой. Если инструмент ускорил исполнение вдвое, но объём по-прежнему уточняется поштучно и молча, разрыв между оценкой и фактом сохранится — просто он будет выражен в других единицах.

Четыре правила, которые убирают большую часть разрыва

01

Не называть число до описания объёма

На вопрос «примерно сколько» есть один безопасный ответ: диапазон порядка величины и срок, к которому будет названа оценка. Всё остальное станет якорем.

02

Считать не только производство

Согласование, ожидание материалов, круги правок и повторная сборка — это часы. Если их нет в оценке, они всё равно есть в факте.

03

Писать, что не входит

Перечень исключений короче перечня работ и работает лучше него. Именно он превращает уточнение в отдельный разговор, а не в бесплатное дополнение.

04

Пересчитывать на середине

Назначьте точку, в которой факт сравнивается с оценкой, и сделайте её обязательной. Неудобный разговор в середине проекта дешевле молчаливого списания в конце.

Если оценка появляется в переписке раньше, чем описан объём, вы уже не оцениваете проект — вы торгуетесь о числе, которое назвали случайно.

Вопросы, которые задают чаще всего

Как правильно оценить трудоёмкость проекта, если требования ещё не готовы?

Никак — и это честный ответ. До описания объёма оценивается не проект, а стадия: сколько времени займёт разбор требований и подготовка технического задания. Эту стадию можно оценить точно, потому что её содержание известно. Оценка всего проекта даётся после неё, и клиент получает не одно число в начале, а два в известные моменты.

Что делать, если клиент требует цифру немедленно?

Дать диапазон порядка величины и назвать срок, к которому будет дана оценка. Диапазон должен быть достаточно широким, чтобы не стать якорем: «от двух до шести недель, точнее — после ТЗ». Узкий диапазон, названный из желания выглядеть уверенно, работает как точное число и создаёт ту же проблему.

Какой резерв закладывать в оценку?

Резерв в процентах не решает проблему, потому что разрыв возникает от изменения объёма, а не от неточности расчёта. Работает другое: отдельная строка бюджета на требования, которые появятся после первого показа результата, с собственным владельцем и правилом расходования. Если такой строки нет, эти требования всё равно будут выполнены — за счёт исполнителя.

Насколько показателен разрыв 129 против 49?

Это один проект одной компании, а не отраслевой ориентир. Показательно в нём не соотношение, а то, что обе цифры сохранились: фактические часы были записаны, а не восстановлены по памяти. В большинстве компаний такого сравнения просто нельзя сделать, потому что фактические трудозатраты нигде не фиксируются.

Откуда внутренние цифры

Цифры «129 часов фактически» и «49 часов выставлено» — из внутренней сметы по проекту сезонного лендинга в архиве Alego.Digital. Порядок стадий (заявка → уточнение → техническое задание → оценка трудозатрат → согласование → выполнение → сдача → три дня приёмки) и абонентская модель с отдельной ставкой за дополнительные часы — из регламента взаимодействия с клиентами того же периода. Это внутренние документы компании автора; они не проверялись независимой стороной и приводятся как иллюстрация механики, а не как отраслевой ориентир. Перечень пяти событий, на которые разложен разрыв, реконструирован по документам проекта и переписке.

Внешние источники
  1. Moløkken-Østvold K. J. Effort and Schedule Estimation of Software Development Projects. University of Oslo, PhD thesis, август 2004. simula.no
  2. Jørgensen M. A Review of Studies on Expert Estimation of Software Development Effort. Journal of Systems and Software, 2004. simula.no
  3. Flyvbjerg B., Budzier A. Why Your IT Project May Be Riskier Than You Think. Harvard Business Review, сентябрь 2011. hbr.org
  4. Project Management Institute. Pulse of the Profession 2018 (опрос 5 402 респондентов). pmi.org