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

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

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

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

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

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

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

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

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

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

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

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

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