Планирование и оценки: почему сроки врут и что с этим делать

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

Именно на этом переводе всё и ломается. Не на том, что инженеры плохо оценивают (они оценивают примерно так же плохо, как все остальные люди на планете), а на том, что по дороге от команды к стейкхолдеру из числа вымывается вся информация о неопределённости, и наружу выходит голая дата, выглядящая как факт.

Эта глава — про механику: что происходит с числом на этом пути, как считать доступное время команды без самообмана, как прогнозировать без оценки каждой задачи, где ставить буфер и как устроено раннее предупреждение. Сами техники оценки — планинг-покер, PERT, три точки, дискуссия вокруг #NoEstimates — разобраны в главе про оценку и планирование, velocity и burndown — в главе про эмпиризм и метрики. Здесь я на них ссылаюсь и не пересказываю: ваша задача другая — не «посчитать точнее», а решить, что вы говорите наружу, что берёте на себя и как ведёте себя, когда план расходится с реальностью.

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

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

Что можно считать установленным:

• Систематический оптимизм. Обзор Магне Йоргенсена (A review of studies on expert estimation of software development effort, JSS, 2004) по десяткам исследований: экспертная оценка доминирует на практике, средний перерасход держится около 30% и не улучшился за десятилетия, а формальные модели систематически не обыгрывают экспертов.
• Оценки поддаются якорению нерелевантной информацией. Йоргенсен и Гримстад (IEEE TSE, 2011): достаточно упомянуть рядом с задачей произвольное число или сказать «клиент думает, это несложно» — оценки сдвигаются, причём люди уверены, что на них это не повлияло. Прямое следствие: фраза руководителя «нам бы к концу месяца», сказанная до оценки, делает саму оценку бессмысленной.
• Ошибка планирования (planning fallacy, Канеман и Тверски, 1979; Бюлер, Гриффин и Росс, 1994): люди недооценивают собственные задачи, даже когда точно помнят, что прошлые аналогичные заняли больше. Знание об эффекте от эффекта не спасает.
• Прогноз по референтному классу (reference class forecasting) — единственный метод с внятной доказательной базой за пределами IT (Флайвбьерг). Суть: не считать задачу с нуля, а смотреть на распределение фактических сроков похожих задач, которые вы уже делали. Ниже это же под именем прогноза по потоку.
• Конус неопределённости сужается хуже, чем его рисуют. Картинка Боэма и Макконнелла (разброс ×4 в начале, сходящийся к точке) — модель, а не измерение. Тодд Литтл (IEEE Software, 2006) на данных сотен реальных проектов Landmark Graphics показал, что отношение «факт к оценке» остаётся смещённым и разбросанным даже во второй половине проекта: конус в жизни куда толще у своего узкого конца.
• Цифры Standish CHAOS про провалы проектов ненадёжны. Йоргенсен и Молёккен-Эствольд (IST, 2006) разобрали методологию и показали, что перерасход в 189% не воспроизводится и, скорее всего, завышен в разы. Если вам цитируют CHAOS — это слабый аргумент.

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

Три разных числа, которые называют одним словом «срок»

Разделение принадлежит Стиву Макконнеллу (Software Estimation: Demystifying the Black Art, 2006) и стоит того, чтобы держать его в голове дословно:

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

Как это выглядит на практике — вот путь одного числа:

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

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

Кто на самом деле решает дату

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

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

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

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

Почему сроки врут: пять механизмов

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

2. Инженеро-дни не равны календарным дням. Пять человек на две недели — не 50 дней работы. Это 50 минус отпуска, дежурства, собеседования, онбординг новичка, встречи, поддержка прода, переключения контекста. Реалистичный коэффициент в командах со средней нагрузкой — 0,5–0,7, и это не лень, а состав работы. Считаем ниже явно.

3. Ожидание, а не работа. Задача на 10 дней работы проходит через очередь ревью, приёмку продакта, релизное окно, ответ соседней команды. Время выполнения (cycle time) состоит из времени работы и времени ожидания, и на большинстве досок ожидание больше работы. Отсюда контринтуитивное следствие из теории очередей (закон Литтла, подробно у Райнертсена в The Principles of Product Development Flow): чем ближе загрузка людей к 100%, тем нелинейно длиннее ожидание. Команда «под завязку» медленнее команды с запасом при той же производительности каждого. Механика потока — в главе про Kanban.

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

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

Диапазон вместо точки: как называть срок

Практический формат, который работает лучше всего (отраслевая практика, не исследование): дата + вероятность + условие.

«С вероятностью около 80% — к 20 марта. С вероятностью около 50% — к 6 марта. Обе даты предполагают, что API платежей будет доступно до 25 февраля; если позже — двигаются обе на столько же. Если нужна дата, под которой я подпишусь при внешнем обещании, — 3 апреля».

Три отдельных смысла в этой фразе. P50 — для внутреннего планирования: это медиана, а не «план», и по определению в половине случаев вы её пропустите; ставить её обязательством значит гарантировать провал в половине случаев. P80 — для координации с соседями: дата, к которой можно готовить смежные работы. Условие — не оговорка, а самая ценная часть: оно превращает срыв из «команда не справилась» в «сработал названный риск» (работа с рисками — в отдельной главе).

Как выглядит нарушение: вас дожали до одной цифры («ну примерно-то когда?») и вы её назвали. Что произойдёт: названное в разговоре число будет процитировано как обязательство. Защита не требует конфронтации: назвать две цифры вместо одной и обе записать в переписку сразу после разговора. Устное не существует.

Что на самом деле спрашивают, когда спрашивают «когда»

Вопрос про срок почти никогда не про срок. Прежде чем считать, выясните, какое решение зависит от ответа и с какой точностью.

Про последнюю строку: добавление людей в опаздывающий проект задерживает его ещё сильнее (Фред Брукс, 1975). Строгих экспериментов нет, но механизм наблюдаем — цена входа новичка в контекст оплачивается временем самых загруженных (про адаптацию).

Ёмкость команды: считаем честно

Первое, что должен уметь тимлид, — не оценивать задачи, а знать, сколько инженерного времени у него вообще есть. Это арифметика, но её почти никто не делает вслух.

from dataclasses import dataclass

WORKDAYS_PER_QUARTER = 60  # 13 недель минус праздники, округлённо


@dataclass
class Member:
    name: str
    allocation: float       # доля ставки в этой команде: 1.0 — целиком
    vacation_days: int      # согласованный отпуск в квартале
    oncall_weeks: int       # недели дежурства
    ramp_up_days: int = 0   # для новичка: дни, когда он ещё не даёт выхода


def available_days(m: Member,
                   meeting_overhead: float = 0.15,
                   interrupt_overhead: float = 0.15,
                   oncall_efficiency: float = 0.4) -> float:
    """Сколько инженеро-дней человек реально отдаст проектной работе за квартал.

    Коэффициенты — не константы природы: замерьте свои по календарю и трекеру.
    """
    gross = WORKDAYS_PER_QUARTER * m.allocation - m.vacation_days - m.ramp_up_days
    # дежурная неделя не пропадает целиком, но и половины от неё ждать не стоит
    oncall_loss = m.oncall_weeks * 5 * (1 - oncall_efficiency)
    net = (gross - oncall_loss) * (1 - meeting_overhead - interrupt_overhead)
    return round(max(net, 0.0), 1)


team = [
    Member("Аня",   allocation=1.0, vacation_days=10, oncall_weeks=3),
    Member("Борис", allocation=1.0, vacation_days=0,  oncall_weeks=3),
    Member("Вика",  allocation=0.5, vacation_days=5,  oncall_weeks=0),   # половина в другой команде
    Member("Глеб",  allocation=1.0, vacation_days=0,  oncall_weeks=0, ramp_up_days=30),  # новичок
    Member("лид",   allocation=0.3, vacation_days=5,  oncall_weeks=0),   # честная доля тимлида
]

for m in team:
    print(f"{m.name:6} {available_days(m):5.1f} д")
print("итого:", round(sum(available_days(m) for m in team), 1), "инженеро-дней")

Вывод этой модели: 228 «человеко-дней по табелю» превращаются в 112 рабочих инженеро-дней — ровно вдвое меньше. Ни одна из статей вычета не является чьей-то виной: отпуск согласован, дежурство необходимо, новичок обязан входить в контекст, лид на 30% в коде — это уже щедро (см. главу про делегирование).

Три следствия для планирования:

• Никогда не планируйте на 100% ёмкости. Разумный потолок обязательств — 60–70% расчётной ёмкости; остальное съедят непредвиденные вещи, которые предвидеть можно только статистически.
• Дежурство — крупнейшая скрытая статья. В модели выше шесть недель дежурства — это 30 календарных дней, из которых списано 18; с учётом разбора инцидентов и «хвостов» на следующий день бывает больше. Отдельно про эту нагрузку — в главе про дежурства.
• Найм оплачивается из этой же ёмкости. Каждое собеседование — час-полтора инженера плюс переключение; активная воронка стоит команде несколько дней в месяц (глава про найм).

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

Прогноз по потоку вместо оценки каждой задачи

Если у вас есть история закрытых задач, оценивать каждую новую часто не нужно: достаточно знать, сколько задач в неделю команда закрывает и как сильно это число скачет. Это тот же прогноз по референтному классу, только на своих данных.

Псевдокод:

вход: history — список «сколько задач закрыто» по прошлым неделям
      backlog — сколько элементов нужно закрыть
      trials  — число прогонов симуляции

повторить trials раз:
    done ← 0; weeks ← 0
    пока done < backlog:
        done ← done + случайный элемент history   # бутстрап прошлого
        weeks ← weeks + 1
    записать weeks

вернуть перцентили записанных weeks: P50, P80, P95

Реализация:

import random


def forecast_weeks(history: list[int], backlog: int,
                   scope_growth: tuple[float, float] = (1.0, 1.4),
                   trials: int = 20_000,
                   seed: int | None = 42) -> dict[str, int]:
    """Монте-Карло по историческому throughput.

    history      — закрытых элементов по неделям (берите 8–12 последних недель);
    backlog      — сколько элементов нужно сделать сейчас;
    scope_growth — во сколько раз объём вырастет по ходу (замерьте свой диапазон!).
    """
    if not history or max(history) == 0:
        raise ValueError("история пуста: прогнозировать не на чем")

    rnd = random.Random(seed)
    results: list[int] = []
    for _ in range(trials):
        target = backlog * rnd.uniform(*scope_growth)  # объём почти всегда растёт
        done, weeks = 0.0, 0
        while done < target and weeks < 500:           # защита от вырожденной истории
            done += rnd.choice(history)
            weeks += 1
        results.append(weeks)

    results.sort()

    def pick(q: float) -> int:
        return results[min(int(len(results) * q), len(results) - 1)]

    return {"p50": pick(0.50), "p80": pick(0.80), "p95": pick(0.95)}


history = [7, 4, 9, 6, 2, 8, 5, 6, 3, 7]   # неделя с «2» — был инцидент, и это правда
print(forecast_weeks(history, backlog=40))
# {'p50': 9, 'p80': 10, 'p95': 11}

Сложность. Время — O(trials × backlog / mean(history)), то есть линейно по числу прогонов и по горизонту прогноза; при 20 000 прогонов и горизонте в десяток недель это миллисекунды. Память — O(trials) на массив результатов; при желании можно считать перцентили потоково и обойтись O(1).

Что здесь важно методически:

• Неделя с плохим результатом (2 в примере) не выбрасывается: инциденты и отпуска — часть вашего процесса, а не помеха измерению. Очищенная история даёт красивый и лживый прогноз.
• scope_growth — самый чувствительный параметр, и его не берут из головы: посчитайте по трём прошлым эпикам, сколько задач было в начале и сколько к концу.
• Модель молча предполагает, что процесс стабилен. Она ломается, если меняется состав команды, если задачи стали принципиально другого размера, если сменилась предметная область или если из потока пропала однородность (одна эпопея и двадцать мелочей — не одно распределение). Проверяйте эти условия прежде, чем показывать числа. Подробнее о подходе — у Даниэля Ваканти (Actionable Agile Metrics for Predictability) и Троя Магенниса.

Честная граница метода: он прогнозирует пропускную способность, а не конкретную сложную задачу. Для «переписать биллинг» истории похожих задач у вас нет — там спасает только декомпозиция до кусков, похожих на уже сделанное, или прототип.

Где ставить буфер

Классическое наблюдение Голдратта (метод критической цепи, Critical Chain, 1997): если дать каждому исполнителю запас внутри его задачи, запас исчезнет, а срок — нет. Работают два механизма: закон Паркинсона (работа занимает всё отведённое время) и «студенческий синдром» (за задачу берутся, когда запас съеден). Строгих экспериментальных подтверждений CCPM мало — это инженерная эвристика, но эвристика, у которой понятен механизм и легко наблюдаемо нарушение.

Верхний вариант заканчивается тем же числом, что нижний, и почти наверняка позже: каждый «запас» будет израсходован независимо от нужды, а любое опоздание передастся по цепочке целиком. Нижний отличается принципиально: буфер общий, и его расход виден. Съели 3 дня из 9 на первой задаче — это сигнал, который можно обсуждать сегодня, а не открытие в апреле. Практический приём: сделайте расход буфера главным показателем статуса. «Прошло 40% срока, съедено 70% буфера» — разговор по существу, в отличие от «всё идёт по плану» и «готово на 80%».

Жизненный цикл обязательства

План — не документ, а состояние, у которого есть переходы. Если переходы не описаны, план переходит из «зафиксирован» сразу в «сорван», минуя всё полезное.

Три перехода, которые в реальности отсутствуют чаще всего. Draft → Committed без явного решения: оценка «протекла» наружу и стала датой, момента никто не заметил — лечится ритуалом «обязательство рождается только письменно и только от вас». Deviation → Replanned откладывается: все видят отклонение, но надеются нагнать; правило — эскалировать в течение 48 часов после того, как отклонение стало видно, даже если план по его устранению ещё не готов, потому что сигнал важнее решения. Replanned → Cancelled не рассматривается: отмена — легитимный и часто самый дешёвый исход (как считать ценность против цены — в главе про приоритизацию).

Что ломается чаще всего

Отказы, которые повторяются независимо от индустрии. Для каждого — как выглядит нарушение и что за ним следует. Три первых уже разобраны выше и здесь просто названы: оценка молча становится обязательством (лечится тем, что дату формулируете и пишете вы, первым); тимлид оценивает за команду — систематическое занижение плюс исполнитель, не считающий оценку своей; буфер размазан по задачам — запас исчезает бесследно, а вы теряете единственный наблюдаемый индикатор.

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

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

6. Переработки как способ уложиться. Нарушение: «дожмём в выходные». Последствие: краткосрочно работает и потому соблазнительно; среднесрочно растёт доля неудачных изменений и падает скорость восстановления (DORA и глава про инженерные метрики); долгосрочно — выгорание и уход людей, чья замена стоит кварталов (про выгорание). И отдельно неприятное: успешная переработка учит бизнес, что дату можно назначать произвольно.

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

Раннее предупреждение вместо сюрприза

Срок никогда не срывается в последний день. Он срывается за недели до этого — просто никто не смотрит на индикаторы. Сравните два разговора:

Разница между сценариями — не в компетентности команды и не в качестве оценки. Она в одном действии тимлида на второй неделе. В первом случае молчание выглядело как профессионализм («решу сам, не буду поднимать панику»), во втором — сигнал выглядел как слабость, но дал бизнесу три недели на манёвр.

Индикаторы, на которые смотреть еженедельно:

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

Сколько усилий вкладывать в саму оценку

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

• Левый нижний. Мелочи, которые дешевле сделать, чем обсуждать: оценка здесь — чистые накладные расходы.
• Левый верхний. Понятно как, но ошибка дорога (миграция данных, схема прод-БД): вкладывайтесь не в точность оценки, а в план отката и репетицию.
• Правый нижний. Непонятно, но не смертельно: таймбокс на исследование («два дня разбираемся, потом оцениваем») вместо попытки угадать.
• Правый верхний. Единственный квадрант, где длинные обсуждения оправданны — но и здесь эффективнее не спорить о числах, а уменьшать неопределённость: прототип, спайк, разговор с соседней командой, письменное архитектурное решение (ADR).

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

Как это выглядит в проде: три коротких случая

«Мы же договорились на 20-е». Команда назвала 2–4 недели, лид передал «3 недели», продакт записал дату. К 20-му готово 80%. Разбор показал: разница — ровно ожидание ревью от соседней команды, которое никто не считал работой. Изменение: в план встали строки «ожидание внешнего ревью: 5 рабочих дней» как обычная задача с ответственным. Точность прогнозов выросла не оттого, что стали лучше оценивать код, а оттого, что перестали не считать ожидание.

Квартал, забитый под завязку. Планировалось 228 человеко-дней работ на 228 человеко-дней табеля; к середине квартала сделано 40%, команда работает по вечерам. Изменение: расчёт ёмкости с вычетами и потолок обязательств в 65%. Первый квартал после этого выглядел как «мы стали брать меньше», второй — как «мы наконец попадаем в сроки». Разговор с руководством был неприятным ровно один раз.

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

Чеклист тимлида

Перед тем как назвать срок: знаю, какое решение зависит от даты и с какой точностью; есть письменные критерии «готово» (миграции, мониторинг, откат, документация); оценку давали исполнители и до того, как прозвучала желаемая дата; ёмкость посчитана с вычетами; обязательства не выше 60–70% ёмкости; названы P50 и P80 плюс условие; внешние зависимости имеют письменные даты; буфер собран в конце.

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

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

Мини-итог

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

Источники

• Steve McConnell. Software Estimation: Demystifying the Black Art, 2006 — оценка, цель и обязательство как три разные вещи (книги автора).
• Magne Jørgensen: A review of studies on expert estimation… (JSS, 2004); с Гримстадом — The Impact of Irrelevant and Misleading Information… (IEEE TSE, 2011); с Молёккен-Эствольдом — How large are software cost overruns? (IST, 2006).
• Todd Little. Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty (IEEE Software, 2006) — конус неопределённости на данных реальных проектов.
• Frederick Brooks. The Mythical Man-Month, 1975. Eliyahu Goldratt. Critical Chain, 1997. Donald Reinertsen. The Principles of Product Development Flow, 2009.
• Daniel Vacanti. Actionable Agile Metrics for Predictability, 2015 — прогноз по потоку. Daniel Kahneman. Thinking, Fast and Slow, 2011. Bent Flyvbjerg, Dan Gardner. How Big Things Get Done, 2023.
• DORA и SPACE framework — что измерять на уровне системы, а не человека.
• Механизмы: planning fallacy, reference class forecasting, закон Литтла, закон Паркинсона, закон Гудхарта.

Что дальше

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

Дежурства и инциденты: нагрузка, которую легко не заметить