Критерии оценки пользовательского интерфейса систем автоматизации бэк-офиса

    Российский фондовый рынок имеет специфическую черту - отношения между его агентами строятся на принципах интимной доверительности и не предполагают столь подробного описания бизнес-процессов, на которое рассчитывают отечественные разработчики. В такой ситуации создателям автоматизированных систем остается полагаться на свой рефлексивный потенциал, который во многом определяется опять-таки методами сбора и анализа материала, которыми они владеют. Таким образом, задачи автоматизации российского фондового рынка могут решаться только междисциплинарным исследовательским коллективом, в состав которого, как это ни прозвучит странно для представителей фирм-разработчиков, должны входить психологи, этнографы и культурологи. Данная проблематика рассматривается на примере автоматизации внутреннего учета инвестиционных компаний (бэк-офиса).
    В современной мировой практике при проектировании и оценке потребительских качеств программных продуктов первостепенное значение уделяется их инженерно-психологическим и когнитивно-эргономическим характеристикам. На смену дискредитировавшему себя расплывчатому термину <дружественность пользователю> (user friendliness) пришла теоретически и практически более обоснованная концепция (обычно переводится на русский как <удобство использования>).
    Согласно международному стандарту ISO 9241-11 к основным факторам, определяющим удобство использования программного продукта, относятся:

эффективность - точность и полнота при достижении пользователями целей;

продуктивность - количество психических, физических и временны 'х ресурсов, необходимых для достижения пользователями своих целей с необходимой точностью и полнотой;

удовлетворенность пользователя - субъективное ощущение комфорта и удобства при использовании продукта;

адекватность контексту - соответствие системы характеристикам ее пользователей, их целям, задачам, оборудованию, физическим и социальным характеристикам среды, в которой используется продукт.
    В настоящее время общепризнанной стала необходимость включения в жизненный цикл разработки программного обеспечения работ по проектированию и тестированию удобства использования. Эти работы выполняются на технологических фазах определения требований, распределения функций, дизайна пользовательского интерфейса, оценки прототипов, внесения изменений, тестирования готового продукта. На этих этапах разработчики программного обеспечения привлекают специалистов, чья гуманитарная подготовка позволяет решать задачу обеспечения <человеческого измерения> в программных продуктах: эргономистов, промышленных дизайнеров, этнографов, организационных и инженерных психологов.
    Комиссия НАУФОР по сертификации коммерческих программных продуктов для бэк-офиса проводит их экспертную оценку не только на соответствие стандартам НАУФОР и функциональным требованиям, но и в плане качества пользовательского интерфейса и потребительских характеристик программных систем. Автор данной статьи является членом комиссии и специализируется именно по данному направлению.
    В статье дан обзор нынешнего состояния отечественного программного обеспечения для бэк-офиса и критерии оценки пользовательского интерфейса.
    В целом с точки зрения учета человеческого фактора в программных продуктах складывается довольно неутешительная картина. Отечественные разработчики игнорируют мировую практику включения в команду разработчиков специалистов гуманитарного профиля. Программное обеспечение разрабатывается исключительно силами программистов, не имеющих подготовки в области анализа человеческой деятельности и психологических характеристик пользователей. Только в исключительных случаях компании-разработчики включают в состав команды разработчиков специалистов по предметной области (сотрудников бэк-офисов) на правах полноправных членов. Обычно же им отводится роль внешних консультантов, чего явно недостаточно.
    Результатом этого становится недостаточное понимание разработчиками организационной структуры и задач, решаемых сотрудниками бэк-офиса, проблем их практической деятельности (распределение ролей и функций, внутри- и внешнеорганизационные коммуникации, типовые задачи и их вариации, нестандартные ситуации и их обработка).
    <Автоматизаторы> сосредоточивают свое внимание на моделировании <потоков данных>, не обращая внимания на реальную деятельность рядовых работников и их субъективное восприятие целей, задач, действий и операций, реализуемых бэк-офисом.
    Эти недостатки находят выражение в пользовательском интерфейсе разрабатываемых систем. Ни одна из обследованных нами систем (включая те, что уже получили сертификаты НАУФОР) не может быть рекомендована к использованию рядовым бэк-офицером.
    В рамках журнальной статьи невозможно обучить читателя профессиональным критериям оценки пользовательского интерфейса, поэтому мы ограничимся указанием на ряд оценочных признаков, не выходящих за пределы здравого смысла.
    С точки зрения потенциального потребителя, важнейшим критерием при принятии или отказе от продукта становится история разработки системы. Следует предельно осторожно относиться к системам, созданным <с чистого листа> в строгом соответствии со стандартами и рекомендациями ФКЦБ и НАУФОР, но не прошедшим <обкатки> в реальных бэк-офисах. Также осторожно следует относиться и к системам автоматизации бухгалтерского учета или складской деятельности, приспособленным к задачам бэк-офиса.
    Более высокими оказываются потребительские качества продуктов, которые первоначально были заказными разработками, а впоследствии превращены в рыночные продукты. В этом случае вполне вероятно, что разработчики учли поток обратной связи (от пользователей системы). Однако может выявиться негативный момент: система, подогнанная под требования первоначального заказчика, окажется малопригодной для другой компании. Следует ожидать, что разработчики будут советовать новому клиенту <работать по-научному> и ломать существующую организацию деятельности бэк-офиса вместо того, чтобы настроить систему на эту иную организацию.
    На наш взгляд, наилучшими потребительскими качествами могут обладать системы, исторически спроектированные <с чистого листа>, но опирающиеся на предварительный одновременный анализ реальной деятельности бэк-офисов нескольких инвестиционных компаний.
    Потенциальному потребителю следует постараться собрать как можно больше исторической и технологической информации о программном продукте. Например, очень важное значение имеет информация о том, использовались ли в процессе разработки прототипы будущей системы, прошла ли она <обкатку> пользователями при решении практических задач, какая была получена обратная связь и как разработчик организовал учет этой обратной связи. Важное значение имеют и сведения о том, насколько активно пользователи участвовали в процессе разработки: использовались ли фокус-группы, интервью, протоколирование и анализ деятельности сотрудников бэк-офиса, были ли включены на постоянной основе в команду разработчиков сотрудники бэк-офисов.
    При первоначальном знакомстве с системой следует получить ответы на следующие вопросы: насколько система легка для освоения, насколько она интуитивна и требуются ли от пользователя специальные компьютерные знания? Если система трудна в освоении, то обязательно ли требуется предварительно обучить пользователей? Обладает ли система поддержкой и контролем выполняемых пользователем операций, облегчено ли устранение операторских ошибок? Или, напротив, система требует от пользователя повышенного внимания, не защищена от операторских ошибок? Подготовлена ли пользовательская документация техническим писателем, т.е. ориентирована ли она на рядовых пользователей, а не на программистов? Или, напротив, документация к системе отсутствует или недостаточно понятна рядовому пользователю?
    При оценке собственно пользовательского интерфейса системы важны следующие характеристики.

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

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

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

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