Замышляя недоброе

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

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

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

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

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

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

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

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

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

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

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

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

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

Рассказ Скотта подтверждает общеизвестную истину: «Что посеешь, то и пожнешь». Если постоянно напоминать разработчикам про сроки, проект уложится в график, а если игнорировать потребности пользователя, то люди будут чувствовать себя униженными. Скотт продолжает рассказывать свою историю:

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

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

В своей книге «Об интерфейсе» ты упоминал, насколько важным является перестать тратить время пользователя. Я обеими руками «за». Но это только верхушка айсберга. Это происходит лишь после того, как продукт уже вышел на рынок и предлагается к продаже. Но ведь еще великое множество продуктов даже не доходит до рынка или проваливается на этапе продаж. Каждый инженер, которого я когда-либо встречал, глубоко переживал из-за опасения, что продукт, над которым он работает, может никогда не попасть в руки пользователя. И когда в результате разработку продукта закрывают или он терпит крах из-за недостаточно качественного проектирования взаимодействия, получается, что усилия инженеров пропадают впустую. А в мире не так много действительно хороших разработчиков, чтобы так бездарно растрачивать их время. В этом я и вижу наш моральный долг – не просто «прекратить растрачивать время пользователя», а не тратить впустую время и жизнь любого человека, включая разработчиков.

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

Хотелось бы подчеркнуть, что опыт Скотта не так уж необычен. Другому моему коллеге из этой индустрии – Джону Ривлину – тоже есть что рассказать. У Джона своя небольшая, но достаточно успешная компания по дизайну и проектированию в Пало-Альто. Вот его история:

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

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

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