Подготовка катастрофы

Мой коллега Скотт Мак-Грегор (Scott McGregor) поделился изложенной ниже историей, когда я спросил, знает ли он о случаях, когда проекты по разработке выходили из-под контроля из-за отсутствия проектирования взаимодействия. Его история печальна, и особенно тем, что типична для нашей отрасли.

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

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

Чтобы успеть сдать версию 1.2 к 31 декабря, мы просто приняли решение назначить версию 1.2 тому, что будет готово в пять вечера 31 декабря. Разработчики трудились, не имея фиксированной спецификации. Необходимость в значительных изменениях «без объявления войны» обнаружилась 29 декабря.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хочу подчеркнуть, что опыт Скотта вполне типичен. Вот история другого коллеги из нашей области, Джона Ривлина (John Rivlin). Джон управляет небольшой, но очень успешной компанией в Пало-Альто, специализирующейся на проектировании и разработке программного обеспечения. Он прислал мне свою историю:

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

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

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