Требования с точки зрения клиента

Герхард, старший менеджер компании Contoso Pharmaceuticals, встретился с Синтией, новым сотрудником отдела по разработке информационных систем. «Нам нужно создать новую систему контроля химических препаратов, — начал Герхард. — Она должна обеспечить контроль за всеми химическими контейнерами на складе и в лабораториях. Возможно, благодаря этому химики смогут отказаться от заказа новых

контейнеров. Система сэкономит компании уйму денег. Кроме того, отделу контроля безопасности и здравоохранения необходимо отчитываться перед правительством». "Понимаю, почему этот проект важен, Герхард, —сказала Синтия. — Но прежде чем я набросаю график разработки проекта, нам потребуется собрать некоторые требования к системе". Герхрад удивился: «Что вы имеете в виду? Я только что перечислил вам требования».

«На самом деле вы описали концепцию и некоторые бизнес-цели проекта, — объяснила Синтия. — Бизнес-требования такого высокого уровня не дают достаточно информации, чтобы точно определить, какую систему создавать и сколько времени на это может потребоваться. Я хочу, чтобы аналитик поработал с несколькими пользователями и понял, что они ожидают от системы. Затем мы определим, какая функциональность удовлетворит одновременно ваши бизнес-цели и потребности пользователей. Возможно, вам даже не потребуется новая система, чтобы сэкономить средства».

Герахрд никогда раньше не сталкивался с подобной реакцией специалиста отдела информационных систем. "Химики — занятые люди, — запротестовал он. — Вряд ли у них найдется время объяснить все подробности до того, как вы начнете писать программу. Не могут ли ваши люди сами определить конечную цель?»

Синтия попыталась объяснить, почему необходимо выслушать именно пользователей новой системы. «Если мы сами станем угадывать ожидания пользователей, ничего хорошего не выйдет. Мы — разработчики ПО, а не химики. Нам на самом деле неизвестно, чего именно хотят специалисты от системы контроля препаратов. Я по собственному опыту знаю, что, если не

потратить время на изучение проблемы до начала программирования, результаты окажутся неудовлетворительными».

«У нас нет времени на это, — настаивал Герхард. — Я описал вам мои требования. Теперь, пожалуйста, просто создайте систему. Сообщайте мне о ходе работы».

Такие диалоги регулярно возникают при разработке ПО. Клиенты, которым требуется новая информационная система, зачастую не понимают, насколько важно непосредственно опросить будущих реальных пользователей. Специалисты по маркетингу, разработавшие концепцию нового замечательного продукта, считают, что адекватно представляют интересы предполагаемых покупателей. Тем не менее мнение непосредственных покупателей ПО неоценимо, и заменить его чем-либо иным нельзя. Согласно некоторым современным концепциям разработки ПО, например концепции экстремального программирования (Extreme Programming), клиент, даже если он постоянно занят собственным бизнесом, должен тесно взаимодействовать с командой разработчиков. Как говорится в одной книге по экстремальному программированию, «успех проекта зависит от согласованных действий клиента и программистов» (Jeffries, Anderson и Hendrickson, 2001). Одна из проблем при формировании требований в том, что люди путают разные уровни требований: бизнес-уровень, уровень пользователей и функциональный. Герхард перечислил несколько преимуществ, которые, по его мнению, получит компания Contoso, внедрив новую систему контроля химикатов. Однако он не знает требований пользователей, поскольку не работаете этой системой. Пользователе, в свою очередь, могут описать необходимые им возможности системы, но не способны грамотно перечислить функции, которые должны реализовать разработчики для предоставления им таких возможностей.

В данной лекции речь пойдет о взаимодействии клиента и разработчика

жизненно важной для успеха проекта по разработке ПО. Я предлагаю вашему вниманию «Билль о правах клиента ПО» и соответствующий «Билль об обязанностях клиента ПО» при формировании требований. Таким образом, я, надеюсь, прояснить роль клиента, а конкретнее

пользователя, в процессе создания требований.

Страх отказа

Побывав в отделе информационных систем одной фирмы и услышал печальную историю. Разработчики только что создали новую внутрикорпоративную систему. Пользователи с самого начала не хотели общаться с разработчиками, и когда те с гордостью представили новую систему, пользователи отвергли ее как совершенно неприемлемую. Разработчики, приложившие немало усилий, чтобы удовлетворить потребности пользователей, как они их понимали, испытали настоящий шок. И что же они предприняли? Да просто все исправили. При несоответствии требований систему всегда можно подправить, однако это значительно дороже, чем если бы пользователи описали свои потребности с самого начала.

Безусловно, разработчикам пришлось потратить на доводку проекта больше времени и, значит, отложить следующий проект. Это абсолютно проигрышная ситуация. Разработчики растеряны и расстроены, клиенты разочарованы, так как система не оправдала их ожиданий, а компания потеряла кучу денег. Когда клиенты с самого

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

Дата добавления: 2014-01-14