1. Планирование согласно плану управления качеством
Все заинтересованные стороны должны иметь пути взаимодействия
Каждая сторона, участвующая в проекте, должна иметь определённые каналы и механизмы коммуникации. Это обеспечивает своевременный обмен информацией, согласование решений и прозрачность процессов.
Пример:
В проекте по внедрению корпоративной системы IT необходимо организовать каналы связи между заказчиком, командой разработки, тестировщиками и службой поддержки.
Создаётся матрица коммуникаций:
- заказчик → еженедельный отчёт;
- команда разработки → ежедневные стендапы;
- тестировщики → отчёты о дефектах в системе отслеживания задач.
Все мероприятия по взаимодействию должны быть перенесены в план‑график
Все виды коммуникаций — совещания, согласования, отчётность, проверки — должны быть включены в общий план‑график проекта. Это позволяет учитывать их влияние на сроки и ресурсы.
Пример:
Если проект предусматривает еженедельные встречи по статусу, они вносятся в план как отдельные задачи:
- «Статус‑встреча — каждая пятница, 10:00».
Это позволяет учитывать их длительность и людей, участвующих во встрече.
Для каждого мероприятия должны быть определены тип, шаблоны и даты
Каждое взаимодействие оформляется как формальная задача с чётким типом (например, встреча, обсуждение, проверка), установленными шаблонами документов и конкретными временными рамками.
Пример:
- Тип мероприятия: «Встреча по контролю качества».
- Шаблон: стандартная форма протокола.
- Дата: каждый вторник, 15:00.
Такой подход упрощает подготовку и обеспечивает единый формат отчётности.
Выполнение работ должно подтверждаться документально
Все выполненные этапы и мероприятия по качеству должны фиксироваться соответствующими документами. Это создаёт доказательную базу выполнения задач и обеспечивает контроль качества.
Пример:
После проверки качества создаётся акт приёмки этапа или протокол проверки.
Если тестировщик завершил тест‑план, он загружает документ в систему и отмечает задачу в MS Project как выполненную.
Все заинтересованные стороны анализируются на наличие требований качества
Для каждого участника проекта проводится анализ его ожиданий и требований к качеству, чтобы обеспечить их отражение в документации и при планировании.
Пример:
- заказчик требует стабильности и производительности;
- команда разработки — технической ясности требований;
- отдел эксплуатации — лёгкости сопровождения.
Все эти требования фиксируются и учитываются в план‑графике.
Все требования качества заинтересованных сторон учитываются
Требования всех внешних и внутренних участников должны быть включены в план‑график и учтены при формировании критериев качества продукта.
Пример:
Если заказчик настаивает на тестировании нагрузки, добавляются задачи:
- «Нагрузочное тестирование — 40 часов»,
- «Анализ результатов — 16 часов».
Все требования качества компании учитываются
Корпоративные стандарты, политики, процессы и нормы организации также обязаны быть включены в планирование и критерии качества.
Пример:
Компания может требовать обязательной проверки безопасности.
В план включаются задачи:
- «Аудит уязвимостей»,
- «Корректировка кода по результатам аудита».
Все критерии оценки качества учитываются при описании продукта
Описание продукта должно содержать полный набор критериев, по которым будет оцениваться его соответствие требованиям качества.
Пример:
- функциональность подтверждается тест‑кейсами;
- производительность — измерениями в JMeter;
- соответствие требованиям — трассировочной матрицей.
Эти критерии фиксируются в документации и проверяются в финальных этапах.
Все требования качества включают мероприятия по контролю
Каждое требование должно сопровождаться конкретными процедурами контроля, позволяющими убедиться в его выполнении в процессе проекта.
Пример:
Если есть требование «интерфейс должен работать без ошибок», планируется:
- «UI‑тестирование»,
- «Юзабилити‑сессия с пользователями»,
- «Ретест дефектов».
2. Планирование согласно плану управления рисками
Все группы рисков должны быть проанализированы при идентификации
На этапе анализа рисков необходимо рассмотреть все возможные их группы: технические, организационные, внешние, ресурсные и другие, чтобы обеспечить полноту оценки проекта.
Пример:
Группы рисков: технические, финансовые, организационные, кадровые.
Для каждой проводится анализ:
- Технические — риск несовместимости библиотек.
- Кадровые — риск потери ключевого специалиста.
Все заинтересованные стороны анализируются при идентификации рисков
Каждая сторона проекта оценивается с точки зрения рисков, которые могут быть вызваны её действиями, ограничениями или вовлечённостью.
Пример:
- заказчик: риск задержки обратной связи;
- подрядчик: риск нехватки экспертов;
- пользователи: риск сопротивления изменениям.
Каждый риск должен иметь мероприятия по минимизации последствий
Для каждого риска должны быть определены шаги, направленные на уменьшение ущерба в случае его наступления.
Пример:
Риск: задержка данных от заказчика.
Мероприятие: включить буфер в план + обеспечить резервный источник данных.
Каждый риск должен иметь мероприятия по снижению вероятности наступления
Проект должен содержать меры профилактики, уменьшающие вероятность возникновения идентифицированных рисков.
Пример:
Риск: ошибки из‑за недостаточной детализации требований.
Мероприятие: дополнительные рабочие сессии по уточнению требований.
Каждый риск должен иметь мероприятия по снижению влияния
Даже если риск наступает, его влияние на проект должно быть уменьшено заранее разработанными действиями, включёнными в план‑график.
Пример:
Риск: падение производительности системы.
Мероприятие: регулярное нагрузочное тестирование по спринтам.
Заключение
Эти рекомендации помогают создать предсказуемый, прозрачный и управляемый план‑график, который учитывает как качество результата, так и риски реализации. Примеры демонстрируют, как каждый пункт можно применить на практике, превращая общие требования в конкретные задачи.
