Билль об обязанностях клиента ПО

Обязанность № I Ознакомить аналитиков и разработчиков с особенностями вашего бизнеса

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

Обязанность № 2. Потратить столько времени, сколько необходимо, на объяснение требований

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

Обязанность № 3. Точно и конкретно описать требования к системе

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

В спецификации требований к программному обеспечению рекомендуется использовать пометки «TBD» (to be determined — необходимо определить), указывающие на необходимость дополнительных исследований, анализа и информации. Тем не менее иногда такие маркеры используют в случаях, когда конкретное требование трудно определить точно и никто не хочет с ним возиться. Попытайтесь прояснить цель каждого требования, чтобы аналитик мог точно выразить его в спецификации требований к ПО. Если точное определение невозможно, выработайте совместно процедуру, которая позволит достичь необходимой ясности. Зачастую в таких случаях применяют метод прототипов — когда вы совместно с разработчиками формулируете требования поэтапно и постепенно.

Обязанность № 4. Принимать своевременные решения

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

Обязанность № 5. Уважать определенную разработчиком оценку стоимости и возможность реализации ваших требований

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

Иногда требования можно изменить так, что они станут дешевле и достижимее. Например, «мгновенное» выполнение операции реализовать нельзя, однако вполне по силам задать минимальный временной интервал (скажем, «в пределах 50 миллисекунд»).

Обязанность № 6. Определять приоритеты требований

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

Обязанность № 7. Просматривать документы с требованиями и оценивать прототипы

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

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

Обязанность № 8. Своевременно сообщать об изменениях требований

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

Обязанность № 9. Поддерживать принятый в организации-разработчике порядок контроля изменений

Для снижения негативного эффекта от изменений выполняйте необходимые процедуры контроля изменений, определенные в проекте. Это гарантирует, что никакое требование не потеряется, будет проанализирован эффект каждого изменения и все предполагаемые коррективы будут согласованы друг с другом.

Обязанность № 10. Уважительно относиться к методам, с помощью которых аналитики создают требования

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

Что насчет подписи?

Результатом сотрудничества клиента и разработчика считается соглашение по требованиям к продукту. Многие организации просят клиента поставить свою подпись на документах с требованиями: это означает, что клиент их подтверждает. Все участники процесса утверждения требований должны понимать свою меру ответственности. Подписав документ, клиент не может впоследствии заявить: «Мне дали лист бумаги с моим именем под чертой, и я на этой черте расписался, иначе разработчики не начали бы программировать». Если такой заказчик захочет через некоторое время изменить требования или его не устроит результат работы, детским лепетом прозвучат слова: «Ну да, я подписал эти требования, но у меня не было времени их читать. Я доверял вам, ребята - и вы меня подвели!».

Иногда проблему создает менеджер по разработке, он не должен рассматривать подпись как способ сделать требования неизменными. Когда клиент просит о каких-то изменениях, глупо указывать ему на спецификацию требований к ПО и протестовать: «Но вы же подписали эти требования, и именно такую систему мы и создаем. Если вам нужно было что-то другое, следовало сказать об этом раньше».

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

Гораздо важнее ритуала подписи концепция создания базовой, или основной версии (baseline) требований — «моментального снимка документа на какой-то момент времени. Текст под подписью на странице базовой версии должен звучать примерно так: «Подтверждаю что настоящий документ наилучшим образом представляет наше понимание требований к этому проекту на данный момент и что описанная система удовлетворит наши потребности. Я согласен вносить в будущем изменения в эту базовую версию в соответствии с процессов изменения требований, определенным в проекте. Я понимаю, что утвержденные изменения могут потребовать переоценки стоимости, ресурсов и сроков сдачи проекта». Благодаря этому документу, команда получает возможность контролируемо изменять границы проекта, анализируя влияние каждого предполагаемого изменения на сроки сдач и прочие факторы успеха проекта.

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

· клиент уверен, что разработчики будут взаимодействовать с ним для создания нужной системы, даже если перед началом работы над проектом они не успели продумать все требования:

· клиент уверен, что границы проекта не выйдут из-под контроля, поскольку решения относительно границ принимает он;

· менеджер проекта уверен, что команда разработчиков получила достойного делового партнера, который совместно с разработчиками готов отвечать за качество продукта;

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

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