В начало

Часть II. Масштабные издержки

Глава 3. Пустая трата денег

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

Управление, ориентированное на крайние сроки сдачи

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

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

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

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

Что такое «готово»?

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

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

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

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

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

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

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

Закон Паркинсона

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

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

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

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

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

Продукт, вечно не готовый к выпуску

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

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

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

Даже корпорация Мiсrоsоft не обладает иммунитетом против подобных заблуждений. Ее первая попытка создать продукт для управления базами данных в конце восьмидесятых годов поглотила множество человеко-лет, и Билл Гейтс в конечном итоге милосердно, закрыл проект. Преждевременная смерть проекта ударной волной прокатилась по сообществу разработчиков. Следующий продукт этого направления, Access, разрабатывался с нуля другими разработчиками и другими руководителями.

Поздний выпуск - не беда

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

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

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

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

Торг за набор функций

Одним из последствий управления, ориентированного на фиксированные сроки сдачи, является феномен, который я называю «торгом за набор функций».

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

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

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

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

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

Кто главный? Программисты

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

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

Возможности не всегда нужны

Несмотря на кажущееся пристрастие к функциональности, пользователи не слишком стремятся получить максимум возможностей. Успехи и неудачи продуктов неоднократно демонстрировали, что пользователей не очень волнуют функции продуктов. Они интересуются лишь возможностью решать задачи. Иногда функции необходимы для этого, но чаще они просто смущают пользователей и мешают им делать работу. Бесполезные возможности заставляют пользователей чувствовать себя глупо. Если обратиться к предыдущему примеру, успешный PalmPilot обладал гораздо меньшим количеством функций, чем провалившиеся Magic Link от General Magic, Newtown от Apple и компьютер Penpoint. Своим успехом PalmPilot обязан проектировщикам, единодушно сосредоточившимся на целевой аудитории и ее потребностях.

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

Для нашего зациклившегося на функциях мира мысль, наверное, непривычная - вы не достигнете своих целей, используя набор функций как инструмент. Можно замечательно реализовать все функции из утвержденного набора и все равно попасть в беду. Для доказательства этого тезиса проектировщик взаимодействий Скотт Мак-Грегор на своих занятиях использует вот такой замечательный тест. Он описывает продукт с помощью перечня функций и просит слушателей записать, что это за продукт, как только они догадаются. Он перечисляет: 1) двигатель внутреннего сгорания; 2) четыре колеса с резиновыми покрышками; 3) трансмиссия, связывающая двигатель с ведущими колесами; 4) трансмиссия и Двигатель смонтированы на ходовой части; 5) рулевое колесо. На этот момент времени каждый слушатель уже записал, что это автомобиль, но здесь Скотт перестает описывать особенности продукта и вместо этого называет пару задач потенциального пользователя: 6) быстро и легко срезает траву; 7) на этом удобно сидеть. На основании пяти функций-подсказок ни один слушатель не может догадаться, что это минитрактор-газонокосилка. Очевидно, что цели пользователя намного более наглядны, чем набор функций продукта.

Итерации и миф о непредсказуемости рынка

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

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

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

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

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

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

* * *

Среды быстрой разработки, такие как Всемирная паутина и Visual Basic до нее, также внесли свой вклад в развитие подхода, согласно которому повторять попытки следует до тех пор, пока одна из них не окажется успешной. Всемирная паутина, будучи новой рекламной площадкой, привлекала и привлекает массу специалистов по маркетингу, которые особенно восприимчивы к мифу о непредсказуемости рынка и, следовательно, правилу повторения попыток. Маркетологам хорошо знаком жестки и капризный мир рекламы и средств массовой информации. В конце концов, реклама во многих случаях - просто стрельба наугад. Например, в рекламе «новое» считается наиболее эффективной концепцией для продвижения продуктов на рынке, однако когда компания Coca-Cola десять лет назад представила миру новый напиток «New Coke», она потерпела фиаско. Никто не смог бы предсказать такой исход. Вкусы и предпочтения людей меняются случайным образом, поэтому может казаться, что эффективность маркетинга тоже зависит от случая.

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

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

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

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

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

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

Скрытые издержки некачественного программного обеспечения

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

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

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

Одна из самых затратных статей, связанных со сложными в применении программами, - это техническая поддержка. Мiсrоsоft ежегодно тратит 800 миллионов долларов на техническую поддержку. А ведь речь идет о компании, которая тратит многие сотни миллионов долларов на юзабилити-тестирование и исследования. Очевидно компания Microsoft убеждена, что такие масштабы поддержки - неизбежное зло. Я в это не верю. Представьте, какие преимущества получит ваша компания, если вы не будете так думать. Представьте, насколько более эффективными станут ваши усилия по разработке, если вы сможете сохранить пять процентов прибыли, не оплачивая техническую поддержку.

Спросите любого, кому пришлось поработать в службе технической поддержки любой компании, создающей приложения для настольных компьютеров, и этот человек скажет, что большая часть его времени и усилий уходит на разъяснение вопросов, связанных с файловой системой. Совсем как Джейн из главы 1, пользователи не понимают рекурсивную иерархию файловой системы - будь то Finder или Explorer, система Windows, Мас или UNIX. Как ни странно, очень немногие компании тратят средства на проектирование и реализацию более дружественных к человеку альтернатив файловой системе. Все прочие выбирают гораздо более дорогой вариант бесконечной телефонной поддержки по связанным с файловой системой вопросам.

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

Дороже разработки ПО обходится только разработка плохого ПО

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

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

Если проектирование не предшествует программированию, вряд ли оно окажет какое-либо влияние. Один руководитель сказал мне: «Наши люди уже пишут код, и я не собираюсь их останавливать». Эти ковбои думают: «Пока мы будем лететь к земле, я успею сшить парашют». Отважное заявление, однако, мне не довелось видеть ему подтверждения.

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

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

Стоимость возможностей

В эпоху информации дороже всего обходится не создание чего-либо, а потерянная возможность создать это. Создание провального продукта означает, что вы не создали успешный. Если для создания хорошего продукта потребовалось в течение трех лет выпускать по одной его версии, значит, за три года вы не создали три хороших продукта. Основной бизнес компании Novell - сети, но она же пыталась открыто состязаться с Мiсrоsоft в области офисных приложений. Попытки пробиться на этот рынок обошлись Novell очень и очень недешево, однако самой серьезной потерей стала потеря лидерства на сетевом рынке. Деньги - ничто в сравнении с исключительной возможностью момента.

Компания Netscape утратила лидирующие позиции на рынке броузеров точно таким же образом, а именно когда решила состязаться с Мiсrоsоft в сегменте операционных систем.

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

Издержки прототипирования

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

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

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

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

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

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

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

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

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

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

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

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

Ценность прототипа в знаниях, приобретенных в процесс е его создания, а совсем не в коде. Мудрый разработчик Фредерик Брукс говорит: «Планируйте выбросить одну версию». Так или иначе, вы ее выбросите, так почему не запланировать это событие с самого начала?

В 1988 году я продал Биллу Гейтсу программу под названием Ruby, представлявшую собой язык визуального программирования, который в сочетании с продуктом Билла QuickBasic стал средой Visual Basic. Ruby была просто прототипом, но демонстрировала некоторые значительные новшества в подходе и технологии (при первом знакомстве с Ruby Билл спросил: «Как ты это сделал?»). Проектом Ruby стал заниматься тогдашний руководитель разработки Windows 3.0 Расс Вернер. По договору я должен был завершить разработку Ruby и представить полноценный продукт. Первое, что я сделал, - выбросил прототип и начал все с нуля, не имея ничего, кроме знаний и опыта. Когда Расс узнал об этом, он пришел в изумление, ярость и негодование. Он никогда не слышал о столь возмутительных действиях и выражал убежденность, что отказ от прототипа задержит выпуск продукта. Но это был уже свершившийся факт, и, несмотря на страхи Расса мы сдали золотую мастер-копию в срок. После интеграции с языком Basic запуск среды VB стал одним из самых успешных для Microsoft. Windows 3.0, напротив, задержалась более чем на год и впоследствии пользовалась дурной славой из-за большого объема рудиментарного кода, унаследованного из прототипа.

В целом, далекие от технологии руководители ошибочно ценят завершенный код, независимо от его надежности, гораздо выше, чем замысел, или мнение тех, кто этот код писал. Коллега Клэй Колье (Clay Collier), занятый в создании программного обеспечения для автомобильных систем навигации, поведал историю о системе, над которой он работал по заказ у крупной японской автоэлектронной компании. Клэй разработал по просьбе своего клиента прототип системы навигации. Как и подобает хорошему прототипу, он доказывал, что система будет работать, но в целом программа была едва функциональна. Однажды в США прилетел президент этой японской компании - производителя автомобильной электроники. Президент желал увидеть программу в действии. Коллега Клэя, назовем его Ральф, знал, что президенту из Японии отказать нельзя, придется сотворить демонстрацию. Ральф встретил президента в аэропорту на автомобиле, специально оборудованном прототипом навигационной системы. Ральф знал, что прототип может указать дорогу к офисам компании в Лос-Анджелесе, но остальные адреса даже не проверялись. К огорчению Ральфа, президент попросил отвезти его на ланч в конкретный ресторан. Ральф не знал, где находится ресторан, и вовсе не был уверен, что прототип сможет указать туда дорогу. Он скрестил пальцы и набрал название ресторана. К его удивлению, компьютер начал давать указания: «Повернуть направо на Линкольн-стрит», «Перестроиться в левый ряд» И так далее. Ральф послушно следовал указаниям, в то время как президент молча думал о чем-то своем, однако вскоре инструкции привели их в сомнительные районы города, так что Ральф забеспокоился. Его беспокойство достигло предела, когда он остановил машину по команде компьютера, и в этот момент кто-то распахнул дверь автомобиля снаружи. К бесконечному облегчению Ральфа дверь открыл сотрудник ресторана. Президент расплылся в улыбке.

Успех демонстрации прототипа обернулся для Ральфа неприятностями. Президент настолько впечатлился работой системы, что захотел, чтобы Ральф превратил ее в готовый продукт. Ральф возразил, что прототип недостаточно надежен, чтобы стать основой миллионов устройств, но президент ничего не хотел слышать - он же видел, что прототип работает. Ральф согласился, и восемь долгих лет спустя его компания, наконец, поставила первую работающую версию продукта. Она работала медленно, с ошибками и уже не могла угнаться за новыми, более сильными конкурентами. Газета New York Times назвала его «очевидно слабым».

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

* * *

Если определять границы проекта разработки лишь в терминах фиксированных сроков сдачи и перечня функций, даже своевременная сдача продукта не сделает его желанным. Если же определять проект в терминах качества и удовлетворения потребностей пользователей, вы получите востребованный продукт, и сроки разработки не будут более длительными. Старая шутка Кремниевой Долины: «Как сделать небольшое состояние на программном обеспечении?» И ответ, конечно: «Начать с большого состояния!» Скрытые издержки проекта по разработке программного обеспечения, даже при опытном руководстве, достаточно велики, чтобы даже Дональд Трамп задумался. Гонки на яхтах и пристрастие к наркотикам в долгосрочной перспективе обходятся дешевле, чем неконтролируемое создание программного обеспечения.

Глава 4. Танцующий медведь

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

Если это проблема, то почему ее до сих пор не решили?

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

Жертва бытовой электроники

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

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

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

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

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

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

Чем плохи почтовые клиенты

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

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

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

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

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

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

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

Чем плохи программы для планирования

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

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

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

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

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

Чем плохи календари

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

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

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

Кроме того, ни одна из этих программ не учитывает время, которое мне необходимо, чтобы добраться до места встречи. Если мне нужно подъехать на другой конец города к двум часам дня, я должен выйти из дома в половине второго. На какое время я должен назначить встречу, на 1:30 или на 2? Качественно спроектированная программа должна решить этот вопрос самостоятельно и помочь мне выйти вовремя.

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

Массовая веб-истерия

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

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

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

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

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

Что не так с программным обеспечением?

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

Программы забывают

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

Программы ленивы

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

Программы скупы на информацию

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

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

Программы не гибки

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

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

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

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

Программы возлагают вину на пользователей

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

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

Программы не несут ответственности

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

Все очень логично и совершенно неправильно.

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

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

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

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

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

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

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

* * *

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

Глава 5. Нелояльность клиентов

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

Привлекательность

Ларри Кили (Larry Keeley) из Doblin Group создал занимательную концептуальную модель трех важнейших качеств в бизнесе высоких технологий. Кили называет первое качество потенциалом - его источником служат инженеры. Они спрашивают: «На что мы способны? Что возможно?» Инженеры должны знать, что можно создать и чего создать нельзя. Продукт не может стать успешным, если его невозможно создать и заставить работать.

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

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

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

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

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

Третье качество Кили называет привлекательностью, и за эту составляющую отвечают проектировщики. Они должны спрашивать: «Что привлечет людей? Чего они хотят?» Проектировщики должны знать, что сделает людей счастливыми и даст им удовлетворение. Продукт не может иметь долгосрочного успеха, если не дает удовлетворения и ощущения могущества людям, для которых он предназначен.

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

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

Для примера: в начале девяностых годов одним из серьезных игроков на рынке программ для Windows была компания Borland International. У меня была возможность изучить ее бизнес, когда я занимался в этой компании консультированием. В компании существовал замечательный альянс высокопрофессиональных деловых людей и очень сильных разработчиков программного обеспечения. Едва ли не каждый день я знакомился с еще одним впечатляющим экспериментальным проектом. Во главе каждого проекта стояла пара - бизнесмен экстракласса и не менее одаренный разработчик.

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

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

Привлекательность легко перепутать с потребностью, но это кардинально различные свойства. Меня привлекает возможность провести полтора месяца на Бермудских островах, но мне это не нужно. Если у меня желчные камни, то я нуждаюсь в операционном лечении, но меня это не привлекает. Риэлтор Салли нуждается в том, чтобы продать четыре дома в этом году. А возможность обеспечить четыре семьи счастьем и уютом ее привлекает. Она нуждается в МLS-программе, позволяющей опубликовать предложения своих услуг в многочисленных каталогах, но если эта программа будет заставлять ее чувствовать себя глупой, то она ее не привлечет.

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

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

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

Одно сравнение

Существует три известных высокотехнологичных компании, иллюстрирующих динамику треножной модели Кили, каждая со своими плюсами и минусами: Novell, Microsoft, Apple.

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

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

В начале девяностых годов компании Microsoft, 3Com и даже Apple начали поставлять на рынок продукты, обладающие тем же потенциалом, что NetWare, но не ставящие клиентов в жесткую зависимость от приходящих специалистов по установке и особенно по сопровождению. Novell в немом ужасе наблюдала, как испаряется ее лидирующее положение. Как только возникла конкуренция, сказалось отсутствие лояльности клиентуры компании Novell. Сегодня бизнес Novell⁵ в основном заключается в поддержке тех клиентов, которые оказались технологически привязаны к компании. Новые клиенты выбрали другие компании.

Компания Novell была жизнеспособной и обладала крайне высоким потенциалом. Она владела мощной технологией и адекватной деловой хваткой, но пострадала из-за полного отсутствия проектирования взаимодействия.

* * *

История Мiсrоsоft проста. Продукты компании технически полноценны, но редко когда оказываются передовыми. Мiсrоsоft предпочитает стоять на плечах гигантов, уже проведших исследования и разработку⁶. Однако не вызывает сомнения, что Билл Гейтс является одним из самых талантливых бизнесменов своего поколения, а то и века. Он обладает удивительной способностью извлекать успех из практически каждого предприятия, несмотря на возникающие препятствия.

Мiсrоsоft не занимается или почти не занимается проектированием, а ее продукты известны тем, что заставляют пользователей чувствовать себя глупо. Они известны также большим количеством функций.

Многие деловые предприятия и профессионалы испытывают приверженность к продукции Microsoft, но в большинстве своем из-за экономической необходимости и вследствие отсутствия альтернатив. Немногие другие компании способны предоставить столь же полное решение, как Microsoft. Однако не следует путать экономическую необходимость с лояльностью клиентов. Очень немногие пользователи преданы Мiсrоsоft.

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

* * *

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

Такая приверженность дизайну и внимание к деталям взаимодействия создали для Apple граничащую с фанатизмом - и часто переходящую в него - лояльность клиентов. Пользователи компьютеров Macintosh - самые преданные из всех владельцев продуктов, основанных на программном обеспечении. Никакой другой продукт или производитель не вдохновляет на такую личную преданность, как Apple. Клиенты компании наклеивают логотипы Apple на автомобили, заказывают специальные номерные знаки для своих автомобилей, носят футболки Apple, показывают свою принадлежность духу Apple. Они превозносят достоинства Maков любому, кто готов выслушать. В большинстве ситуаций компьютер Wintel удовлетворит все потребности человека лучше, дешевле и быстрее, чем Мак, но Macintosh всегда остается избранным компьютером. На недавней конференции по дизайну только одна докладчица использовала машину Wintel вместо Макинтоша, при этом она очень сильно извинялась перед аудиторией за свое «предательство» - ведь она предала компьютер, единственно достойный обладателя хотя бы зачатков чувства гармонии.

Технологическая доблесть Apple достойна, но лишена величия. С точки зрения технического потенциала Apple в плане инноваций не лучше Мiсrosoft.

У Apple ушло двенадцать лет на потерю лидерства, которое Novell потеряла всего за год. Мало какие проблемы Apple были связаны с внешними факторами. Напротив, эта компания пострадала от поразительного разнообразия ею же самой созданных проблем. К примеру, в середине восьмидесятых Стива Джобса, основателя и главного энтузиаста компании, изгнали и заменили не имеющим отношения к компьютерам и употребляющим только безалкогольные напитки руководителем, который раз за разом принимал негодные с точки зрения бизнеса решения. Завышенные цены на продукцию, плохой маркетинг, злобно-пренебрежительное отношение к сторонним разработчикам программного обеспечения, и помимо прочего Мак оставался закрытой платформой; последняя стратегия широко упоминается как причина свержения других платформ, властвовавших на рынке (таких как VMS, MVS и OS/2).

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

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

Основанная на дизайне преданность заставляет поклонников Маков закрывать глаза на многочисленные преимущества продукции других производителей. Нежелание фанатов использовать другие продукты дает Apple время среагировать на инновации конкурентов. Лояльность покупателей дает Apple способность выдерживать сюрпризы, которые преподносят технологические прорывы. Падение Novell началось в тот же момент, когда конкурент - речь о Microsoft, - предложил жизнеспособный сетевой продукт. Гигантская доля рынка Novell ничего не смогла противопоставить натиску рыночных сил. С другой стороны, Apple, никогда не владевшая более чем 15% рынка компьютеров, упрямо сопротивляется натиск умного численных конкурирующих компьютеров, мощных и дешевых.

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

Учти Novell проектирование, компания могла бы преодолеть последствия слабых маркетинговых ходов. Если Мiсrоsоft когда-либо очнется и осознает значимость проектирования взаимодействия, конкурентам останется только сложить оружие и разойтись по домам. Apple в саморазрушении уподобилась звезде гранж-рока, однако, продолжая восстанавливать прежнюю форму, она может вновь стать жизнеспособной компанией.

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

Время выхода на рынок

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

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

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

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

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

Однако тяжкий труд Билла Гейтса по-прежнему не может пробудить любовь к его продуктам. Более того, средний уровень желанности практически всех высокотехнологических продуктов остается примерно на уровне продуктов Microsoft, несмотря на разум, искренность и тяжелый труд создателей. В следующем разделе я покажу, что за размножение неприятных и нежеланных танцующих программ-медведей ответственны простые, однако практически повсеместно существующие изъяны процесса создания продуктов, основанных на программном обеспечении.

1 Специалист по юзабилити (usability professional), или эргономист, и проектировщик взаимодействия (interaction designer) – разные люди. Подробно о различиях рассказано в главе 12 «В отчаянных поисках эргономики».

2 Мы говорили, что хотим сделать «объединение в сети компьютеров Intel/Windows столь же простым, как объединение в сети компьютеров Macintosh». В то время Mac’и до смешного просто объединялись в сети посредством протокола AppleTalk. Тогда, как и сегодня, объединять ПК Wintel в сети было трудно.

3 Некоторые программы дают пользователю возможность вручную создавать нити и управлять ими, однако лекарство оказывается хуже болезни. Этой возможностью непросто управлять, и нити общения по-прежнему считаются чем-то исключительным.

4 В этом смысле я не лучше остальных программистов. В 1984 году я написал SuperProjects для Computer Associates, одну из первых программ управления проектами. Как и практически все другие программы, появившиеся позже, она полностью игнорировала вопросы взаимодействия нескольких проектов.

5 Впрочем, в индустрии высоких технологий положение дел может измениться очень быстро. Я пишу эти строки весной 1998 года, в то время как Эрик Шмидт, новый президент Novell, начинает реанимировать компанию.

6 В старой шутке говорится, что исследовательское подразделение Microsoft находится в Купертино. Это город в Кремниевой Долине, где расположен центр передовых технологий компании Apple.

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

8 Как указывает Джеффри Мур в своей великолепной книге «Crossing the Chasm» (Пересекая бездну), дополнительные возможности привлекательны лишь для первых пользователей, но не для рынка в целом.