Письмо 06 - Взаимодействие с конечными пользователями

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

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

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

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

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

Какие проблемы могут подстерегать на этом пути? Наиболее распространённая ошибка состоит в том, что разработчики идут «на поводу» у пользователей, произвольно меняя структуру системы в процессе работы. Если требования пользователей противоречат логике системы, то это означает, что, либо система концептуально непродуманна и противоречива, либо пользователи хотят применять систему для тех задач, которые не соответствуют или противоречат декларированной цели. Если возникает данная проблема, то необходимо вернуться к формулированию цели проекта (определению контура предметной области), заново проверить правильность декомпозиции по уровням и согласовать требования пользователей. В ситуации, когда и цель была сформулирована верно, и декомпозиция по уровням выполнена правильно, то надо показать пользователям противоречие, которое порождается новыми требованиями и исходной целью проекта.

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

Одной из важнейших задач, которую необходимо решить при создании сложной системы под заказ, является задача составления бизнес-плана и календарного плана разработки. Заказчик должен иметь возможность контроля сроков и качества выполнения проекта. Разработка проекта итерационным методом имеет свои особенности, которые необходимо учитывать при подготовке проектной документации. Основная особенность состоит в том, что на каждый новый этап составляется своя спецификация, где должно отражаться не только существо работ, но и те показатели, которые должен иметь проект по завершении текущего этапа. Эти показатели имеют тенденцию к уточнению и расширению от одной стадии к другой, что позволяет говорить о методике разработки с повышением качества, в отличие от методики «waterfall», которая является методикой разработки с понижением качества. Формирование спецификаций на каждый новый этап с указанием, контрольных значений и методик проверки должно происходить совместно со специалистами заказчика. Соответственно и оплата работ по каждому из этапов должна выполняться с учётом составленных спецификаций.