Управление проектами в IT: карта трека и связь с материалами портала

Проектный менеджер — не «человек, который двигает карточки в Jira», и не «тот, кто спрашивает статус». Роль существует ради одного:

сделать так, чтобы обещание, данное бизнесу, и физическая реальность разработки сошлись — а если не сходятся, чтобы это обнаружилось рано, пока расхождение дёшево.

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

1. Проблема: почему проекты расходятся с планом

1.1. Что реально известно из данных

Самая цитируемая цифра — отчёт Standish Group CHAOS (1994): 31% проектов отменяются, 52,7% превышают бюджет в среднем на 189%. К ней стоит относиться скептически: Магне Йоргенсен и Кьетиль Молёккен разобрали методологию и показали, что выборка смещена к проблемным проектам, определение «успеха» не раскрыто, а расчёт перерасхода невоспроизводим (Jørgensen & Moløkken, IST 2006). Отсюда первый профессиональный навык менеджера: отличать измеренное от разрекламированного.

Аккуратные исследования дают более скромную, но всё равно неприятную картину:

Вывод не «все врут в оценках», а форма распределения: перерасход не нормален, у него толстый правый хвост. Медианный проект отклоняется умеренно, но малая доля уходит в катастрофу — и именно она определяет ожидаемые потери портфеля. Управление проектом — управление хвостом, а не средним.

1.2. Три причины

1. ПО невидимо и уникально. У него нет геометрии: нельзя окинуть взглядом и увидеть, что готово 30% — отсюда синдром «90% готово» длиной в полгода (Brooks, «No Silver Bullet», 1986). А повторяемая работа имеет статистику; уникальность и точный прогноз несовместимы по определению.
2. Искажения систематичны, а не случайны. Ошибка планирования Канемана и Тверски: люди оценивают по оптимистичному сценарию своей задачи, игнорируя статистику похожих работ. Каталог из десяти устойчивых искажений — у Флювбьерга, PMJ 2021.
3. Организация добавляет свои потери. Ожидание согласований, передача между командами, переключения контекста — часто больше половины календарного времени задачи. Это ровно то, чем менеджер управляет напрямую, в отличие от скорости написания кода.

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

Барри Бём в «Software Engineering Economics» (1981) показал эмпирику, которую Стив Макконнелл назвал конусом неопределённости: на стадии идеи оценка отличается от факта в диапазоне 0,25×…4× (разброс в 16 раз) и сужается по мере снятия неизвестных (McConnell, 2006).

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

2. Что такое проект строго

2.1. Определение и границы

Проект — временное начинание для создания уникального результата (формулировка PMBOK/ISO 21502). Каждое слово несёт нагрузку: временное — конец наступает, когда цель достигнута или признана недостижимой (отмена — законный исход); уникальное — нет прецедента, значит есть неопределённость; результат — оценивается достигнутый эффект, а не факт закрытия задач.

Проектом не является эксплуатация (поддержка, SRE — без конечной даты), продуктовая работа (непрерывный цикл гипотез, см. Product management) и поток мелких изменений, где накладные расходы «проектности» больше пользы. Мартин Фаулер аргументирует, что для долгоживущих систем проектное финансирование вредно: команда расформировывается ровно тогда, когда разобралась в домене («Products Over Projects»). Это не отменяет проектную дисциплину — миграции, интеграции, запуск в новом регионе, требования регулятора остаются проектами. Отменяется автоматизм «всё делаем проектами».

2.2. Тройное ограничение — и почему оно врёт в IT

Классика: содержание — сроки — стоимость, зафиксируй два, третье станет следствием. Как способ показать заказчику, что бесплатных изменений не бывает, модель полезна. В IT у неё три дыры.

Качество — не регулятор. В строительстве дешёвый бетон даёт экономию сегодня ценой ремонта через десять лет; в ПО «сэкономленное» качество отдаёт долг уже через недели (Fowler, «Is High Quality Software Worth the Cost?», DesignStaminaHypothesis). Внутреннее качество — не сторона треугольника, а скорость самого треугольника; см. Качество и релизы.

Люди не складываются. Закон Брукса: добавление людей в опаздывающий проект задерживает его ещё сильнее — новичков надо обучать, отнимая время у опытных, а число каналов коммуникации растёт как n(n−1)/2 («The Mythical Man-Month», 1975):

Содержание не фиксируется, потому что неизвестно. «Зафиксировать scope» на старте — значит зафиксировать самую невежественную его версию, придуманную в момент максимальной неопределённости.

Аткинсон предложил заменить треугольник четырьмя группами критериев: процесс доставки, качество системы, польза для организации, польза для стейкхолдеров (Atkinson, IJPM 1999). Практический перевод: проект, сданный в срок и в бюджет, но никем не используемый, — провал.

2.3. Жизненный цикл

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

3. Как выбрать режим управления

Главная развилка — предиктивный («водопад») против адаптивного (итеративного). Спор «какой лучше» бессмыслен без контекста: они решают разные задачи. Сначала историческая справедливость: Уинстон Ройс в 1970 году действительно нарисовал водопадную схему, но подписал под ней, что подход «рискован и напрашивается на провал», и дальше предложил прототипирование и итерации (Royce, 1970, PDF). Индустрия двадцать лет цитировала картинку и игнорировала текст.

3.1. Диагностика неопределённости

Полезная рамка — матрица Стейси: два независимых вопроса, «насколько согласовано что делать» и «насколько известно как делать».

Режим управления выбирается по квадранту, а не по моде. Миграции БД не нужны продуктовые гипотезы — ей нужен план, критический путь и план отката. Продукту на новом рынке не нужен план на год — ему нужны дешёвые проверки. Тот же выбор в виде процедуры:

Правило, которое стоит запомнить: итерации — способ купить информацию. Они выгодны, когда информация дешёвая и быстрая. Если обратная связь стоит месяцы (сертификация, физическое оборудование, регуляторная приёмка), итерации не окупаются и нужен настоящий предиктивный план. Родственная рамка — Cynefin: ясный, сложный, комплексный и хаотичный контексты (Snowden & Boone, HBR 2007).

4. Ядро № 1: критический путь

При наличии зависимостей срок проекта определяет не сумма работ и не самая большая работа, а самая длинная цепочка зависимостей. CPM (DuPont, 1957) и PERT (проект Polaris, 1958) формализовали это первыми.

Проект — направленный ациклический граф: вершины — работы с длительностями, рёбра — зависимости. Считаем ES/EF (самые ранние старт и конец), LS/LF (самые поздние, не сдвигающие проект), резерв = LS − ES; работы с нулевым резервом образуют критический путь.

ПРЯМОЙ ПРОХОД (в топологическом порядке):    ES[t] = max(EF[p] по предшественникам p), иначе 0
                                             EF[t] = ES[t] + duration[t];  end = max(EF[t])
ОБРАТНЫЙ ПРОХОД (в обратном порядке):        LF[t] = min(LS[s] по последователям s), иначе end
                                             slack[t] = LF[t] - duration[t] - ES[t]

from collections import deque

def critical_path(duration: dict[str, float], preds: dict[str, list[str]]):
    """CPM: ранние старты, резервы и длительность проекта.
    duration — работа -> длительность в днях; preds — работа -> предшественники."""
    tasks = list(duration)
    succs = {t: [] for t in tasks}
    indeg = {t: 0 for t in tasks}
    for t in tasks:
        for p in preds.get(t, []):
            succs[p].append(t)
            indeg[t] += 1
    order, q = [], deque(t for t in tasks if indeg[t] == 0)   # топологическая сортировка Кана
    es = {t: 0.0 for t in tasks}
    while q:                                                  # прямой проход
        t = q.popleft()
        order.append(t)
        for s in succs[t]:
            es[s] = max(es[s], es[t] + duration[t])   # старт не раньше конца всех предшественников
            indeg[s] -= 1
            if indeg[s] == 0:
                q.append(s)
    if len(order) != len(tasks):
        raise ValueError("в графе зависимостей есть цикл")   # обычно — взаимная блокировка команд
    end = max(es[t] + duration[t] for t in tasks)
    lf = {t: end for t in tasks}
    for t in reversed(order):                                 # обратный проход
        if succs[t]:
            lf[t] = min(lf[s] - duration[s] for s in succs[t])
    return es, {t: lf[t] - duration[t] - es[t] for t in tasks}, end

duration = {"A": 5, "B": 8, "C": 6, "D": 3, "E": 4, "F": 2}
preds = {"B": ["A"], "C": ["A"], "D": ["B", "C"], "E": ["B"], "F": ["D", "E"]}
es, slack, end = critical_path(duration, preds)
print(end, {t: slack[t] for t in sorted(slack)})
# 19.0 {'A': 0.0, 'B': 0.0, 'C': 3.0, 'D': 1.0, 'E': 0.0, 'F': 0.0}
# критический путь (нулевой резерв): A -> B -> E -> F, 19 дней

Сложность: O(V + E) по времени и памяти — каждая вершина и ребро обрабатываются константное число раз. План из десятков тысяч работ считается мгновенно: узкое место планирования никогда не в алгоритме, а в качестве входных данных. Топологическая сортировка разбирается в треке Алгоритмы. Тот же план диаграммой Ганта (Генри Гант, 1910-е; форма пережила все методологии):

Что делать: ускорять только критические работы (ускорение фронтенда здесь не даст ничего); следить за работами с малым резервом — они станут критическими при первой задержке; разрывать зависимости архитектурно — заранее согласованный контракт API позволяет вести бэкенд и фронтенд параллельно и физически укорачивает критический путь.

Чего не делать: верить в детерминированные длительности. Настоящая ловушка CPM — слияние путей: если в точку сходятся три ветки, каждая успевает с вероятностью 0,8, то шанс уложиться всем — 0,8³ ≈ 0,51. Задержки складываются, опережения — нет. Поэтому «каждая задача с запасом» не даёт запаса проекту: резерв съедается студенческим синдромом (начинаем в последний момент) и законом Паркинсона (работа заполняет отведённое время). Голдратт предложил снимать локальные буферы и собирать один общий буфер проекта («Critical Chain», 1997). PERT смягчает проблему трёхточечной оценкой E = (O + 4M + P)/6, σ = (P − O)/6 — разбор в статье Оценка и планирование.

5. Ядро № 2: поток и загрузка

Критический путь отвечает, когда закончим при заданном плане. Второй вопрос — почему работа стоит в очереди, хотя все заняты. Ответ даёт теория очередей, и он контринтуитивен. Закон Литтла (Little, 1961) верен для любой стабильной системы, без предположений о распределениях:

L = λ · W      →      время прохождения = незавершённая работа / пропускная способность

При неизменной пропускной способности время выполнения задачи пропорционально количеству одновременно начатой работы. Команда, взявшая 30 задач вместо 10, не делает их быстрее — она делает каждую втрое дольше и получает втрое более старую обратную связь. Отсюда WIP-лимиты, см. Kanban и управление потоком.

Ещё жёстче эффект загрузки. Для модели M/M/1 среднее ожидание в очереди относительно времени обработки равно ρ/(1−ρ), где ρ — коэффициент загрузки:

Проверим честной дискретной симуляцией, без формул:

import random, statistics

def simulate(arrival_rate: float, service_rate: float, n: int = 200_000, seed: int = 1) -> float:
    """Одноканальная очередь FIFO: среднее время задачи в системе. arrival_rate (λ) — сколько задач
    приходит за единицу времени; service_rate (μ) — сколько команда способна закрыть за то же время."""
    rnd = random.Random(seed)
    now = free_at = 0.0          # приход очередной задачи / когда исполнитель освободится
    times = []
    for _ in range(n):
        now += rnd.expovariate(arrival_rate)      # задачи приходят неравномерно
        start = max(now, free_at)                 # либо сразу, либо ждём очереди
        free_at = start + rnd.expovariate(service_rate)
        times.append(free_at - now)               # ожидание + сама работа
    return statistics.mean(times)

mu = 1.0
for rho in (0.5, 0.7, 0.8, 0.9):
    print(f"{rho:>5.0%}  симуляция {simulate(rho * mu, mu):>5.2f}  теория {1 / (mu - rho * mu):>5.2f}")
#   50%  симуляция  2.00  теория  2.00
#   70%  симуляция  3.31  теория  3.33
#   80%  симуляция  4.97  теория  5.00
#   90%  симуляция  9.86  теория 10.00

Сложность: O(n) по времени, O(n) по памяти (сводится к O(1) при потоковом подсчёте среднего); точность растёт как O(1/√n) — обычная скорость Монте-Карло.

Читается так: подняв загрузку с 80% до 90%, менеджер «выжал ресурс» на 12,5% и удвоил срок прохождения задачи. Это корень большинства провалов сроков в организациях, которые гордятся тем, что «у всех всё занято». Дональд Рейнертсен посвятил этому книгу («The Principles of Product Development Flow», 2009); короткое следствие — свободная мощность не потери, а плата за предсказуемость.

5.1. Вероятностный прогноз вместо даты

Зная историю пропускной способности, дату можно прогнозировать вообще без оценок задач:

import random

def forecast(weekly_throughput: list[int], remaining: int, trials: int = 20_000, seed: int = 42):
    """Сколько недель нужно, чтобы закрыть `remaining` задач. Возвращает перцентили."""
    rnd, runs = random.Random(seed), []
    for _ in range(trials):
        done = weeks = 0
        while done < remaining and weeks < 500:      # страховка от нулевой пропускной способности
            done += rnd.choice(weekly_throughput)    # тянем случайную неделю из прошлого
            weeks += 1
        runs.append(weeks)
    runs.sort()
    return {p: runs[int(len(runs) * p / 100)] for p in (50, 70, 85, 95)}

history = [4, 7, 5, 9, 3, 6, 8, 5, 2, 6, 7, 4]       # 12 прошедших недель
print(forecast(history, remaining=60))               # {50: 11, 70: 12, 85: 13, 95: 13}

Сложность: O(trials × E[недель]) по времени, O(trials) по памяти. Метод честнее суммы экспертных оценок по двум причинам: опирается на фактическое поведение системы — со всеми её отпусками, инцидентами и переключениями — и выдаёт распределение, а не точку. Разговор с заказчиком меняется качественно: вместо «будет 15 мая» — «с вероятностью 85% уложимся за 13 недель; нужна уверенность 95% — берите 14 или сокращайте объём» (Vacanti, «Actionable Agile Metrics»). Ограничение честное: метод предполагает, что будущее статистически похоже на прошлое, и неприменим для новой команды, нового домена и сразу после реорганизации — там нет валидной истории.

6. Ядро № 3: деньги и освоенный объём

EVM отвечает на вопрос «отстаём или перерасходуем?» одним набором чисел: PV — сколько работы по плану должно быть сделано (в деньгах), EV — сколько сделано фактически (в тех же плановых деньгах), AC — сколько реально потрачено.

def evm(bac: float, pv: float, ev: float, ac: float) -> dict[str, float]:
    """BAC — бюджет проекта целиком; PV/EV/AC — на отчётную дату."""
    cpi, spi = ev / ac, ev / pv    # индексы стоимости и сроков: < 1 — перерасход / отставание
    eac = bac / cpi                # прогноз итоговой стоимости при той же эффективности
    return {"CV": ev - ac, "SV": ev - pv, "CPI": round(cpi, 3), "SPI": round(spi, 3),
            "EAC": round(eac, 1), "ETC": round(eac - ac, 1), "VAC": round(bac - eac, 1)}

print(evm(bac=1000, pv=400, ev=320, ac=440))
# {'CV': -120, 'SV': -80, 'CPI': 0.727, 'SPI': 0.8, 'EAC': 1375.0, 'ETC': 935.0, 'VAC': -375.0}

Читается так: потратили 44% бюджета, сделали работы на 32% — каждый вложенный рубль приносит 73 копейки плановой работы; если ничего не менять, проект стоимостью 1000 обойдётся в 1375. Ценность EVM в том, что прогноз строится по фактической эффективности, а не по обещанию «наверстаем»: CPI после 20% выполнения эмпирически стабилен.

Ограничения, из-за которых EVM в продуктовой разработке применяют мало: EV требует заранее известного объёма (в адаптивном режиме знаменатель плывёт); метод измеряет output, а не outcome — можно иметь CPI = 1,0 и построить ненужное; сам учёт трудозатрат стоит времени команды, часто дороже пользы. Где EVM жив: фиксированные контракты, госзаказ, аутсорс с оплатой по этапам, крупные программы с внешней отчётностью. Где мёртв: продуктовая команда с непрерывным потоком — там место занимают метрики потока и DORA.

7. Ядро № 4: риск как ожидаемая величина

Риск — не «что-то плохое», а событие с вероятностью и последствием. Простейшая мера — ожидаемая стоимость EMV = P × Impact.

risks = [   # (описание, вероятность, ущерб в днях, стоимость меры в днях)
    ("Внешнее API отдаёт не тот формат",    0.40, 15, 2),
    ("Не пройдём нагрузочное тестирование", 0.30, 20, 4),
    ("Ключевой инженер уходит в отпуск",    0.90,  3, 1),
    ("Регулятор меняет требования",         0.05, 60, 8),
]
for name, p, impact, cost in sorted(risks, key=lambda r: -r[1] * r[2]):
    emv = p * impact
    print(f"{name:<40}{emv:>6.1f}{cost:>5}{'снимать' if emv > cost else 'принять':>10}")
# Внешнее API отдаёт не тот формат           6.0    2   снимать
# Не пройдём нагрузочное тестирование        6.0    4   снимать
# Регулятор меняет требования                3.0    8   принять
# Ключевой инженер уходит в отпуск           2.7    1   снимать

Правило: тратить на снятие риска меньше, чем стоит сам риск. Строка про регулятора — случай, когда менеджер осознанно принимает риск и фиксирует решение письменно, вместо восьми дней защиты от маловероятного события. Оговорка ради раздела 1.1: EMV — среднее, а разорение приходит из хвоста. Риск «утечка данных» с P = 0,01 и ущербом «конец компании» нельзя сравнивать по EMV с риском «задержка на день»: для него критерий не ожидаемая величина, а допустимость худшего исхода. Полный разбор — Управление рисками.

8. Что менеджер делает на практике: недельный ритм

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

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

1. Оценка выдаётся за обязательство. «Примерно две недели» превращается в «14 дней». Оценка — распределение, обязательство — точка с запасом; лечится явными перцентилями (раздел 5.1).
2. Управление людьми вместо управления потоком. Догонять график ростом загрузки — получить эффект из раздела 5, ровно противоположный желаемому. Родственное: люди как взаимозаменяемые единицы — «пять человеко-месяцев» не значит, что пятеро сделают за месяц (раздел 2.2).
3. Резерв размазан по задачам. Локальные буферы съедаются полностью; нужен один буфер на цепь.
4. Статус вместо решения. Совещание, где обменялись процентами готовности и ничего не решили, — чистые потери, умноженные на число участников. Рядом — отчёт по output: «закрыли 47 задач» ничего не говорит о том, стало ли лучше пользователю.
5. Изменения без цены. Заказчик вправе менять содержание, но каждое изменение обязано иметь видимую стоимость в сроке или объёме — иначе scope creep неизбежен.
6. Отмена как табу — превращает мелкую ошибку в крупные потери (раздел 2.3).
7. Копирование фреймворка целиком без причин, породивших его в оригинале, — карго-культ; см. Масштабирование.
8. Игнорирование внешних зависимостей. В большинстве сорванных проектов критический путь в какой-то момент проходил через чужую команду или подрядчика — то есть через то, чем менеджер управляет хуже всего и о чём поэтому должен думать больше всего.

10. Откуда дисциплина взялась

Диаграмма Ганта (1910-е) — учёт работ на производстве; CPM и PERT (1957–58) — критический путь и вероятностные оценки; Ройс (1970) — водопад, описанный и сразу названный рискованным; Брукс (1975–86) — люди не складываются, сложность ПО неустранима; спиральная модель Бёма (1987) — итерации, управляемые риском; PMBOK и PRINCE2 (1990-е) — кодификация; Голдратт (1997) — буферы и теория ограничений; Agile Manifesto (2001) — работающее ПО и обратная связь; Kanban и Рейнертсен (2007–09) — лимиты WIP и экономика потока; DevOps (2010-е) — непрерывная поставка; Accelerate и DORA (2018) — метрики, связанные с бизнес-результатом; PMBOK 7 (2021) — переход от процессов к принципам.

Линия читается не как «новое вытеснило старое», а как накопление инструментов под разные боли. CPM отвечает на «когда закончим при известных зависимостях», Agile — на «что делать, когда требования неизвестны», теория очередей — на «почему все заняты, а ничего не готово», DORA — на «как понять, что процесс правда стал лучше». Зрелый менеджер держит все четыре и выбирает по контексту из раздела 3, а не по последней прочитанной книге.

11. Карта трека

Трек следует логике этой статьи: режимы работы (01, 02) → прогноз и неопределённость (03, 04) → люди (05) → результат и его измерение (06, 07) → что ломается при росте организации (08). Каждая статья самодостаточна.

Связь с порталом. Product management — «что и зачем строим», проектный менеджмент отвечает на «как и когда» (различие — в разделе 2.1). Архитектурные паттерны — границы сервисов определяют, какие работы идут параллельно, а значит и длину критического пути; DDD — единый язык снижает потери на передаче требований. Принципы и Паттерны проектирования — то самое внутреннее качество, то есть скорость треугольника из 2.2. Data engineering — откуда берутся данные для метрик; без надёжного пайплайна они превращаются в фольклор. Языковые треки (Go, TypeScript, C#, Elixir) — оценивая трудоёмкость, полезно понимать, что именно оценивается.

12. Мини-итог

• Проекты расходятся с планом не из-за лени, а из-за формы распределения — толстого правого хвоста. Управлять надо хвостом: ограничивать размер ставки и ускорять обратную связь. Конус неопределённости: оценка на старте — диапазон в 16 раз, сужает его не время, а снятые неизвестные, поэтому обязательство из широкой части конуса — лотерея.
• Тройное ограничение — упрощение. Качество не регулятор, а множитель скорости; люди не складываются (n(n−1)/2 каналов); содержание на старте известно хуже всего. Режим управления выбирается по неопределённости, а не по моде.
• Критический путь считается за O(V+E); ускорять имеет смысл только его. Но детерминированные длительности лгут: пути сливаются, задержки складываются, опережения — нет.
• Поток важнее загрузки. Закон Литтла: время прохождения ∝ WIP; рост загрузки с 80% до 90% удваивает срок. Свободная мощность — плата за предсказуемость.
• Прогноз должен быть вероятностным: Монте-Карло по фактической истории даёт перцентили, а не фальшивую точку. Риск — P × Impact, но для недопустимого худшего исхода критерий иной.
• Хороший проектный менеджер узнаётся не по красоте плана, а по тому, как рано в его проекте становится известно, что план не сходится.

Источники

• Frederick Brooks. The Mythical Man-Month, 1975; No Silver Bullet, 1986 (PDF)
• Winston Royce. Managing the Development of Large Software Systems, 1970 (PDF)
• Bent Flyvbjerg, Dan Gardner. How Big Things Get Done, 2023 — сайт; Top Ten Behavioral Biases, PMJ 2021; HBR 2011
• Steve McConnell. Software Estimation, 2006; Donald Reinertsen. The Principles of Product Development Flow, 2009; Eliyahu Goldratt. Critical Chain, 1997
• Forsgren, Humble, Kim. Accelerate, 2018 — dora.dev; Daniel Vacanti. Actionable Agile Metrics
• Jørgensen & Moløkken. A review of the 1994 CHAOS report, IST 2006; Snowden & Boone. A Leader’s Framework for Decision Making, HBR 2007
• Martin Fowler. Is High Quality Software Worth the Cost? · Products Over Projects · Melvin Conway. How Do Committees Invent?, 1968
• PMBOK Guide, 7th ed. · PRINCE2 · Scrum Guide · Little, 1961

Что дальше

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

Читайте: Agile и Scrum: ценности, роли, церемонии, честная критика