Психбольница в руках пациентов

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

Часть V Возвращаемся на место водителя

Глава 12 В отчаянных поисках эргономики

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

Последовательность

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

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

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

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