Ландшафт стандартов: ISO 21500/21502, IPMA ICB, P3.express, ГОСТ и модели зрелости

Две предыдущие главы разобрали два самых известных ответа на вопрос «как управлять проектами»: PMBOK как свод знаний и PRINCE2 как метод. Это два дерева, за которыми обычно не видно леса — а лес большой. В нём есть ISO, задающие нейтральный словарь; IPMA, стандартизирующая не процесс, а компетенции человека; открытые методы на десять страниц; российские ГОСТы, без которых не берут госконтракт; и модели зрелости, измеряющие не проект, а организацию целиком.

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

1. Зачем нужны стандарты

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

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

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

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

Стандарт, свод знаний и методология — три разные вещи

Слова используются как синонимы, и из-за этого спорят впустую.

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

2. Две оси карты

Поле проще всего разложить по двум измерениям: что именно стандартизуется и кто издаёт.

По первой оси документы делятся на четыре класса: компетенции человека (IPMA ICB, схемы сертификации), процесс работы над проектом (PMBOK, PRINCE2, ISO 21502, ГОСТ Р 54869), результат и его документация (ГОСТ 34, ГОСТ 19, ISO/IEC/IEEE 12207) и зрелость организации (CMMI, P3M3, OPM3).

По второй оси — издатели. ISO (комитет TC 258) даёт нейтральные документы без методологической позиции. PMI — американская профессиональная ассоциация: PMBOK и стандарты по программам и портфелям. AXELOS / PeopleCert — коммерческий владелец британского семейства PRINCE2 / MSP / MoP / ITIL / P3M3. IPMA — европейская федерация ассоциаций с компетентностным подходом. Национальные органы (Росстандарт, ANSI, BSI, DIN) издают свои стандарты, часто как перевод ISO.

Третья, неявная, но самая практичная ось — строгость: одни документы являются проверяемым требованием (ГОСТ в госконтракте, Automotive SPICE для автопоставщика), другие — рекомендацией, которую можно взять частями (PMBOK, ISO 21502). Смешивать их нельзя: за первые не выполнить — потерять контракт, за вторые — ничего.

3. Семейство ISO 21500

Международные стандарты по управлению проектами разрабатывает комитет ISO/TC 258. Их принципиальная особенность — методологическая нейтральность: ISO не говорит, водопад у вас или Scrum, не задаёт роли и не требует конкретных документов, а фиксирует, что должно быть учтено, оставляя «как» организации. Поэтому ISO — хороший общий знаменатель, когда в одном проекте встречаются подрядчик на PRINCE2 и заказчик на PMBOK.

Важная деталь истории: ISO 21500:2012 была руководством по управлению проектом и напоминала PMBOK по структуре (те же группы процессов). В 2020–2021 годах серию перестроили: руководство переехало в 21502, а 21500 стала головным документом про контекст и концепции. Ссылка «ISO 21500 — руководство по управлению проектом» относится к редакции 2012 года.

Как ISO соотносится с PMBOK. Изначально 21500:2012 создавалась при участии PMI и была почти его калькой. Сегодняшняя 21502 ближе к «общему знаменателю практик»: короче PMBOK (около 50 страниц против нескольких сотен), без инструментов и техник, в стиле «организация должна обеспечить…». Проще всего думать так: PMBOK учит, ISO проверяет, PRINCE2 организует.

Отдельно стоит ISO/IEC/IEEE 12207:2017 — стандарт на процессы жизненного цикла ПО: не про управление проектами, а про то, какие процессы вообще существуют в создании софта (соглашения, организационное обеспечение, техническое управление, технические процессы). Парный ему ISO/IEC/IEEE 15288 описывает жизненный цикл систем. В ИТ 12207 всплывает в требованиях крупных заказчиков и как основа процессных аудитов.

4. IPMA ICB 4.0: стандартизуют человека, а не процесс

IPMA (International Project Management Association) — федерация национальных ассоциаций, и её подход принципиально отличается от всего остального в этой главе. IPMA стандартизует не процесс и не документы, а компетенции человека.

Логика по-своему убедительная: процесс можно описать как угодно подробно, но исполнять его будет человек, и результат определится тем, что он умеет. Поэтому ICB (Individual Competence Baseline) описывает 28 элементов компетенций в трёх областях — «глаз компетентности»:

• Perspective (контекст, 5 элементов) — стратегия, руководство и структуры, соответствие стандартам, культура и ценности, власть и интересы: как проект встроен в организацию и внешнюю среду.
• People (люди, 10 элементов) — саморефлексия, личная целостность, коммуникация, отношения и вовлечённость, лидерство, командная работа, конфликты и кризисы, находчивость, переговоры, ориентация на результат. Ровно та область, которую молчаливо обходит PRINCE2.
• Practice (практика, 13 элементов) — замысел, требования и цели, содержание, время, организация и информация, качество, финансы, ресурсы, закупки, план и контроль, риск, стейкхолдеры, изменения и трансформация.

Сертификация четырёхуровневая и, в отличие от экзаменационных схем, оценивает подтверждённый опыт управления, а не знание книги:

Оценка на уровнях A–C включает разбор реального проекта кандидата и интервью с асессорами — процедура дороже и длиннее теста; в России IPMA представлена через национальную ассоциацию и её систему сертификации.

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

5. P3.express: минимализм как позиция

P3.express — открытый бесплатный метод управления проектами, созданный Надером Хоррами Раадом и сообществом практиков. Его манифест — противоположность всему, что описано выше: не «опишем всё, что бывает», а «оставим минимум, без которого не работает».

Устройство: 33 активности в 7 группах — инициация проекта (A), ежемесячная инициация (B), еженедельное управление (C), ежедневное управление (D), ежемесячное закрытие (E), закрытие проекта (F), послепроектная работа (G). Основной такт — месяц: в начале планируем, каждую неделю проверяем прогресс и риски, в конце закрываем цикл, оцениваем удовлетворённость и фиксируем уроки. Каждая активность описана на одной странице (зачем, что делать, типичные ошибки), всё руководство читается за вечер и не требует ни сертификации, ни консультантов, ни лицензии; для микропроектов на 1–7 человек есть ещё более короткая редакция micro.P3.express.

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

6. Российский контур: ГОСТы

В России действуют собственные национальные стандарты по управлению проектами, принятые в 2011 году и построенные на выходной модели: они описывают требования к результату процесса, а не к способу его выполнения.

Формулировки ГОСТ Р 54869 устроены характерно: «должны быть определены и документированы…», «должен быть разработан план…». Проверяется наличие и содержание выходов, а не то, каким образом вы их получили. Это делает его совместимым почти с любым подходом — при желании ГОСТ Р 54869 закрывается и Scrum-командой, если она фиксирует нужные артефакты.

Что требуют в госконтрактах. Ссылка на ГОСТ Р 54869 встречается в конкурсной документации как подтверждение управляемости подрядчика. Гораздо чаще и болезненнее требуют стандарты на документацию. ГОСТ 34 (комплекс стандартов на автоматизированные системы) задаёт стадии и этапы создания АС (34.601-90), состав технического задания (34.602-89) и требования к содержанию документов (РД 50-34.698-90) — это источник ТЗ, пояснительных записок, программ и методик испытаний, ведомостей и актов, которые в госпроектах составляют половину трудозатрат. ГОСТ 19 (ЕСПД, Единая система программной документации) описывает техническое задание (19.201-78), описание программы (19.402-78), руководство системного программиста (19.503-79) и прочее — стандарты 1970-х, применяемые буквально до сих пор.

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

7. Портфель, программа, проект — и PMO

Проекты не существуют поодиночке. Над ними надстроены два уровня, у каждого свой вопрос, свои метрики и свои стандарты.

Проект — временное усилие ради уникального результата; вопрос уровня «уложимся ли в срок, бюджет и качество», стандарты — PMBOK, PRINCE2, ISO 21502, ГОСТ Р 54869. Программа — группа связанных проектов, управляемых вместе ради эффекта, недостижимого по отдельности; вопрос уровня — складываются ли результаты в обещанную выгоду, и ключевое отличие от проекта в том, что программа управляет не поставкой, а реализацией выгод, и живёт дольше входящих в неё проектов (MSP, ISO 21503, PMI Standard for Program Management). Портфель — все инициативы организации как инвестиционный набор; вопрос уровня — делаем ли мы правильные вещи и в правильной пропорции, и управления исполнением здесь нет вообще, только отбор, приоритизация, балансировка риска и прекращение (MoP, ISO 21504).

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

PMO: три типа и две болезни

Project Management Office — организационная единица, обслуживающая проектную деятельность. PMBOK различает три типа:

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

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

8. Модели зрелости

Модель зрелости измеряет не проект, а способность организации получать предсказуемый результат повторно; идея пришла из работ Уотса Хамфри в SEI (Институт программной инженерии Университета Карнеги — Меллона) в конце 1980-х. Самая известная — CMMI (Capability Maturity Model Integration, сейчас принадлежит ISACA), пять уровней:

Соседи по классу. OPM3 (Organizational Project Management Maturity Model) — модель PMI, оценивавшая зрелость через набор best practices; исторически важна, сейчас практически не развивается. P3M3 от AXELOS — те же пять уровней, но оценка ведётся отдельно по трём моделям (портфель, программа, проект) и семи перспективам (управление, контроль, выгоды, финансы, стейкхолдеры, риск, ресурсы); главное достоинство — можно быть зрелым в одном и незрелым в другом, что ближе к реальности. SPICE / ISO/IEC 15504, развёрнутый ныне в серию ISO/IEC 33000, задаёт не модель, а способ оценки процессов по шкале способности; его отраслевая версия Automotive SPICE обязательна для автопоставщиков.

Честно о том, что измеряет зрелость

Первое и главное: зрелость коррелирует с предсказуемостью, а не со скоростью. Организация уровня 3 по CMMI попадает в срок чаще, чем организация уровня 1, но почти всегда медленнее в единицах фактической поставки: предсказуемость покупается буферами, согласованиями и документированием. Осмысленный размен там, где цена ошибки высока (авионика, медтехника, биллинг), и разорительный там, где выигрывает скорость обучения.

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

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

Практический синтез: используйте модель зрелости как диагностику, а не как цель. Пройти оценку P3M3 и увидеть, что управление выгодами на уровне 1, а контроль на уровне 3, — полезно: это показывает, куда вкладываться. Поставить цель «достичь третьего уровня к концу года» — почти гарантированный путь к бумажному процессу.

9. История поля

Видна общая траектория: от подробного описания процессов (1990-е — 2000-е) к более коротким документам про принципы, контекст и адаптацию (2020-е). Причина простая: подробные предписания плохо переносятся между контекстами, а попытка описать все случаи даёт объём, который никто не читает.

10. Как выбирать

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

Три правила, стоящие за этим деревом. Внешнее требование не обсуждается, но локализуется: если контракт требует ГОСТ 34, вы его выполняете — но это не значит, что внутренняя работа команды должна идти по ГОСТ 34; здоровая конструкция — команда работает как ей эффективно, а соответствие обеспечивается отдельным слоем с посчитанной стоимостью. Берите самое лёгкое, что закрывает боль: правильный ответ почти никогда не выглядит как «внедрим весь стандарт», он выглядит как «возьмём допуски из PRINCE2, оценку по аналогии из PMBOK, месячный такт из P3.express». Стандарт не лечит отсутствие обратной связи: если правду о проекте узнают на восьмом месяце, это изменит сокращение цикла, а не регламент; стандарт полезен, когда проблема в согласованности и памяти, а не в скорости обучения.

11. Сводная таблица

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

Мини-итог

• Стандарты решают организационные задачи, а не проектные: общий язык, допуск к контрактам, аудит, перенос людей и разумные умолчания. Успешность проекта они не гарантируют.
• Свод знаний, стандарт, метод и модель зрелости — разные жанры. Проверка одна: что будет, если не выполнить? У свода знаний — ничего, у метода — не заработает процесс, у стандарта — не пройдёте аудит.
• ISO — нейтральный общий знаменатель (21500 — контекст и словарь, 21502 — руководство, 21503/21504/21505 — программы, портфели и governance, 12207 — процессы жизненного цикла ПО); IPMA стандартизует человека (28 компетенций, уровни A–D с проверкой опыта); P3.express — правильная первая покупка для малой компании.
• ГОСТы важны не столько управленческие, сколько документационные: ГОСТ 34 и ГОСТ 19 создают трудоёмкость, сравнимую с разработкой, и её закладывают в оценку явно.
• Портфель, программа и проект — три разных вопроса и три разные метрики. Инструменты одного уровня на другом не работают; PMO полезен памятью и видимостью, вреден отчётностью без решений.
• Зрелость коррелирует с предсказуемостью, а не со скоростью, и легко вырождается в карго-культ. Используйте как диагностику; результаты поставки честнее измеряет DORA.

Источники

• ISO 21500:2021 — Context and concepts и ISO 21502:2020 — Guidance on project management; актуальный состав серии — у ISO/TC 258.
• ISO/IEC/IEEE 12207:2017 — Software life cycle processes и ISO/IEC/IEEE 15288.
• IPMA Individual Competence Baseline (ICB 4.0) — 28 элементов компетенций, уровни A–D.
• P3.express — открытый минималистичный метод; micro.P3.express для микропроектов.
• Стандарты PMI, в том числе Standard for Program Management.
• PRINCE2, MSP, MoP — британское семейство; CMMI Institute — модель зрелости.
• ГОСТ Р 54869/54870/54871-2011; ГОСТ 34.601-90, ГОСТ 34.602-89, РД 50-34.698-90; комплекс ГОСТ 19 (ЕСПД) — тексты в Федеральном информационном фонде стандартов.
• DORA / DevOps Research and Assessment — измерение результатов вместо описанности процессов.

Что дальше

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

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

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