Устав, содержание и WBS: три базовых документа проекта и контроль изменений

PMBOK описывает три основных документа проекта, у каждого своё назначение: устав проекта — официальная авторизация; описание содержания проекта — описание работы, которую предстоит выполнить, и результатов поставки, которые надлежит произвести; план управления проектом — описание того, как работа будет выполняться. Три вопроса: можно ли начинать, что именно делаем, как мы это делаем. Разные стандарты называют их по-разному (в PRINCE2 это Project Brief, PID и продуктовые описания; ГОСТ Р 54869 требует «документированных целей, содержания и плана»), но набор вопросов не меняется полвека.

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

Документ — это зафиксированное решение и адрес ответственности. Не описание, не отчёт, не формальность. Если в тексте нет решения и нет имени того, кто за него отвечает, это не документ, а конспект.

Отсюда правило проверки формата: если документ никто не читает после подписания, его формат неверен.

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

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

1. Устав проекта

Устав (project charter) делает одну вещь: превращает намерение в проект. До устава есть идея и заинтересованные люди; после — проект, у которого выделены ресурсы, назначен менеджер и определены границы полномочий.

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

Шаблон на одну страницу

# Устав проекта: Портал самообслуживания корпоративных клиентов
**Спонсор:** Смирнова А., директор по операциям · **Менеджер:** Орлов Д. · **Версия:** 1.0 от 2026-07-16

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

## Цель и критерии успеха
| Критерий | Сейчас | Цель | Когда проверяем |
|---|---|---|---|
| Доля изменений, выполненных клиентом самостоятельно | 0% | 60% | +3 мес. после запуска |
| Медианный срок ответа поддержки по классу | 19 ч | 4 ч | +3 мес. после запуска |
| Ручные часы поддержки на класс | 340/мес | 120/мес | +6 мес. после запуска |

## В объёме
Смена тарифа и платёжных реквизитов через личный кабинет; история операций за 24 месяца;
интеграция с биллингом на чтение и запись.

## Вне объёма
- Миграция исторических данных старше 2 лет
- Мобильное приложение — только адаптивный веб
- Интеграция с 1С — отдельный проект после этого
- Сегмент SMB — другой сценарий и другой интерфейс

## Допущения (владелец / проверка / срок)
1. Не менее 60% клиентов готовы работать сами — аналитик / 12 интервью / до 15.08
2. Биллинг держит 40 запросов/с — тимлид биллинга / нагрузочный тест / до 15.08
3. Смена реквизитов законна без бумажного заявления — юрист / заключение / до 01.08

## Ограничения
Дата: контракт с колл-центром заканчивается 01.06.2027, продление невозможно. Бюджет: 9 000 тыс.
руб., первый транш 1 200 тыс. руб. до гейта 1. Технологии: текущий стек, новых СУБД не вводим.

## Ключевые риски
| Риск | Влияние | Реакция | Владелец |
|---|---|---|---|
| Биллинг не держит нагрузку | +3 мес., переписывание модуля | Нагрузочный тест до гейта 1 | Тимлид биллинга |
| Клиенты не готовы к самообслуживанию | Проект не окупается | Интервью, пилот на 10 клиентах | Аналитик |

## Полномочия менеджера
До 5 человеко-дней — решает менеджер; 5–20 — спонсор; свыше 20 или сдвиг даты —
спонсор с пересмотром бизнес-кейса; запуск в прод — спонсор по чек-листу готовности.

## Критерии закрытия
Успешное: три критерия успеха достигнуты, сервис передан в эксплуатацию с владельцем и дежурством.
Досрочное: готовность клиентов ниже 35% по интервью; либо нагрузочный тест требует переписывания
биллинга (>3 мес.); либо прогноз по 85-му перцентилю выходит за 8 месяцев на гейте 2.

**Подпись спонсора:** ______________________

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

2. Содержание проекта

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

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

«Вне объёма» — самый ценный раздел

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

Критерии приёмки и связь с DoD

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

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

3. WBS: иерархическая структура работ

WBS (Work Breakdown Structure), по-русски ИСР, — иерархическая декомпозиция полного содержания проекта на управляемые элементы. Это не список задач и не график: структура отвечает на вопрос «из чего состоит проект» прежде, чем кто-либо задаст вопрос «когда это будет готово».

Правило 100%

Сумма элементов каждого уровня равна ровно родительскому элементу — не больше и не меньше.

«Не меньше» означает: работа, которой нет в WBS, не входит в проект. Это и есть механизм защиты от размывания объёма — любая просьба «а ещё сделайте вот это» немедленно превращается в вопрос «в какой элемент WBS это попадает», а если ни в какой, то в запрос на изменение с ценой. «Не больше» означает: в WBS нет элементов, не ведущих к результату проекта; самая частая их разновидность — gold plating, улучшения, которых никто не просил. Правило применяется рекурсивно: если «1.3 Личный кабинет» разложен на три подэлемента, эти три вместе составляют весь личный кабинет — и ничего, кроме него.

Декомпозиция по результатам, а не по действиям

Элементы WBS — существительные, обозначающие результаты (deliverables), а не глаголы, обозначающие действия.

Причина не в педантизме: у действия нет момента завершения — «анализировать» можно бесконечно, и статус «анализ на 70%» ничего не значит. У результата момент завершения есть: он либо предъявлен и принят, либо нет. Планирование от действий систематически даёт проекты, где 90% готовности держится месяцами. Именно из этого выросло продуктовое планирование в PRINCE2.

Пакет работ, словарь и коды

Пакет работ (work package) — элемент нижнего уровня, который дальше не декомпозируется на этом этапе планирования. У него обязательно один ответственный, проверяемый результат и оценка. Классический ориентир глубины — правило 8/80: трудоёмкость лежит между 8 и 80 часами. Мельче — накладные расходы на планирование и учёт превышают пользу от контроля; крупнее — слишком долго идёт без сигнала, между «начал» и «закончил» проходят недели неизвестности. Второй ориентир — правило отчётного периода: пакет не длиннее интервала между отчётами, иначе два подряд статуса «в работе» не сообщают ничего. Третий, самый практичный — правило оценимости: дробите, пока команда не сможет дать оценку, в которую сама верит; это признак, что элемент понят.

Словарь WBS — сопроводительный документ, где для каждого элемента описано, что именно входит, критерии приёмки, ответственный, оценка, предшественники и ресурсы. Без него WBS остаётся набором заголовков, и через месяц два человека понимают «1.4.2 Адаптер биллинга» по-разному. Коды WBS (1.3.2, 1.4.1) — не украшение, а идентификаторы, по которым сшивается остальное: бюджет распределяется по кодам, трудозатраты списываются на коды, требования трассируются на коды, отчётность агрегируется вверх по дереву.

Чем WBS отличается от графика, бэклога и PBS

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

WBS против PBS: обе декомпозируют результаты, но WBS включает всю работу проекта (управление, обучение, миграцию), а PBS — только сами продукты; формально PMI тоже требует deliverable-ориентированной WBS, но на практике она сползает в перечень активностей, а PBS этого не допускает конструктивно. WBS против историй — это не конкуренты, а разные оси: WBS режет горизонтально, обеспечивая полноту, история режется вертикально, тонким сквозным срезом через все слои ради обратной связи. Восемь приёмов декомпозиции и границы дробления — в отдельной главе.

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

4. Матрица прослеживаемости

Матрица прослеживаемости требований (requirements traceability matrix) связывает четыре вещи в цепочку: требование → элемент WBS → тест → критерий приёмки.

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

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

5. Базовый план и контроль изменений

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

Scope creep против gold plating

Gold plating опаснее: расползание объёма хотя бы даёт заказчику что-то, чего он хотел, а золочение тратит бюджет на то, чего никто не просил, и вдобавок увеличивает поверхность поддержки. Ловится одним вопросом на ревью плана: какое требование закрывает этот элемент работы?

Процесс запроса на изменение

Три места, где процесс обычно ломается.

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

CCB как единственная точка принятия решений. Change Control Board полезен там, где изменения крупные и редкие, и вреден там, где их много: заседающий раз в две недели комитет создаёт очередь с лид-таймом в две недели, а дальше появляется обходной путь «договорились в коридоре». Лечится не усилением комитета, а порогами полномочий: мелкое решает менеджер, среднее — спонсор, крупное — комитет; пороги пишутся в уставе.

У изменения нет видимой цены. Главное правило контроля изменений формулируется в одну строку:

Изменение принимается вместе с ответом на вопрос «что выпадает или что сдвигается». Не «нет», а «да, ценой вот этого».

Заказчик обычно не хочет сорвать проект — он просто не видит, что его просьба с чем-то конкурирует; как только альтернатива названа вслух, значительная часть запросов отзывается их же авторами. Развёрнутый разбор — с формой запроса, метрикой churn объёма и влиянием формы контракта на то, кто несёт риск, — в запуске и закрытии проекта.

6. План управления проектом

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

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

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

7. Лёгкий вариант: как это выглядит в проде

Полный комплект из раздела 6 оправдан на крупном контракте с внешним заказчиком и регуляторикой. Для внутренней команды из шести человек он вреден: время уйдёт на документы, которые никто не откроет. Работающий минимум выглядит так.

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

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

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

Итого: одна страница устава, один список исключений, один DoD, три числа порогов. Это не упрощение ради лени, а применение того же принципа, из которого выросли все документы: зафиксировать решение и адрес ответственности в форме, которую действительно читают.

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

Мини-итог

• Документ — это зафиксированное решение и адрес ответственности. Если после подписания его никто не читает, неверен формат, а не идея документа.
• Устав превращает намерение в проект: измеримые критерии успеха, один спонсор-подписант, явное «вне объёма», допущения с владельцами и способами проверки, пороги полномочий и критерии закрытия, включая досрочное.
• Содержание бывает продуктовым и проектным. Обучение, миграция, документация, передача в эксплуатацию — проектное содержание, которого нет в продуктовом; проекты, оценённые без него, промахиваются в одну сторону. И «вне объёма» ценнее «в объёме»: пока список исключений короче списка целей, устав недописан.
• WBS держится на двух правилах: 100% (сумма детей равна родителю, работы вне WBS не существует) и декомпозиция по результатам, а не по действиям. Нижний уровень — пакеты работ по правилу 8/80, с одним ответственным и проверяемым результатом. WBS — не график и не бэклог: она даёт полноту, график — последовательность, бэклог — скорость обратной связи.
• Матрица прослеживаемости отвечает на три вопроса: всё ли сделано, зачем мы это делаем и во что обойдётся изменение.
• Базовый план меняется только через контроль изменений, а одобрение изменения и обновление baseline — одно действие. Пороги полномочий работают лучше комитета, а у изменения всегда есть цена: «да, ценой вот этого».
• План не равен графику. График — одна его проекция; остальное — правила принятия решений, и именно их не хватает в первый кризис.

Источники

• PMBOK Guide, PMI — устав, описание содержания, план управления проектом, управление содержанием и интеграцией.
• PMI Practice Standard for Work Breakdown Structures — правило 100%, словарь WBS, уровни декомпозиции.
• PRINCE2 — продуктовое планирование, PBS, Product Description, Project Brief и PID.
• ISO 21502:2020 — практики управления содержанием, изменениями и приёмкой.
• ГОСТ Р 54869-2011 «Проектный менеджмент. Требования к управлению проектом» — требования к документированию целей, содержания и плана.
• PMI: Top five causes of scope creep — разбор причин расползания объёма.
• Google SRE Book: production readiness — передача в эксплуатацию как часть проектного содержания.

Что дальше

Устав, содержание и WBS отвечают на вопросы «зачем», «что» и «из чего». Остаётся вопрос, который задают первым, а отвечают на него хуже всего: сколько это займёт и сколько будет стоить.

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

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