Текст книги "Психбольница в руках пациентов. Алан Купер об интерфейсах"

Часть II. Цена слишком высока

3. Пустые растраты

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

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

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

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

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

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

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

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

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

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

Без подобных планов создатели программ оказываются лишенными ясного понимания, что считать готовым продуктом, поэтому они назначают приблизительную дату завершения, а когда она наступает, просто объявляют продукт готовым. Наступило первое июня? Значит, продукт готов. «Запускаем!» – говорят они, и дедлайн становится единственной контрольной точкой степени завершенности продукта.

Разумеется, программисты и предприниматели далеко не дураки, оттого продукт не получится слишком уж оторванным от реальности. У него будет широкий набор функций, и работать он станет стабильно и без сбоев. Он даже начнет прекрасно справляться с задачами, если окажется в руках людей, сильно заинтересованных в том, чтобы так оно и было. Может статься даже так, что продукт проходил юзабилити-тестирование, при котором группа добровольцев пытается выполнять на нем задачи под наблюдением специалистов по юзабилити[7]7
  Специалист по юзабилити (usability professional) – это не то же самое, что проектировщик взаимодействия (interaction designer). Подробно различия рассмотрены в главе 12 «В отчаянном поиске юзабилити».


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

Руководители знают, что разработка программного обеспечения идет в соответствии с законом Паркинсона: работа заполняет все время, отпущенное на нее, увеличиваясь в объеме. Если вы работаете в сфере разработки ПО, то вам, скорее всего, известно и следствие из этого закона, которое называют «правилом 90/90» (автором этого правила считают Тома Каргилла из Веll Labs): «Первые 90 % кода занимают первые 90 % времени разработки. Остальные 10 % кода занимают вторые 90 % времени разработки». Это уничижительное правило просто-напросто говорит, что даже в тот момент, когда первые 90 % кода написаны, программистам по-прежнему неизвестно, в какой стадии находится проект! Руководство прекрасно знает, что сдать проект в срок не получится, какие бы сроки ни были установлены. А учитывая то, что программисты наиболее продуктивно работают под давлением, руководители применяют дедлайн как один из рычагов воздействия на них.

В 1980-е и 1990-е годы вице-президентом по разработке в небольшой, но достаточно влиятельной компании под названием Т/Maker был Ройял Фаррос. Он говорил так: «Многие из нас устанавливали настолько жесткие дедлайны, что в них было заведомо невозможно уложиться. Такая ситуация лишний раз подтверждала одно из следствий закона Паркинсона: „Этап завершения проекта разработки требует в два раза больше времени, чем планировалось“. Я пребывал в твердом убеждении, что, если установить дедлайн, например, через шесть месяцев, на самом деле это займет год. Таким образом, если нужно было получить продукт через два года, дедлайн надо было устанавливать на один год. Такие сроки просто огорошивали, но метод срабатывал всегда».

Риджли Эверс, предприниматель в сфере разработки программного обеспечения, работая в Intuit над созданием QuickBooks, наблюдал ту же проблему. «Первая версия QuickBooks должна была выйти спустя девять месяцев. Мы правильно решили, что период разработки будет длиться столько же, сколько беременность, правда, кое в чем слегка ошиблись: срок подготовки проекта составил почти два с половиной года – как беременность слона».

Скотт Макгрегор, архитектор программного обеспечения, отмечает, что в такой ситуации применим также закон Грешема, гласящий: «Худшие деньги вытесняют из обращения лучшие». Если на рынке присутствует две валюты, то более сильную люди хранят, а тратят более слабую. В результате это выливается в то, что в обращении преимущественно остается слабая валюта. Аналогичным образом недостоверная оценка сроков реализации проекта вытесняет реалистичные прогнозы. Если все только и занимаются тем, что делают слишком оптимистичные прогнозы, взятые «с потолка», то руководитель, который пытается предлагать более долгие, но вместе с тем приближенные к реальности сроки, выглядит так, будто умышленно саботирует процесс разработки. В конечном счете на него будет оказано давление, и ему придется скорректировать свою оценку ситуации в сторону уменьшения времени работы над проектом.

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

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

Так, в конце 1990-х годов один громко разрекламированный стартап Worlds, Inc., команда которого состояла из множества умных и способных специалистов, работал над созданием виртуального онлайн-мира, где аватары людей могли бы перемещаться по виртуальному пространству и вовлекать других аватаров в общение в реальном времени. У продукта никогда не было полного определения или описания, и после того, как на этот проект были спущены десятки миллионов долларов инвестиций, руководство стартапа благоразумно свернуло эту затею.

В начале 1990-х годов еще один стартап Nomadic Computing потратил почти 15 миллионов долларов на попытку создать новый продукт для бизнесменов, обладающих высокой степенью мобильности. К несчастью, ни один человек в компании не мог точно сказать, что это за продукт. Команда понимала, на какой рыночный сегмент она ориентируется и каким функционалом должен обладать продукт, но не имела ясной картины о целях потенциальных пользователей. Как безумный скульптор откалывает кусок за куском от мраморной глыбы, надеясь обнаружить внутри статую, так и программисты писали внушительные объемы кода, по сути своей бесполезного, который затем просто выкидывали вместе с деньгами, временем, репутацией и своей карьерой. Самой же обескураживающей потерей была упущенная возможность сделать по-настоящему желанный для пользователя продукт.

Не удалось избежать такой напасти даже корпорации Microsoft. Впервые попытавшись создать программное обеспечение для управления базами данных в конце 1980-х годов, компания затратила на это множество человеко-лет, и завершился этот проект тем, что Билл Гейтс просто-напросто милосердно его закрыл. Ударной волной прошла эта преждевременная кончина проекта по сообществу разработчиков. Последовавший за ним программный продукт Access стал совершенно новой попыткой, над которой работала другая команда разработчиков и другие руководители.

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

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

Так, компьютеру PenPoint, разработанному компанией GO в 1990 году, пророчили славу прародителя поколения носимых карманных компьютеров и основоположника революции в этом направлении. Однако в 1992 году PenPoint потерпел крах, и эстафету по перевороту индустрии носимых устройств перехватил компьютер Apple Newton. После того как и Newton не смог воодушевить пользователей, на горизонте эры карманных компьютеров забрезжила новая надежда – Magic Link от General Magic. На календаре был 1994 год. Когда продажи Magic Link также провалились, на рынке карманных компьютеров наступила мертвая тишина. Инвесторы провозгласили этот сегмент рынка бесперспективным. А потом, словно из ниоткуда, в 1996 году на рынке возник PalmPilot и в мгновение ока снискал всеобщее признание. Его создатели вступили на никем не захваченную территорию с опозданием на шесть лет. Рынок всегда готов принять качественный продукт, доносящий ценность и удовлетворяющий потребности клиентов.

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

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

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

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

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

По рассказу Фарроса, флагманским продуктом компании T/Maker был текстовый процессор WriteNow – «идеальный программный продукт для университетов. В 1987 году количество продаж копий WriteNow университетам было больше, чем количество продаж копий Word компанией Microsoft. Тем не менее мы не смогли удержать лидерские позиции, потому что не учли одной функции, крайне необходимой текстовым процессорам для университетов, – концевые сноски, чем сильно разозлили наших самых лояльных потребителей в этом рыночном сегменте. В попытках не сорвать дедлайн мы так и не смогли включить ее в спецификацию. В результате продукт вышел точно в срок, но при этом мы потеряли целый сегмент рынка».

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

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