Смысл жизни программного обеспечения

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

Смысл жизни каждый находит для себя сам. Физики могут сказать, что смысл жизни в борьбе с энтропией: преобразовании хаоса в порядок.
В этом случае, смысл софта в устранении рутины, чтобы cделать создание порядка более эффективным и интересным.

Текст будет длинный. Если вы никуда не торопитесь и удобно устроились в кресле, то давайте попробуем обосновать это утверждение.

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

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

Базовый элемент в дизайне программ — разделение функциональности и ее реализации. Как и многие другие вещи в жизни, это поднимает 3 крупных вопроса:
1. Что мы хотим сделать?
2. Как мы хотим cделать это?
3. Почему мы хотим это делать?

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

Дизайн ПО часто дает качественные ответы на вопросы «что» и «как», даже если мы опускаемся до мельчайших деталей:
— Какую прозрачность сделать у тени для этой кнопки?
— Как переслать эти 2 байта на сервер?

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

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

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

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

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

Картинка

Пример первый: сохранение файла в MS Word

Большинство пользователей работали с Word. Диалог сохранения документа, особенно в первый раз, может серьезно озадачить:

— Выбрал ли я правильный тип файла?
— Надо ли мне заполнить все теги, ввести название и тему, или только часть из этих полей?
— В чем вообще разница между названием и темой?
— Должен ли я указать кодировку? Я помню, у меня были проблемы с неправильной кодировкой раньше, так что это должно быть важно.
— Где сохранить файл? У меня есть мои статьи на общем диске, записи в Моих Документах, корпоративные файлы на сетевом ресурсе, проектная документация в папке проекта и т.д. Может просто сохранить файл в любую временную папку и решить позже?
— Почему файл теперь называется по первой строке текста, а заголовок окна был «Документ 1»; это баг или фича?

Со временем вы привыкли к этому диалогу и знаете какие параметры надо вводить, а какие игнорировать. Остается только вопрос так ли необходимы все эти параметры.

Что нужно пользователю — это «задать имя текста и убедиться, что я смогу найти его в следующий раз, когда я захочу поработать с ним». В задачу не входит определение папки для сохранения файла или выбор правильной кодировки. На самом деле, даже сохранение файла не входит: все что пользователь хочет, это убедиться, что он может найти свой текст в следующий раз и что-то сделать с ним: распечатать, продолжить работу или отправить кому-то по почте.

Можно ли сделать сохранение файла по-другому? Например, некоторые люди с удовольствием используют черновики писем Gmail для подготовки текстов с несложным форматированием. Gmail не напрягает пользователя вопросами когда и как сохранять документ — это делается автоматически. Вы можете ввести тему, но даже это не является обязательным.

Глядя на то, как GMail удалось убрать все рутинные действия и сделать сохранение документов полностью прозрачным для пользователя, можно ли было сделать то же самое в MS Word? Конечно:

— Определить стандартное место для сохранения новых документов
— Называть и сохранять документ автоматически
— Дать пользователю возможность переименовывать и перемещать документы

В результате, пользователь больше не отвлекается на технические детали:

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

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

Конечно, Word — большая и сложная программа, которую можно настроить под себя. Можно даже написать VBA скрипт чтобы сделать «сохранение как в Gmail». Но за это придется платить временем на изучение и вдаваться в технические детали, которые совершенно неинтересны автору пишущему роман или повару оформляющему свои рецепты. Да и программисту… Не знаю как вы, но у меня, например, рефлекс периодического нажатия Ctrl+S выработался намного раньше, чем я узнал про автосохранение в Word'е.

Второй пример: дождливый день

Мне надо не забыть зонтик, если планируется дождь, для чего я использую гаджет прогноза погоды на странице iGoogle.

По шагам процесс такой:

1. Проверить с утра iGoogle
2. Нажать на ссылку детального прогноза, посмотреть в какие часы ожидается дождь
3. Сравнить с планом на день и решить, брать зонт или нет
4. Не забыть про зонт, когда буду выходить

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

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

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

Все риски теперь остались в единственном шаге — взглянуть на планшет перед выходом из дома.

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

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

Заключение

Приведенные примеры можно использовать для создания «контрольных вопросов» по оценке удобства использования программы.

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

Такие вопросы полезны сами по себе, но основываются они на одном базовом вопросе:

— Какая часть работы (при использовании программы) характеризуется как повторяющаяся, скучная, необязательная и механическая, а какая остается творческой, интересной и важной?

В отсутствие лучшего термина, я обзываю первую часть «рутиной». «Рутина» — это та часть работы которая может быть автоматизирована, устранена или скрыта.

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

Автор: DeeKey