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