Отличные программные продукты — результат правильно реализованной архитектуры, основанной на требованиях, полученных в результате эффективного, то есть тесного взаимодействия разработчиков и клиентов. Слишком часто сотрудничество разработчиков и клиентов оборачивается враждой. Напряженность также создают менеджеры, изменяющие требования пользователей по собственному усмотрению. В этом случае не выигрывает никто.
Совместная работа возможна только тогда, когда все участники процесса разработки знают, что именно необходимо им для успеха, и когда они понимают и уважают стремление их соратников к успеху. Когда при работе над проектом нагнетается напряжение, очень легко забыть, что у всех участников единая цель — создать успешный программный продукт, ценный для бизнеса и отвечающий чаяниям всех участников проекта,
«Билль о правах клиента ПО» (табл.2-1) содержит 10 положений на выполнении которых клиенты могут на вполне законных основаниях настаивать при общении с аналитиками и разработчиками на этапе формулирования требований к проекту. Каждый пункт этого права описывает соответствующую ответственность аналитиков и разработчиков ПО. «Билль об обязанностях клиента ПО» (табл.2-2), напротив содержит 10 положений, определяющих ответственность клиента перед аналитиком и разработчиком на этапе формулирования требований. Возможно, его стоит назвать «Билль о правах разработчика».
Перечисленные ниже права и обязанности распространяются непосредственно на клиентов в случае, когда программный продукт разрабатывается для внутрикорпоративного использования, на заказ или для определенной группы крупных клиентов. При разработке продуктов для массового рынка интересы клиентов представляют сотрудники, например, отдела маркетинга.
В процессе планирования проекта клиенту и разработчикам следует изучить оба этих списка и постараться достигнуть взаимопонимания. Сильно занятые клиенты, возможно, предпочтут не принимать участия в формулировании требований (то есть попытаются избежать обязанности № 2). Однако мы знаем, что в этом случае значительно повышается риск создания продукта ненадлежащего качества. Убедитесь, что основные участники процесса формулирования требований понимают и принимают свои обязанности. В случае затруднений организуйте семинар и обсудите спорные пункты. Это позволит избежать трений позже, когда одна сторона будет ожидать чего-то, что другая не может или не желает предоставить.
| Таблица 2-1. Билль о правах клиента ПО при формировании требований | ||
| Клиент имеет право | ||
| 1. | Иметь дело с аналитиком, который разговаривает на вашем языке | |
| 2. | Иметь дело с аналитиком, хорошо изучившим ваш бизнес и цели, для которых создается система | |
| 3. | Потребовать, чтобы аналитик преобразовал требования, предоставленные вами устно в письменную спецификацию требований к программному продукту | |
| 4. | Получить от аналитика подробный отчет обо всех рабочих продуктах, созданных в процессе формулирования требований | |
| 5. | На уважительное и профессиональное отношение к вам со стороны аналитиков и разработчиков | |
| 6. | Знать о вариантах и альтернативах требований и их реализации | |
| 7. | Описать характеристики, упрощающие работу с продуктом | |
| 8. | Изменить требования или разрешить использование имеющихся программных компонентов | |
| 9. | Получить исчерпывающие сведения о сумме затрат, ожидаемом эффекте и необходимых компромиссах, которые возникают в связи с изменениями в ПО | |
| 10. | Потребовать, чтобы система функциональностью и качеством удовлетворяла требования заказчика | |
| Таблица 2-2. Билль об обязанностях клиента ПО при формировании требований | |
| Клиент обязан | |
| 1. | Ознакомить аналитиков и разработчиков с особенностями вашего бизнеса |
| 2. | Потратить столько времени, сколько необходимо на объяснение требований |
| 3. | Точно и конкретно описать требования к системе требований |
| 4. | Принимать своевременные решения |
| 5. | Уважать определенную разработчиком оценку стоимости и возможность реализации ваших требований |
| 6. | Определять приоритеты требований |
| 7. | Просматривать документы с требованиями и оценивать прототипы |
| 8. | Своевременно сообщать об изменениях требований |
| 9. | Поддерживать принятый в организации-разработчике порядок контроля изменений |
| 10. | Уважительно относиться к методам, с помощью которых аналитики создают требования |
| Ловушка Не предполагайте, что участники проекта интуитивно знают, как сотрудничать при формулировании требований. Потратьте время и обсудите, каким образом организовать взаимодействие наиболее эффективно. |