Оценка трудозатрат как стадия процесса, а не как реплика в переговорах
В большинстве компаний оценка трудозатрат не является стадией процесса. Она является репликой: кто-то спросил «сколько это», кто-то ответил. У реплики нет входа, нет владельца, нет оформленного результата и нет правила, по которому её можно пересмотреть.
Разница видна в момент конфликта. Когда объём изменился, а число осталось прежним, спор идёт о добросовестности сторон — потому что предъявить нечего. Когда оценка была стадией, спор идёт о том, изменился объём или нет, и на этот вопрос есть документ.
Оценка становится управляемой, когда у неё появляются четыре атрибута: вход — описанный объём, владелец — конкретный человек, выход — оформленное основание оценки, и точка возврата — правило, по которому изменение объёма возвращает процесс к пересчёту. Точность расчёта при этом вторична: формат постановки вопроса влияет на результат сильнее, чем метод вычисления.
Четыре атрибута стадии
Проверить, является ли оценка в вашей компании стадией, можно за пять минут — по наличию четырёх вещей. Отсутствие любой из них означает, что оценка живёт в переписке.
Вход: описанный объём. Оценивать можно только то, что описано, причём описание должно включать перечень того, что в работу не входит. Исключения короче включений и работают лучше: именно они определяют, будет ли следующее уточнение бесплатным дополнением или отдельным разговором.
Владелец: конкретный человек. Не «команда оценила», а человек, чья подпись стоит под числом и кто отвечает на вопрос, из чего оно сложилось. Коллективная оценка без владельца снимает ответственность со всех сразу и лишает организацию возможности учиться на расхождениях.
Выход: основание оценки. Не число, а число с составом: из каких работ оно сложилось, какие допущения приняты, что не учтено. Основание нужно не заказчику — оно нужно тому, кто через месяц будет разбираться, почему факт разошёлся с планом.
Точка возврата. Правило, по которому изменение объёма возвращает процесс к пересчёту, а не добавляется к текущей работе. Без такого правила изменения накапливаются молча, и это основной механизм расхождения плана с фактом.
| Атрибут | Признак наличия | Что ломается без него |
|---|---|---|
| Вход: описанный объём | Есть перечень того, что не входит | Каждое уточнение бесплатно |
| Владелец | Известно имя автора числа | Некому объяснить расхождение |
| Выход: основание | Число разложено на состав и допущения | Нельзя разобрать причину промаха |
| Точка возврата | Изменение объёма запускает пересчёт | Изменения накапливаются молча |
Эта конструкция не изобретена мной. Она формализована в отраслевых сводах практик, и полезно посмотреть, как именно.
Как оценка описана в своде практик
Жизненный цикл оценки описан как четыре последовательные стадии: подготовка к оценке (формирование подхода и входных данных), формирование оценки с оформленным выходом «основание оценки», управление оценкой (пересмотр при изменении объёма) и улучшение самого процесса оценки по накопленным расхождениям.
Ограничение называю прямо: это нормативный документ, а не измерение, и я читал изложение его структуры на сайте организации, а не полный текст стандарта. Полезен он не как доказательство, а как подтверждение, что «оценка — это процесс с входом и выходом» является общепринятой практикой, а не моим личным предпочтением. Стоит знать и контраргумент: более новый международный стандарт ISO 21502:2020 сознательно отказался от табличной модели «вход — выход» в пользу описания практик.
Формат вопроса меняет результат сильнее метода
Самое неожиданное в теме оценки — то, что качество результата сильнее зависит от формулировки вопроса, чем от квалификации оценщика. Это проверено в поле.
Когда оценщиков просили назвать интервал «от и до» с уверенностью 90%, фактические затраты попадали в заявленный интервал лишь в 74% случаев. Когда тот же вопрос переформулировали как вероятностный — «насколько вероятно, что затраты превысят такое-то значение», — попадание выросло до 87%.
Выборка невелика и ограничена двумя норвежскими компаниями и программными проектами — переносить проценты в другую отрасль нельзя. Практический вывод переносится: если вы спрашиваете «сколько», то получаете уверенность, которой нет. Вопрос «какова вероятность, что мы превысим Х» даёт заметно более честный ответ и, что важнее, задаёт формат, в котором неопределённость можно обсуждать без потери лица.
Что даёт формализация входа
Второй проверяемый эффект — связь между проработанностью объёма перед оценкой и предсказуемостью итога. Он измерялся в капитальном строительстве, где выборки крупнее и данные полнее, чем в ИТ.
Качество предпроектной проработки объёма объясняет около 23% разброса итоговых затрат по промышленным проектам. Проекты с лучшей проработкой стабильно показывали более предсказуемые стоимость и сроки, чем проекты с худшей.
Это строительная отрасль, а не разработка, и переносить сюда сами проценты неправильно. Переносится механизм: формализованный вход даёт измеримый вклад в предсказуемость — но лишь четверть разброса, а не весь. Остальные три четверти зависят от того, что происходит после оценки, и это ровно та часть, которую закрывает точка возврата.
Уверенность не растёт сама по себе
Распространено убеждение, что по ходу проекта неопределённость сужается автоматически — так называемый конус неопределённости. У этой красивой картинки есть эмпирическая проверка, и она её не подтверждает.
Диапазон неопределённости оценок оставался практически неизменным на всех фазах проектов — соотношение верхней и нижней границ около 3,25, — вместо ожидаемого сужения. Медианная ошибка оценки составила 1,8 раза, средняя — 2,0.
Это данные одной компании, то есть кейс, опровергающий популярную кривую, а не окончательное опровержение для всех контекстов. Но вывод для процессного дизайна прямой: если неопределённость не сужается сама, стадия оценки не может быть однократной. Она должна повторяться при каждом изменении объёма — и именно поэтому четвёртый атрибут, точка возврата, важнее первых трёх.
Как встроить стадию в существующий процесс
Единственное, что здесь по-настоящему трудно, — держать возврат. Возвращать процесс к описанию объёма из-за получасовой правки кажется бюрократией, и именно поэтому первое исключение делается почти всегда, а после первого счёт уже не ведётся. Практическое решение — порог: изменения меньше согласованной величины накапливаются в отдельный список и пересчитываются пакетом, всё остальное возвращает процесс на первый шаг. Как накапливается такой список и во что он обходится, я разбираю на конкретном проекте, где факт разошёлся с оценкой в 2,6 раза.
Четыре решения, чтобы оценка стала стадией
Запретите называть числа до описания объёма
На вопрос «примерно сколько» — диапазон порядка величины и срок, к которому будет дана оценка.
Спрашивайте о вероятности превышения
Не «сколько это займёт», а «какова вероятность, что мы выйдем за Х». Формат вопроса меняет качество ответа.
Оформляйте основание, а не число
Состав работ, допущения и то, что не учтено. Полстраницы, которая через месяц объяснит расхождение.
Назначьте порог возврата
Изменение больше порога возвращает процесс к описанию объёма. Меньше — накапливается в список и пересчитывается пакетом.
Если под числом нет имени и основания, у вас нет оценки — у вас есть цифра, которую кто-то однажды назвал.
Вопросы, которые задают чаще всего
Что должно входить в основание оценки?
Три вещи: перечень работ с трудозатратами по каждой, принятые допущения и список того, что в оценку не вошло. Объём — от половины до одной страницы. Смысл документа не в точности, а в возможности через месяц открыть его и увидеть, какое именно допущение не подтвердилось. Без этого разбор расхождения превращается в обмен воспоминаниями.
Кто должен быть владельцем оценки?
Тот, кто будет отвечать за выполнение, а не тот, кто ведёт переговоры. Если оценку даёт менеджер по продажам, а выполняет команда, расхождение гарантировано, и разбирать его будет некому: у числа не окажется автора, готового объяснить его состав. Компромисс — оценку формирует исполнитель, а коммерческие условия строит менеджер поверх неё.
Как оценивать, если требования будут меняться постоянно?
Оценивать не проект, а итерацию, и делать стадию оценки повторяющейся. Эмпирика показывает, что неопределённость не сужается сама по ходу проекта, поэтому однократная оценка на старте в таких условиях бессмысленна. Работает другое: короткий горизонт с точной оценкой плюс явно названный диапазон на весь объём, пересматриваемый по правилу.
Не превратится ли формализация оценки в бюрократию?
Превратится, если оформлять всё. Порог возврата и существует для того, чтобы мелкие изменения не запускали полный цикл: они накапливаются в списке и пересчитываются пакетом. Признак правильно выбранного порога — за месяц список пересчитывается один-два раза, а не каждый день и не ни разу.
Стадийность процесса (заявка → уточнение → техническое задание → оценка трудозатрат → согласование → выполнение → сдача → три дня приёмки) — из регламента взаимодействия с клиентами Alego.Digital. Это внутренний документ компании автора; он не проверялся независимой стороной и приводится как иллюстрация механики. Правило порога возврата и накопления мелких изменений в пакет — авторская практика, сложившаяся после разбора проектов с расхождением плана и факта; формализованного описания этого правила в документах компании нет.
- Project Management Institute. Practice Standard for Project Estimating, 2011 (описание структуры на pmi.org). pmi.org
- Jørgensen M. Realism in Assessment of Effort Estimation Uncertainty. IEEE Transactions on Software Engineering, апрель 2004. simula.no
- Wang Y.-R., Gibson G. E. Jr. Project Definition Rating Index as an Indicator of Project Performance. PMI Research Conference, 2002. pmi.org
- Little T. Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty. IEEE Software, 2006. researchgate.net