Читать онлайн «Человеческий фактор в программировании». Страница 37

Для примера возьмем задачу по извлечению наличных денег из банкомата. Физическая модель может быть следующей: клиент вставляет карту; система читает информацию с магнитной полоски и запрашивает PIN-код;[29] пользователь вводит PIN-код; система подтверждает PIN-код и предлагает меню возможных операций; пользователь выбирает нужную операцию; система предлагает меню счетов; пользователь выбирает счет; система запрашивает сумму; пользователь вводит сумму и нажимает на кнопку подтверждения; система выдает наличность; пользователь берет деньги и убегает. Что может быть проще?

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

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

Сущностная модель отражает идеализированную цель проектирования. Хорошо разработанный пользовательский интерфейс требует ровно столько шагов или столько информации, сколько определено в сущностной пользовательской ситуации. Клиенту банка должно быть достаточно сказать: «Это я. Как обычно. Спасибо!» — и уйти. Мы определяем идеальный случай — если бы мы его не смоделировали, то не смогли бы проектировать в соответствии с ним. А без проектирования в соответствии с идеальным случаем можно не увидеть, где нас ограничивает технология или технические условия, и упустить возможность использования альтернативных подходов.

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

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

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

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

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

Меилир сразу же перевел мне: «Остерегайтесь машин, выпрыгивающих из воды слева».

Разыменовывайтесь. Попробуйте. И старайтесь думать по существу. Из журнала Software Development, том 2, № 11, ноябрь 1994 г.

CASE умер? Многие жрецы программирования объявляли, что смерть уже наступила. Однако на каждого плакальщика всегда находится тот оптимист, который верит в воскресение из мертвых, а на каждого очернителя находится свой ликующий поборник. Ведомое духом времени, в 1994 году Австралийское компьютерное сообщество (Australian Computer Society, ACS) собрало в Мельбурне две звездных команды австралийских консультантов и специалистов-практиков. Руководили командами сторонник Грэме Симшн (Graeme Simsion) и скептик Роб Томсет (Rob Thomsett). В ходе дискуссии, названной «великим спором о CASE», обсуждались все «за» и «против» в вопросе, как обстоит дело с CASE в Австралии. Этот спор стал весьма значительным событием для такого консервативного сообщества, как ACS, — настолько, что привлек даже больше внимания, чем презентация книги бывшего премьер-министра, которая проводилась в этом же зале несколькими часами ранее. По неизвестным причинам меня втянули в этот спор в качестве члена опровергающей команды. Томсет, которого Симшн называл самым диким консультантом Австралии, привел нашу команду к победе, хотя к концу обсуждения было видно, что обе стороны находились приблизительно на одном уровне.