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

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

Следующую историю рассказал мой коллега, Джим Гей (Jim Gay). Он показывает, как легко умные инженеры загораются увлекательными и интересными проблемами, вместо того чтобы заниматься решением проблем, действительно того требующих.

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

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

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

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

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

Подобно ребятам из General Magic, Джим на горьком опыте убедился, что, классная технология и раскаленный докрасна рынок не способны поднять тяжелый груз плохо продуманного кода. Недостаточно перебросить мост между технологией и потребностью. Кто-то еще должен сделать так, чтобы люди захотели ходить по этому мосту.

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

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