ЭРГОНОМИКА

Александр Белышкин,

Алексей Лукутин

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

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

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

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

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

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

Некая компания разработала программу банковского обслуживания на дому. В настоящий момент техническая поддержка конечных пользователей представляет значительную статью расходов (как правило, разработчики “коробочного” ПО включают ее в стоимость продукта). Предположим, что сейчас продукт имеет 1500 пользователей. Полная стоимость часа работы оператора технической поддержки (включая зарплату, оборудование, налоги, связь и т. п.) составляет $10, при этом на один запрос он тратит 20 минут (1/3 часа). Допустим, что оптимизация интерфейса предотвратит хотя бы три звонка в службу технической поддержки от каждого пользователя в год. Тогда по формуле “количество пользователей x количество звонков x x длительность обработки звонка x стоимость оператора” получаем:

1500 пользователей x 3 обращения x 1/3 часа x $10 = $15 000

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

Как это происходит

В зависимости от поставленных задач исследование может принимать разные формы.

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

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

Зачастую используются методы лабораторного тестирования: пользователям дается определенное задание, и процесс его выполнения записывается на видеопленку (при этом фиксируются и их действия, и то, что они видят на экране компьютера). Затем специалист по проектированию интерфейсов (при необходимости вместе с разработчиками) анализирует полученную видеозапись и выявляет интерфейсные решения, вызвавшие наибольшие затруднения. Детальное обсуждение помогает понять, как надо изменить интерфейс, чтобы подобных затруднений не возникало. Такие исследования могут иметь свою специфику в зависимости от того, какая характеристика интерфейса тестируется (скорость работы, количество ошибок, простота обучения, субъективное удовлетворение и т. п.). При необходимости экспериментатор может попросить пользователя проговаривать свои мысли вслух. Кроме того, чтобы выявить наиболее узкие места интерфейсных решений, могут быть наложены различные ограничения: по времени, по дружественности среды и т. п.

Другие интерфейсы

У большинства пользователей компьютеров слово “интерфейс” ассоциируется с оконным интерфейсом Windows, однако на самом деле данное понятие гораздо шире. Одним из наиболее ярких примеров является интерфейс прикладного программирования - API. Эта аббревиатура хорошо знакома программистам, работающим с различными библиотеками функций или компонентами CORBA, COM, JavaBeans. Очевидно, что при обращении к той или иной библиотеке либо компоненту программист сталкивается с теми же проблемами, что и пользователь, изучающий новую прикладную программу. Например, довольно сложно понять, для чего предназначена функция с именем NeverCallMe, принимающая в качестве 25 параметров указатели на данные произвольного типа void* с именами a, b, c... К сожалению, нельзя сказать, что подобные функции редко встречаются в библиотеках. Если прикладной программист усложняет со временем пользовательский интерфейс, то программист системный усложняет программный интерфейс библиотек, делая их запутанными, нарушая стройность и логическую целостность API. В итоге первые не знают, как пользоваться такими библиотеками, делают все больше и больше ошибок и выдают ПО низкого качества. А надо-то было всего лишь чуть больше внимания уделить тестированию удобства использования API!

Есть и другие интерфейсы, не настолько скрытые от пользователя, как API, но и не так часто применяемые (хотя и очень важные). Речь идет о возможностях программы по инсталляции и конфигурации. Это критически важные характеристики ПО, особенно в отсутствие системного администратора, способного вводить десятки параметров командной строки по памяти. Некоторые программы, обладая весьма неплохим пользовательским интерфейсом при нормальном режиме работы, начинают буквально выводить пользователя из себя, когда случается малейший сбой или нестандартная ситуация. А это далеко не редкость: вспомните, например, борьбу с Windows при некорректной установке драйвера или последствие ручной установки клона Unix. Тем не менее разработчики ПО часто не уделяют должного внимания удобству инсталляции программы и содержательности сообщений об ошибках.

А сколько мучений может вызвать настройка ПО! Современные программы часто поставляются не готовыми, а в виде “полуфабрикатов” или конструкторов. При этом настройка либо адаптация программы может стоить гораздо дороже лицензии на ПО. Причина этого часто кроется в непродуманности способа настроек и в низкой эргономичности интерфейса пользователя. При этом и потребитель, и разработчик ПО несут существенные затраты на сопровождение (см. пример выше), а зарплата специалистов, способных разобраться в головоломке конфигурационных файлов, растет экспоненциально. Так не лучше ли сразу сделать удобный для использования “конструктор” или хотя бы выбрать более подходящий из имеющихся в продаже? Только проведение независимого тестирования интерфейсов ПО может дать объективный ответ на этот вопрос.

И последнее. Что делает рядовой пользователь, который не может заставить работать программу как надо? Он пытается выудить что-то полезное для себя из документации. И этот “интерфейс” тоже должен быть надлежащего качества. Язык, структура подачи материала, доступность для понимания, возможности поиска нужной информации представляют собой характеристики, исключительно важные для пользователя и непосредственно влияющие на его общее впечатление о программном продукте. Хорошо написанная документация часто маскирует недостатки программирования. Как добиться этого? Нужны хорошо разработанные шаблоны, талантливые технические писатели, грамотные редакторы и конечно же проверка и тестирование документации.

Выводы

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

С авторами можно связаться по адресам: alexandr.belyshkin@usethics.ru (Александр Белышкин) и lav@aqt.ru (Алексей Лукутин).