Кто же клиент?

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

Менеджер Герхард — это клиент, оплачивающий, или спонсирующий, проект по разработке ПО. Клиенты уровня Герхарда определяют бизнес-требования к системе. Они формулируют высокоуровневую концепцию продукта и бизнес-обоснование для его развертывания.

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

Бизнес-требования формируют каркас всего проекта. Любые другие функции и требования к продукту должны удовлетворять бизнес-требования. Тем не менее бизнес-требования не предоставляют разработчикам достаточно информации для создания продукта.

Следующий уровень требований — требования пользователей: и определяют те, кто прямо или косвенно взаимодействуют с продуктом, то есть конечные пользователи. Они способны описать требуемую функциональность, а также ожидаемые качественные характеристики продукта.

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

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

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

В области разработки коммерческог о ПО, где клиент и пользователь зачастую представлены одним лицом, ситуация несколько иная. Представители клиента, например, из отдела маркетинга или менеджеры по продукту, обычно пытаются на свой вкус определить, что клиент счел бы привлекательным. Тем не менее без конечных пользователей сформулировать требования пользователей не удастся (подробнее — в лекции 7). В противном случае будьте готовы читать обзоры в журналах, описывающие недостатки вашего продукта, которых удалось бы избежать при активном участии пользователей.

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

Сотрудничество клиентов и разработчиков (лекция 10-2)

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

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

«Билль о правах клиента ПО» (табл. 2-1) содержит 10 положений, на выполнении которых клиенты могут на вполне законных основаниях настаивать при общении с аналитиками и разработчиками на этапе формулирования требований к проекту. Каждый пункт этого права описывает соответствующую ответственность аналитиков и разработчиков ПО. «Билль об обязанностях клиента ПО» (табл. 2-2), напротив, содержит 10 положений, определяющих ответственность клиента перед аналитиком и разработчиком на этапе формулирования требований. Возможно, его стоит назвать «Билль о правах разработчика». Перечисленные ниже права и обязанности распространяются непосредственно на клиентов в случае, когда программный продукт разрабатывается для внутрикорпоративного использования, на заказ или для определенной группы крупных клиентов. При разработке продуктов для массового рынка интересы клиентов представляют сотрудники, например, отдела маркетинга.

В процессе планирования проекта клиенту и разработчикам следует изучить оба этих списка и постараться достигнуть взаимопонимания, Сильно занятые клиенты, возможно, предпочтут не принимать участия в формулировании требований (то есть попытаются избежать обязанности № 2). Однако мы знаем, что в этом случае значительно повышается риск создания продукта ненадлежащего качества. Убедитесь, что основные участники процесса формулирования требований понимают и принимают свои обязанности. В случае затруднений организуйте семинар и обсудите спорные пункты. Это позволит избежать трений позже, когда одна сторона будет ожидать чего-то, что другая не может или не желает предоставить.

Таблица 2-1. Билль о правах клиента ПО при формировании требований

Ловушка! Не предполагайте, что участники проекта интуитивно знают, как сотрудничать при формулировании требований. Потратьте время и обсудите, каким образом организовать взаимодействие наиболее эффективно.

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