[comp.flame] Если бы программисты ставили себя на место пользователей…

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

На мой взгляд, такие замечания неизбежны. Нельзя разрабатывать программу так, чтобы их не было совсем. Что-то теряется на этапе постановки задачи, что-то упускается на этапе реализации, о чем-то вообще было забыто, что-то появилось уже после начала работ. Так что от “тщательной доработки напильником” не уйти. Но вот сократить объем этой работы можно, иногда очень серьезно. Что для этого нужно?

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

Вот такой вот несложный, на первый взгляд, рецепт. Когда разработчик становится пользователем своей программы, он начинает сам замечать, что “Эта операция используется достаточно часто и доступ к ней хорошо бы иметь на toolbar-е и через горячую клавишу”, “Две эти операции, как правило выполняются одна после другой, но им назначены такие горячие клавиши, что задействовать их одной рукой не получается”, “Было бы хорошо, если бы мне не приходилось обязательно задавать вот эти три параметра, лучше чтобы по умолчанию для них использовались значения вот этого четвертого параметра”, “Вот для таких операций в логе и в мониторинговой панели хотелось бы видеть следующие показатели…” и т.д., и т.п.

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

А почему же не удается ставить себя на место пользователя? С ходу я могу назвать две причины.

Первая причина в том, что у программистов и пользователей разные цели. Пользователь хочет с помощью программы решать свои задачи. А программисту нужно написать программу (обычно “еще вчера”, а иногда и “еще позавчера”). Поэтому программисту важно минимизировать собственные усилия, сделать так, как проще ему. Хорошо, если в рамках того, о чем просил пользователь :) В итоге получается, что простота реализации для программиста не есть простота использования для пользователя. Как следствие – замечания, переделки и доработки.

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

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

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

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

* фотографии должны быть предоставлены в цветовых координатах RGB, в профиле sRGB, обязательно в 8-битном цвете, иметь разрешение 300dpi, размер по длинной стороне минимум 2568 пикселей. Рекомендуемый (но не обязательный) размер 2413x3626 пикселей. Размер файла фотографии должен быть не менее 16 КВ, формат JPG, TIFF (в формате PC) или BMP. Допускается участие в конкурсе изображений, отсканированных с бумажных носителей или негативов.

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

Итак ситуация – у меня есть несколько любительских снимков, которые можно было бы отдать на конкурс. Но как хотя бы понять, подходят ли они по техническим параметрам? Можно поставить Photoshop и сделать в нем необходимые преобразования (если они вообще необходимы). Но что такое Photoshop и с чем его едят? ;)

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

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

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

Disclaimer. Я знаю, что есть отдельное понятие usabillity. И что в серьезных проектах (типа MS Office) этим делом занимаются специальные люди. Но если usabillity пользовательского интерфейса – это еще более-менее хорошо освещенная тема, то удобство использования, скажем, server-side приложений, рассматривается не так широко. Хотя там непаханое поле работы. Особенно в небольших проектах, которые делают маленькие команды, в сжатые сроки, с небольшими бюджетами, с прямым общением между разработчиками и пользователями…

PS. На тему usabillity: сегодня наткнулся на интересную презентацию -- The Keyhole Problem