Билль об обязанностях клиента ПО
Обязанность № 1. Ознакомить аналитиков и разработчиков с особенностями вашего бизнеса Только вы можете полноценно познакомить разработчиков с концепциями и терминологией своего бизнеса. Вам не надо делать аналитиков экспертами в предметной области, основная задача — помочь им понять ваши проблемы и цели. Не ожидайте, что аналитики постигнет нюансы и неявные особенности бизнеса. Скорее всего у них нет знаний, воспринимаемых вами и вашими коллегами, как должное. Невысказанные предположения о таких знаниях могут вызвать проблемы в дальнейшем.
Обязанность № 2. Потратить столько времени, сколько необходимо, на объяснение требований. Клиенты — занятые люди, и те, кто участвует в формулировании требований — обычно самые занятые из них. Тем не менее вы обязаны потратить время на участие в совещаниях, мозговых штурмах, интервью и прочих процедурах, необходимых для выявления требований. Иногда аналитик считает, что понял вашу идею, а позже сообразит, что ему необходимы дополнительные разъяснения. Пожалуйста, терпеливо относитесь к такому поэтапному подходу к формулированию и прояснению требований; это — природа сложного человеческого общения и ключ к успеху. Терпимо относитесь к глупым, на ваш взгляд, вопросам; хороший аналитик задает вопросы, которые заставляют вас говорить.
Обязанность № 3. Точно и конкретно описать требования к системе. Весьма заманчиво оставить требования неопределенными и нечеткими, ведь прояснять подробности так утомительно и долго. Тем не менее на каком-то этапе разработки участникам проекта необходимо устранить все неоднозначности и неточности. Вам, как клиенту, и карты в руки. В противном случае угадывать, что же именно вам нужно, будут разработчики.
В спецификации требований к программному обеспечению рекомендуется использовать пометки «TBD» (to be determined — необходимо определить), указывающие на необходимость дополнительных исследований, анализа и информации. Тем не менее иногда такие маркеры используют в случаях, когда конкретное требование трудно определить точно и никто не хочет с ним возиться. Попытайтесь прояснить цель каждого требования, чтобы аналитик мог точно выразить его в спецификации требований к ПО. Если точное определение невозможно, выработайте совместно процедуру, которая позволит достичь необходимой ясности. Зачастую в таких случаях применяют метод прототипов — когда вы совместно с разработчиками формулируете требования поэтапно и постепенно.
Обязанность № 4. Принимать своевременные решения
Точно так же, как и подрядчик при строительстве дома, аналитик задаст вам множество вопросов и попросит выбрать различные варианты и принять решения. Это может быть согласование противоречивых запросов от разных клиентов, выбор между конфликтующими атрибутами качества и оценка точности информации. Клиенты, обладающие соответствующими полномочиями, должны принять эти решения, когда их об этом попросят. Зачастую работа стопорится, так как клиент не может принять окончательного решения, и поэтому, медля с ответом, он затягивает работу над проектом.
Обязанность № 5. Уважать определенную разработчиком оценку стоимости и возможность реализации ваших требований Все программные функции чего-то стоят. Разработчики лучше всего способны оценить эту стоимость, хотя многие из них и не имеют опыта в этом деле. Может оказаться, что некоторые необходимые вам функции технически неосуществимы или их реализация слишком дорога, например недостижимая в рабочей среде производительность или доступ к данным, которые системе просто недоступны. Даже если сведения об осуществимости и стоимости некоторых функций, сообщенные разработчиком, вам не понравятся, следует уважать эту оценку.
Иногда требования можно изменить так, что они станут дешевле и достижимее. Например, «мгновенное» выполнение операции реализовать нельзя, однако вполне по силам задать минимальный временной интервал (скажем, «в пределах 50 миллисекунд»}.
Обязанность № 6. Определять приоритеты требований
Лишь при работе над ограниченным кругом задач можно рассчитать время и ресурсы для реализации всей желаемой функциональности, Определить, какие возможности необходимы, какие полезны и без каких пользователи обойдутся, — важная составляющая анализа требований. Именно вы определяете эти приоритеты, поскольку разработчики не в состоянии расставить приоритеты. Чтобы вам облегчить задачу, разработчики предоставляют информацию о стоимости и рискам всех требований. Определив приоритеты, вы поможете разработчикам вовремя и с минимальными затратами создать максимально эффективный продукт.
Обязанность № 7. Просматривать документы с требованиями и оценивать прототипы. Просмотр требований — одна из наиболее значимых операций, обеспечивающих качество ПО. Участие клиентов в таких просмотрах — единственный способ узнать, отражены ли потребности клиента наиболее полно и точно. Если клиенты не уверены в точности задокументированных требований, им следует как можно раньше сообщить об этом лицам, ответственным за реализацию требований, и предложить варианты усовершенствования.
Читая спецификацию требований, не всегда удается четко представить работу программы. Чтобы лучше понять потребности клиента и выявить оптимальные способы их удовлетворения, разработчики иногда создают прототипы предполагаемого продукта. Ваша ответная реакция на эти предварительные, частичные или пробные версии дает разработчикам необходимую информацию. Поймите, что прототип ни является рабочим продуктом, и не давите на разработчиков.
Обязанность № 8. Своевременно сообщать об изменениях требований
Постоянное изменение требований — серьезная угроза для возможности своевременной сдачи проекта командой разработчиков. Изменение неизбежно, но чем позже в ходе разработки о нем сообщается. Тем более сильное влияние оно окажет. Изменения могут стоить дорого, и сроки будут нарушены, если клиент пожелает реализовать в практически завершенном проекте новую функциональность. Как только вы решите изменить требования, сразу же сообщите об этом аналитику, с которым работаете.
Обязанность № 9. Поддерживать принятый в организации-разработчике порядок контроля изменений Для снижения негативного эффекта от изменений выполняйте необходимые процедуры контроля изменений, определенные в проекте. Это гарантирует, что никакое требование не потеряется, будет проанализирован эффект каждого изменения и все предполагаемые коррективы будут согласованы друге другом,
Обязанность № 10. Уважительно относиться к методам, с помощью которых аналитики создают требования Сбор и проверка требований — одни из самых трудных задач в разработке ПО. У всех подходов, применяемых аналитиками, есть рациональная основа. И хотя операции по созданию требований могут вас разочаровать, время, затраченное, чтобы разобраться в требованиях, — не пропадет даром. Процесс окажется менее болезненным, если вы разберетесь в методах, используемых аналитиками для создания требований. Не стесняйтесь и просите аналитиков объяснить,
зачем необходимы те или иные сведения и почему они просят вас по-
участвовать в некоторых операциях по созданию требований.
Что насчет подписи?
Результатом сотрудничества клиента и разработчика считается соглашение по требованиям к продукту. Многие организации просят клиента поставить свою подпись на документах с требованиями: это означает, что клиент их подтверждает. Все участники процесса утверждения
требований должны понимать свою меру ответственности. Подписав
документ, клиент не может впоследствии заявить: «Мне дали лист бу-
маги с моим именем под чертой, и я на этой черте расписался, иначе
разработчики не начали бы программировать». Если такой заказчик
захочет через некоторое время изменить требования или его не устро-ит результат работы, детским лепетом прозвучат слова: «Ну да, я под-
писал эти требования, но у меня не было времени их читать. Я доверял
вам, ребята — и вы меня подвели!» Иногда проблему создает менеджер по разработке, он не должен
рассматривать подпись как способ сделать требования неизменным!/
,
Когда клиент просит о каких-то изменениях, глупо указывать ему н.д
спецификацию требований к ПО и протестовать: «Но вы же подписали
эти требования, и именно такую систему мы и создаем. Если вам нуж-
но было что-то другое, следовало сказать об этом раньше».
Реальность такова, что на ранних этапах работы над проектом из-
вестна лишь часть требований, со временем они меняются. Утвержде •
ние требований — вот та самая операция, которая закрывает прение,
возникающие в процессе создания требований. Тем не менее участни-
кам необходимо подтвердить свои слова подписями.
Ловушка Не используйте подпись в качестве оружия. Применяйте ее как завершение этапа проекта и выработайте четкое коллективное понимание того, как подпись повлияет на возможные в будущем изменения.
Гораздо важнее ритуала подписи концепция создания базовой, или
основной версии (baseline) требований — «моментального снимка
документа на какой-то момент времени. Текст под подписью на стра
нице базовой версии должен звучать примерно так: «Подтверждаю