О выходах из процесса думаем так: что мы делаем, зачем, и каков ожидаемый результат. Мы валидируем содержание для того, чтобы сохранить проект в рамках с точки зрения клиента, во время исполнения проекта, а не надеясь на одну финальную приемку в конце. Всегда лучше выявлять изменения и проблемы во время исполнения проекта, а не когда пора подписывать акты. Так клиент будет либо принимать работы, либо вносить изменения заранее. В любом случае, проектную документацию надо обновлять, либо отражая в ней сданные объемы, либо внося изменения. Так что, выходы:
- информация о состоянии исполнения работ
- принятые продукты
- запросы на изменение
- апдейты в реестр вынесенных уроков, матрицу требований, и документацию на требования
Помимо сбивающего с толку наименования, в Процессе валидации содержания есть и еще несколько хитрых аспектов.
- Валидацию можно делать как в конце фазы проекта, для получения формальной приемки продуктов, так и в промежутках, как часть процесса Контроля и мониторинга, для приемки промежуточных продуктов. Так что, содержание валидируется клиентом многократно в течение проекта. В change-driven проектах, это случается в конце каждой итерации, как часть приемки итерации клиентом
- Есть тонкая разница между Валидацией содержания, и Закрытием проекта или фазы. Валидация это приемка промежуточных продуктов, а Закрытие это финальное закрытие проекта или фазы в целом и списание их из актива
- Надо понимать, как процесс Валидации содержания связан с процессом Контроля качества:
Хотя Контроль качества обычно проводится первым, чтобы проверить продукты перед сдачей клиенту, оба процесса очень похожи, и подразумевают проверку качества работы. Разница - это фокус усилия, и кто делает проверку. В Контроле качества, отдел качества проверяет соответствие продукта спецификациям, и вообще их правильность. В Валидации содержания, клиент проверяет, и в хорошем случае принимает продукты.
Комментариев нет:
Отправить комментарий