Предварительная оценка IT-проекта: аналогия, оценка по фичам, PERT и конус неопределённости

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

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

1. Оценка, цель и обязательство — три разные вещи

Стив МакКоннелл в «Software Estimation: Demystifying the Black Art» начинает с различения, которое снимает половину конфликтов вокруг сроков.

Смешение этих понятий — источник самой дорогой патологии отрасли. Когда менеджер спрашивает «сколько это займёт?», а имеет в виду «скажи, что успеешь к 15 марта», разговор идёт не об оценке, а о цели, замаскированной под вопрос. Инженер называет число, число мгновенно становится обязательством, и через три месяца выясняется, что обещание не выполнено, хотя оценки никто и не делал. Здоровая последовательность другая: сначала оценка, не подогнанная под желаемое; затем сравнение с целью; затем — если они не сходятся — явный разговор о размене (урезать объём, добавить людей, сдвинуть дату, снизить требования); и только потом обязательство. Оценка, скорректированная под цель до того, как размен обсуждён, не содержит информации: она уже равна тому, что от неё хотели услышать.

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

Практическое следствие: прежде чем заказывать оценку, спросите, какое решение она обслуживает. «Чтобы знать» означает, что оценка не нужна. «Выбрать между подрядчиком А и Б, разница в цене двукратная» — достаточно вилки «от трёх до шести месяцев». «Подписать фикс-прайс на 12 миллионов рублей» — точность придётся покупать, и покупается она снижением неопределённости, а не старанием оценщика.

2. Конус неопределённости: сколько точности физически доступно

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

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

И сразу честная оговорка, которую в популярных пересказах теряют. Конус не сужается сам по себе от того, что прошло время. Он сужается только там, где вы реально снимаете неопределённость: фиксируете требования, выбираете стек, рисуете интерфейс, пишете прототип, проверяете, что смежная система выдаёт нужные данные. Проект, который три месяца писал код, ни разу не поговорив о границах, остался в той же точке конуса, что и на старте, — на диаграмме это оранжевый пунктир. Конус — граница достижимого, а не расписание. Отсюда правило: если на гейте просят уточнить оценку, правильный ответ не «пересчитаю аккуратнее», а «назовите, какую неопределённость мы снимем, и я скажу, насколько сузится вилка». Второе следствие важно для переговоров: односторонняя оценка почти всегда враньё — число «четыре месяца» без диапазона неявно обещает точность, которой на этой стадии не существует. Правильная форма ответа — вилка с указанием, чем она обусловлена: «от 3 до 6 месяцев, сузим до 4–4,5 после двух недель аналитики и подтверждения формата данных».

3. Методы оценки: полный набор

Метод выбирают по двум параметрам: что есть на входе и какое решение оценка обслуживает. Практика пресейла в IT-компаниях опирается на два основных метода, с них и начнём.

Метод аналогии. Если нужно оценить потенциал клиента и соотнести его с предполагаемыми затратами, берут данные по похожим проектам. Очевидное условие: у компании должна быть накопленная база; без архива пар «что обещали — что получилось» метод вырождается в «мне кажется, это как тот проект». Занимает такая оценка от одного до трёх часов и даёт вилку — её достаточно, чтобы понять, разговариваем ли мы вообще: если у клиента бюджет 2 миллиона рублей, а аналоги стоили от 15, дальнейшая работа бессмысленна, и это хорошая новость, полученная за три часа вместо трёх недель. Академическая версия метода называется reference-class forecasting (раздел 6) и отличается дисциплиной: класс аналогов определяется заранее по формальным признакам, а не подбирается под ответ.

Метод по фичам. Для детальной оценки трудозатрат в большинстве IT-проектов подходит он. Проект декомпозируется, разбивается на фичи; каждая описывается и оценивается отдельно пресейлом каждого направления — так видно, сколько времени на конкретную фичу потратит аналитик, дизайнер, фронтендер, бэкендер, QA, DevOps. Затем вся информация сводится в единый список. Подход решает две задачи сразу: позволяет учесть все необходимые работы (а не только написание кода) и подобрать оптимальный состав команды — из свода видно, что дизайнер нужен на полтора месяца, а не на весь проект, и что без второго бэкендера сроки удваиваются. Сроки самой оценки зависят от проекта: для стандартного приложения — до 8 часов при условии, что все эксперты работают над оценкой одновременно. На практике так почти не бывает (пресейлы постоянно задействованы на коммерческих проектах), поэтому в среднем предварительная оценка занимает 3–5 дней календарного времени.

• Нисходящая (top-down) оценивает проект целиком или крупными блоками, распределяя сумму по частям: быстро при наличии аналогов, но систематически прячет забытые работы. Восходящая (bottom-up) — ровно метод по фичам: точнее по составу, но систематически оптимистична, потому что интеграция, ожидание и переключение контекста не принадлежат ни одной части. Считайте обоими способами: расхождение больше полутора раз означает потерянную работу.
• Параметрическая связывает размер продукта с трудоёмкостью; канонический пример — COCOMO II Барри Боэма: $E = a \cdot KLOC^{b} \cdot \prod_i EM_i$, где $KLOC$ — размер в тысячах строк, показатель $b$ отражает эффект масштаба (проект вдвое больше стоит больше чем вдвое), а $EM_i$ — 17 множителей от опыта команды до требований к надёжности. Ценность модели сегодня в двух выводах: трудоёмкость растёт нелинейно от размера, и разброс между сильной и слабой командой достигает порядка величины — больше, чем любой выбор технологии. Функциональные точки измеряют размер не в строках кода, а в функциональности: IFPUG считает входы, выходы, запросы, файлы и интерфейсы, COSMIC — перемещения данных через границы; полезны в госзаказе и при сравнении подрядчиков, но сам счёт стоит примерно столько же, сколько оценка по фичам.
• Групповые методы. Wideband Delphi — оценка в несколько раундов: эксперты высказываются анонимно, расхождения обсуждаются, раунд повторяется; дорого, но целенаправленно борется с эффектом якоря. Planning poker — его облегчённая версия (описание Джеймса Греннинга): ценность не в числе, а в разговоре — расхождение «2 и 13» почти всегда значит, что участники поняли задачу по-разному. T-shirt sizes — грубая градация S/M/L/XL для портфеля, когда надо расставить два десятка инициатив по порядку, а не назвать сроки.
• Оценка по пропускной способности не оценивает задачи вовсе: считает их количество и умножает на историческую скорость команды — работает, если задачи нарезаны примерно одного размера, и даёт распределение, а не число. Доведённая до конца позиция — #NoEstimates: при одинаковой нарезке оценка каждой задачи не добавляет информации сверх счёта задач, а стоит времени всей команды (разбор у Рона Джеффриса); работает на продуктовой разработке и не работает там, где цену надо назвать до начала работы, — то есть ровно в пресейле.

Левый верхний квадрант — единственный по-настоящему опасный. «Данных нет, но нужна смета под фикс-прайс» не решается никаким методом оценки: разброс ×4 нельзя убрать вычислением. Здоровых выходов ровно три — продать отдельный оплачиваемый этап аналитики и оценить после него; заложить резерв, соответствующий разбросу, и честно назвать его в переговорах; поменять форму договора на T&M с потолком.

4. Три точки: диапазон и PERT

Есть два общепринятых способа подсчёта трудозатрат по одной фиче. Диапазонный метод: оценщик на основании опыта даёт пессимистическое и оптимистическое значение — «от 16 до 28 часов»; просто, честно и сразу показывает неопределённость, широкая вилка сама по себе является сообщением. Метод PERT — расчёт по трём точкам:

$$t_e = \frac{t_o + 4 t_m + t_p}{6}, \qquad \sigma = \frac{t_p - t_o}{6}$$

Здесь $t_o$ — оптимистическое время, минимально возможная длительность выполнения задачи; $t_p$ — пессимистическое, максимально возможная; $t_m$ — наиболее вероятное; $t_e$ — ожидаемое время, оценка длительности на основе всех трёх. Коэффициент 4 при наиболее вероятном значении означает, что формула — среднее бета-распределения, в котором мода весит вчетверо больше краёв. Вторая формула, про которую забывают в девяти случаях из десяти, важнее первой: $\sigma$ — среднеквадратичное отклонение, мера того, насколько мы не уверены. Если считать диапазон от $t_o$ до $t_p$ примерно шестью сигмами нормального распределения, одна сигма — шестая часть разброса; ради этого числа и стоит собирать три точки вместо одной.

Почему сумма оценок не равна оценке суммы. Ожидаемые значения складываются честно: $T_e = \sum_i t_{e,i}$. А вот пессимистические значения складывать нельзя: сумма пессимизмов описывает событие «все фичи одновременно пошли по худшему сценарию», а это произведение вероятностей — число исчезающе малое. Складывать можно дисперсии (при условии независимости оценок):

$$\sigma_T = \sqrt{\sum_{i=1}^{n} \sigma_i^2}$$

Корень из суммы квадратов растёт медленнее суммы. Это математическое выражение житейского факта: на большом наборе задач часть переоценок гасит часть недооценок, и относительная точность суммы выше точности каждого слагаемого. Вывод для практики: не требуйте от оценщика точности по каждой фиче — требуйте честности диапазона, агрегирование сделает остальное. Численный пример: интернет-магазин, часы одного направления, укрупнённые блоки (по регламенту из раздела 5 каждый дробится на единицы по 8 часов).

• Ожидаемая трудоёмкость 216 часов, а не 194 (сумма наиболее вероятных): PERT сдвигает оценку вправо, потому что распределение длительностей асимметрично — задача может занять втрое больше ожидаемого, но не может втрое меньше. Суммарная сигма 21 час, а не 43,7 (сумма отдельных сигм); разница вдвое — выигрыш агрегирования. Интервал «плюс-минус сигма» (около 68%) — от 195 до 237 часов, оценка по 85-му перцентилю $216{,}3 + 1{,}04 \cdot 21{,}0 \approx 238$ часов, по 90-му — около 243.
• Сумма пессимистичных оценок, 392 часа, отстоит от ожидания на 8,3 сигмы: при независимых оценках вероятность такого исхода неотличима от нуля. Именно этим числом обычно пугают заказчика, и именно оно чаще всего попадает в договор как «максимальная стоимость» — это не осторожность, это арифметическая ошибка.
• Последняя строка кричит громче остальных: интеграция с 1С даёт 68% всей дисперсии проекта (300,4 из 442,8). Уточнение оценок каталога и корзины не изменит ничего; единственное осмысленное действие — потратить два дня на спайк, увидеть реальный формат выгрузки и переоценить. Так дисперсия превращается в план работ.

Аналитическая формула делает два допущения — нормальность суммы и независимость слагаемых. Симуляция позволяет проверить оба.

import random, statistics

# (название, оптимистичная, наиболее вероятная, пессимистичная) — часы
FEATURES = [("Регистрация", 12, 16, 28), ("Каталог с фильтрами", 24, 32, 56), ("Корзина", 16, 20, 32),
            ("Оплата картой", 20, 32, 72), ("Личный кабинет", 18, 24, 40), ("Админка (CRUD)", 24, 30, 44),
            ("Интеграция с 1С", 16, 40, 120)]

def pert(to, tm, tp):
    """Ожидаемое время и сигма по трём точкам. O(1) по времени и памяти."""
    return (to + 4 * tm + tp) / 6, (tp - to) / 6

def rollup(features):
    """Свод: ожидания складываем, а вместо сигм — ДИСПЕРСИИ. O(n) по времени и памяти."""
    pairs = [pert(a, m, b) for _, a, m, b in features]
    return sum(te for te, _ in pairs), sum(sd ** 2 for _, sd in pairs) ** 0.5

def sample(to, tm, tp, lamb=4.0):
    """Случайная длительность из beta-PERT — распределения, среднее которого и даёт формулу te. O(1)."""
    mu = (to + lamb * tm + tp) / (lamb + 2)
    if tp <= to or abs(mu - tm) < 1e-9:                        # вырожденный и симметричный случаи
        return random.triangular(to, tp, tm)
    alpha = ((mu - to) * (2 * tm - to - tp)) / ((tm - mu) * (tp - to))
    return to + random.betavariate(alpha, alpha * (tp - mu) / (mu - to)) * (tp - to)

def monte_carlo(features, runs=10_000, corr=0.0, seed=42):
    """k прогонов по n фичам. corr — сила ОБЩЕЙ причины (незнакомый стек, один оптимист-оценщик на всех,
    один и тот же смежник): множитель сразу на весь прогон. O(n·k) по времени, O(k) по памяти."""
    rnd = random.Random(seed); random.seed(seed); totals = []
    for _ in range(runs):
        shock = 1.0 if corr <= 0 else max(0.5, rnd.gauss(1.0, corr))     # общий сдвиг всего прогона
        totals.append(shock * sum(sample(a, m, b) for _, a, m, b in features))
    totals.sort()
    q = lambda p: totals[int(p * (runs - 1))]
    return {"P50": q(.50), "P80": q(.80), "P90": q(.90), "сигма": statistics.pstdev(totals)}

te, sigma = rollup(FEATURES)
print(f"PERT: {te:.1f} ч, сигма {sigma:.1f} ч, P85 ≈ {te + 1.04 * sigma:.0f} ч")
# PERT: 216.3 ч, сигма 21.0 ч, P85 ≈ 238 ч
print({k: round(v, 1) for k, v in monte_carlo(FEATURES).items()})
# {'P50': 215.2, 'P80': 236.1, 'P90': 246.9, 'сигма': 22.5}     <- симуляция подтверждает формулу
print({k: round(v, 1) for k, v in monte_carlo(FEATURES, corr=0.20).items()})
# {'P50': 214.1, 'P80': 256.6, 'P90': 279.9, 'сигма': 48.8}     <- 20% общей причины удваивают сигму

Без корреляции симуляция подтверждает аналитику — P50 около 215, сигма 22,5 против расчётных 21,0. Но 20% общей причины удваивают сигму, а P90 уезжает с 247 до 280 часов — на треть выше ожидания вместо четырнадцати процентов. Независимость оценок — самое хрупкое допущение PERT, и нарушается оно постоянно: все семь блоков оценивал один человек в одном настроении; вся команда одинаково не знает нового фреймворка; все фичи зависят от одного смежника. Корреляция — не экзотика, а норма, поэтому к аналитическому P85 стоит относиться как к оптимистичной границе. Глубокая вероятностная часть — симуляция по историческим циклам, перцентильные обязательства и прогноз по пропускной способности — разобрана в оценке и планировании трека Project Management; здесь достаточно трёх выводов: складывайте дисперсии, а не пессимизмы; называйте перцентиль, а не число; проверяйте чувствительность к общей причине.

5. Два этапа предварительной оценки: как это устроено в пресейле

Отправляя заявку в IT-компанию, заказчик обычно преследует одну из двух целей: оценить проект «под ключ» (у него может быть определён объём задач и разработано ТЗ — или только объём без ТЗ) либо узнать, что можно сделать в рамках определённого бюджета или в конкретные сроки. Это разные задачи: в первом случае считают цену за фиксированный объём, во втором — подбирают объём под фиксированную цену.

Этап 1: созвон, бриф и границы. Чтобы выяснить детали, специалист компании (обычно сотрудник отдела продаж) организует созвон с клиентом. Один из способов получить нужные данные — вместе с клиентом заполнить бриф, но обычно беседа проходит в свободной форме: так выявляются действительно важные для бизнеса аспекты, которые в анкету не помещаются. После разговора становится понятно, достаточно ли клиенту оценки «по аналогии» или нужна детальная оценка по фичам, и есть ли вообще вся необходимая информация. На этом этапе формируются ответы на ключевые вопросы:

• Границы разработки — какие этапы нужно оценить и в перспективе выполнить, а какие клиент берёт на себя? Самый ценный вопрос встречи: половина будущих споров о деньгах идёт про работы, которые каждая сторона считала чужими.
• Какие направления подключить к оценке — нужен ли дизайнер, есть ли мобильная часть, требуется ли DevOps. Какой стек предпочтителен — часто ограничен тем, что уже эксплуатирует клиент.
• Что ещё нужно заложить в оценку. Например, клиент решает, что дизайн будет разрабатывать сам, — значит, в оценку нужно включить время на приёмку дизайна заказчика: проверить, соответствует ли он функционалу системы. Классическая «забытая работа».

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

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

В чате оценки ведётся вся переписка: фиксируются договорённости и допущения, варианты реализации, собираются мнения по поводу выбора стека, преимуществ и недостатков конкретных способов реализации, возможности применения готовых фреймворков и коробочных решений, необходимости тех или иных работ. Например, если видно, что на проекте важен UX, добавляются работы по исследованию юзабилити и проверке гипотез на фокус-группах; если есть требования к производительности — принимается решение о нагрузочном тестировании. Обе строки почти никогда не приходят от клиента: он не знает, что они существуют, и узнаёт о них в момент, когда система ляжет под первой распродажей. Все сведения по оценке, её статус и результаты хранятся в таск-трекере, включая готовое КП. Смысл требования не в бюрократии — трекер и есть тот архив, без которого через год не заработает аналогия.

Внутренние регламенты. Зрелые компании держат жёсткие требования к оценкам; три из них стоит завести у себя.

1. Оценка разработки одной фичи не должна превышать 8 часов (в крайнем случае — 16). Правило выглядит произвольным, но за ним логика: оценка длиной в неделю означает, что оценщик не представляет себе реализацию в деталях — он оценивает не работу, а свою тревогу. Лекарство одно — декомпозиция (см. следующую главу).
2. Разброс между минимальным и максимальным значением не должен превышать 40%. Иначе уровень неопределённости в реализации фичи высок, что прямо повышает риски проекта. Нарушение — не повод «сузить вилку», а сигнал: нужен спайк, прототип или явное допущение; интеграция с 1С из раздела 4 с разбросом 87% по регламенту не имеет права попасть в смету в таком виде.
3. Оценщик обязан зафиксировать в комментарии, как он видит реализацию задачи за указанное время — это превращает число в проверяемое утверждение: комментарий «беру готовый SDK эквайринга, свой только вебхук и страница статуса» можно оспорить, а число «32» нельзя. Побочный эффект: при передаче в разработку комментарий становится техническим решением, а расхождение «реализовали не так» превращается в явный вопрос, а не в тихий перерасход.

После того как все оценщики завершили свою часть, проводится проверка оценки — как правило, вторым экспертом, не участвовавшим в счёте. Далее готовится описание и на основе сметы — примерный состав будущей команды, сроки реализации или roadmap. Порядок важен и часто нарушается: смета порождает команду, команда порождает сроки; обратный ход («у нас есть пять человек и три месяца, впишите объём») даёт не оценку, а подгонку.

6. Что систематически ломает оценку

Слово «систематически» здесь ключевое: случайные ошибки взаимно гасятся при агрегировании (раздел 4), а смещения складываются.

Ошибка планирования. Канеман и Тверски описали planning fallacy ещё в 1977 году: люди прогнозируют срок собственной задачи, представляя, как она пойдёт, — то есть строят один сценарий, обычно успешный, и игнорируют статистику похожих задач («Intuitive Prediction: Biases and Corrective Procedures»). Эксперименты Бюлера, Гриффина и Росса показали, что смещение сохраняется, даже когда людям напоминают об их собственном прошлом опыте срывов: они соглашаются, что раньше опаздывали, и всё равно обещают успеть (Buehler, Griffin, Ross, 1994). Это не лень и не безответственность, это устройство мышления: прогноз строится из деталей плана, а не из истории исходов.

Взгляд снаружи и reference-class forecasting. Противоядие называется outside view: вместо «как пойдёт наша задача» задаётся вопрос «как заканчивались задачи этого класса». Бент Флювбьерг довёл идею до применимой процедуры («From Nobel Prize to Project Management»): определить класс аналогов формально — не «похожие проекты», а «интеграции с внешней ERP, выполненные этой компанией за три года»; собрать распределение исходов по классу — медиану, 80-й перцентиль, худший случай; и начать оценку с базовой ставки класса, двигая её только на основании доказуемых отличий. Третий шаг контринтуитивен и потому не делается: обычно берут свою оценку и «немножко накидывают», а надо наоборот. Организации, ведущие архив пар «прогноз — факт», выигрывают не за счёт талантов, а за счёт наличия базовой ставки — поэтому регламент и требует класть факт в трекер.

Закон Паркинсона и синдром студента. Даже верная оценка не сохраняется в исполнении. Закон Паркинсона («работа заполняет всё время, отпущенное на неё», The Economist, 1955) означает, что оценка, данная с запасом, будет израсходована полностью; синдром студента — что к работе приступают в последний момент, съедая запас в начале, а не в конце. Вместе они дают эффект, убивающий буферы: ранние окончания не наследуются, а поздние наследуются всегда. Задача, законченная на два дня раньше, не двигает график — следующий исполнитель не готов начать; опоздавшая на два дня двигает всё.

Забытые работы. Самая массовая причина промаха — не ошибка в числе, а отсутствие строки в смете: забытая работа оценена в ноль. Чек-лист ниже стоит прогонять на каждой оценке; в среднем он добавляет от 25 до 60% к «наивной» смете, посчитанной по одним фичам.

1. Миграция данных из старой системы: разбор форматов, чистка, повторные прогоны, сверка итогов.
2. Интеграции: получение доступов, песочница, лимиты API, обработка ошибок смежника, его SLA.
3. Окружения и инфраструктура: dev/stage/prod, конвейер сборки, секреты, домены, сертификаты.
4. Аутентификация, авторизация и ролевая модель — почти всегда недооценена вдвое.
5. Нефункциональные требования: производительность, нагрузочное тестирование, отказоустойчивость.
6. Безопасность: моделирование угроз, пентест, устранение находок, ревью прав доступа.
7. Наблюдаемость: логи, метрики, алерты, дашборды, трассировка запросов.
8. Обработка ошибок и краевых случаев: пустые состояния, таймауты, повторы, идемпотентность.
9. Приёмка заказчиком: демо, сбор замечаний, доработка, повторная приёмка — обычно два-три круга.
10. Приёмка чужих артефактов: дизайн, макеты, тексты, ТЗ от заказчика — проверка на полноту и соответствие функционалу.
11. Документация и обучение: пользовательская документация, API, runbook, схема данных, материалы для поддержки.
12. Локализация и совместимость: языки, часовые пояса, форматы дат и валют, налоги, браузеры, версии мобильных ОС, доступность.
13. Управление и координация: планирование, статусы, ревью кода, переключение контекста — 10–20% инженерных часов.
14. Резервное копирование, восстановление и план отката, юридические артефакты вроде политики обработки персональных данных.
15. Календарные потери: отпуска, болезни, праздники, онбординг новых людей, дежурства.

Чек-лист становится обязательной секцией шаблона оценки: напротив каждого пункта оценщик ставит либо часы, либо явное «не применимо, потому что…». Пустая клетка и есть забытая работа.

7. Оценка, деньги и буфер

Часы превращаются в цену не умножением на «ставку разработчика». Цепочка длиннее: полная стоимость специалиста (выплаты на руки, налоги и взносы, оборудование, лицензии) → накладные расходы (офис, HR, бухгалтерия, менеджмент, обучение, простои — множитель обычно от 1,4 до 1,8) → утилизация (сколько календарных часов реально оплачивается клиентом; 70% — хороший показатель, а отпуска, больничные, внутренние встречи и непроданные пресейлы оплачиваются из этих же денег) → маржа. Пример счёта: разработчик обходится компании в 330 000 руб. в месяц с налогами, накладные ×1,6 дают 528 000 руб. полной стоимости; при утилизации 70% оплачиваемых часов в месяце около 120, себестоимость часа — 4 400 руб.; при марже 35% ставка выходит около 6 800 руб. в час. Наши 216 часов превращаются примерно в 1 470 000 руб. по ожидаемой оценке и в 1 650 000 руб. по 90-му перцентилю. Разница между этими числами и есть резерв, и его природу важно различать (терминология PMBOK): contingency reserve покрывает «известные неизвестные» — перечисленные риски, — находится внутри базового плана и расходуется менеджером без эскалации; management reserve покрывает «неизвестные неизвестные», лежит вне базового плана, не показывается команде как доступное время и требует решения спонсора. Слияние их в один «запас» приводит к тому, что резерв уходит на первом же сюрпризе; contingency удобно считать от разброса оценок — разница между P50 и P85 хорошая отправная точка.

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

Буфер и как его защищать. Стандартный способ учесть неопределённость — «накинуть 20% на каждую задачу» — не работает по названной выше причине: буфер, размазанный по задачам, съедается на месте. Оценка в 8 часов с запасом до 10 превращается в 10 часов работы (Паркинсон), а если исполнитель начал в последний момент — то и в 12. Локальный запас потребляется локально и не доживает до момента, когда действительно нужен. Элияху Голдратт предложил обратное: срезать локальные буферы и собрать их в один общий в конце цепочки — ядро метода критической цепи (обзор). Логика прямо следует из арифметики выше: общий буфер можно сделать меньше суммы локальных ровно потому, что дисперсии складываются как корень из суммы квадратов — десять задач по 8 часов с личным запасом 2 часа дают 20 часов буфера, а общий буфер того же уровня защиты около 6–7 часов. Три условия, без которых это не работает: оценки для планирования берутся агрессивными (P50), иначе вы просто удвоили запас; люди не наказываются за превышение отдельной задачи, иначе скрытый запас мгновенно вернётся в оценки; расход буфера видим — процент потраченного буфера против процента сделанной работы даёт ранний сигнал задолго до срыва даты. Механика сетевого графика и критической цепи разобрана отдельно: расписание, зависимости и ресурсы.

8. Типичные ошибки

9. Как это выглядит в проде

Регламент оценки в компании среднего размера умещается на одну страницу. Кто: модератор (пресейл-менеджер или руководитель направления) отвечает за процесс и срок; по каждому направлению — один оценщик и один проверяющий, не участвовавший в счёте. За какое время: аналогия — 3 часа; оценка по фичам — 8 рабочих часов суммарной работы экспертов при календарном сроке 3–5 дней. Какие артефакты: список фич с тремя точками и комментарием о реализации по каждой; допущения с владельцами; чек-лист забытых работ с проставленными часами или «не применимо»; свод по направлениям; смета; состав команды; roadmap; КП — всё в одной задаче трекера. Какие пороги: фича больше 16 часов или разброс больше 40% — оценка не принимается, фича идёт на декомпозицию или в спайк; суммарная сигма больше 15% от ожидания — в КП указывается диапазон, а не число. Что после: через месяц после закрытия проекта в ту же задачу кладётся факт, а раз в квартал считается медианное отношение «факт / оценка» по классам — это и есть база для аналогии.

Где регламент сработал. Оценка интеграционного проекта дала по одному блоку разброс 16–120 часов; по правилу 40% блок не прошёл, и вместо спора продали двухдневный спайк, в котором выяснилось, что смежная система отдаёт остатки раз в сутки файлом, а не по API. Трудоёмкость выросла на 60 часов, но выяснилось это до подписания, а не на четвёртом месяце. Где не сработал. Тот же тип проекта, но фикс-прайс подписали по сумме наиболее вероятных оценок (194 часа) — без резерва и диапазона. Фактические 260 часов съели маржу целиком; менеджер полгода объяснял, что «команда работала плохо». Команда работала нормально — в договор попал 25-й перцентиль.

Мини-итог

• Оценка — вход в решение, а не обещание. Различайте estimate, target и commitment; перед оценкой спрашивайте, какое решение она обслуживает и какой точности для него достаточно.
• Точность ограничена стадией, а не старанием. Конус даёт ×4 на идее и ×1,25 к готовому дизайну интерфейса — и сужается только тогда, когда неопределённость реально снимают решениями, а не когда просто проходит время.
• Два рабочих метода пресейла — аналогия (1–3 часа, нужен архив) и оценка по фичам (8 часов работы, 3–5 дней календаря, оценка каждым направлением, сведение в единый список). Остальные — от COCOMO и функциональных точек до planning poker и оценки по пропускной способности — выбираются по входным данным и нужному решению.
• Считайте по трём точкам и складывайте дисперсии, а не пессимизмы. Один блок с огромным разбросом может давать две трети дисперсии проекта — его и надо снимать спайком, а не уточнять оценки остальных.
• Смещения не гасятся агрегированием. Ошибка планирования, отсутствие взгляда снаружи, Паркинсон, синдром студента и забытые работы бьют в одну сторону; чек-лист забытых статей — самая дешёвая из известных контрмер.
• Регламент важнее методики: фича не больше 8–16 часов, разброс не больше 40%, обязательный комментарий о реализации, проверка вторым экспертом, факт возвращается в архив. Часы становятся деньгами через накладные, утилизацию и маржу, а неопределённость — через резервы; contingency нельзя путать с management reserve, а буфер надо держать общим, а не размазанным по задачам.

Источники

• McConnell S., «Software Estimation: Demystifying the Black Art», Microsoft Press, 2006 — конус неопределённости, различение estimate/target/commitment, обзор методов.
• Boehm B., COCOMO II, USC CSSE — параметрическая модель оценки; IFPUG и COSMIC — функциональный размер как альтернатива строкам кода.
• Grenning J., «Planning Poker», 2002; Wideband Delphi — групповые методы оценки.
• Kahneman D., Tversky A., «Intuitive Prediction: Biases and Corrective Procedures», 1977 — ошибка планирования и взгляд снаружи.
• Buehler R., Griffin D., Ross M., «Exploring the Planning Fallacy», JPSP 1994 — смещение сохраняется даже при напоминании о прошлом опыте.
• Flyvbjerg B., «From Nobel Prize to Project Management: Getting Risks Right», PMJ 2006 — reference-class forecasting.
• «Parkinson’s Law», The Economist, 1955; Goldratt E., Critical Chain Project Management — почему локальные буферы исчезают.
• PMBOK Guide — терминология резервов: contingency reserve против management reserve.
• Jeffries R., «The NoEstimates Movement»; Vacanti D., «Actionable Agile Metrics for Predictability» — прогноз по потоку вместо оценок.
• Как справиться с декомпозицией задач и не перестараться — практика нарезки, из которой выросла следующая глава.

Что дальше

Всё описанное выше упирается в один вход — список того, что оцениваем. Пока фича формулируется как «личный кабинет», ни PERT, ни конус, ни правило сорока процентов не спасут: оценка будет мерить не работу, а неуверенность оценщика. Правило «не больше 8–16 часов на фичу» — это, по сути, требование декомпозиции, спрятанное в регламент оценки.

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

Читайте: Декомпозиция задач: вертикально или горизонтально, восемь приёмов и границы дробления