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

Автор книги: Алан Купер

сообщить о нарушении

Текущая страница: 7 (всего у книги 28 страниц) [доступный отрывок для чтения: 11 страниц]

Программный апартеид

В Голливуде шутят, что можно обратиться к незнакомцу в бакалейной лавке и спросить, как продвигается его сценарий. И незнакомец без промедления ответит: «Отлично! Я только что реструктурировал второе действие, чтобы усилить напряжение событий!» Та же шутка теперь верна и в отношении Кремниевой Долины. Вы можете пристать к незнакомке в очереди в кофейне и поинтересоваться, как продвигается работа над веб-сайтом. И она ответит, глазом не моргнув: «Отлично! Я только что реструктурировала фреймы, чтобы улучшить навигацию!»

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

Программисты обычно работают в окружении технически равноценных коллег, в анклавах вроде Кремниевой Долины, трассы 128 в пригороде Бостона, Научного Треугольника в Северной Каролине, Редмонда в Вашингтоне и Остина в Техасе. Разработчики программного обеспечения постоянно встречаются с коллегами в магазинах, в ресторанах, когда отвозят детей в школу, на отдыхе, в то время как их контакт с раздраженными пользователями компьютеров ограничен. Более того, редкие всплески досады пользователей, не направленные ни на кого конкретно, компенсируются частыми проявлениями энтузиазма со стороны продвинутой элиты. Мы забываем, насколько далеки от неудовольствия, вызываемого у других жителей страны (не говоря уже обо всем мире) работой с интерактивными инструментами.

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

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

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

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

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

А как же те, кто не склонен пособничать технократам, не способен или не желает получать компьютерное образование? Такие люди, многие сознательно, а большинство в силу обстоятельств, остаются за бортом информационной революции. К примеру, многие высокотехнологические компании даже не рассматривают кандидатов, не имеющих адресов электронной почты. Уверен, есть множество подходящих по всем остальным параметрам кандидатов, которым не светит найм только потому, что они еще не подключены к Интернету. Что бы ни говорили апологеты, эффективно работать с электронной почтой сложно, это требует значительного уровня компьютерной образованности. Следовательно, речь идет об искусственной изоляции части рабочей силы. С моральной точки зрения это напоминает банковский прием «красная черта». Смысл этого незаконного приема в том, что все дома определенного района объявляются неприемлемыми в качестве обеспечения жилищных займов. Красные линии на карте предположительно проводятся по экономическим контурам, но на деле слишком четко следуют контурам расовым. Банкиры заявляют, что никакого расизма здесь нет, однако результаты именно такие.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

Руководителям известно, что разработка программного обеспечения подчиняется закону Паркинсона: работа увеличивается в объеме, занимая любое отведенное под нее время. Если вы заняты в бизнесе программного обеспечения, то, вероятно, знакомы со следствием закона Паркинсона, известным в качестве правила Девяносто-Девяносто (авторство приписывается Тому Каргилу из Ве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. Однако мы не смогли удерживать лидерство, потому что рассердили своих самых преданных поклонников на этом рынке, не добавив самую нужную для них функцию: концевые сноски. Пытаясь успеть к сроку, мы не смогли включить ее в спецификацию. Мы успели к сроку, но потеряли целый сегмент рынка».