Управление разработкой: карта трека, три контура и зачем инженеру классика

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

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

1. Зачем инженеру классика, если вокруг Agile

Главное недоразумение сформулируем прямо:

Agile не отменил вопросов «что мы строим», «на чьи деньги», «кто отвечает», «как мы поймём, что закончили». Он переставил ответы, а не удалил вопросы.

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

Второй практический аргумент прозаичнее: классика — это язык, на котором с вами говорит внешний мир. Крупный заказчик пишет ТЗ и требует WBS. Тендер по 44-ФЗ или 223-ФЗ требует календарного плана с этапами и актов приёмки. Госконтракт требует ГОСТ-совместимого комплекта документов. Аудит требует прослеживаемости требований до тестов. PMO холдинга требует отчёт об освоенном объёме. Ни одно из этих требований не исчезнет от того, что внутри команды стоит Kanban-доска. Инженер, который умеет перевести «наш поток» на язык «этапы, гейты, освоенный объём», получает влияние; инженер, который не умеет, получает менеджера-переводчика, а вместе с ним — искажения перевода.

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

И четвёртый, самый неприятный: половина управленческого фольклора в IT — это плохо понятая классика. «Водопад — это когда всё планируют заранее и не меняют» — неверно уже относительно статьи Ройса 1970 года, где итерации и прототип предлагались явно (разбор — в главе про модели процесса). «Гейты — это бюрократия» — верно только для гейтов, на которых нельзя сказать «нет». Не зная оригиналов, спорить с этим фольклором нечем.

2. Три контура управления

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

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

2.1. Пять типовых подмен

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

3. Карта трека: четырнадцать глав

Одной строкой про каждую главу:

1. Проект, продукт и жизненный цикл — что такое проект строго, чем ЖЦ продукта отличается от ЖЦ проекта и от SDLC, зачем нужны фазы и гейты.
2. Модели процесса разработки — code-and-fix, водопад (и что на самом деле написал Ройс), V-модель, инкремент против итерации, спираль Боэма.
3. Подходы и методологии — предиктивный, итеративный, гибкий; семейство Agile целиком и чем подход отличается от модели и от фреймворка.
4. PMBOK — как свод знаний прошёл путь от 49 процессов и 10 областей к 12 принципам и 8 доменам, и что из него имеет смысл брать в IT.
5. PRINCE2 — семь принципов, семь тем, семь процессов, управление по отклонениям и постоянное экономическое обоснование.
6. Ландшафт стандартов — ISO 21500 и 21502, IPMA ICB, P3.express, российские ГОСТ, модель зрелости CMMI: кто кому родственник и зачем это нужно на тендере.
7. Устав, содержание и WBS — три базовых документа проекта, правило 100%, словарь WBS и контроль изменений.
8. Предварительная оценка IT-проекта — аналогия, оценка по фичам, PERT, конус неопределённости и почему диапазон честнее одной цифры.
9. Декомпозиция задач — вертикально или горизонтально, восемь приёмов разрезания и признак, что дробить дальше уже вредно.
10. Делегирование и распределение ответственности — уровни делегирования, RACI и его родственники, контрольные точки вместо контроля процесса.
11. Методы решения проблем — мозговой штурм и его известные дефекты, brainswarming, «5 почему», диаграмма Исикавы, TRIZ-подобные приёмы.
12. Принятие решений в проекте — типы решений, DACI и RAPID, ADR, эскалация и допуски на отклонение.
13. Контроль исполнения и извлечённые уроки — отчётность без «арбузных» статусов, освоенный объём, health check проекта и база знаний, которая переживает проект.

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

4. Границы с соседними треками портала

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

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

5. Честно про доказательную базу

Управление проектами — область с очень неравномерным качеством доказательств. Смешивать уровни доказательности вредно, поэтому разложим сразу.

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

Где данные есть. Самая цитируемая цифра отрасли — отчёт Standish Group CHAOS (1994) с его «31% проектов отменяются» — как раз пример того, чему верить нельзя без оговорок: Магне Йоргенсен и Кьетиль Молёккен показали, что выборка смещена к проблемным проектам, определение успеха не раскрыто, а расчёт перерасхода невоспроизводим (Jørgensen & Moløkken, IST 2006). Аккуратнее устроены работы Бента Флювбьерга: база из 16 000+ проектов, явная методология, публикации в рецензируемых журналах — и главный вывод про форму распределения перерасходов, у которого толстый правый хвост (Flyvbjerg & Budzier, HBR 2011; «How Big Things Get Done», 2023). Отдельный островок настоящей статистики — программа DORA: многолетние опросы с проверкой гипотез и публикацией методологии (книга «Accelerate», отчёты DORA). У неё свои ограничения — данные самоотчётные, связи корреляционные, — но методология открыта, а это уже редкость.

Где фольклор. Утверждение «дефект, найденный в проде, стоит в 100 раз дороже, чем найденный на этапе требований» живёт в сотнях презентаций, а его источники прослеживаются к нескольким небольшим наборам данных 1970-х годов, часть которых восстановить не удаётся; подробный разбор — у Лорана Боссави («The Leprechauns of Software Engineering»). Туда же: «Agile-проекты в три раза успешнее» из отчётов вендоров инструментов, «правило 10x» про разброс продуктивности программистов, «стоимость переключения контекста ровно 23 минуты». Всё это может быть направленно верно и при этом не иметь той точности, которую ему приписывают.

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

6. Три маршрута чтения

Маршрут инженера (5 глав, примерно вечер чтения). Цель — понимать, что происходит на уровень выше вас, и уметь разговаривать на этом языке. Ключевые главы: жизненный цикл (чтобы отличать «проект закрыт» от «система работает»), модели процесса (чтобы не воевать с фольклором), подходы, принятие решений (ADR — единственный управленческий артефакт, который инженеры пишут сами и постоянно), декомпозиция (вертикальная нарезка — навык, который заметен на код-ревью). После этого разумно уйти в трек по управлению проектами в IT: там та же материя в операционном виде.

Маршрут нового менеджера проекта (7 глав, но с упражнениями). Читать по порядку и делать: написать устав на страницу для своего текущего проекта, построить WBS, дать диапазонную оценку, разложить RACI, поставить контрольные точки. Своды знаний (главы 04–06) в этом маршруте идут после практики, а не до: без собственного опыта PMBOK читается как справочник неизвестно чего, а после — как каталог решений знакомых проблем.

Маршрут «сертификация, тендер, госконтракт» (5 глав, читать медленно). Здесь важны точные формулировки, состав документов и терминология, а не интуиция. Главы 04–07 и 13 дают структуру, которую спрашивают на экзамене PMP или PRINCE2 Foundation и требуют в конкурсной документации. Подготовку к экзамену по Scrum отдельно закрывает глава в треке скрам-мастера.

7. Как этим пользоваться на практике

Три привычки, которые дают больше, чем знание любого свода наизусть.

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

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

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

Мини-итог

• Agile переставил ответы, а не удалил вопросы. «Что строим», «на чьи деньги», «кто отвечает», «как поймём, что закончили» задаются в любом подходе; различается горизонт и форма обязательства.
• Классика — это язык внешнего мира: тендера, госконтракта, аудита, PMO и крупного заказчика. Умение переводить на него свой поток работы — прямое влияние.
• Три контура: продукт, проект, процесс. Ценность, обязательство, исполнение. Они вложены, у каждого свой горизонт и своя петля; сигнал внутреннего контура не заменяет сигнала внешнего.
• Большинство провалов — подмена контуров: проект сдан, ценность не измерена; процесс здоров, обязательств никто не даёт; проектный контроль спущен на уровень двухчасовых задач.
• Своды знаний — консенсус, а не эмпирика. Настоящие данные есть у Флювбьерга и DORA; CHAOS требует оговорок; часть популярных «законов» отрасли — фольклор с неустановленным происхождением.
• Маршрутов три: инженеру — пять глав про язык и решения; новому менеджеру — семь глав с упражнениями и сводами после практики; готовящемуся к сертификации или тендеру — стандарты и документы, медленно и точно.

Источники

• PMBOK Guide, PMI — свод знаний по управлению проектами; 7-е издание построено на принципах.
• PRINCE2 — метод с процессной структурой и управлением по отклонениям.
• ISO 21502:2020 — руководство по управлению проектами, нейтральное к методологии.
• Manifesto for Agile Software Development, 2001 — четыре ценности и двенадцать принципов.
• Royce W., «Managing the Development of Large Software Systems», 1970.
• Boehm B., «A Spiral Model of Software Development and Enhancement», IEEE Computer, 1988.
• Flyvbjerg B., Budzier A., «Why Your IT Project May Be Riskier Than You Think», HBR 2011; «How Big Things Get Done», 2023.
• Jørgensen M., Moløkken K., «How large are software cost overruns? A review of the 1994 CHAOS report», IST 2006 — критика Standish CHAOS.
• Forsgren N., Humble J., Kim G., «Accelerate», 2018; DORA Research.
• Bossavit L., «The Leprechauns of Software Engineering» — разбор происхождения популярных «фактов» отрасли.
• Fowler M., «Products Over Projects» — почему проектное финансирование вредит долгоживущим системам.
• McKinsey & Oxford, «Delivering large-scale IT projects on time, on budget, and on value», 2012.

Что дальше

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

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

Читайте: Проект, продукт и жизненный цикл: фазы, гейты и почему ЖЦ проекта не равен ЖЦ продукта