Очевидно, что в этом случае проявилось плохое отношение или даже недостаточная квалификация представительницы банка, но ориентация на клиента или ее отсутствие может также зависеть и от программного обеспечения. Системы, которые мы разрабатываем и поставляем своим клиентам, могут сильно влиять на качество тех услуг, которые оказываются с их помощью. Если бы в моем случае программное обеспечение было хорошим, то мне не пришлось бы идти в банк, чтобы прослушать лекцию от Хельги Ужасной. Программе, которая применялась в банкоматах, было известно, что у меня нет чекового счета. Она знала, что у меня был один и только один так называемый «сберегательный» счет, и могла сообщить об этом.
Небольшие детали создают или разрушают сервис. Как и многим консультантам, мне удобно заказывать программное обеспечение и оборудование по телефону. Однажды, перечитывая последний пункт сделанного заказа, я все еще вертел в руках мою кредитную карту. И тут я внезапно понял, что вместо банковского счета компании я сообщил оператору данные моей личной кредитной карты. Я попросил ее изменить номер карты. Последовала длинная пауза и вздох. «Мне придется заново оформить этот заказ», — сказала она. «Разве вы не можете просто вернуться назад к этому полю и изменить его?» — «Нет, это поле уже заблокировано после выхода из того окна, поэтому все придется начать сначала». Клик, клик. «Назовите, пожалуйста, свою фамилию еще раз». Я заявил, что уже называл свое имя. «Но оно в том заказе, который нужно удалить».
Как видно, безмозглые программисты, которые создавали эту программу, даже никогда не задумывались о возможном применении этой системы. Они не предусмотрели способ вернуться назад или отменить часть совершенной операции. В результате — лишняя суета для продавца и по крайней мере один раздраженный покупатель, подумывающий о размещении следующего заказа в другой компании.
Все может быть и по-другому. Хорошее программное обеспечение помогает людям оказывать более качественные услуги. Расскажу о своем опыте общения с представителями винного клуба «Cellar Door Direct» в Южной Австралии. Через несколько месяцев после получения рекламного объявления я решил позвонить им и заказать немного вина. Все, что у меня было, — это листок с моими каракулями. К сожалению, код того вина, которое было мне нужно, не отображался на экране у телефонного оператора. Я слышал, как она «листала» файлы с данными, пока не нашла то, что нужно. «Это Jarrondale'92 Shiraz, правильно?» Она назвала цену, которая показалась мне слишком большой, — я напомнил, что это вино было выставлено на распродажу. «А какая цена указана у вас?» — спросила она. Я назвал ей верную, на мой взгляд, сумму. «Я больше не вижу здесь этой цены, но давайте я сделаю исправление». Клик, клик. И через пару дней у моей двери стоит посылка. Сочетание гибкого программного обеспечения с гибким персоналом позволило укрепить отношения с покупателем.
Приведу еще пример. В Сиднее впервые создали замечательную службу под названием «Cuisine Courier». Вы выбираете блюда из меню местных ресторанов, и за какие-то $2 заказ доставляют прямо к вашей двери. Позвонив в эту службу, вы просто сообщаете им свой телефон, а система предоставляет остальные данные. «Мистер Константин? Вы живете по тому же адресу? Хорошо, по какому меню вы хотели бы сделать заказ?» Вы называете краткий код, и оператор подтверждает его, сообщая полное название ресторана, — и так для каждого блюда. «Заказ будет доставлен через 45 минут». Через 45 минут в дверь стучат, и можно начинать пиршество.
Как им это удается? Просто их система хорошо разработана! Как только ваш заказ подтвержден, система отправляет факс с компьютера в нужный ресторан. К тому времени когда курьер прибывает в ресторан, заказ уже готов и к нему приложена инструкция по доставке. И нет никакого беспокойства, как говорят австралийцы, потому что все работают с одними и теми же данными.
Как разработчики программного обеспечения мы должны помнить, что такие небольшие детали, так же как и общая архитектура системы, имеют значение в оказании услуг конечному потребителю. От наших решений зависит, будет ли «голос клиента» недовольным или благодарным.
Из журнала Software Development, том 4, № 3, март 1996 г.
VII
Удобные объекты
42
Объекты, которые раздражают
Графические пользовательские интерфейсы не имеют ничего общего с юзабилити — они связаны с графикой. Какой смысл в фантастическом ГПИ, если вы не применяете его для рисования красивых картинок? А с учетом того, что качество изображения на экране монитора растет, почему бы не анимировать ваши замечательные картинки? Целью является повышение продаж, а мишенями — обозреватели и покупатели программного обеспечения, которые смотрят (не очень внимательно), а потом пишут восторженные рецензии или покупают лицензию на использование системы. Потребители, которые больше заботятся о том, чтобы действительно выполнять работу, — это совсем другая группа людей, поэтому вы больше слышите о пользовательских интерфейсах, чем о юзабилити; больше говорится о философии проектирования, ориентированного на пользователя, чем о реальной поддержке процесса работы; больше рассуждений о необходимости прислушиваться к голосу покупателя, чем о внимании к проблемам пользователей.
Возьмем объектную технологию. Если когда-то всему надлежало быть «структурированным», чтобы заслуживать внимания, то теперь все обязано быть «объектно-ориентированным». Если что-то не «объектно-ориентировано», оно не считается современным. Если программное обеспечение не построено из «объектов» и «классов», то в нем не может быть ничего хорошего. В примитивном представлении объекты считаются естественными и интуитивными. Более того, они политически корректны, потому как могут использоваться повторно!
Сегодня пользовательские интерфейсы стали объектно-ориентированными. По крайней мере, так написано на коробке.
Представьте: вы подумываете об отдыхе, зная, что объекты надежно спрятаны в соответствующих библиотеках классов с огромными возможностями повторного использования — глубоко внутри кодового ядра устойчивого программного обеспечения. И как раз в ту минуту, когда вы подумали, что получили полное представление о полиморфизме, универсальности и перманентных объектах, а объектная технология обрела смысл, объекты неожиданно начинают появляться на экране вашего монитора. Если объекты полезны внутри программного обеспечения, то они должны быть полезны и вне его. Если объекты полезны для разработчиков, то они должны быть полезны и для пользователей. Во всяком случае так утверждается в рекламе.
На что же похожа эта объектная революция, когда она переходит из языка программирования в пользовательский интерфейс? Представьте такую картину. На экране показана модель карманной записной книжки-ежедневника. Вы можете щелкать мышью по вкладкам для перехода к любому разделу. Вы можете щелкнуть мышью в углу «страницы» и «пе-релистнуть» ее. Ну надо же, как удобно! Конечно, большую часть времени пол-экрана не задействовано, а для чтения надписей на вкладках нужно поворачивать голову — сначала по часовой стрелке, потом против, поскольку при перелистывании страниц текст переворачивается с одной стороны на другую. Ах, но зато это выглядит таким знакомым, а ведь каждый знает, что знакомые метафоры облегчают применение программного обеспечения, не так ли? Особенно не следует придавать значение тому, что на экране super-VGA помещается меньше информации, чем на старом DOS-дисплее с 80 колонками, хотя информация отображается более мелким шрифтом. Зато все в цвете. Это очень приятно, если только вы не являетесь одним из двенадцати мужчин, которые не различают цвета. Этот «персональный информационный менеджер», должно быть, очень полезная штука, раз в нем так много замечательных картинок. Но постойте, это не просто картинки, это объекты! Их можно перемещать, с ними можно работать, с ними можно взаимодействовать, и это делает вашу жизнь такой приятной.