Часть V. Вернуть себе бразды правления

В отчаянном поиске юзабилити

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

Координация действий

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

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

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

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

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

Еще одной причиной, благодаря которой в компьютерной индустрии так широко принята именно такая последовательность, как «программирование – тестирование – доводка», является миф о непредсказуемом рынке, упомянутый в главе 3 «Пустые растраты». Если нам заранее не может быть известно, какие потребности возникнут у рынка, для чего в таком случае впустую тратить лишнее время на проектирование взаимодействия? Пишем программу, выпускаем ее на рынок, а дальше смотрим по ситуации. Более того, при таком подходе мы снимаем с себя всякую ответственность за возможный провал.

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

Юзабилити-тестирование

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

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