Отношения с пользователем

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

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

Имеется (уже упоминавшаяся) опасность, что пользователь может изменять свои требования к системе. Отметим, однако, что это никак не связано с непосредственным его участием в работе над проектом. Если требования к системе должны измениться, это произойдет независимо от того, привлечен ли пользователь непосредственно к работе или нет. В действительности если сам пользователь в работе не участвует, разработчик, вероятно, не узнает об изменении требований до тех пор, пока не станет слиш­ком поздно. Если же пользователь непосредственно привлечен к работе, он может значительно лучше представлять себе стоимость каждого изменения. Если правильно предусмотреть условия для изменения требований, участие пользователя может оказаться выгодным и с этой точки зрения.

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

Хотя такой продукт предназначен не для конкретного потреби­теля, разработчик и в этом случае, вероятно, хорошо представляет себе возможных покупателей. С одним или несколькими из них мо­жет быть подписано соглашение о сохранении коммерческой тай­ны, что позволит и возможным покупателям системы участвовать в ее разработке до того, как о ней будет публично объявлено.

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