PMI PMP: Управление качеством и приемка — Руководство по подготовке

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

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

Планирование качества и План управления качеством

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

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

• Идентификатор требования
  • Источник: Документация с требованиями / бэклог
  • Цель: Фиксирует рамки проекта
• Критерии приемки
  • Источник: Разрабатываются с владельцем продукта / заказчиком
  • Цель: Определяют, что значит «готово»
• Идентификатор тест-кейса
  • Источник: План тестирования
  • Цель: Проверяет соответствие критериям
• Результат теста и подтверждение
  • Источник: Отчет о выполнении тестов
  • Цель: Доказывает соответствие
• Поставленная функциональность / сборка
  • Источник: Примечания к выпуску
  • Цель: Связывает с рамками проекта

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

Непрерывная валидация и раннее тестирование

Прогнозные графики, рассматривающие качество как контрольную точку между фазами, накапливают скрытый технический долг. Дефекты, допущенные на этапе проектирования, проявляются во время системного тестирования, когда их исправление экспоненциально дороже и часто вступает в конфликт с давлением сроков. Лекарство — непрерывная валидация: тестирование со сдвигом влево (shift-left testing), автоматизированная регрессия, ранняя интеграция подсистем и частые демонстрации заказчику или владельцу продукта.

В гибридных и адаптивных средах это реализуется через короткие итерации, производящие демонстрируемые инкременты, конвейеры непрерывной интеграции, блокирующие слияние веток при неудачных тестах, и определения готовности/завершения (definition of ready/done), включающие артефакты тестирования. Прогнозный проект может применять те же принципы, вводя этапы интеграции между фазовыми воротами, проводя тестирование на основе рисков для компонентов с высокой степенью неопределенности на ранних стадиях и требуя, чтобы поставки от подрядчиков сопровождались подтверждениями тестов, а не просто заверениями.

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

Определение готовности и приемочное тестирование

Определение готовности (Definition of Done, DoD) — это соглашение о том, что рабочий элемент действительно завершен, а не просто написан код или изготовлен компонент. Зрелое DoD включает: код/компонент прошел ревью, модульные тесты написаны и проходят, интеграционные тесты проходят, критерии приемки продемонстрированы владельцу продукта, документация обновлена, нефункциональные критерии (производительность, безопасность) проверены, где это применимо, и собраны необходимые нормативные подтверждения.

Когда запрос на изменение утверждается, приемочные тесты, связанные с этим изменением, должны быть включены в объем работ. Недостаточно обновить требования и код; соответствующие тест-кейсы должны быть добавлены или изменены, выполнены и отслежены. Комитеты по контролю изменений должны отклонять изменения, у которых отсутствует определенный подход к верификации. Именно так DoD предотвращает тихое ухудшение качества из-за разрастания рамок проекта.

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

Практическая задача: сценарий использования

Сценарий: Прия Менон управляет проектом «MedTrack-3» — инициативой стоимостью 8,4 млн долларов по созданию облачной платформы для учёта приёма лекарств для региональной сети больниц, включающей 14 объектов и около 3200 конечных пользователей из числа медперсонала. Разработка завершена на 70%, а приёмочное тестирование пользователями (UAT) начнётся через шесть недель. В ходе промежуточного аудита качества проекта руководитель отдела контроля качества (QA) сообщает, что для 38 из 214 функциональных требований нет связанных с ними тест-кейсов, а для нескольких нефункциональных требований, включая ведение журнала аудита в соответствии с HIPAA и целевое время загрузки экрана в 2 секунды, вообще не задокументированы критерии приёмки.

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

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

1. Заморозить внесение новых изменений в требования на две недели через официальное уведомление о контроле изменений, чтобы базовый уровень прослеживаемости мог стабилизироваться, пока команда навёрстывает упущенное.
2. Организовать рабочую встречу с владельцем продукта, профильным медицинским экспертом (SME), специалистом по нормативно-правовому соответствию и руководителем QA, чтобы сформулировать измеримые критерии приёмки для каждого из 38 требований, оставшихся без внимания, и для каждого нефункционального требования, используя формат «дано/когда/тогда» (given/when/then) с числовыми пороговыми значениями.
3. Поручить руководителю QA обновить матрицу прослеживаемости «требование — тест — результат», присвоив идентификатор хотя бы одного тест-кейса каждому требованию и пометив любое требование, для которого всё ещё отсутствуют подтверждения, как замечание аудита уровня Severity-1.
4. Пересмотреть базовый план тестирования: разделить UAT на два цикла — целевой «цикл устранения пробелов», охватывающий только что созданные тест-кейсы, с последующим полным регрессионным тестированием — и сообщить об изменённом плане руководящему комитету.
5. Эскалировать вопрос о ведении журнала аудита HIPAA специалисту по соответствию для получения письменного утверждения, поскольку соответствие нормативным требованиям не подлежит обсуждению и не может быть отменено менеджером проекта (PM) или спонсором.
6. Запланировать повторный аудит качества за две недели до UAT, чтобы подтвердить 100%-е покрытие прослеживаемости и устранение всех замечаний уровня Severity-1.

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

← Управление рисками и проблемами · Все домены · Управление закупками и контрактами →

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