Что нужно для начала проекта — цели и задачи, требования, бюджет, команда, … С запуском проекта при наличии важной для бизнеса проблемы и бюджета обычно проблем нет. Но вот всегда ли получается успешно выполнить проект? Нет. Со стороны исполнителей проекта часто звучит — мы им приносим релиз, а они его заворачивают. Мы им говорим — все готово, а они опять что-то придумывают, мы не понимаем что они от нас хотят. Чего же нам не хвататет для успешного завершения проекта при прочих равных условиях (качественная реализация в срок)? Критериев приемки.
[pullquote align=»right»]Критерии приемки – это критерии, в том числе, требования к исполнению и существенные условия, которые должны быть выполнены до приемки результатов поставки проекта [/pullquote]
Как только со стороны бизнеса слышат такие слова как «Критерии приемки» — сразу морщатся и говорят
- Это что-то из разряда тестирования
- Это должны в конце потом написать исполнители и показать нам
- Вы нам просто расскажите как будете тестировать или обеспечивать качество
Нет-нет. Этот вопрос к заказчику (возможно вместе с ИТ и под чутким руководством руководителя проекта со стороны заказчика). Именно заказчик должен определится с тем, как, когда, кто, на основании чего и при каком уровне качества примет продукт у исполнителя. Основные положения, которые вы можете включить в перечень критериев приемки могут быть следующие:
-
- Степень реализации функциональных требований — постарайтесь определить приемлемые рамки реализации (процент реализации) по приоритетам
[blockquote] Например: 100% требований с высоким приоритетом, 80% с нормальным и 30% с низким)[/blockquote]
-
- Ключевые не функциональные требования — какие атрибуты качества являются критически важными и как вы предполагаете их проверить при приемке системы
[blockquote] Например: Система должна генерировать не более 10`000 договоров в течении рабочего дня, в среднем 50 параметров и 20 страниц текста[/blockquote]
-
- Уровень качества — какое количество дефектов для каких групп требований допустимы — при всем нашем стремлении сделать идеальное решение высока вероятность того что баги будут. Но вот определить среди них приоритет для исправления стоит сразу — иначе вам будут исправлять сначала не очень важные для сдачи продукта баги вместо критичных
[blockquote] Например: Дефекты, которые связаны с требованиями с высоким приоритетом должны быть закрыты. [/blockquote]
-
- Перечень процессов или ключевых сценариев, которые должны быть автоматизированны в рамках данной системы и по которым вы будете определять возможность их выполнения с использованием полученного программного решения
[blockquote] Например: Сценарии, которые должны быть пройдены при приемке системы: Регистрация нового клиента, создание обращения, …[/blockquote]
-
- Целевые KPI для процессов или их изменение в связи с использованием системы
[blockquote] Например: сотрудник тратит на ввод данных о новом клиенте не более 2 минут[/blockquote]
-
- Ключевой проектный параметр — срок реализации — указывайте только тогда когда позже указанного срока решение вам уже не нужно вообше
[blockquote] Например: Решение должно быть сдано в промышленную эксплуатацию не позднее 15 февраля 2015 года.[/blockquote]
