Технологии программирования

Костерин В В

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

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

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

В первом случае пользователи, участвующие

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

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

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

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

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

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

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

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

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

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

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

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

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

12.7. АНАЛИЗ ТРЕБОВАНИЙ К ПРОЕКТУ

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

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

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