Оценка и границы работ: как не утонуть в бесконечных правках

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

Внутри этой катастрофы всегда две разные ошибки, которые в разговоре сливаются в одно слово «оценка»:

1. Ошибка измерения — вы неверно посчитали, сколько времени займёт понятная работа.
2. Ошибка границы — вы вообще не определили, какая работа считается «той самой».

Первая лечится арифметикой: три точки, распределение, буфер, журнал прошлых проектов. Вторая арифметикой не лечится — она лечится текстом: списком «что входит», списком «что не входит», критериями приёмки и процедурой изменений. И вторая опаснее: ошибка измерения даёт перерасход в полтора-два раза, ошибка границы не имеет верхней оценки в принципе, потому что «улучшать» можно бесконечно. Статья — про обе. Она продолжает разговор из Ценообразования: любая честно посчитанная ставка обнуляется, если фактических часов вдвое больше плановых. И подводит к Договорам: описанная граница — это то, что вы потом переносите в приложение к договору.

Рамка. Здесь нет юридических, налоговых и бухгалтерских консультаций. Всё, что ниже про «зафиксируйте письменно», «пропишите приёмку», «включите процедуру изменений» — инженерная и переговорная практика, а не готовые формулировки договора. Юридическую силу любых слов, порядок подписания актов, последствия просрочки, применимое право и форму вашей деятельности проверяйте у юриста и бухгалтера, а нормы — на официальных источниках: ФНС России, Госуслуги, портал правовой информации. Правила и суммы меняются: всё прочитанное год назад требует перепроверки на дату вашей сделки.

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

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

Стив Макконнелл в Software Estimation: Demystifying the Black Art делает различение, которое стоит выучить наизусть:

• Оценка (estimate) — беспристрастный прогноз: «по имеющимся данным работа займёт столько-то, с такой-то неопределённостью». У оценки нет желаний, она не бывает «слишком большой».
• Цель (target) — бизнес-желание: «нужно к выставке 20-го». Цель приходит от клиента и не обязана быть достижимой.
• Обязательство (commitment) — обещание сделать к сроку: решение, принятое с учётом оценки, цели и вашей готовности рисковать.

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

Модель оплаты определяет, кто несёт риск ошибки оценки:

Отсюда правило: чем меньше вы знаете о задаче, тем меньше должно быть фиксированного в договоре. Фикс на «сделать CRM для нашего бизнеса» — не смелость, а лотерея, где билет купили вы.

2. Почему оценки систематически занижены

2.1. Оценка — распределение, а не число

Когда вы говорите «два дня», в голове живёт сценарий, где ничего не мешает. Это не медиана и не среднее, а ближе к лучшему исходу — левому хвосту распределения. Реальность скошена вправо: работа не может занять минус три часа, но легко занимает втрое больше. Асимметрия — не пессимизм, а свойство задачи. Отсюда первое правило: никогда не называйте одно число. Одно число утверждает, что дисперсия равна нулю.

2.2. Конус неопределённости

Момент, в который вас просят оценить, важнее методики оценки.

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

2.3. Невидимая работа

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

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

2.4. Ошибка планирования и опора на факты

Канеман и Тверски описали planning fallacy: люди систематически недооценивают срок собственных задач, даже зная, что похожие задачи в прошлом занимали больше. Знание о смещении его не убирает — мы строим прогноз «изнутри», из деталей плана, а не «снаружи», из статистики похожих случаев. Лекарство — прогноз по референтному классу (Bent Flyvbjerg, «From Nobel Prize to Project Management: Getting Risks Right»): не «сколько займёт эта задача», а «сколько занимали похожие задачи у меня». Для этого нужен ровно один артефакт — журнал оценок (раздел 3.5).

3. Арифметика: как превратить незнание в число, которое не стыдно назвать

3.1. Декомпозиция

Единственная техника, улучшающая оценку сразу и заметно, — разбиение до размера, который вы уже делали руками. Правило: не оценивайте то, что не разбито на куски по 0.5–2 дня. Причины: куски меньше дня вы оцениваете реалистичнее, потому что помните конкретные шаги; ошибки на мелких кусках частично гасят друг друга, а ошибка одного большого куска не компенсируется ничем.

Главная же ценность в другом: если задачу не получается разбить, вы её не понимаете. Это не повод угадывать, а сигнал, что нужен либо discovery, либо технический шип (spike) — ограниченный по времени эксперимент с единственной целью снять неопределённость; шип оценивается не результатом, а бюджетом: «два дня на проверку, дальше принимаем решение». Такой пункт либо выносится из объёма, либо превращается в оплаченный шип, но не в число силой воли. Отдельно стоит работа, которая по природе не должна попадать к вам: требования, вытекающие из законодательства (фискализация, персональные данные, отраслевые нормы). Вы можете реализовать письменно сформулированное требование, но определять, «как правильно по закону», — не ваша роль и не ваша ответственность; это задача юриста и бухгалтера клиента.

3.2. Трёхточечная оценка

Для каждого куска называете три числа: $O$ — оптимистичное (всё сложилось), $M$ — наиболее вероятное (обычный ход дела), $P$ — пессимистичное (всплыло то, что уже всплывало в похожих проектах; не «конец света», а «плохой, но реальный день»). Классическая PERT-свёртка и сумма независимых задач:

$$E = \frac{O + 4M + P}{6} \qquad \sigma = \frac{P - O}{6} \qquad E_{\Sigma} = \sum_i E_i \qquad \sigma_{\Sigma} = \sqrt{\sum_i \sigma_i^{2}}$$

Условный список задач (часы, числа взяты для демонстрации арифметики):

Первое, что видно: наивная сумма «самых вероятных» — 72 часа, а PERT-ожидание почти 83. Разрыв в 15 % возник без единого риска, просто из-за асимметрии.

3.3. Буфер проекта меньше суммы буферов задач

Сумма отдельных $\sigma$ равна 21.9, а $\sigma_{\Sigma}$ — всего 10.4: складываются дисперсии, а не стандартные отклонения. Практический смысл огромен. Если вы кладёте буфер в каждую задачу («возьму с запасом»), вы раздуваете срок примерно вдвое сильнее нужного — и всё равно съедаете запас, потому что работа расширяется до отведённого времени. Правильно — убрать буферы из задач и собрать один общий резерв проекта, которым вы управляете явно (ядро идеи Голдратта из Critical Chain: защищать нужно срок проекта, а не срок каждого шага). Для клиента это честнее: резерв виден отдельной строкой, а не размазан скрытым враньём по всем оценкам.

3.4. Монте-Карло: считаем распределение целиком

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

для каждого из N розыгрышей:
    итог := 0
    для каждой задачи:  итог += случайная величина из распределения (O, M, P)
    для каждого риска:  если random() < вероятность: итог += стоимость_риска
    сохранить итог
отсортировать итоги;  P50 := итог на позиции 0.50 * N;  P80 := на позиции 0.80 * N

"""Монте-Карло для срока проекта: превращаем план в распределение, а не в одно число."""
import random

# (название, оптимистично, вероятно, пессимистично) — часы
TASKS = [
    ("импорт справочников", 6, 10, 22),
    ("экран заявки", 8, 14, 26),
    ("интеграция с платёжным шлюзом", 10, 20, 60),
    ("права доступа и роли", 5, 9, 18),
    ("выгрузка отчёта", 4, 7, 14),
    ("развёртывание и приёмка", 6, 12, 30),
]
# (название, вероятность 0..1, стоимость в часах, если сработает)
RISKS = [
    ("песочница шлюза недоступна неделю", 0.30, 16),
    ("формат выгрузки у клиента другой", 0.40, 10),
    ("второй круг правок по дизайну", 0.50, 12),
]


def simulate(tasks, risks, runs=20_000, seed=42):
    """Отсортированный список итоговых длительностей по всем розыгрышам."""
    rnd = random.Random(seed)          # фиксированное зерно — воспроизводимый результат
    totals = []
    for _ in range(runs):
        total = 0.0
        for _, opt, likely, pess in tasks:
            total += rnd.triangular(opt, pess, likely)   # (минимум, максимум, мода)
        for _, prob, cost in risks:
            if rnd.random() < prob:
                total += cost          # риск срабатывает целиком, а не «немножко»
        totals.append(total)
    totals.sort()
    return totals


def percentile(sorted_totals, q):
    """q в долях: 0.5 — медиана, 0.8 — «в 80 % розыгрышей уложились»."""
    return sorted_totals[min(int(q * len(sorted_totals)), len(sorted_totals) - 1)]


totals = simulate(TASKS, RISKS)
print("наивная сумма «самых вероятных»:", sum(t[2] for t in TASKS), "ч")
for q in (0.10, 0.50, 0.80, 0.95):
    print(f"P{int(q * 100)}: {percentile(totals, q):.0f} ч")

Вывод:

наивная сумма «самых вероятных»: 72 ч
P10: 87 ч
P50: 108 ч
P80: 123 ч
P95: 138 ч

Три вывода, ради которых всё затевалось:

1. Наивная сумма 72 часа не достигается почти никогда — даже P10 равен 87. Число, которое вы назвали бы «по ощущениям», лежит за пределами оптимистичного децила.
2. Разрыв между «сколько это займёт» и «на что можно обещать» — почти 1.7 раза (72 против 123 на P80). Именно он и съедает доход на фиксе.
3. PERT дал 83 часа, Монте-Карло — медиану 108. Разница не ошибка: PERT сильнее взвешивает моду, треугольное распределение — хвост, плюс здесь добавлены явные риски. Урок не в том, какая модель «правильная», а в том, что выбор модели двигает число на десятки процентов — значит, одно число вообще не является ответом.

Сложность: $O(N \cdot (n + m))$ по времени и $O(N)$ по памяти, где $N$ — розыгрышей, $n$ — задач, $m$ — рисков. Двадцать тысяч розыгрышей считаются за доли секунды: вычислительная цена честной оценки нулевая, психологическая — высокая. Обязательство давайте по P80–P90, а не по медиане, и проговаривайте это словами: «медиана примерно столько, обязуюсь на столько, разница — резерв на риски, перечисленные в приложении». Есть и альтернативный подход (Daniel Vacanti, Actionable Agile Metrics for Predictability; движение #NoEstimates): не оценивать задачи вообще, а измерять, сколько задач вы фактически закрываете в неделю и сколько дней живёт задача от старта до приёмки, а прогноз строить Монте-Карло по этой истории. Для фрилансера работает отлично при условии, что задачи нарезаны примерно однородно; слабое место — первые проекты, где истории ещё нет.

3.5. Журнал оценок — ваш личный референтный класс

Самый дешёвый и самый недооценённый артефакт. Одна таблица, пополняется в конце каждой задачи:

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

4. Как называть оценку заказчику

Вопрос «ну примерно-то сколько?» задаётся в самый неудобный момент — обычно в первом созвоне, до всякого разбора. Отвечать «не знаю» нельзя, отвечать числом — дорого. У правильного ответа есть структура.

Правила, которые отсюда следуют:

1. Диапазон, а не число. Вслух объясните, что ширина диапазона — это информация: «3–8 недель» честно сообщает, что задача непонятна.
2. Условия. Оценка всегда «при условии, что»: доступы в первый день, ответы в течение суток, один человек принимает решения, макеты готовы. Не выполнено условие — оценка недействительна. Это не угроза, а определение.
3. Срок годности. «Оценка действительна до такого-то числа»: через три месяца изменится всё — ваша загрузка, их требования, версии библиотек.
4. Письменно. Устная оценка живёт в чужой памяти в самом выгодном для собеседника виде. Письмо после разговора — самая дешёвая страховка в профессии.
5. Нельзя фиксировать три вещи сразу. Срок, цена, объём — выбирайте два. Если клиент требует все три, он просит вас принять весь риск проекта: допустимо, но должно быть оплачено.

5. Граница работ

Даже идеально посчитанная оценка ничего не стоит, если непонятно, что именно оценено.

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

5.1. Три обязательных списка

Что входит. Перечень результатов, а не технологий: «пользователь восстанавливает пароль по e-mail», а не «сделать восстановление пароля».

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

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

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

5.2. Scope creep — процесс, а не событие

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

Ключевой узел — «Уступка». Она безобидна ровно один раз. Проблема не в потерянных пяти минутах, а в том, что вы обучили клиента: правильный способ получить работу — попросить между делом. Дальше частота и размер просьб растут, пока вы не сорвётесь. И сорвётесь на чём-то мелком, а выглядеть это будет немотивированной агрессией — ведь для клиента ничего не менялось, он всё время действовал по правилу, которое вы сами и ввели. Отсюда неочевидный вывод: проводить мелочи через шлюз — забота о клиенте, а не жадность. Предсказуемый исполнитель, говорящий «да, это плюс три часа, подтверждаете?», удобнее доброго исполнителя, который однажды взорвётся.

5.3. Правки: где заканчивается работа и начинается бесконечность

Слово «правки» скрывает три разные вещи:

1. Дефект — результат не соответствует согласованному критерию приёмки. Ваша ответственность, бесплатно, всегда.
2. Уточнение — критерий был неоднозначен, стороны понимали по-разному. Обычно делится пополам; поэтому критерии и пишут проверяемо.
3. Изменение — критерий соблюдён, но клиент хочет иначе. Новая работа: оценивается и оплачивается.

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

6. Шлюз изменений

Шлюз — не бюрократия, а протокол. Его смысл: ни один запрос не отклоняется и ни один не проходит бесплатно.

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

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

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

# scope.yml — живёт в репозитории проекта, меняется только через PR
project: "Личный кабинет клиента"
version: 3                    # растёт при каждом согласованном изменении
valid_until: 2026-04-30       # после этой даты оценка требует пересмотра

in_scope:
  - id: PAY-1
    result: "Оплата картой через выбранный шлюз"
    acceptance: "Тестовый платёж проходит, вебхук обрабатывается повторно без дублей"

out_of_scope:                 # самый важный раздел файла
  - "Возвраты и частичные возвраты"
  - "Фискализация и чеки"
  - "Миграция данных из старой системы"
  - "Обучение сотрудников и пользовательская документация"

assumptions:                  # оценка действительна, пока это правда
  - "Доступы к тестовому контуру предоставлены в первый рабочий день"
  - "Ответы на вопросы приходят в течение одного рабочего дня"
  - "Решения принимает один человек со стороны заказчика"

revisions:
  rounds_included: 2          # раундов замечаний на каждый результат
  batching: "Замечания принимаются пачкой одним списком"

acceptance:
  window_days: 5              # срок на проверку результата заказчиком
  environment: "staging, демо-данные заказчика"

Такой файл решает и человеческую задачу: когда через полтора месяца звучит «мы же договаривались», ответом становится не спор о памяти, а git log и ссылка на строку.

7. Модели сделки, которые сами ограничивают объём

Границу держат не только текстом, но и устройством сделки. Выбор зависит от двух вещей: насколько понятна работа и насколько вы доверяете конкретному клиенту.

• Платное исследование — единственный разумный вход в туман: маленькая сумма, маленький риск для обеих сторон, на выходе артефакт.
• Почасовая с лимитом (capped T&M) — часы, но с потолком: «не превышу N часов без вашего письменного согласия». Снимает главный страх клиента перед почасовой и не перекладывает весь риск на вас.
• Фиксированный бюджет, гибкий объём — бюджет и срок закреплены, содержимое приоритизируется и режется. Психологически самая честная модель для сложных проектов: договариваются не о списке функций, а о порядке, в котором они делаются.
• Итерации с правом остановки — работа режется на короткие оплачиваемые отрезки, после каждого клиент может прекратить сотрудничество. Родственная идея из мира Scrum — «change for free / money for nothing»: изменения бесплатны, если равный объём убирается, а досрочная остановка возвращает часть бюджета. Для фрилансера это сильный аргумент: вы продаёте не обещание, а низкий риск.
• Фикс по спецификации — только когда конус уже узкий: работа знакомая, требования письменные, критерии приёмки согласованы.
• Механика денег (предоплата, этапы, что делать при неоплате) — в Договорах и Работе с заказчиком; влияние моделей на ставку — в Ценообразовании.

8. Практики доставки, которые держат границу лучше слов

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

9. Цена ошибки в деньгах

Переработка не абстрактна — она прямо конвертируется в падение ставки. Пусть (числа условные): договорились на фикс, оценка 80 часов, планируемая ставка 100 у.е./час, цена 8000 у.е. Фактически потрачено 128 часов: 12 на недооценённую интеграцию и 36 — на правки, которых нет в описании объёма.

$$R_{\text{эфф}} = \frac{V}{H_{\text{факт}}} = \frac{8000}{128} = 62.5 \text{ у.е./час}$$

Ставка упала на 37.5 % — при том, что клиент доволен, отзыв отличный, конфликта не было. Это и есть механизм, которым «успешные» проекты приводят в финансовую яму. Считайте эффективную ставку по каждому завершённому проекту, а не среднюю по году: среднее скрывает ровно те сделки, которые нужно перестать заключать (полная методика — в Юнит-экономике). И честно про остальные риски, спрятанные за словом «правки»:

• Кассовый разрыв. Проект, растянувшийся вдвое, вдвое сдвигает оплату. Деньги на жизнь нужны каждый месяц, а поступают по факту приёмки — см. Деньги и риски.
• Упущенные заказы. Пока вы бесплатно доделываете, вы не можете взять новый проект. Это не ноль, это полная стоимость альтернативы.
• Выгорание. Бесконечные правки бьют не по кошельку, а по мотивации: работа перестаёт иметь конец. Отсутствие видимого финала — надёжный путь возненавидеть профессию.
• Юридические ловушки. Формулировки вроде «работы считаются выполненными после подтверждения заказчиком» без критериев и сроков превращают приёмку в бессрочное право требовать доработок. Ровно тот случай, когда час юриста дешевле месяца работы.

10. Антипаттерны

• Оценка на глаз в созвоне. Число, названное вслух без записи и условий, живёт дальше как обязательство. Любая оценка → письмо.
• Оценка под давлением. «А если постараться?» — не запрос информации, а торг. Постаравшись, вы меняете не длительность работы, а вероятность уложиться; так и отвечайте.
• Оценка чужого legacy без доступа к коду. До того как вы посмотрели репозиторий, любая цифра — фантазия.
• Одна оценка на весь проект без ревизии. Прогноз обновляется: пересматривайте на каждой итерации и сообщайте сразу, а не за день до срока.
• Клиент-посредник. Требования передаёт человек, который сам их не понимает; каждое уточнение идёт кругом и возвращается искажённым. Требуйте контакта с тем, кто принимает решения, — или закладывайте это в риски явно.
• Правки поштучно в мессенджере. Каждое сообщение стоит переключения контекста; собирайте пачками в фиксированные окна.
• Молчаливое геройство и подгонка под желаемый срок. Доделать за свой счёт и не сказать — деньги потеряны, благодарность не куплена. Назвать срок, который клиент хочет услышать, — не оценка, а обещание, которое вы уже знаете, что нарушите.

11. Чеклист перед стартом

Вопросы себе, а не клиенту, — до того как назвать цену:

1. Разбивается ли работа на куски по 0.5–2 дня? Если нет — какой кусок непонятен и сколько стоит шип?
2. Названы ли поимённо все внешние системы, от которых я завишу? Есть ли к ним доступ?
3. Что записано в раздел «не входит»? Список короче пяти пунктов — значит, я его не думал.
4. Есть ли у каждого результата проверяемый критерий приёмки? Сколько раундов правок включено и что после них?
5. Какие допущения делают оценку действительной и что будет, если они не выполнятся?
6. По какому перцентилю я даю обязательство и виден ли резерв отдельной строкой?
7. Кто принимает решения со стороны заказчика и кто ещё может прислать замечания?
8. Как оформляется запрос на изменение и где ведётся журнал?
9. Что я делаю, если объём вырос вдвое: есть ли право остановиться и что с оплатой уже сделанного? (Формулировки — с юристом, см. Договоры.)

Мини-итог

• Оценка, цель и обязательство — три разных объекта; называйте тип вслух. Одно число — плохой ответ по определению: диапазон, условия, срок годности, письменная фиксация.
• Наивная сумма «самых вероятных» не достигается почти никогда: 72 часа против 123 на P80. Обязательство — по P80–P90, а буферы собирают в один резерв проекта (дисперсии складываются, стандартные отклонения — нет).
• Журнал оценок с фактом и коэффициентом ценнее любой методики: он даёт вашу поправку по типам работ.
• Объём теряют в серой зоне. Список «что НЕ входит» и проверяемые критерии приёмки — главные инструменты границы.
• Каждый запрос — через шлюз: оценка влияния, цена, срок, письменное подтверждение. Ответ по умолчанию «да, и это стоит столько-то».
• Модель сделки — тоже инструмент границы: платное исследование, потолок часов, фиксированный бюджет с гибким объёмом, итерации с правом остановки.
• Переработка — это падение эффективной ставки: 8000 у.е. за 128 часов вместо 80 означают минус 37.5 % к доходу за час.
• Всё про юридическую силу формулировок, приёмку, ответственность и налоги — к юристу и бухгалтеру, а нормы — на официальных источниках и на дату сделки.

Источники

• Steve McConnell. Software Estimation: Demystifying the Black Art — stevemcconnell.com; о конусе неопределённости — блог Construx
• Bent Flyvbjerg. From Nobel Prize to Project Management: Getting Risks Right — прогноз по референтному классу против ошибки планирования
• Daniel Vacanti. Actionable Agile Metrics for Predictability — actionableagile.com — прогноз по историческому потоку вместо оценки задач
• Eliyahu Goldratt. Critical Chain — общий буфер проекта вместо буфера в каждой задаче
• Jonathan Stark. Hourly Billing Is Nuts; Blair Enns. The Win Without Pitching Manifesto — как устройство сделки влияет на объём работ
• Mike Monteiro. F*ck You, Pay Me — доклад про границы, приёмку и деньги
• ISO/IEC/IEEE 29148 — что считается качественно сформулированным требованием: проверяемость, однозначность, полнота
• Смежные статьи портала: Оценка и планирование в проектах, Требования и UX, Тест-дизайн
• Официальные источники по формам деятельности, налогам и отчётности: ФНС России · Госуслуги · портал правовой информации. Проверяйте на дату вашего решения и подтверждайте у бухгалтера и юриста.

Что дальше

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

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