Знаем как запускать, не знаем как приземлять

Что нужно для начала проекта – цели и задачи, требования, бюджет, команда, … С запуском проекта при наличии важной для бизнеса проблемы и бюджета обычно проблем нет. Но вот всегда ли получается успешно выполнить проект? Нет. Со стороны исполнителей проекта часто звучит – мы им приносим релиз, а они его заворачивают. Мы им говорим – все готово, а они опять что-то придумывают, мы не понимаем что они от нас хотят. Чего же нам не хвататет для успешного завершения проекта при прочих равных условиях (качественная реализация в срок)? Критериев приемки.

Критерии приемки – это критерии, в том числе, требования к исполнению и существенные условия, которые должны быть выполнены до приемки результатов поставки проекта

Как только со стороны бизнеса слышат такие слова как “Критерии приемки” – сразу морщатся и говорят

  • Это что-то из разряда тестирования
  • Это должны в конце потом написать исполнители и показать нам
  • Вы нам просто расскажите как будете тестировать или обеспечивать качество

Нет-нет. Этот вопрос к заказчику (возможно вместе с ИТ и под чутким руководством руководителя проекта со стороны заказчика). Именно заказчик должен определится с тем, как, когда, кто, на основании чего и при каком уровне качества примет продукт у исполнителя. Основные положения, которые вы можете включить в перечень критериев приемки могут быть следующие:

  • Степень реализации функциональных требований - постарайтесь определить приемлемые рамки реализации (процент реализации) по приоритетам
  • Например: 100% требований с высоким приоритетом, 80% с нормальным и 30% с низким)

  • Ключевые не функциональные требования – какие атрибуты качества являются критически важными и как вы предполагаете их проверить при приемке системы
  • Например: Система должна генерировать не более 10`000 договоров в течении рабочего дня, в среднем 50 параметров и 20 страниц текста

  • Уровень качества – какое количество дефектов для каких групп требований допустимы – при всем нашем стремлении сделать идеальное решение высока вероятность того что баги будут. Но вот определить среди них приоритет для исправления стоит сразу – иначе вам будут исправлять сначала не очень важные для сдачи продукта баги вместо критичных
  • Например: Дефекты, которые связаны с требованиями с высоким приоритетом должны быть закрыты.

  • Перечень процессов или ключевых сценариев, которые должны быть автоматизированны в рамках данной системы и по которым вы будете определять возможность их выполнения с использованием полученного программного решения
  • Например: Сценарии, которые должны быть пройдены при приемке системы: Регистрация нового клиента, создание обращения, …

  • Целевые KPI для процессов или их изменение в связи с использованием системы
  • Например: сотрудник тратит на ввод данных о новом клиенте не более 2 минут

  • Ключевой проектный параметр – срок реализации – указывайте только тогда когда позже указанного срока решение вам уже не нужно вообше
  • Например: Решение должно быть сдано в промышленную эксплуатацию не позднее 15 февраля 2015 года.