PMI PMP: Закрытие проекта, передача знаний и извлеченные уроки — Руководство по подготовке

By Laurynas Brazys · 22 July 2026 · #pmi #pmp #certification #exam-prep #study-guide

Часть PMP — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов PMI, или пройдите тесты на время на ExamRoll.io.

Суть закрытия проекта

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

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

Формальное принятие и закрытие контрактов

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

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

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

Закрытие реестров, журналов и задач

Каждый артефакт, использовавшийся для отслеживания неопределенности и открытых вопросов во время исполнения, должен быть формально закрыт. Сюда входят:

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

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

Архивирование в СУИП и политика хранения

Архивирование должно соответствовать организационной политике хранения, за которую обычно отвечает ОУП, отдел делопроизводства или юридический отдел. Обязанность руководителя проекта — следовать этой политике, а не изобретать собственный подход. Правила хранения определяют, где хранятся артефакты (СУИП — система управления информацией проекта, система управления документами, репозиторий записей), как долго они хранятся, кто может к ним обращаться и как они индексируются для поиска.

Распространенная ловушка — рассматривать архивирование как личный экспорт: руководитель проекта упаковывает папку в zip-архив, кладет на общий диск и считает дело сделанным. Это не работает, потому что такой архив не переживет смену персонала, не индексируется для поиска и может нарушать классификацию конфиденциальности. Правильное архивирование означает размещение артефактов в утвержденной СУИП или системе записей, применение необходимых метаданных (ID проекта, спонсор, даты, классификация) и подтверждение размещения у хранителя записей.

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

Извлеченные уроки как вклад в АПО

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

Документация должна выходить за рамки простого «что получилось хорошо / что пошло не так». Эффективные записи фиксируют ситуацию, принятое решение или действие, результат и рекомендацию, сформулированную достаточно обобщенно, чтобы ее можно было применить к будущим проектам. Рекомендации, предлагающие изменения в шаблонах, чек-листах, моделях оценки или процессах, должны быть официально представлены в ОУП как предлагаемые обновления АПО. Именно эта подача превращает локальный опыт проекта в организационное улучшение. Без этого каждый будущий проект будет извлекать те же уроки за ту же цену.

Готовность к переходу и передача в эксплуатацию

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

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

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

Планирование поддержки после сдачи проекта

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

Почему распространенные упрощения не работают

Поспешное закрытие проекта ради соблюдения сроков спонсора приводит к потере знаний, которые можно было бы использовать повторно, и подвергает организацию риску выявления нарушений комплаенса; срочность, на которой настаивает спонсор, не отменяет нормативных или договорных обязательств. Отказ от консультаций с PMO (офисом управления проектами) по вопросам хранения данных ведет к их преждевременному удалению или незаконному хранению — и то, и другое создает юридическую ответственность. Если оставить риски и проблемы «открытыми» в завершенном проекте, это заблокирует будущую отчетность и скроет повторяющиеся закономерности от аналитики. Роспуск команды без передачи дел превращает накопленные в организации знания и навыки в зависимость от конкретных сотрудников и гарантирует, что следующий инцидент будут устранять люди, которые никогда раньше не видели эту систему. Каждое такое упрощение — это обмен небольшой, видимой экономии сейчас на большие, скрытые затраты в будущем. Именно такой размен и призвана предотвратить дисциплинированная процедура закрытия проекта.

Практическая задача: Пример из практики

Сценарий: Проект «Платформа Meridian Payments» — инициатива стоимостью 4,2 млн долларов и продолжительностью 18 месяцев по замене устаревшей системы денежных переводов для среднего банка — завершил пользовательское приемочное тестирование, все критические дефекты устранены. Спонсор, испытывая давление со стороны финансового директора (CFO) с требованием высвободить бюджет для конкурирующей инициативы, написал менеджеру проекта, Прие, электронное письмо с указанием «закругляться на этой неделе — система работает, команда нужна в другом месте». Два контракта с поставщиками остаются открытыми, отдел эксплуатации не подписал акт передачи ранбуков, а семинар по извлеченным урокам не запланирован.

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

Рекомендуемый подход:

1. Письменно подтвердить получение указания спонсора о срочности и предложить сжатый 10-дневный план закрытия проекта, в котором перечислены обязательные мероприятия, их ответственные и риски пропуска каждого из них. Затем получить письменное одобрение этого плана от спонсора.
2. Получить официальное письменное подтверждение приемки от владельца продукта и руководителя отдела эксплуатации, проверив каждый результат проекта на соответствие задокументированным критериям приемки и собрав подписи на акте приемки, который будет храниться в репозитории PMO.
3. Закрыть два контракта с поставщиками, подтвердив выполнение всех описаний работ (SOW), обработав окончательные счета, высвободив гарантийные удержания или гарантии исполнения обязательств и выпустив письма о закрытии закупок в соответствии с условиями контрактов.
4. В течение первой недели провести 90-минутный семинар по извлеченным урокам с основной командой и ключевыми заинтересованными сторонами, сосредоточившись на причинах отклонений по стоимости, рисках интеграции и работе поставщиков. Опубликовать результаты в базе знаний организационных активов процесса (OPA).
5. Завершить передачу в эксплуатацию, проверив ранбук, подтвердив обучение персонала поддержки, передав исходный код и учетные данные, а также получив подпись менеджера по эксплуатации о готовности.
6. Заархивировать артефакты проекта в соответствии с политикой 7-летнего хранения данных банка, официально распустить членов команды, предоставив обратную связь об их работе функциональным руководителям, и выпустить отчет о закрытии проекта для спонсора и управляющего комитета.

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

← Управление · Все домены

Отработать эти вопросы → · Тесты на время на ExamRoll.io →