Бизнес заказчик вынашивает идею нового программного продукта или автоматизации бизнес процессов месяцами. Образ светлого будущего рисуется в голове, перерисовывается, выплескивается в промежуточных презентациях для коллег и руководства. И вот настал звездный час — проект запускается. Главный документ — пользовательских требования или описанием каким заказчик видит конечный продукт или автоматизацию своих бизнес процессов — передается аналитику. Чего не хватает?
Обычно заказчики пропускают простые но очень важные пункты:
-
- Бизнес цели — в терминах бизнеса, для бизнеса. Корневая цель упирается в деньги.
[blockquote] Например: снизить операционные расходы на обслуживание клиентов в Контакт центре[/blockquote]
-
- Задачи, поставленные перед проектом разработки ИТ решения — что должно быть сделано. Задачи должны поддерживать озвученные цели.
[blockquote]Например: подключить IVR к системе управления задолженностью[/blockquote]
-
- Ограничения — что вы не готовы делать.
[blockquote]Например: На данном этапе определение приоритета звонка не выполняется[/blockquote]
-
- Предположения — что вы считаете само-собой разумеющееся или то что должно быть. Очень важно понимать на что другое вы опираетесь.
[blockquote]Например: ИТ обновит лицензии Cisco и установит необходимые TAPI драйвера[/blockquote]
Определив цели и задачи вам будет намного легче определять рамки проекта, проверять насколько соответствую требования исходным положения проекта. Все что вы определите как ограничения и предположения помогут аналитику намного лучше ориентироваться в рамках проекта. Кроме упрощения работы для аналитика, вы, как заказчи сможете значительно упростить обсуждение изменения рамок бюджета со своим руководством — как только вам скажут что ожидают новых функций потому что это подразумевалось — вам легко будет доказать что это изменения опираясь на заранее определенный контекст проекта.
