Андрей Орлов - Записки автоматизатора. Профессиональная исповедь

В начале 1990-х, во времена перестройки, кодировки КОИ-7 и клавиатур ЙЦУКЕН/JCUKEN, мне попалось пособие для сотрудников МПС по ликвидации компьютерной безграмотности, в котором я обнаружил поразившую меня строку: «Для выхода из программы нажмите ЯУИТ». Посмеялся, конечно, а при встрече с автором этого произведения не преминул высказать ему свое недоумение. А автор ответил, что поставил в этом месте ЯУИТ вместо QUIT, равно как и другие кириллические заклинания вместо осмысленных английских слов, абсолютно осознанно: «Программа читает только 7 бит из 8, поэтому ей все равно, кириллицей или латынью введена команда. А для пользователей не все равно, они министерские работники, а это значит, что исполнительская дисциплина у них высокая и что никакой чушью их не удивишь. Если написано ЯУИТ, то и наберут на клавиатуре ЯУИТ, а вот английское слово приводит их в ступор, из которого они не выводятся».

Крыть было нечем: автор был абсолютно прав.

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

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

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

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

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

Наверное, основное правило при проектировании интерфейса – это его простота. Если в глазах рябит от кнопок, полей, менюшек – скорее всего, интерфейс спроектирован плохо. – Д. К.

– У пользователей бывает разное зрение. У очень многих оно плохое.

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

Иногда кажется, что разработчик в качестве основной поставил перед собой именно цель доведения пользователя до истерики.

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

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

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

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

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

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

Финишная кривая

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

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

На эту тему написаны сотни умных книг и тысячи еще более умных статей, в том числе с применением теорий вероятностей и массового обслуживания (вывод моей студентки, воспользовавшейся одной такой книгой, я прочитал в ее дипломном проекте: «Таким образом, еще через два часа эксплуатации в программе будет выявлена последняя ошибка»).

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

Но, даже зная это, вы должны решить, когда же можно начинать внедрение. И ваше руководство совершенно не будет волновать, что этот вопрос теоретически неразрешим.

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

Итак, равнение на Гейтса, и – вперед!

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

• Всегда разбивайте работы на небольшие фрагменты, результат которых можно увидеть. Иначе мы уподобимся менеджерам проекта, которые, глядя на график работ, неизменно видят, что работы «выполнены на 80 %» (они всегда будут выполнены на 80 %, пока за день до сдачи системы не выяснится, что работы… выполнены на 80 %).

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