Герхард, старший менеджер компании Contoso Pharmaceuticals, встретился с Синтией, новым сотрудником отдела по разработке информационных систем. «Нам нужно создать новую систему контроля химических препаратов, — начал Герхард. — Она должна обеспечить контроль за всеми химическими контейнерами на складе и. лабораториях. Возможно, благодаря этому химики смогут отказаться от заказа новых контейнеров. Система сэкономит компании уйму денег. Кроме того, отделу контроля безопасности и здравоохранения необходимо отчитываться перед правительством». "Понимаю, почему этот проект важен, Герхард, — сказала Синтия. — Но прежде чем я набросаю график разработки проекта, нам потребуется собрать некоторые требования к системе".
Герхрад удивился: «Что вы имеете в виду? Я только что перечислил вам требования».
«На самом деле вы описали концепцию и некоторые бизнес-цели проекта, — объяснила Синтия. — Бизнес-требования такого высокого уровня не дают достаточно информации, чтобы точно определить, какую систему создавать и сколько времени на это может потребоваться. Я за то, чтобы аналитик поработал с несколькими пользователями и понял, что они ожидают от системы. Затем мы определим, какая функциональность удовлетворит одновременно ваши бизнес-цели и потребности пользователей. Возможно, вам даже не потребуется новая система, чтобы сэкономить средства».
Герахрд никогда раньше не сталкивался с подобной реакцией специалиста отдела информационных систем. «Химики – занятые люди, — запротестовал он. — Вряд ли у них найдется время объяснить все подробности до того, как вы начнете писать программу. Не могут ли ваши люди сами определить конечную цель?»
Синтия попыталась объяснить, почему необходимо выслушать именно пользователей новой системы. «Если мы сами станем угадывать ожидания пользователей, ничего хорошего не выйдет. Мы — разработчики ПО, а не химики. Нам на самом деле неизвестно, чего именно хотят специалисты от системы контроля препаратов. Я по собственному опыту знаю, что, если не потратить время на изучение проблемы до начала программирования, результаты окажутся неудовлетворительными». «У нас нет времени на это, — настаивал Герхард. — Я описан вам мои требования. Теперь, пожалуйста, просто создайте систему. Сообщайте мне о ходе работы».
Такие диалоги регулярно возникают при разработке ПО. Клиенты, которым требуется новая информационная система, зачастую не понимают, насколько важно непосредственно опросить будущих реальных пользователей. Специалисты по маркетингу разработавшие концепцию нового замечательного продукта, считают, что адекватно представляют интересы предполагаемых покупателей. Тем не менее, мнение непосредственных покупателей ПО неоценимо, и заменить его чем-либо иным нельзя. Согласно некоторым современным концепциям разработки ПО, например концепции экстремального программирования (Extreme Programming), клиент, даже если он постоянно занят собственным бизнесом, должен тесно взаимодействовать с командой разработчиков. Как говорится в одной книге по экстремальному программированию, «успех проекта зависит от согласованных действий клиента и программистов» (Jeffries, Anderson и Hendrickson, 2001)
Одна из проблем при формировании требований к ПО состоит в том, что люди путают разные уровни требований: бизнес-уровень, уровень пользователей и функциональный. Герхард перечислил несколько преимуществ, которые, по его мнению, получит компания Contoso, внедрив новую систему контроля химикатов. Однако он не знает требований пользователей, поскольку не работает с этой системой. Пользователи, в свою очередь, могут описать необходимые им возможности системы, но не способны грамотно перечислить функции, которые должны реализовать разработчики для предоставления им таких возможностей.
В этой главе речь пойдет о взаимодействии клиента и разработчика, как о жизненно важной составляющей для успеха проекта по разработке ПО. Я предлагаю вашему вниманию «Билль о правах клиента ПО» и соответствующий «Билль об обязанностях клиента ПО» при формировании требований. Таким образом, я надеюсь прояснить роль клиента, а конкретнее, пользователя, в процессе создания требований,
| Страх отказа Недавно я побывал в отделе информационных систем одной фирмы и услышал печальную историю. Разработчики только что создали новую внутрикорпоративную систему. Пользователи с самого начала не хотели общаться с разработчиками, и когда те с гордостью представили новую систему, пользователи отвергли ее как совершенно неприемлемую. Разработчики, приложившие немало усилий, чтобы удовлетворить потребности пользователей, как они их понимали, испытали настоящий шок. И что же они предприняли? Да просто все исправили. При несоответствии требований систему всегда можно подправить, однако это значительно дороже, чем если бы пользователи описали свои потребности с самого начала. Безусловно, разработчикам пришлось потратить на доводку проекта больше времени и, значит, отложить следующий проект. Это абсолютно проигрышная ситуация. Разработчики растеряны и расстроены, клиенты разочарованы, так как система не оправдала их ожиданий, а компания потеряла кучу денег. Если бы клиенты с самого начала плотно и постоянно были бы вовлечены в разработку системы, такого неудачного, но, к сожалению, нередкого итога удалось бы избежать. |
Кто же клиент?
В широком смысле, клиент — это человек или организация, получающая от продукта прямую или косвенную выгоду. Клиентами ПО можно считать заинтересованных в проекте лиц, требующих, оплачивающих, выбирающих, определяющих, использующих и получающих программный продукт. Как говорилось в главе 1, прочие заинтересованные лица — аналитики требований, разработчики, специалисты по тестированию, технические писатели, менеджеры проектов, а также персонал службы поддержки, юридической службы и маркетинговой службы.
Менеджер Герхард — это клиент, оплачивающий, или спонсирующий, проект по разработке ПО. Клиенты уровня Герхарда определяют бизнес-требования к системе. Они формулируют высокоуровневую концепцию продукта и бизнес-обоснование для его развертывания.
Как вы узнаете из главы 5, бизнес-требования описывают бизнес-цели, которых хочет достичь клиент, компания или другие посредники. Бизнес-требования формируют каркас всего проекта. Любые другие функции и требования к продукту должны удовлетворять бизнес-требования. Тем не менее бизнес-требования не предоставляют разработчикам достаточно информации для создания продукта.
Следующий уровень требований — требования пользователей: их определяют те, кто прямо или косвенно взаимодействуют с продуктом, то есть конечные пользователи. Они способны описать требуемую функциональность, а также ожидаемые качественные характеристики продукта.
Клиенты, предоставляющие бизнес-требования, иногда пытаются говорить от имени пользователей, но обычно они слишком далеки от реальной работы, чтобы точно описать их нужды. В случае с информационными системами или разработкой нестандартного приложения бизнес-требования должен определять тот, кто платит, а требования пользователей — те, кто будет стучать по клавишам и непосредственно работать с продуктом. Всем участникам проекта рекомендуется проверить согласованность бизнес-требований и требований пользователей.
К сожалению, клиенты иногда не хотят найти время, чтобы поработать с аналитиком требований, собирающим, анализирующим и документирующим требования. Иногда клиенты полагают, что аналитики или разработчики собственными силами определят, что именно необходимо пользователям, и не желают вступать в долгие дискуссии. Если бы все было так просто...
В области разработки коммерческого ПО, где клиент и пользователь зачастую представлены одним лицом, ситуация несколько иная. Представители клиента, например, из отдела маркетинга или менеджеры по продукту, обычно пытаются на свой вкус определить, что клиент счел бы привлекательным. Тем не менее без конечных пользователей сформулировать требования пользователей не удастся (подробнее — в главе 7). В противном случае будьте готовы читать обзоры в журналах, описывающие недостатки вашего продукта, которых удалось бы избежать при активном участии пользователей.
Неудивительно, что бизнес-требования и требования пользователей иногда противоречат друг другу. Бизнес-требования отражают организационную стратегию или бюджетные ограничения, скрытые от пользователей. Пользователи, разочарованные тем, что менеджмент насильно внедряет новую информационную систему, не всегда хотят общаться с разработчиками ПО, считая последних предвестниками неблагоприятного будущего. Избежать этого помогает ясное и полное обсуждение целей и ограничений проекта. Возможно, действительность не удовлетворит никого, но у людей появится возможность понять и подстроиться под нее. Для сглаживания всех конфликтов аналитику необходимо взаимодействовать с полномочными представителями пользователей и менеджеров.