Читать книгу: «Психбольница в руках пациентов. Алан Купер об интерфейсах»
Alan Cooper
THE INMATES ARE RUNNING THE ASYLUM:
Whe High-Tech Products Drive Us Crazy And How to Restore the Sanity
Права на издание получены по соглашению с Addison-Wesley Longman. Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.
Информация, содержащаяся в данной книге, получена из источников, рассматриваемых издательством как надежные. Тем не менее, имея в виду возможные человеческие или технические ошибки, издательство не может гарантировать абсолютную точность и полноту приводимых сведений и не несет ответственности за возможные ошибки, связанные с использованием книги.
Серия «Библиотека программиста»
© 2004 by Sams Publishing
© Перевод на русский язык ООО Издательство «Питер», 2018
© Издание на русском языке, оформление ООО Издательство «Питер», 2018
© Серия «Библиотека программиста», 2018
© ООО Издательство «Питер», 2018
* * *
Сью, Скотту и Марти, с любовью
Благодарности
Этой книги не было бы без помощи и поддержки многих моих замечательных друзей и коллег. Некоторые из них, в частности, выполняли сложную работу со множеством требований – вычитывали и комментировали рукопись, иногда даже по несколько раз. Благодаря их комментариям я отвечал на нелегкие вопросы, предлагал новые темы, резюмировал свои убеждения, усмирял свой пыл и брал в узду свое возмущение. Еще лучше этой книге помогли стать Ким Гудвин (Kim Goodwin), Лейн Хэлли (Lane Halley), Келли Боуман (Kelly Bowman), Скотт Макгрегор (Scott McGregor), Дэвид Уэст (David West), Майк Нельсон (Mike Nelson), Марк Джирск (Mark Dziersk), Алан Карп (Alan Karp), Терри Суок (Terry Swack), Луи Вейцман (Louie Weitzman), Уэйн Гринвуд (Wayne Greenwood), Райан Ольшавски (Ryan Olshavsky), Джон Майер (John Meyer), Лайза Сондерс (Lisa Saunders), Винни Шоуз (Winnie Shows), Кевин Вандрайк (Kevin Wandryk), Глен Халстед (Glenn Halstead), Брайан О’Салливан (Bryan O’Sullivan), Чак Оуэн (Chuck Owen), Майк Суэйн (Mike Swaine), а также Скип Уолтер (Skip Walter). Я благодарен всем вам за ваше время, поддержку и мудрость. Особую ценность для меня также возымели советы и комментарии Джонатана Кормана (Jonathan Korman) – с их помощью я смог лучше выделить темы для книги. Я также должен поблагодарить всех невероятно талантливых и трудолюбивых сотрудников из Cooper Interaction Design, которые взяли мои обязанности на себя, пока я занимался подготовкой книги. Особую благодарность выражаю директору по проектированию Уэйну Гринвуду (Wayne Greenwood), которому пришлось работать в жестких стрессовых условиях, сохраняя при этом высокое качество наших проектов и не утрачивая боевой дух.
Одним из самых интересных вызовов при создании этой книги стала задача подготовки иллюстраций. Чед Кубо (Chad Kubo), гениальный создатель иллюстраций, проделал невероятную работу по претворению моих смутных задумок в четкие и запоминающиеся изображения. Благодаря им книга заиграла другими красками. Но этих иллюстраций не было бы без интенсивного руководства художественной частью в исполнении Пенни Бейлес (Penny Bayless) и Дэвида Хейла (David Hale). Другие специалисты помогали с решением производственных задач. Я благодарю Брит Кацен (Brit Katzen) за выверку фактов и исследования, а также Майка Генри (Mike Henry) за редактуру текста.
Создание книги – это бизнес-проект, и за его успех я должен выразить благодарность моей команде подкованных в технологиях предпринимателей, во главе которой стоял мой агент Джим Левайн (Jim Levine), а саму команду составляли Глен Халстед (Glenn Halstead), Линн Боуман (Lynne Bowman), Келли Боуман (Kelly Bowman) и Сью Купер (Sue Cooper). Также поддержку по ходу всего проекта оказывало и издательство Pearson в лице Брэда Джоунса (Brad Jones), но самые большие благодарности я хотел бы высказать Крису Веббу (Chris Webb) за его целеустремленность, высочайшую концентрацию и тяжелый труд, без которых эта книга вообще бы не состоялась.
Для меня невероятно ценно внимание всех тех людей, что оказывали мне моральную поддержку, а также снабжали меня историями, советами и тратили на проект время. Огромное спасибо таким людям, как Дэниел Эпплман (Daniel Appleman), Тодд Баше (Todd Basche), Крис Байер (Chris Bauer), Джефф Безос (Jeff Bezos), Элис Блэр (Alice Blair), Мишель Борк (Michel Bourque), По Бронсон (Ро Bronson), Стив Калде (Steve Calde), Дэвид Карлик (David Carlick), Джефф Карлик (Jeff Carlick), Кэрол Кристи (Carol Christie), Клэй Коллье (Clay Collier), Кендалл Косби (Kendall Cosby), Дэн Крэйн (Dan Crane), Роберт Крингели (Robert X. Cringely), Трой Дэниелс (Troy Daniels), Лайза Пауэрс (Lisa Powers), Филип Энглхарт (Philip Englehardt), Карен Ивенсен (Karen Evensen), Риджели Эверс (Ridgely Evers), Ройял Фаррос (Royal Farros), Пэт Флек (Pat Fleck), Дэвид Фор (David Fore), Эд Форман (Ed Forman), Эд Фридкин (Ed Fredkin), Жан-Луи Гассе (Jean-Louis Gassee), Джим Гэй (Jim Gay), Pacc Голдин (Russ Goldin), Влад Горелик (Vlad Gorelik), Марсия Грегори (Marcia Gregory), Гаррент Грюнер (Garrett Gruener), Чак Хартледж (Chuck Hartledge), Тед Харвуд (Ted Harwood), Уилл Хирст (Will Hearst), Тамра Хизершоу-Харт (Tamra Heathershaw-Hart), Джей-Ди Хильдебранд (JD Hildebrand), Лори Хиллз (Laurie Hills), Питер Хиршберг (Peter Hirshberg), Ларри Кили (Larry Keeley), Гэри Краткин (Gary Kratkin), Дебора Курата (Deborah Kurata), Том Лефлер (Tom Lafleur), Пол Лотон (Paul Laughton), Элен Леви (Ellen Levy), Стивен Лист (Steven List), Ти-Си Манган (ТС Mangan), Дэвид Майстер (David Maister), Роберт Мэй (Robert May), Дон Маккини (Don McKinney), Кэтрин Медоуз (Kathryn Meadows), Лайза Митчелл (Lisa Mitchell), Джеффри Мур (Geoffrey Moore), Брюс Мовери (Bruce Mowery), Нат Майерс (Nate Myers), Эд Нихаус (Ed Niehaus), Констанс Петерсен (Constance Petersen), Кит Плис (Keith Pleas), Роберт Райнман (Robert Reimann), Джон Ривлин (John Rivlin), Говард Рейнгольд (Howard Rheingold), Хайди Ройцен (Heidi Roizen), Нил Рубенкинг (Neil Rubenking), Пол Сафо (Paul Saffo), Джош Зайден (Josh Seiden), Pacc Зигельман (Russ Siegelman), Донна Слоут (Donna Slote), Линда Стоун (Linda Stone), Тони Уокер (Toni Walker), Кевин Уикс (Kevin Weeks), Кевин Уэлш (Kevin Welch), Дэн Уиллис (Dan Willis), Хизер Уинкл (Heather Winkle), Стефан Уайлдстром (Stephen Wildstrom), Терри Виноград (Terry Winograd), Джон Цикер (John Zicker) и Пьерлуиджи Заппакоста (Pierluigi Zappacosta).
Этот проект «сроком на год» занял двадцать месяцев, и моя семья проявила величайшее терпение. Я в большом долгу любви и благодарности перед моей супругой Сью Купер и моими прекрасными юными сыновьями Скоттом и Марти. Люблю вас всем сердцем.
Предисловие
Спасайся кто может – мир захватывают компьютеры. Великолепные, мощные, они справляются с еще более важными задачами посредством ужасных, старомодных интерфейсов. Все больше проникая во все сферы жизни человека, они будут злить, раздражать нас, а некоторых способны даже убить. В ответ мы тоже будем безумно желать уничтожить наши компьютеры, но не осмелимся, потому что мы уже так сильно, неразрывно привязаны к ним, к этим монстрам, обещающим нам столь многое и без которых современная жизнь уже немыслима.
К счастью, выход есть. Мы должны фундаментально переосмыслить взаимодействие компьютера и человека. Изменить эти взаимоотношения на более глубоком уровне, применяя новаторские подходы, потому что причина наших все возрастающих проблем кроется вовсе не в машинах, а внутри нас самих. Именно люди создали интерфейсы, которые нас так раздражают; люди продолжают использовать ставшие нефункциональными машины, невзирая на то, что эти ужасные интерфейсы утомляют глаза, приводят к боли в спине и вредят сухожилиям в запястьях. Как следует из названия этой книги, все мы стали безумцами, обитающими в технологическом сумасшедшем доме, и создали этот безумный мир мы сами.
Эта книга – наш путь к спасению. А точнее, целью Алана Купера было показать, что дверь на свободу и без того широко раскрыта. Мы вольны выйти в любой момент, но, ослепленные безумием, мы до сих пор не замечали выхода. Весь секрет в том, чтобы переопределить способ, которым мы взаимодействуем с компьютерами, и сделать это в более широком контексте.
Сам Алан Купер – не просто такой же безумец, как и все мы; он еще и еретик, чьи взгляды способны разъярить тех, кто намерен держать нас в заключении. А желают этого инженеры, которые и разрабатывают столь ненавистные нам системы и по-прежнему придерживаются мнения, что единственный выход из этого ужаса – еще больше совершенствовать интерфейсы. Только сама концепция интерфейса – это реликвия из той поры, когда компьютеры были не столь распространены, их производительность была слабой, а сами они не слишком эффективно взаимодействовали с людьми, которые ими управляли. Интерфейсы были полезны, когда все взаимодействие с пользователем происходило через неизведанную территорию на стеклянном экране компьютера. Теперь же, в эпоху, когда компьютеры проникают в каждый уголок нашей жизни, мыслить категориями интерфейсов становится даже опасным. Компьютеры больше не используют интерфейсы лишь в качестве «прослойки» между пользователем и их внутренним устройством – теперь они взаимодействуют с людьми, и такое взаимодействие будет лишь переходить на более глубокий уровень, становиться все более незаметным и более критичным для здравомыслия нашего общества и всеобщего выживания.
Алану Куперу разница между интерфейсом и взаимодействием знакома как никому другому. Его идеи произрастают из многолетнего опыта по содействию в проектировании продуктов, мягко и ненавязчиво заполоняющих мир вокруг нас. Он апробировал свои идеи на практике в течение долгих лет, и теперь, наконец, у него появилось время преобразовать полученный практический опыт в четкое описание того вызова, с которым мы столкнулись, в методологию побега из сумасшедшего дома, который мы воздвигали с такой любовью. Читайте эту книгу, и вы станете свободными.
Пол Саффо (Paul Saffo), директор Института будущего
Предисловие к оригинальному изданию
Книга-обоснование
Изначально я собирался написать совершенно другую книгу – книгу-руководство о процессе проектирования взаимодействия. В мае 1997 года, во время поездки в Тоскану двое моих друзей, Дон Маккини (Don McKinney) и Дэйв Карлик (Dave Carlick), уговорили меня написать книгу, которую вы держите в руках. Они убедили меня, что следует, прежде всего, обращаться к деловой аудитории.
Они знали о моем намерении написать руководство, но сомневались в востребованности книги о проектировании взаимодействия (interaction design). Они хотели, чтобы я написал книгу о том, насколько важен и нужен этот процесс. Предложение друзей было, конечно, интересным, но я не был уверен, что смогу.
Однажды поздней ночью на веранде нашей общей виллы с видом на Флоренцию у меня состоялся серьезный разговор с Дэйвом и Доном. На столе несколько пустых бутылок из-под кьянти и остатки хлеба, сыра и оливок. Сияют звезды, светлячки танцуют на лужайке, а вдалеке подмигивают огни древних куполов столицы Тосканы. Дэйв снова предложил мне отказаться от идеи книги-руководства и вместо этого «дать деловое обоснование проектированию взаимодействия».
Я энергично запротестовал: «Дэйв, я же не знаю, как писать такую книгу». И начал загибать пальцы: «Мне придется объяснять, насколько мерзок тот процесс разработки, что существует сейчас, как компании теряют деньги на неэффективном создании программного обеспечения, как ненадежны неудовлетворенные клиенты и как все эти проблемы способен разрешить более совершенный процесс проектирования».
Дэйв перебил меня: «Алан, это называется главами».
Его ответ лишил меня сил сопротивляться дальше. Я вдруг осознал, что повторяю избитый сценарий и что Дэйв прав. Книга, содержащая «бизнес-обоснование», необходима и более своевременна, чем книга-руководство. Дэйв и Дон убедили меня, что я действительно способен написать такую книгу.
Инженер, разбирающийся в бизнесе, либо бизнесмен, разбирающийся в технологиях
Успешный профессионал XXI века – это либо инженер, разбирающийся в бизнесе, либо бизнесмен, разбирающийся в технологиях, и именно такому человеку адресована моя книга.
Бизнесмен, разбирающийся в технологиях, понимает, что его успех зависит от качества доступной ему информации и его умения воспользоваться этой информацией. Инженер, разбирающийся в бизнесе, – это предприимчивый конструктор или ученый, специализирующийся на технологиях, но при этом обладающий деловой хваткой и осознающий, какая огромная сила заключена в информации. Оба новых архетипа будут доминировать в современном бизнесе.
Всех деловых людей можно разделить на две категории: на тех, кто овладеет высокими технологиями, и тех, кто скоро выйдет из бизнеса. Руководители больше не могут делегировать обработку информации специалистам, ведь бизнес и есть обработка информации. Сегодня вы можете выделиться качеством своих систем обработки информации, но не качеством систем производства. Если вы производите что-либо, скорее всего, в вашем продукте есть микросхема. Если вы предлагаете услугу, то, скорее всего, вы используете компьютеризованные инструменты. Попытка определить, какие предприятия зависят от высоких технологий, столь же глупая затея, как попытка определить, какие предприятия зависят от телефона. Революция высоких технологий затронула все сферы деловой деятельности, а цифровая информация стала основой ваших трудовых будней.
Кто-то сказал: «Человеку свойственно ошибаться, но чтобы провалить дело капитально, нужен компьютер». Неэффективные механические системы способны приносить незначительные убытки на каждой производимой детали, однако из-за некачественных информационных процессов можно потерять целую компанию. Влияние на вашу компанию продуктов, основанных на программном обеспечении, как и влияние инженеров, создающих эти продукты, огромно.
К сожалению, наши цифровые средства сложны для изучения, понимания и применения; они часто препятствуют достижению наших целей. Мы теряем деньги, время, возможности. Будучи инженером, понимающем в бизнесе, или же бизнесменом, понимающем в технологиях, вы создаете или потребляете продукты, основанные на программном обеспечении, а вернее всего, потребляете и создаете одновременно. Обладание более совершенными, более простыми в освоении и применении высокотехнологичными продуктами – в ваших личных и профессиональных интересах. Более качественные продукты не требуют больших временных и денежных затрат на свое создание. Ирония в том, что они не должны быть сложными и являются таковыми лишь потому, что устарели процессы их создания. Лишь давние традиции, основанные на заблуждениях, мешают нам сегодня получить более качественный продукт. Эта книга покажет вам, как можно требовать и получать лучшие продукты – продукты, которых вы заслуживаете.
Идея этой книги незамысловата: мы можем создавать мощные и приятные продукты, основанные на программном обеспечении, используя простой прием: проектируя взаимодействие продукта с пользователем до этапа программирования. Сегодня мы этого не делаем. Проектирование интерактивных продуктов, использующих программное обеспечение, – специализация столь же сложная, как собственно разработка.
* * *
Сделав выбор в пользу книги-обоснования и отказавшись от книги-руководства, я прошу прощения у каждого проектировщика взаимодействия, который возьмет в руки эту книгу. Из уважения к деловой части аудитории она содержит лишь краткие отступления в область практической методологии проектирования взаимодействий (в основном в главах части IV). Я включил лишь необходимое количество информации, чтобы показать, что такая методология существует, что она применима в любой предметной области и что ее преимущества очевидны всем, независимо от технических знаний.
Алан Купер,Пало-Альто, Калифорнияwww.cooper.cominmates@cooper.com
Предисловие ко второму изданию
Недавно я познакомился с топ-менеджером одной из крупнейших технологических компаний мира. Официальное название его должности – вице-президент по вопросам простоты использования, и он несет ответственность за очень многие программные продукты, как небольшие, так и крупные. Это выдающийся и состоявшийся человек, выходец из сообщества HCI (Human-Computer Interaction, взаимодействие человека и компьютера), где принят формализованный подход. Он, как и его компания в целом, искушен в «юзабилити» – в тестировании и наблюдении из-за односторонних зеркал. Однако он пришел поговорить со мной не о тестировании, а о проектировании, и не о пользователях, а о персонах. Он рассказал, что в его компании полностью прекращено тестирование юзабилити на завершающей стадии разработки; вместо этого усилия прикладываются до начала разработки – при проектировании. Более того, он упомянул, что все его люди, умеющие и привыкшие наблюдать за пользователями в искусственных условиях, проходят переподготовку и будут заниматься этнографическими исследованиями в «полевых» условиях.
Этот топ-менеджер и его компания – символ тех огромных изменений, которые произошли в отрасли за пять коротких лет с момента выхода в 1999 году первого издания книги The Inmates Are Running the Asylum («Психбольница в руках пациентов»). Книга стала одновременно и манифестом для революции, и учебником. Не сосчитать, сколько писем я получил от менеджеров среднего звена, в которых рассказывалось, как после прочтения книги они покупали по экземпляру каждому из своих руководителей. Между тем разработчики программного обеспечения и университеты восприняли три главы части IV как исходный материал для руководства «сделай сам» по претворению в жизнь целеориентированного (Goal-Directed®) проектирования с использованием персон.
Я глубоко признателен всем менеджерам, программистам, руководителям и специалистам по юзабилити за то, что они воспользовались моими идеями и вывели юзабилити из лаборатории в жизнь, сместили фокус с тестирования на проектирование. Благодаря их усилиям полностью изменилась профессия специалиста по юзабилити. Сегодня в большинстве организаций, с которыми я контактирую, на полной ставке работают один или несколько профессиональных проектировщиков взаимодействия, и влияние этих людей на качество и поведение программных продуктов и услуг постоянно растет. Мне приятно осознавать, что эта книга способствовала их успеху.
Помню, как читал программную речь на конференции программистов в 1999 году, вскоре после опубликования книги. Название речи совпадало с названием книги, и свою речь я начал со слов, что «психбольница находится в руках пациентов, и эти пациенты – вы». В аудитории воцарилась гробовая тишина: 2500 инженеров пытались осмыслить мое обвинение. Я продолжил представлять основные идеи книги, и час спустя это сборище Хомо логикус настолько прониклось моими аргументами, что мне аплодировали стоя. Удивительно, но большинство программистов с энтузиазмом восприняли идеи проектирования и проектировщиков взаимодействия. Они понимают, что нуждаются в помощи там, где речь идет о человеческой стороне конструирования программ, и счастливы получить, наконец, некоторые полезные указания. Программисты признают, что любая практика, повышающая качество и успех программ, не является для них угрозой.
В прошлом руководители считали проектирование взаимодействия задачей программирования и делегировали ее решение программистам, которые прилежно трудились над ней, хотя их опыт, подготовка, образ мышления и рабочий график не позволяли добиться успеха. В духе диагностики проблем эта книга подробно описывает такой провал, который всегда оказывается провалом программиста. Некоторые из программистов восприняли книгу враждебно, подумав, будто я злословлю или пытаюсь переложить на программистов вину за некачественный софт. Определенно, некачественные программы создаются при их участии, но они никоим образом не заслуживают осуждения. Я не виню программистов за сложные в использовании программы, и мне очень жаль, что у некоторых из них сложилось обратное впечатление. За некоторыми исключениями, знакомые мне программисты прилежны и добросовестны в своем желании угодить конечным пользователям, и стремятся неустанно повышать качество программ. Подобно пользователям, программисты – лишь жертвы несовершенного процесса, характеризующегося цейтнотом, противоречивыми указаниями и недостаточно эффективным руководством. Мне очень жаль, если у кого-то из программистов сложилось впечатление, будто я их обвиняю.
Жесткий процесс создания программ, в особенности высокая стоимость программирования и низкое качество взаимодействия, – проблема, попросту говоря, не технического плана. Это результат применения бизнес-практик в том направлении, в котором они устарели, – в разработке программ. С чистым сердцем, благими намерениями и с благословения руководства программисты пытаются решить эту проблему инженерным путем. Но работать интенсивнее здесь не помогает. Программисты ощущают все большую тщетность своих усилий, и их отчаяние нарастает.
Из нескольких своих недавних поездок я сделал вывод, что тревога в сообществе программистов нарастает. К сожалению, хуже всего чувствуют себя лучшие и опытные программисты. Они прикладывают титанические усилия, но излучают цинизм и впадают в тоску, понимая, что их умения растрачиваются попусту. Они могут и не знать точно, как именно получается, что их квалификация не находит правильного применения, но они не могут не видеть очевидного. Многие из лучших программистов вообще перестали программировать, поскольку работа раздражает их. Они ушли в преподавание, религию, писательство, консультационную сферу, потому что эти занятия не оставляют ощущения пустой траты времени и сил. Но этих трагических потерь вполне можно избежать. (В некотором смысле движение свободных программ с открытым кодом можно назвать раем для этих отчаявшихся программистов – тут они могут писать код по своим стандартам и быть судимыми только равными, не выслушивая советы от маркетологов или руководителей.)
Программистам не хватает времени, четких указаний и адекватных планов, позволяющих добиться успеха. Эти три кита – на совести руководителей, именно они не дают всего этого программистам, причем вовсе не по злому умыслу или по глупости, а по причинам, которых можно было бы избежать. Они просто не вооружены адекватными инструментами, позволяющими решать сложные и уникальные проблемы информационной эпохи. Ну вот, звучит так, будто я снова кого-то критикую, но на этот раз в мой прицел попали бизнесмены, а не программисты. Повторюсь, чтобы решить проблему, ее следует сначала разобрать на составляющие. Я ищу решения, а не козлов отпущения.
Мудрый руководитель Питер Друкер (Peter Drucker) в свои девяносто два года, большую часть которых он провел, направляя действия руководителей, смотрит на эту проблему со своей, уникальной точки зрения. В недавнем интервью журналу CIO он упомянул о наивном оптимизме руководителей в 1950-е – 1960-е годы, когда компьютеры только прокладывали дорогу в деловой мир. Эти руководители думали, что компьютеры «окажут огромное воздействие на способы ведения бизнеса», но Друкер утверждает: «Но так не случилось. Очень немногие руководители задавали вопрос: „Какая информация мне требуется для выполнения данной работы?“» Компьютеры дали руководителям небывалые объемы данных, но лишь немногие поинтересовались, подходят ли эти данные для управления корпорацией. Образ существования бизнеса менялся очень быстро, однако менеджмент остался прежним. Друкер нападает на наши устаревшие бухгалтерские системы, рожденные в эпоху меркантилизма, повзрослевшие в век пара и стали и угасающие на пороге XXI века, эпохи информации. Друкер говорит: «Самая нужная вам информация – информация о внешнем мире, и этой информации у вас нет».
В последние несколько лет XX века, по мере раздувания мыльного пузыря доткомов, целые цистерны чернил уходили на продажу идеи, что в интернете существует «новая экономика». Знатоки утверждали, что продажа вещей во Всемирной паутине, где магазины строят из страниц, а не из кирпичей, принципиально отличается от привычных стилей бизнеса и что «старую экономику» уже не оживить. Разумеется, почти все компании новой экономики мертвы, финансисты, поддержавшие их, пережили шок, а эксперты, пропагандировавшие новую экономику, теперь заявляют, что то была пустая мечта. Новая-преновая линия такова, что нам суждено пока оставаться со старой-престарой экономикой.
Вообще говоря, я считаю, что мы живем при новой экономике. Более того, я думаю, что доткомы никогда не были ее частью. Напротив, они стали последним вздохом старой экономики, экономики производства.
В промышленную эпоху, до появления программ, продукты создавались из реальных материалов – из атомов. Затраты на добычу, плавку, приобретение, транспортировку, нагрев, формовку, сварку, окраску и снова транспортировку преобладали над всеми прочими расходами. В бухгалтерском учете эти расходы называются «переменными затратами», поскольку они различны для каждого продукта. «Фиксированные затраты», как вы, наверное, догадываетесь, очевидным образом не меняются и включают такие затраты, как корпоративное администрирование или начальная стоимость завода.
Классические правила управления бизнесом обусловлены производственными традициями промышленной эпохи. Однако эти правила не учитывают новые реалии эпохи информационной, в которой продукты уже не создаются из атомов, а состоят в основном из программного кода, из наборов битов. А биты не подчиняются тем же экономическим правилам, что атомы. Некоторые фундаментальные истины остаются справедливыми и для новой экономики. Цель любого бизнеса – стабильная прибыль, и есть лишь один законный способ получать ее: продавать товары или услуги дороже, чем обходится их создание. Из этого следует, что есть два пути повышения прибыльности: снижение затрат или рост прибыли. В старой экономике лучшим способом было снижение затрат. В новой экономике куда лучше работает рост прибыли.
Сегодня наиболее нужные и дорогие продукты состоят (полностью или почти полностью) из программного обеспечения. Они не требуют сырья. У них нет стоимости производства. Они не требуют затрат на транспортировку. Не требуют литья, обработки, покраски. Вот она, реальная разница между экономикой промышленной эпохи и экономикой эпохи информационной: в информационную эпоху практически или совсем отсутствуют переменные затраты, тогда как в позднюю промышленную эпоху именно эти затраты были главным фактором. Очевидно, что именно отсутствие переменных затрат делает новую экономику новой.
Зарплата программистов в вашем штате – фиксированные затраты или переменные? Один час работы программиста нельзя связать с одной продажей продукта – один и тот же код можно продавать много раз. Вложение в программирование можно амортизировать продажей миллионов копий продукта – точно так же, как продажа продуктов, созданных на заводе, амортизирует вложения в этот завод.
Стоимость создания программ не переменна, но и не фиксирована тоже. Разработка программ – это непрерывный процесс для компании, приносящий прибыль, и это совсем не то же самое, что строительство завода. Высокооплачиваемые строители завода после завершения работ уходят на другую рабочую площадку. Программисты стоят гораздо дороже плотников и сварщиков и никогда не исчезают, потому что, по всей видимости, их работа никогда не кончается. Кто-то может сказать, что программирование – это научно-исследовательские работы, и сходство действительно есть. Однако же научно-исследовательская работа – это гипотезы и эксперименты, призванные оценить теоретическую жизнеспособность продукта, и они происходят совсем не так, как настоящее создание продуктов. Эта мысль подтверждается тем, что традиционный бухгалтерский учет разделяет исследования/разработку и ежедневную деятельность, приносящую прибыль. Создание программ не попадает ни в одну из этих категорий учета, приемлемых для прежних предприятий.
Да, этим маленьким терминологическим несоответствием можно было бы и пренебречь как придиркой, уместной в беседе счетоводов за кружкой пива, но в действительности оно оказывает огромное влияние на финансирование разработки программ, на управление проектами по разработке и, что самое важное, на то, как к разработке программ относятся топ-менеджеры.
Программисты создают приложения, а руководители создают потоки прибылей и структурные подразделения. Программисты оценивают свой успех по качеству продукта, а руководители – по прибыльности вложений. Эту прибыльность они оценивают на языке математических терминов, позволяющем учитывать фиксированные затраты, переменные затраты, затраты на корпоративное администрирование, исследования и разработку, но, к сожалению, не описывающем подходящие модели для программ и программирования. Бухучет – основной язык бизнеса, и перечисленные категории настолько фундаментальны для всех оценок предпринимательской деятельности и коммуникации в бизнесе, что современные руководители полностью их усвоили. Программирование для них – еще одна статья корпоративных расходов, которую следует причислить к одной из существующих категорий. На практике большинство руководителей расценивают программирование как производственный процесс, имеющий переменные затраты. (Для целей налогообложения в большинстве компаний-разработчиков ПО программирование проходит по статье исследований и разработок, но во всех остальных отношениях расценивается как деятельность с переменными затратами.) Это худший выбор из всех возможных, поскольку он наносит серьезный ущерб процессу принятия бизнес-решений.
В промышленную эпоху основным преимуществом была массовость, которая позволяла снижать цены и делать продукцию доступной для широких слоев населения. Покупатель при этом получал функции, которые ранее были не доступны или доступны для богатых людей, поскольку производились вручную. Компании конкурировали в области продажных цен, непосредственно связанных с переменными затратами – затратами на производство и доставку. В информационную эпоху доступность продукции по разумным ценам считается обстоятельством само собой разумеющимся. В конце концов, программы можно распространять через интернет – практически бесплатно и почти не прилагая усилий.
Как вы помните, бизнес может повышать доходность за счет роста прибыли или сокращения расходов. Другими словами, предприятие может увеличивать инвестиции в области фиксированных затрат, повышая качество продукции и укрепляя таким образом ценовые позиции, или же снижать переменные затраты, что означает снижение стоимости производства. В старой, «атомной» экономике снижение затрат давалось легко и было эффективным и предпочтительным. Сегодня же руководители, ставящие программирование на одну доску с производством, воображают, будто снижение стоимости программирования дается так же легко и оказывается таким же эффективным. К сожалению, старые правила больше не действуют.
Поскольку производство программ сопровождается незначительными переменными затратами, снижение этих затрат не дает преимущества в бизнесе. С точки зрения бухгалтера зарплаты программистов – переменные затраты, однако в действительности их зарплаты представляют собой долгосрочные вложения, фиксированные затраты. Снижение стоимости программирования и снижение стоимости производства – разные вещи. Первое можно сравнить, скорее, с раздачей работникам дешевых инструментов, чем со снижением зарплат. Компании, заказывающие разработку в других странах с целью снижения зарплат, просто не понимают сути дела.
Более того, единственно возможный вариант для экономического подъема – это повышение качества и, как следствие, привлекательности продукта или услуги, а повышения качества невозможно добиться, сокращая затраты на проектирование и программирование. Правда в том, что в исследования, анализ, планирование и проектирование следует вкладывать больше времени и денег, чтобы полученный результат лучше соответствовал потребностям потребителя.
Разумеется, такой подход требует мышления, непривычного для предпринимателей XXI века. Им следует не снижать затраты на создание каждого объекта в отдельности, а повышать затраты на создание всей совокупности объектов. В этом суть новой экономики, и именно об этом говорит Питер Друкер.
Современные фармацевтические компании, разрабатывающие высокотехнологичные лекарства, имеют кое-что общее с новой экономикой программного обеспечения. Действительная стоимость производства одной таблетки минимальна, однако разработка лекарства может обойтись в миллиарды долларов и продолжаться более десяти лет. Подъем после выхода на рынок нового волшебного препарата может длиться до бесконечности, а вот выпуск недоработанного препарата способен принести только катастрофический спад. Фармацевтические компании знают, что снижение издержек на разработку – нежизнеспособная стратегия.
Как и разработка лекарственных препаратов, разработка ПО совсем не похожа на строительство завода. Завод – физический актив, который принадлежит компании, а работников завода, как правило, легко заменить другими. Неосязаемые, но невероятно сложные паттерны мыслей, составляющие программное обеспечение, обладают ценностью только вместе с написавшим код программистом. Ни одна компания не может себе позволить относиться к программистам так же, как к заводу. Программисты требуют постоянного внимания и поддержки, причем гораздо большей, чем любой завод.
Чаще всего пытаются сэкономить на архитектуре программного продукта, а эта часть проектирования (во время которого изучаются пользователи, определяются сценарии работы, проектируется взаимодействие, определяется форма, описывается поведение) выполняется человеком. Конечно, иногда проектированию уделяют слишком большое внимание, но сокращение этой фазы пользы точно не приносит. Каждый доллар и каждый час, потраченные на архитектуру, принесут десятикратную экономию на этапе программирования. Кроме того, вложения в достаточно качественное проектирование сделают ваш продукт привлекательным, а это означает, что продукт принесет больше прибыли. Его привлекательность станет основой для вашего бренда, создаст возможности для повышения цен, сделает клиентов лояльными, подарит вашему продукту более долгую и плодотворную жизнь. И хотя здесь нет экономии средств, вы получаете большое преимущество в смысле качества. По иронии судьбы лучший способ увеличить прибыльность в информационную эпоху состоит в том, чтобы больше потратить.
К сожалению, в руководителях живет практически неистребимое желание расходовать на программирование поменьше времени и средств. Они не считают тактику сокращения затрат устаревшей и не понимают, что сокращение инвестиций в программирование крайне негативно влияет на качество, привлекательность и прибыльность продукта в долгосрочной перспективе. Разумеется, простым повышением затрат не добиться улучшений. Зачастую ситуация даже ухудшается, если деньги вкладываются бездумно, без анализа и правильного руководства. Мой первый наставник, Дэн Хоакин (Dan Joaquin), любил повторять, что старую истину «получаешь то, за что платишь» нужно поменять на «не получаешь того, за что не платишь». Действия без планирования всегда чреваты риском потратить слишком много. Фокус в том, чтобы потратить правильное количество денег, а для этого нужно разбираться в управлении созданием программного обеспечения. Еще для этого нужны процессы, обеспечивающие руководителей пониманием и информацией для принятия верных решений. Дать компаниям такие процессы – цель этой книги.
В буме доткомов участвовали компании с бизнес-моделями, полностью ориентированными на снижение переменных затрат. Хотя многие доткомы рекламировали преимущества онлайн-покупок, их сайты, тяжеловесные и неудобные, были плохой альтернативой обычной поездке в торговый центр. Основатели доткомов просто лучились от восторга (и пресса, кстати, тоже), потому что им удалось создать предприятия розничной торговли с невероятно низкими переменными затратами. Феерический провал этих предприятий, несомненно, доказывает, что информационной эпохой правят иные экономические правила, чем промышленной эпохой.
В старой экономике более низкие переменные затраты приводили к более широкому распространению товара и снижению розничных цен. Это двойное преимущество было выгодно покупателям, а покупатели – фундамент экономического успеха промышленной революции. В новой экономике успех бизнеса зависит от способности дать потребителю что-то новое и более качественное. Реальное качество каждого шага транзакции – от просмотра страниц до сравнения товаров – должно быть ощутимо более высоким для пользователя. Гораздо приятнее сделать покупку обычным путем, чем продираться через 11 экранов и в конечном итоге выяснить, что все равно придется звонить в компанию. Покупки в сети становятся совершенно ненужными и непривлекательными, если требуется набрать свое имя, свой адрес и ввести информацию о кредитной карте три или четыре раза, а затем обнаружить, что сайт не позволяет купить все необходимое и все равно придется ехать в обычный магазин, сделанный из атомов. Сегодня простое снижение цены на продукт уже не дает гарантии успеха.
Компания Pets.com, специализирующаяся на продаже корма для собак через интернет, не предлагала более качественный корм, как не предлагала и шопинг, более приятный, чем в обычном зоомагазине; она не предлагала новую информацию, новые возможности, новую уверенность. Она предлагала лишь дешевую доставку, складирование и торговлю (все это переменные затраты) на сайте Pets.com. Компания применила классическую тактику снижения затрат, характерную для промышленной эпохи, проигнорировав фундаментальные принципы новой экономики. Конечно, это было еще не первое дыхание новой экономики, но для старой это были последние судороги. Я совершенно убежден, что любой товар можно продавать через интернет успешно и прибыльно. Для этого всего лишь нужно, чтобы в онлайн-магазине было намного приятнее покупать, чем в конкурирующих розничных сетях, и цена здесь – всего лишь один из факторов. Есть лишь один способ добиться этого: архитектуру системы следует создавать с целью максимально удовлетворить конечного пользователя. Нельзя относиться к любому аспекту проектирования и создания программного обеспечения как к производственному процессу – это повлечет за собой провал. Проектирование и программирование – это неподходящие цели для традиционных методов сокращения затрат. Конечно, можно потратить на создание программ слишком много времени и денег, но опасность потратить меньше необходимого гораздо серьезнее.
Скорее всего, эта опасность вам знакома и удивления не вызывает, но большинству топ-менеджеров крупных компаний сама идея кажется неприемлемой. Эти руководители до сих пор работают по моделям бухучета, вошедшим в моду в эпоху паровых машин, тогда как все аспекты жизни их компаний – функционирование, принятие решений, коммуникации и финансы – полностью зависимы от программного обеспечения. Термины и понятия, которыми оперируют эти руководители, не учитывают уникальную природу бизнеса в эпоху, когда инструменты и продукты торговли являют собой неосязаемые переплетения битов вместо железнодорожных составов, груженных сталью.
Корпорации уже нанимают проектировщиков взаимодействия и начинают применять целеориентированный подход, однако качество программных продуктов не слишком улучшилось. Более того, высокие затраты на программирование и жесткий процесс создания программ никуда не делись. Почему?
Перемены невозможны, пока топ-менеджеры компаний не осознают, что проблемы с программами – это не технические сложности, а важные бизнес-вопросы. Наши проблемы останутся неразрешенными до тех пор, пока мы не изменим процесс и организацию.
Компании живут не только по устаревшим финансовым моделям, но еще и по негодной организационной модели. Эта модель скопирована с научной, в ней создание программы смешивается с планированием и решением инженерных задач. Такова природа исследований. Прискорбно, что эта парадигма без предупреждения была перенесена в неизменном виде в мир бизнеса, где ей не место.
Корни всех современных производственных дисциплин уходят в доиндустриальные времена. Всех, кроме дисциплины программного обеспечения, которая возникла, когда индустриализация уже закончилась. Только программирование вышло сразу из университетской среды, где время исследований не ограничивалось, студенческой рабочей силы было хоть отбавляй, о прибылях вообще не говорили, а неработающая программа могла сойти за весьма удачный эксперимент. Неслучаен тот факт, что Microsoft, IBM, Oracle и другие ведущие компании-разработчики ПО расположены в «кампусах». Университетам не нужны прибыли, они не стараются успеть создать привлекательный и полезный продукт к определенному сроку.
Любой бизнес, не связанный с программным обеспечением, начинается с исследований и заканчивается распространением продуктов или предложением услуг. Компания тщательно планирует время между этими двумя событиями, осознавая, что преждевременный выпуск непродуманного продукта опасен как для банковского счета, так и для репутации. Руководители знают, что время, размышления и деньги, вложенные в планирование, обернутся крупными дивидендами – отлаженным и быстрым процессом производства, популярностью и прибыльностью конечных продуктов.
Во всех других конструкторских дисциплинах инженеры создают стратегию, а ремесленники претворяют ее в жизнь. Инженеры не строят мосты сами, этим занимаются монтажники. Только в области программного обеспечения перед инженером стоит задача создать собственно продукт. Только в области программного обеспечения перед «монтажником» стоит задача определить, как следует создавать продукт. Только в области программного обеспечения эти две задачи решаются не последовательно, а одновременно. Однако компании-разработчики ПО, похоже, не осознают существования такой аномалии. Инженерное дело и конструкторское дело так тесно пересекаются, что специалисты и руководители их не разделяют и, вероятно, не различают. Планированием любого рода здесь пренебрегают или откладывают его до тех пор, пока не станет слишком поздно. Считается нормальным откладывать решение очень сложных инженерных проблем до момента, когда экономически станет накладно откатываться к фазе проектирования, потому что полным ходом пишется код для коммерческой версии продукта.
Проектирование архитектуры следует начинать на ранних стадиях инженерного планирования. Более того, именно оно должно быть движущей силой на этих стадиях, но такие разработки обычно откладываются до момента старта проекта и ведутся параллельно с созданием кода, поэтому не занимают должного места в процессе конструирования продукта. Компании нанимают проектировщиков взаимодействия и обучают специалистов по юзабилити создавать персон, однако работа этих людей почти не влияет на стоимость разработки и качество завершенного продукта.
Решение проблемы – в руках президентов и генеральных директоров корпораций. Делегируя решение своим техническим директорам или вице-президентам по разработке, они поступают неверно. Эти достойные исполнители – технари, а проблема не техническая. Как сказал Друкер, инструменты для бухгалтерии, на которые полагаются директора компаний, попросту не отражают истинной природы этих компаний. Нельзя ведь на основе точных показаний спидометра утверждать, что автомобиль движется в нужном направлении. В мире бизнеса цифровых технологий такой подход не может быть эффективным.
Одна из серьезных проблем применения неверных методов бухучета и организации для разработки программ состоит в том, что руководители не видят, сколько денег, израсходованных на программирование, потрачено впустую. Точная система показала бы, что из каждого доллара около пятидесяти центов тратится неправильно и что еще два или три доллара требуется, чтобы исправить проблему, вызванную этим некорректным вложением средств. В любом другом бизнесе подобная статистика вызвала бы революцию, однако отрасль программного обеспечения продолжает жить в состоянии блаженного неведения.
За последние тринадцать лет моя компания Cooper проконсультировала сотни компаний. Мои талантливые проектировщики создали для большинства клиентов «чертежи» продуктов, позволяющие коренным образом изменить ситуацию, но лишь немногие сумели воспользоваться всеми полученными преимуществами. В большинстве этих компаний проектирование взаимодействия и архитектуру программ считают лишь рекомендацией, в этих компаниях последнее слово всегда остается за программистами и инженерами. Ни один из президентов этих компаний не имеет ни малейшего представления о том, что происходит в офисах инженеров, и потому расписание ужимается безо всякой причины. Программисты постоянно работают в условиях дефицита ресурсов, и прежде всего – времени на хорошее программирование, а также времени, чтобы определить, где вообще требуется программирование. Они вынуждены защищаться, отвергая советы, и изворачиваться, общаясь со своими менеджерами.
На мой взгляд, существует два типа исполнителей: инженеры и боящиеся инженеров. Первые множат знакомые проблемы, поскольку их точка зрения безнадежно затуманена конфликтом интересов. Вторые множат проблемы, поскольку не умеют говорить на языке программистов. И я не имею в виду языки Java и С#. Я имею в виду, что у предпринимателей и программистов нет общих инструментов и общих целей. Хомо сапиенс делегирует человеческие проблемы Хомо логикус, не осознавая, что решение могло бы оказаться куда лучше в случае применения – на исполнительном уровне – уместных финансовых и организационных моделей.
У компаний есть прекрасная возможность сдвинуться с мертвой точки и сосредоточить усилия на удовлетворении потребностей клиентов, а не на программах, на персонах, а не на технологиях, на выгоде, а не на программистах. Я с нетерпением жду, когда появится просвещенный руководитель, который ухватится за эту возможность и навсегда изменит способ создания программного обеспечения, подав смелый и успешный пример.
Алан Купер,Менло-Парк, Калифорния,октябрь 2003 г.www.cooper.cominmates@cooper.com
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.
Часть I. Компьютерная неграмотность
1. Загадки информационной эры
Что будет, если скрестить компьютер и самолет?
Декабрь 1995 года. Самолет авиакомпании American Airlines совершает вылет по регулярному рейсу 965, следуя из Майами в колумбийский город Кали. Подлетая к взлетно-посадочной полосе, пилот «Боинга-757» должен был выбрать радиомаяк ROZO, чтобы определить ее координаты. Воспользовавшись бортовым навигатором, пилот ввел первую букву названия радиомаяка – R. Навигатор незамедлительно вывел список ближайших радиомаяков, названия которых начинались с R, – пилоту оставалось лишь выбрать нужный. Он выбрал самый первый, ориентируясь на указанные рядом с названием, казалось бы, верные координаты маяка. К несчастью, это оказался маяк ROMEO, который находился в 212 километрах к северо-востоку. Рейс же летел в южном направлении, а в момент выбора маяка вошел в долину, которая тянулась с севера на юг, так что отклоняться от курса было крайне рискованно. Ориентируясь на показания бортового навигатора, пилоты приступили к корректировке курса в направлении востока, а спустя несколько минут «Боинг-757» на высоте 3000 метров врезался в вершину гранитного утеса. Погибли 152 пассажира и 8 членов экипажа. Выжили только четверо пассажиров, все из них получили тяжелые травмы. Как обычно бывает в подобных ситуациях, причиной крушения самолета, объявленной Национальной комиссией по безопасности, был человеческий фактор. Бортовой навигатор, который использовали пилоты для ориентировки, отобразил верные данные, только не те, что нужны были для успешной посадки самолета в аэропорту Кали. Фактически человеческий фактор действительно имел место – ведь именно пилот выбрал маяк, совершив роковую ошибку, однако общая оценка ситуации позволяет утверждать, что вины пилота здесь не было.
На передней панели бортового навигационного компьютера самолета был показан радиомаяк, на который ориентировался рейс, и индикатор отклонения от курса. Если курс взят верно, стрелка будет указывать в центр шкалы, но правильность выбора самого маяка не проверяется. Внешний вид индикатора одинаков как в ситуации посадки, так и при возможном крушении. В данном случае навигатор отобразил данные о верно взятом курсе, но не учел, что неверно выбранный маяк может стать причиной катастрофы.
* * *
Полнота и точность передаваемых данных может быть абсолютной, но при этом повлечь трагический исход из-за их некорректности в текущей ситуации. При взаимодействии с компьютерами это происходит повсеместно, а ведь в современном мире все сложнее найти сферу, в которой бы не применялись компьютерные устройства. Начиная от пассажирских самолетов и заканчивая потребительскими товарами и услугами – везде используются компьютеры и везде их применение сопровождается характерным способом взаимодействия и поведения.
Существует такая шутка, широко известная в компьютерной среде: пилот небольшого самолета заблудился в облаках. Он идет на снижение, пока не оказывается рядом с офисным зданием, и кричит человеку в открытом окне: «Не подскажете, где я?» На что человек выдает ответ: «Вы в самолете, примерно в тридцати метрах над землей». Пилот тут же берет верный курс и спустя некоторое время благополучно приземляется в аэропорту. Пассажиры самолета удивленно спрашивают, как он понял, куда лететь. И пилот говорит: «Тот человек ответил мне совершенно точно и правдиво, но эта информация была абсолютно бесполезна, поэтому я сразу догадался, что этот человек – разработчик программного обеспечения из Microsoft, а я знаю, где расположено здание Microsoft по отношению к аэропорту».
В свете описанной выше трагедии рейса 965 эта шутка звучит зловеще, тем не менее профессионалы из цифрового мира не упускают возможности в очередной раз рассказать ее и посмеяться, потому что она подчеркивает главную особенность компьютеров: они могут выдавать нам факты, но не разъясняют их. Их информация отличается точностью, но только лишь ее нам недостаточно, чтобы достичь намеченных целей. В бортовой навигатор рейса 965 легко можно было заложить функцию сообщать пилотам о неверном выборе маяка. Один простой намек на то, что выбор маяка ROMEO «нетипичен» или «незнаком», мог бы предотвратить крушение. Только пассажиры и сам рейс, вероятно, не были тем, что занимало ум бортового компьютера. Он был занят исключительно собственными вычислениями.
Сложности во взаимодействии с компьютерами влияют на всех нас, временами приводя к фатальным последствиям. Но программные продукты сложны в применении не из-за сложности самих компьютеров, а потому, что в основу их разработки заложен неверный процесс. Данная книга призвана не только продемонстрировать следствия такого неверного процесса, но и прояснить причины его возникновения. Далее мы рассмотрим, как следовало бы изменить процесс, чтобы наше программное обеспечение обрело дружелюбный вид и мощный функционал. В этой главе основной акцент прежде всего делается на серьезность рассматриваемой проблемы.
Что будет, если скрестить компьютер и фотокамеру?
Вот одна из загадок эры информации: что будет, если скрестить компьютер и фотокамеру? Верный ответ: компьютер! Тридцать лет назад1 моим первым фотоаппаратом был 35-миллиметровый Pentax H, в него вставлялась маленькая батарейка, от которой запитывался датчик освещенности (экспонометр). От меня требовалось только менять батарейку раз в два года, как в наручных часах.
Пятнадцать лет назад моей первой электронной фотокамерой был 35-миллиметровый Canon T70, в который вставлялось уже две пальчиковые батарейки, за счет чего достаточно простой электронный блок экспонометра приводился в действие, а также подавалось питание для автопрокрутки пленки. Сэкономить заряд батареек помогал простой выключатель на корпусе фотоаппарата.
Пять лет назад у меня появился Logitech – цифровой фотоаппарат первого поколения; он тоже имел подобный выключатель, но в дополнение обладал чуть более продвинутой электронной начинкой, напоминавшей зачатки компьютерного разума. Теперь, когда я забывал его отключить, он сам автоматически выключался спустя минуту бездействия. Довольно мило.
Год назад внутри моей Panasonic PalmCam – цифровой фотокамеры второго поколения – находилась куда более умная компьютерная микросхема. Ее ум был настолько велик, что простой рычажок «Вкл/Выкл» эволюционировал в переключатель Off/Rec/Play, который включал разные режимы работы камеры. Режим Rec предназначался для фотосъемки, а просмотр фотографий на небольшом экране осуществлялся в режиме Play.
Последней фотокамерой, которой я обзавелся, стал цифровой фотоаппарат третьего поколения Nikon CoolPix 900, и он еще более сообразительный. Его электронный мозг настолько умный, что представляет собой полноценный компьютер, который даже показывает песочные часы в стиле Windows во время загрузки. Его переключатель, словно рыба-мутант, отрастил дополнительные «головы», и теперь их стало четыре. Каждая из них отвечает за свою функцию: Off/ARec/MRec/Play. ARec – это режим автоматической записи, а MRec – режим записи вручную. Как по мне, разницы между ними нет. При этом у камеры нет режима On (включено), так что даже мои друзья не смогли понять, как ее включить, без моих объяснений.
Эта новая камера потребляет достаточно много энергии, так что создатели предусмотрительно наделили ее изощренной функцией контроля уровня заряда аккумулятора. Теперь все обычно происходит так: я перевожу злосчастный переключатель Off в режим MRec, мучительно жду приблизительно семь секунд, пока камера загрузится, и только потом могу направить ее на предмет съемки. Далее я выбираю подходящий ракурс и приближение камеры для получения наилучшего кадра. И в тот самый миг, когда мой палец почти нажал на спуск, камера вдруг решает, что одновременное увеличение кадра, питание вспышки и поддержание яркости экрана способны вконец исчерпать заряд батареи. Порываясь сохранить последние капли жизненных сил, камера временно отключает функцию съемки. Но мне об этом неизвестно, мой взгляд направлен в видоискатель. Я воодушевляюще машу руками, прошу сказать «Сы-ы-ыр!» и нажимаю на спуск. Компьютерный блок фотокамеры отслеживает нажатие кнопки, но не способен ничего предпринять. Программа управления питанием делает еще одну слабую попытку спасти ситуацию и в мгновение ока принимает ответственное решение: уменьшить нагрузку. В результате этого энергоемкий LCD-экран гаснет. Я недоуменно гляжу на камеру, пытаясь понять, почему не получилось сделать снимок, пожимаю плечами и опускаю руку, в которой держу камеру. Однако сэкономленная на отключении экрана энергия позволяет дополнительно запитать другие элементы камеры. У программы управления питанием открывается «второе дыхание», и она решает, что прямо сейчас энергии хватит, чтобы сделать снимок. Она посылает сигнал основной программе, которая терпеливо ждет момента, когда можно будет продолжить процесс фотосъемки и выполнить ранее посланную мной команду сделать снимок. В результате камера делает великолепно сфокусированное, безупречно экспонированное высококлассное цифровое фото моего колена.
На моем старом механическом фотоаппарате Pentax все настройки фокусировки, экспозиции и выдержки нужно было устанавливать вручную, тем не менее это вызывало куда как меньше мучений, чем процесс фотосъемки на современный, полностью компьютеризованный Nikon CoolPix 900, в котором все эти функции автоматические. Nikon по-прежнему позволяет делать снимки, но его поведение характерно для компьютера, а не для фотокамеры.
* * *
Лягушке, оказавшейся в кастрюле с холодной водой на плите, невдомек, что повышение температуры смертельно. Это происходит оттого, что нарастающий жар притупляет ее ощущения. Мои фотокамеры медленно эволюционировали от простого к сложному, становясь все более компьютеризированными, а я не осознавал этого, совсем как та лягушка. И это характерно для всех нас, испытывающих на себе это медленное, убаюкивающее чувства посягательство компьютеров и присущего им поведения на нашу жизнь.
Что будет, если скрестить компьютер и будильник?
Компьютер! Недавно я поставил в своей спальне новый дорогой будильник со встроенным радио марки JVC FS-2000. Внутри устройства кроется довольно сложная компьютерная начинка, обещающая высокую точность. Кроме того, оно обладает цифровым звуком и еще множеством функций. Теперь я могу просыпаться в точно заданное время под мелодию с компакт-диска и, более того, будильник настолько умен и деликатен, что звук этой мелодии не взорвет барабанные перепонки в шесть утра, а будет нарастать постепенно. Эта редкая в будильниках опция действительно приходится весьма кстати, и только мысль о ней усмиряет мое желание вышвырнуть это дьявольское изобретение из окна.
Понять, на какой день недели установлен звонок будильника, чертовски сложно, так что периодически он не будит меня в понедельник и нагло врывается в мой мирный сон ранним субботним утром. Конечно, в этом устройстве имеется индикатор активности будильника, но это вовсе не значит, что он пригоден для использования. Встроенный алфавитно-цифровой LCD-дисплей запутанно отображает всяческие обозначения функций в часах. Например, маленький значок часов в левом верхнем углу LCD-дисплея сообщает о том, что будильник активен. Только в полутемной спальне опознать этот значок весьма затруднительно. У дисплея имеется функция подсветки, благодаря которой значок часов становится заметным, но включается она лишь в том случае, когда работает радио или играет компакт-диск. При этом есть один нюанс: будильник, даже если его установить, не прозвенит при включенном проигрывателе компакт-дисков. Именно такое противоречивое поведение часто ставит меня в тупик.
Отключить будильник проще простого: для этого нужно только один раз нажать кнопку Alarm, и значок часов пропадет с дисплея. А вот чтобы включить будильник, потребуется нажать эту кнопку не меньше пяти раз. Когда нажимаешь ее первый раз, на дисплее появляется время, в которое должен прозвенеть будильник. На второй раз отображается время, когда звук будильника должен выключиться. На третьем нажатии нужно выбрать, зазвучит ли радио или же компакт-диск. А на четвертом – определить желаемый уровень громкости. Завершающее пятое нажатие закрывает меню установки будильника и приводит часы к обычному режиму. Здесь главное – не нажать еще один, лишний раз, ведь тогда будильник вовсе отключится. Однако полусонному человеку в темноте спальни безошибочно исполнить этот маленький цифровой кордебалет бывает весьма затруднительно.
В силу своей упрямой симпатии к подобного рода гаджетам я не оставляю попыток разобраться в этом устройстве, надеясь однажды победить. Чего не скажешь о моей супруге – она уже давно перестала пытаться найти подход к этому дьявольскому агрегату. Она восхищается сглаженными линиями в его современном дизайне и качеством звучания, но экзамен в качестве будильника он не прошел, потому что требуется слишком много усилий, чтобы заставить устройство делать то, что нужно. Эти часы хотя и могут разбудить меня, но ведут себя как компьютер.
В отличие от него, мой древний 11-долларовый некомпьютеризированный будильник разливался внезапным жутким дребезжанием, когда требовалось меня разбудить. О том, что он включен, можно было узнать по яркой красной лампочке. А когда он выключался, лампочка гасла. Тот старый будильник не нравился мне по ряду причин, но по меньшей мере мне было ясно, собирается он меня будить или нет.
* * *
По той причине, что производителям намного выгоднее применять для контроля внутренних процессов устройств компьютеры, нежели механизмы старого образца, компьютеризация устройств и процессов оказания услуг в нашей жизни экономически неотвратима. Это значит, что все существующие устройства скоро начнут вести себя как самые несносные компьютеры, если только мы не попробуем подойти к этому иначе.
* * *
Продуктами для конечного потребителя описанное выше явление не ограничивается. Устройства, снабженные компьютерной начинкой, и компьютеризированные сервисы отличаются от своих простых собратьев с ручным управлением широтой вариантов применения и количеством опций. Но в реальности люди чаще склонны использовать именно механические устройства и делать это более гибко, искусно и осознанно, нежели при обращении с их современными версиями, работающими на кремниевых микросхемах.
Высокотехнологичные компании, в стремлении улучшить свои разработки, сводят этот процесс к наполнению их сложным и часто ненужным функционалом. Но такой некорректный процесс не помогает повысить качество продуктов, а только добавляет новые функции, так что это именно то, чем в действительности и занимаются его создатели. Далее в этой книге я продемонстрирую, как совершенствование процесса разработки приносит больше счастья пользователям, без лишних затрат на никому не нужные дополнительные функции.
Что будет, если скрестить компьютер и автомобиль?
Компьютер! Роскошный высокотехнологичный спортивный автомобиль Boxster от Porsche оснащен семью компьютерами, посредством которых управляются его сложные подсистемы. Один из них целиком предназначен для управления двигателем. В память этого компьютера заложены специальные программы, которые помогают преодолевать критические ситуации. К несчастью, эти программы сами периодически становятся причиной странных сбоев в работе автомобиля. Некоторые ранние модели отличались такой особенностью: когда уровень топлива в баке доходил до предельно низкой отметки – где-то около четырех литров, – бензин скапливался у стенки бака под действием центробежной силы при крутых поворотах. Это приводило к попаданию воздуха в топливную систему. Компьютер определял, что в топливной смеси произошли серьезные изменения, и интерпретировал это как фатальный сбой системы топливного впрыска. Для предотвращения критических последствий компьютер отключал зажигание, и автомобиль останавливался. Более того, во избежание тех же последствий компьютер не позволял заново запустить двигатель до тех пор, пока не будет произведена буксировка машины в автомастерскую для устранения неисправностей.
Все, что могла посоветовать тогда компания Porsche владельцам ранних Boxster, столкнувшихся с этой проблемой, – это открыть капот и отсоединить аккумулятор минимум на пять минут, тогда компьютер удалил бы из памяти сведения об инциденте. Несмотря на то что спортивные автомобили позволяют разъезжать по двухполосным асфальтированным дорогам на предельной скорости, в крутых поворотах они начинают вести себя в точности как компьютер.
* * *
В похвальном стремлении уберечь владельцев Boxster от всяческих бед разработчики программ для автомобиля только унизили их и заставили страдать. Каждый, кто любит гоночные автомобили, знает, что клиентская политика компании Porsche направлена на выражение уважения своим клиентам и предоставление большого количества привилегий. А случаи, подобные описанному выше, показывают, что программное обеспечение для автомобиля создавалось не той же самой Porsche, что выпускает другие его компоненты. Его создала компания внутри компании: программисты, а не легендарные немецкие инженеры автомобилестроения. По какой-то причине внедрение новых технологий привело к тому, что солидная компания с долгой историей пренебрегла своими ключевыми ценностями. Стандарты качества для проектировщиков программного обеспечения намного ниже, чем для более традиционных инженерных дисциплин.
Что будет, если скрестить компьютер и банк?
Компьютер! В те моменты, когда я снимаю денежные средства в банкоматах, я каждый раз наблюдаю одно и то же угнетающе запутанное поведение, столь характерное для компьютеров. Малейшая допущенная мной ошибка приводит к отмене всей транзакции и выкидывает меня из сеанса. Мне приходится вытаскивать карту, снова ее вставлять, снова набирать PIN-код и снова вводить запрос. И ошибку-то обычно я допускаю не по своей воле, а потому, что компьютер банкомата мастерски вводит меня в заблуждение.
Каждый раз он задает мне один и тот же вопрос: каким счетом я хотел бы воспользоваться для снятия наличных – текущим, сберегательным или депозитным, – и это учитывая то, что у меня всего один счет – текущий. Каждый раз я забываю правильный ответ, так что такой вопрос сбивает меня с толку. Приблизительно раз в месяц я нечаянно выбираю сберегательный счет, и адский агрегат без долгих размышлений прерывает сеанс, так что мне приходится начинать сначала. При этом для отказа в снятии наличных со сберегательного счета банкомат должен знать, что такой счет у меня отсутствует, однако он все равно предлагает мне его как один из вариантов. Единственное, что отличает меня в момент выбора банковского счета от пилота рейса под номером 965, который ошибочно выбрал маяк ROMEO, – это масштабы последствий.
Помимо этого, банкомат ограничивает мои действия, налагая суточный лимит снятия наличных, который составляет 200 долларов. Так что, даже если я успешно преодолею весь путь – аутентификацию, выбор типа счета, запрос нужной суммы – и это будет, к примеру, сумма, равная 220 долларам, компьютер банкомата, не церемонясь, отклонит транзакцию, выдав грубое сообщение о превышении суточного лимита. Он не скажет мне, какова величина этого лимита, не отобразит остаток на моем счете и даже не позволит ввести другую сумму меньшего порядка. Вместо этого он просто выплюнет мою карту и предоставит мне возможность начать все с «чистого листа», не снабдив меня ни каплей дополнительной информации, заставляя растущую очередь за моей спиной беспокоиться и раздраженно вздыхать. Реакции банкомата точны и основаны на фактах, но толку от них никакого.
В память банкомата заложены определенные правила, которым он должен следовать. Я бы тоже рад следовать им, но это так по-компьютерному неблагоразумно – не сообщать мне об этих правилах, снабжать меня противоречивыми указаниями, а затем бесцеремонно наказывать меня за нарушение этих правил по чистому незнанию. Такое столь характерное для компьютеров поведение вовсе не является их истинной натурой.
Если быть точнее, никакой натуры у них нет: они просто выполняют операции по заданной программе. А программы такие же гибкие, как человеческая речь. Человек может говорить грубыми или вежливыми словами, выражать поддержку или высказывать недовольство. Компьютер может так же легко, как и человек, сообщать сведения с должным уважением и учтивостью. Его только требуется этому научить. Увы, программисты не те люди, которые способны успешно обучить компьютеры таким вещам.
Как легко попасть в беду с помощью компьютера
Компьютер, воцарившийся на вашем рабочем столе, обладает именно таким несносным раздражающим поведением, какое и полагается компьютеру, для этого его даже не нужно ни с чем скрещивать. Моя подруга Джейн когда-то занимала должность координатора по связям с общественностью. На ее компьютере была установлена операционная система Windows 95 и программа Microsoft Word, в которой Джейн редактировала заметки и договоры. Основой Windows 95 являлась иерархическая файловая система. Все документы Джейн помещались в маленькие папки, которые, в свою очередь, помещались в другие маленькие папки. Джейн не понимала этого, так же как и не видела необходимости хранить файлы именно таким образом. Если быть точнее, Джейн вообще не слишком задумывалась об этом, а просто выбирала путь наименьшего сопротивления.
Получилось так, что Джейн только что закончила набрасывать черновик нового договора на пиар-услуги для стартапа из Кремниевой долины. Она выбрала опцию Закрыть в меню Файл. Вместо того чтобы просто выполнить команду и закрыть документ, программа Word вывела диалоговое окно. Как вы догадались, речь идет о всем знакомом вопросе Сохранить изменения в документе…? (Do you want to save changes…?). Джейн, как и обычно, нажала кнопку Да (Yes). Она слишком часто видела это окно, так что нажимала кнопки почти не глядя.
За первым диалоговым окном немедленно последовало следующее – и снова слишком хорошо знакомое Сохранить как… (Save As). В этом окне было великое множество непонятных для Джейн кнопок, значков и текстовых полей. Все, что она здесь могла понять и чем активно пользовалась, – это поле для ввода имени файла. Набрав подходящее имя, Джейн нажала кнопку Сохранить. Файл с договором сохранился в папке Мои документы. Джейн столько раз проделывала эту нудную процедуру, что уже даже не задумывалась о своих действиях.
В обеденное время, когда Джейн не было в офисе, Сунил, системный администратор компании, установил на ее компьютер обновленную версию антивируса VirusKiller 2.1. Находясь за рабочим компьютером Джейн, Сунил открыл программу Word, чтобы просмотреть файл Readme для антивируса. Окончив просмотр файла, Сунил закрыл его и вернул компьютер Джейн в то состояние, в каком тот находился до обеда. По крайней мере, так ему казалось.
После обеда Джейн потребовалось снова открыть файл договора для распечатки и демонстрации руководителю. Джейн выбрала опцию Открыть в меню Файл, после чего на экране возникло диалоговое окно Открыть. Согласно ожиданиям Джейн, все ее договоры и другие документы должны были удобно отобразиться в этом окне в алфавитном порядке. Однако вместо этого ее взору явилось множество файлов, имен которых она никогда до этого не видела и не смогла опознать. Название одного из этих файлов значилось как Readme.doc.
Конечно, все дело было в том, что, когда Сунил открыл Word для просмотра файла Readme, он поручил программе отыскать неведомую папку на шестом уровне вложенности файловой системы и нечаянно изменил привычное для Джейн местоположение Мои документы на другое.
Ситуация на экране поставила Джейн в тупик. Первое, о чем она нерадостно подумала, что вся большая работа, которую она проделала, просто не сохранилась. Джейн взволнованно обратилась за помощью к Рене – своей подруге и коллеге, но Рене пришла в не меньшее замешательство. В итоге, дойдя почти до полного отчаяния, Джейн набрала номер Сунила, чтобы попросить помощи у него. Но Сунила на месте не было, а поймать его и вернуть все на круги своя удалось только в понедельник утром. В результате Джейн, Рене, Сунил и PR-компания в целом потеряли каждый по половине рабочего дня.
И хотя такие иерархические файловые системы нужны операционным системам компьютеров, людям они без надобности. Нет ничего удивительного в том, что больше всего древовидная структура каталогов нравится программистам, как нет и ничего примечательного в том, что обычным пользователям, таким как Джейн, это не приносит никакого удовольствия. А точнее, это непримечательно для всех, кроме тех самых программистов, которые разрабатывают подобное программное обеспечение. Они закладывают в программы такое поведение и отображение информации, что оно понятно для них самих, но между ним и тем, что подходит для Джейн, простирается большая пропасть. Вина за несоблюдение сроков и низкую эффективность труда ложится на Джейн, а не на разработчиков программного обеспечения, чей продукт привел к провалу проекта.
Как бы то ни было, Джейн работой обеспечена. Но ведь ко многим другим людям отношение как к недостаточно «компьютерно грамотным», так что их отказываются принимать на работу. Чем для большего количества должностей требуются навыки взаимодействия с компьютерами, тем шире становится разрыв между людьми, потенциально подходящими для этих позиций, и теми, кто не подходит, и тем сложнее его преодолеть. Политики могут сколько угодно требовать создания рабочих мест для малоимущих, только компании не дадут ни единого шанса сесть за их компьютеры людям, не имеющим достаточного опыта в этом деле. Их нужно слишком долго обучать, и остается большой риск порчи информации и причинения вреда бесценным базам данных.
Несносное поведение и невнятность взаимодействий, которыми отличаются продукты, работающие на программном обеспечении, уже настолько вошли в норму, что я называю происходящее «софтверным апартеидом». Из-за такого положения совершенно нормальные в целом люди не могут найти работу и устроиться в обществе, так как не владеют компьютером на приемлемом уровне.
Социальные активисты нашего просвещенного общества трудятся не покладая рук, пытаясь преодолеть расовые и классовые барьеры, пока специалисты индустрии технологий не менее тяжким трудом воздвигают еще более высокие заслоны. Но целенаправленная деятельность по проектированию таких программных продуктов, которые бы обладали большей человечностью и меньшей требовательностью, автоматически сделает их более близкими к народу, вне зависимости от класса и цвета кожи пользователей.
Коммерческому программному обеспечению тоже нелегко
Компьютеры распространяют свое влияние не только на кабины пилотов в самолетах, но и на пассажирские салоны, показывая там свой упрямый и своевольный характер, так хорошо знакомый нам. В современных авиалайнерах устанавливают системы развлечений в полете, через которые пассажиры могут слушать музыку и смотреть фильмы. Такие системы представляют собой обычные компьютеры, соединенные в локальную сеть, как те, что стоят в вашем офисе. Системы развлечений с расширенным набором опций обычно устанавливают только на больших самолетах, следующих трансокеанскими рейсами.
Бортпроводники одной из авиакомпаний были так расстроены использованием встроенной системы развлечений, что многие из них настоятельно требовали перевести их на более короткие местные рейсы, лишь бы не изучать ее сложный функционал. И это в высшей степени примечательно, потому что карьерный рост на авиалиниях – это всеми почитаемый процесс, происходящий в порядке старшинства, и именно эти маршруты дальнего следования всегда расценивались как самые лакомые кусочки: это было вызвано продолжительными остановками в экзотических уголках планеты, таких как Сингапур и Париж. Поэтому такое стремление стюардов и стюардесс мотаться туда-обратно на ничем не примечательных и совсем не романтических рейсах из Денвера в Даллас или Лос-Анджелеса в Сан-Франциско лишь для того, чтобы избежать взаимодействия с системой развлечения в полете, говорило о полном упадке боевого духа. Любая авиакомпания, которая когда-либо вынуждала своих самых ценных сотрудников – тех, что проводят с клиентами больше всего времени, – страдать из-за плохого оборудования, делала самую большую ошибку в своей жизни, попусту растрачивая денежные средства и рискуя доверием лояльных потребителей и собственного персонала.
Другая крупная авиакомпания установила еще более несносную компьютерную систему развлечений. К просмотру фильмов через систему этой компании была привязана функция оплаты. Ранее процесс сбора денег протекал в довольно расслабленном режиме: трудно было покинуть замкнутое пространство реактивного самолета на высоте одиннадцати тысяч метров, не оплатив услуги. Бортпроводники выполняли запросы пассажиров в товарах и услугах, а оплату собирали позже, когда их руки не были заняты подносами и когда пассажиры прекращали от них чего-то требовать. Такая процедура уберегала стюардов от беспрестанных хождений туда-сюда по узким проходам салона. Разумеется, случайные ошибки периодически возникали, но это никогда не превышало нескольких долларов. Имеющаяся система была довольно дружелюбной и терпимой; все были счастливы и довольны работой.
Новая компьютеризированная система оплаты услуг доставки медиаконтента привела к тому, что бортпроводникам сначала требовалось получить деньги от пассажиров, потом пройти через весь салон к его началу, где установлена панель управления для стюардов, затем ввести пароль обслуживающего персонала, а затем провести оплату. Только по завершении транзакции пассажир мог начать просмотр фильма или прослушивание музыки. Такой бессмысленный подход к проектированию системы привел к тому, что бортпроводники были вынуждены сотни лишних раз пройти по узким проходам за один только рейс. Вконец отчаявшиеся бортпроводники придумали устраивать короткое замыкание перед каждым рейсом долгого следования ровно через несколько минут после взлета. Далее следовало вежливое объявление с извинениями за сбой в работе системы и сообщением о том, что посмотреть фильмы на этом рейсе не получится.
Миллионы долларов затратила авиакомпания на то, чтобы разработать настолько бестолковую систему, что пользователи были готовы умышленно отключить ее, избегая всяческих взаимодействий с ней. Невинными жертвами этого процесса стали тысячи пассажиров, скучающих во время полета. И все это происходило на трансокеанских рейсах дальнего следования, обычно заполненных важными клиентами, постоянно пользующимися услугами этой авиакомпании. Сложно навскидку определить количество потерянных авиакомпанией денег, но я уверен, что речь шла о катастрофически огромных суммах.
Программное обеспечение в системах развлечений в полете функционировало безупречно, но его провал был обусловлен неумением адекватно взаимодействовать с людьми. Как могла компания не спрогнозировать такой невеселый исход? Как упустила эту взаимосвязь? Цель данной книги – найти ответ на подобные вопросы и показать, как избегать таких катастроф современного высокотехнологичного мира.
Что будет, если скрестить компьютер и военный корабль?
Сентябрь 1997 года. Во время маневрирования в Атлантическом океане авианосец Военно-морских сил (ВМС) Соединенных Штатов Америки под названием Yorktown, являвшийся одним из новых крейсеров морфлота с боевой информационно-управляющей системой Aegis2, неожиданно прекращает движение.
Во время калибровки топливного клапана техник ВМС ввел нуль в один из управляющих компьютеров, оснащенных процессором Pentium Pro и операционной системой Windows NT. Программа предприняла попытку поделить другое число на это нулевое значение, иначе говоря, выполнить действие, запрещенное в математике. Результатом стал глобальный сбой во всей системе управления бортом. Оставшись без компьютерного управления, двигатель встал, и корабль дрейфовал на волнах 2 часа 45 минут, до тех пор пока его не отбуксировали на базу. Удача, что подобное не случилось в зоне боевых действий.
Что будет, если скрестить компьютер и военный корабль? Адмирал Нимиц3 перевернулся бы в своем гробу! Проигнорировав вышеописанную неудачу, ВМС решили оснастить компьютерными системами все имеющиеся корабли в целях экономии на человеческих ресурсах. Чтобы противостоять возражениям, они возложили всю вину за указанный инцидент на человеческий фактор. Ввиду того, что процесс проектирования программного обеспечения вышел из-под контроля, индустрия высоких технологий должна выбрать один из вариантов: навести порядок в этом процессе либо продолжать обвинять во всех грехах обычных пользователей, в то время как все более масштабные механизмы будут простаивать, намертво обездвиженные.
Технобезумие
Как-то в одном из номеров Wall Street Journal вышла статья, в которой был описан анонимный видеоклип, вирусно распространившийся через электронную почту. В этом клипе «…Усатый Обыватель в рубашке с коротким рукавом сгорбился над своим компьютером. Вдруг, в порыве гнева, он наносит удар по монитору. Удивленный коллега заглядывает в его отсек, а человек со всей силы швыряет в монитор клавиатуру, отчего тот валится на пол. Вскочив с места, безумец настигает поверженный монитор и наносит завершающий яростный удар».
Статья продолжалась рассуждениями о том, что данный клип «неимоверно всколыхнул» общественность и что он, по-видимому, вскрыл «мощную скрытую тенденцию к технобезумию».
Удивительная ирония этой ситуации в том, что для просмотра или простой пересылки этого видеоклипа нужно владеть компьютером на достаточном уровне. Человек на видео вполне мог быть актером, но ему удалось задеть струну, которая есть у каждого человека в бизнесе. Разочарование, вызванное сложностью и неприятием программных продуктов, нарастает стремительными темпами.
По закрытым спискам рассылки ходит шутка о «компьютерном синдроме Туретта». В основе этой игры слов лежит упоминание психического расстройства, похожего на нервный тик. Люди, страдающие таким расстройством, склонны бесконтрольно разражаться приступами ругани. Юмор состоит в том, что, окажись вы в помещениях практически любого современного офисного здания, вы услышите, как в целом нормальные люди, работая на своих персональных компьютерах, раздраженно стискивают зубы и непрестанно шепчут бранные слова. Одному богу известно, что вызывает в них такие приступы безумной ярости: утерянный документ, недоступное изображение или то самое взаимодействие, которое выводит из себя. А быть может, программа просто ненавязчиво удалила единственный имеющийся у пользователя экземпляр пятисотстраничного файла просто потому, что его ответом было «Да» в очередном диалоговом окне, похожем на то, где предлагается сохранить изменения, а на деле спрашивающем, желает ли он стереть данные.
Отказ индустрии нести ответственность
Мы живем в мире, который заполонили высокотехнологичные инструменты. Компьютеры безраздельно властвуют на наших рабочих местах и в наших домах, а транспортные средства пичкают гаджетами на кремниевых микросхемах. Каждое из этих компьютерных устройств невероятно мощное и оснащено богатым набором опций, но все они столь же грандиозно сложны и демонстрируют запутанное поведение.
Индустрия высоких технологий упрямо не признает тот простой факт, о котором мог бы поведать каждый владелец мобильного телефона или текстового процессора: наши компьютеризированные устройства слишком сложны в применении. Проектировщики программ и высокотехнологичных гаджетов гордятся своими достижениями. Разработчики программного обеспечения4, также принимающие участие в их создании, прилагают все возможные усилия, чтобы упростить использование этих инструментов, и даже достигли в этом отношении некоторого успеха. Они думают, что имеющийся уровень простоты использования их продуктов настолько велик, насколько это позволяет их техническое устройство. Как истинные инженеры, они безгранично верят в технологии и имеют твердое убеждение, что только новейшие разработки – например, в области распознавания речи или искусственного интеллекта – способны улучшить опыт пользовательского взаимодействия.
Каким бы смешным это ни казалось, но в случае с программными продуктами меньше всего улучшений в отношении их использования принесут именно новейшие технологии. С точки зрения технического устройства сложный и запутанный программный продукт практически ничем не отличается от простой, мощной и приятной в использовании программы. Здесь все дело, скорее, заключается в уровне культуры, подготовки и отношении людей, которые создают эти программы, а отнюдь не в применяемых микросхемах и языках программирования. Червоточина находится в процессе разработки, а не в инструментарии.
Во главе индустрии высоких технологий каким-то странным образом оказались программисты и инженеры, чья сложная инженерная культура теперь превалирует в этой сфере. Топ-менеджеры фактически утратили способность влиять на индустрию высоких технологий, невзирая на занимаемые ими должности. Инженеры – вот кто правит бал. Стремясь наилучшим образом употребить все возможности, открывшиеся нам с изобретением кремниевой микросхемы, мы забыли об ответственности. Психбольница оказалась руках пациентов.
Когда психически больные завладевают сумасшедшим домом, у них нет четкого осознания причин собственных проблем. Глядя в зеркало, проще всего видеть только лучшее в себе и игнорировать недостатки. То же самое происходит и с разработчиками в тот момент, когда они пристально разглядывают результаты своего труда – они упускают из виду его плохие стороны. Вместо этого их взору предстает невероятная гибкость и мощь. Их взгляд направлен на богатство функционала и опций. Они упрямо отказываются признавать, что пользование таким продуктом вызывает страдания, требует множества мучительных часов для его изучения и что пользователи сойдут с ума от безысходности и уничижения, будучи вынужденными применять его каждый день.
Что послужило причиной написания этой книги
Я занимался изобретением и разработкой программных продуктов двадцать пять лет. Долгие годы проблема запутанного программного обеспечения не давала мне покоя, пока, наконец, в 1992 году я не оставил программирование, чтобы полностью посвятить себя компаниям-разработчикам, помогая им делать их программные продукты приятнее и проще в применении. И тут произошло чудо! Ко мне вдруг пришло понимание, что только после того, как я освободил себя от программистских требований, я по-настоящему осознал, какими мощными они были. Программирование способно настолько захватить ваш ум своей сложностью, что только эта задача будет подавлять все прочие измышления, в том числе и заботу об удобстве пользователя. Я пришел к этой мысли лишь тогда, когда силой разорвал эти программистские узы.
Вместе с этим открытием ко мне пришло также осознание того, почему программы выглядят столь неудачными, по мнению пользователей. В 1995 году увидела свет моя книга5, в которой я описал то, что узнал, и которая существенно повлияла на процесс разработки некоторых современных программ.
Чтобы стать хорошим программистом, необходимо обладать неким умением чувствовать природу и потребности компьютера. Вот только природа и потребности компьютера абсолютно чужды природе и потребностям людей, которые будут в конечном счете пользоваться этим компьютером. Процесс создания программ требует от разработчиков так много интеллектуальных усилий и такой степени вовлеченности в задачу, что они вынуждены полностью погружаться в инородный для человека образ мышления. В голове программиста все, что требуется для процесса разработки, получает наивысший приоритет, оставляя далеко позади какие-либо потребности внешних пользователей. Даже языки, на которых говорит каждый из этих миров, противоречат друг другу.
Процесс программирования и процесс разработки простых в использовании программ не согласуются по той причине, что программист и конечный пользователь преследуют в корне разные цели. У программиста есть потребность, чтобы разработка велась легко и непринужденно. А у конечного пользователя потребность звучит иначе – легким и непринужденным должен быть процесс взаимодействия с программой. Создать такую программу, которая удовлетворяла бы потребности и тех и других, не удается практически никогда. В современной индустрии компьютеров программисты наделены возможностями для создания дружелюбных пользователю взаимодействий, но из-за постоянного давления конфликта интересов они просто не в состоянии действительно сделать что-то.
Для процесса разработки программного обеспечения характерна такая особенность, что его результаты можно увидеть только по завершении всей работы. Отсюда вытекает тот факт, что любые прогнозы со стороны человека, не связанного с программированием, уже не смогут что-либо изменить. Использовать программное обеспечение для настольных компьютеров так тяжело потому, что в его создании принимают участие исключительно программисты и нет никого, кто выполнял бы роль посредника между программистами и пользователями. Изделия наподобие телефонов и камер всегда имели изрядную долю механических деталей, что позволяло быстрее изучать их устройство. Но исходя из наших исследований, если скрестить компьютер и любую другую вещь, характер компьютера непременно возобладает в ней.
Ключом к решению данной проблемы является проектирование пользовательского взаимодействия перед началом непосредственно процесса разработки. Нам нужно вырастить новый класс профессионалов пользовательского взаимодействия, которые будут проектировать поведение программ. Сегодняшние программисты осознанно подходят лишь к проектированию кода, а пользовательское взаимодействие отходит на второй план. Они планируют, что будет делать программа, но не то, как она будет себя вести, коммуницировать с пользователем и уведомлять его. Проектировщики взаимодействия, напротив, уделяют максимум внимания именно тому, как пользователи воспринимают программные интерфейсы различных устройств и как взаимодействуют с ними.
Искусство проектирования пользовательского взаимодействия достаточно молодое и знакомо не всем программистам. Но даже если программисты и признают его важность, они обычно фокусируются на нем лишь в завершение создания кода. Только в этом случае поздно что-либо менять.
Специалисты, управляющие проектами по разработке программ и устройств на их основе, либо попадают в заложники к программистам из-за своей недостаточной технической подкованности, либо ведут себя чрезмерно понимающе, так как сами являются разработчиками. Пользователям таких программ и устройств невдомек, что эти продукты могут также обладать необходимым функционалом и при этом обеспечивать приятное взаимодействие, как все прочие качественно спроектированные инструменты.
Программисты отнюдь не являются нашими врагами. Они прилагают массу усилий, чтобы придать своим программам должной легкости взаимодействия. К сожалению, они воспринимают все через призму собственного опыта; в итоге программами с легкостью могут пользоваться только другие разработчики, чего не скажешь о простых людях.
Невозможно даже представить стоимость некачественно спроектированного программного обеспечения. Сколько стоит потерянное время Джейн и Сунила, негодование скучающих пассажиров самолета, жизни людей, летевших роковым рейсом 965? Это нельзя измерить. Но наибольшую цену мы платим за упущенные возможности. Пока мы растрачиваем свое время на раздражение, попытки разобраться, разгребание последствий и несем издержки в смертельной схватке с программами, мы не используем весь тот заложенный в них потенциал обещаний быть более человечными, мощными и дружелюбными созданиями, какие только можно вообразить. На самом деле программное обеспечение невероятно гибкое и способно превзойти самые смелые ожидания. Все, что для этого нужно, – создать условия для разумного сотрудничества между проектировщиками пользовательского взаимодействия и разработчиками программ.
2. Когнитивное сопротивление
Одно дело – понимать, что проблема есть, а другое – предложить план ее решения. Одним из ключевых моментов при решении проблем является тот язык, который мы используем. За годы своей работы я изобрел множество удобных терминов и ментальных моделей. Они доказали свою актуальность при обозначении проблемы, вызванной сложными в применении программными продуктами. В этой главе вы познакомитесь с этими терминами и идеями и увидите, как с их помощью польза от проектирования взаимодействия проникнет в наш дефективный процесс разработки.
Поведение, не зависимое от физических сил
Едва оставив позади индустриальную эпоху, мы оказались в преддверии эры информации, но инструменты в наших руках все те же. В индустриальную эпоху инженерам была под силу любая задача. Подчиняя себе сталь и бетон, они воздвигали мосты и небоскребы, создавали автомобили и космические корабли, которые прекрасно работали и радовали тех, кто ими пользовался. Теперь мы осторожно ступаем в век информации, нам все чаще приходится работать с программами, и мы снова задействуем лучших из наших инженеров для решения задач. Но, в отличие от прошлого, все уже не так просто. Конечно, компьютеры обладают несомненной производительностью и скоростью, а на программное обеспечение в целом можно положиться, но теперь мы столкнулись с расстроенными, неудовлетворенными, несчастливыми и непродуктивными пользователями.
Сегодня инженеры обладают не меньшим потенциалом, чем они обладали ранее, поэтому отсюда следует, что перед ними предстала качественно новая проблема, отличная от всего того, с чем им приходилось сталкиваться в индустриальную эпоху. Будь это не так, они успешно решали бы задачи и прежними инструментами. За неимением подходящего термина я обозначил сущность этой новой проблемы как «когнитивное сопротивление». Это такое сопротивление, с которым сталкивается человеческий ум, когда ему приходится разбираться в сложной системе правил, меняющихся в зависимости от поставленной задачи. Процесс взаимодействия с программами обладает высоким коэффициентом когнитивного сопротивления. Процесс взаимодействия с физическими устройствами, даже сложными, обычно имеет более низкий коэффициент сопротивления; это объясняется тем, что у механических устройств, как правило, ограниченный набор возможных состояний относительно количества возможных действий с ними.
Играть на скрипке чрезвычайно сложно, однако это действие обладает низким коэффициентом когнитивного сопротивления. Несмотря на то, что скрипач производит с ней множество различных по сложности манипуляций, извлекая самые невероятные звуки, скрипка никогда не войдет в метасостояние, при котором в зависимости от разных способов игры она будет звучать как труба или колокольчик. То, как поведет себя скрипка, всегда можно предвидеть: это подчиняется законам физики, хотя поначалу бывает не так просто понять ее поведение и научиться с ней обращаться. У микроволновой печи, напротив, высокий коэффициент сопротивления, так как каждая из десяти ее кнопок с цифрами может находиться в двух режимах, в зависимости от контекста. В одном случае кнопки регулируют интенсивность микроволнового излучения, а в другом они же отвечают за продолжительность тепловой обработки. Из-за таких переключений, в дополнение к отсутствию сенсорной обратной связи, по которой можно было бы определить, в каком режиме находится печь, когнитивное сопротивление возрастает в разы.
К примеру, клавиатура пишущей машинки не имеет метафункций. Нажимая клавишу с буквой «У», вы увидите на странице букву «У». Нажав последовательность клавиш из букв «СТЕРЕТЬ ВСЕ», вы увидите на листе бумаги слова «СТЕРЕТЬ ВСЕ». Компьютер же, в зависимости от контекста, при той же последовательности букв может задействовать метафункцию. Он выполнит операцию более высокого порядка и в самом деле что-то сотрет. То есть машина будет вести себя уже не так однозначно.
Когнитивное сопротивление, как и сопротивление в физическом мире, порой даже полезно, если присутствует в небольших количествах, но если оно увеличивается стремительными темпами, то вред от него растет экспоненциально. При этом обычное сопротивление является физической силой, которую можно выявить и измерить, а когнитивное сопротивление – инструмент в некотором смысле «судебный», и не нужно воспринимать его буквально. Но стоит отметить, что такие понятия, как любовь, честолюбие, мужество, страх, истина, при всей их реальности нельзя выявить и измерить. Равно как к ним нельзя применить методы инженерной науки.
Опытные производители микроволновых печей, как правило, привлекают экспертных консультантов по человеческому фактору, чтобы спроектировать такие кнопки, различать и нажимать которые пользователю будет удобно. Однако все, к чему адаптируют кнопки, эксперты по человеческому фактору, – это глаза и пальцы человека, но не его ум. В результате у микроволновых печей практически отсутствует коэффициент сопротивления в отношении физических действий с ними, зато когнитивное сопротивление при попытках разобраться в их поведении остается на высоком уровне. Открывать и закрывать дверцу, физически нажимать на кнопки достаточно легко, но вот добиться от панели управления выполнения нужных вам задач бывает не так просто. При всей сложности управления микроволновой печью мы в целом понимаем, как она работает, и это заставляет нас забыть о прочих трудностях взаимодействия с ней. Вспомните, как часто вы ошибочно устанавливали время разогрева на одну секунду или один час вместо одной минуты? Или как часто вы включали десятиминутный разогрев на пятом уровне мощности вместо пятиминутного на десятом уровне?
Каждый элемент на экране компьютера имеет свой коэффициент когнитивного сопротивления. Даже программы с таким простым интерфейсом, как браузеры, заставляют мозг пользователя работать в разы интенсивнее, чем при взаимодействии с любым механическим устройством. Это происходит оттого, что за каждой синей гиперссылкой скрывается переход к другой странице интернета. Все, что вам доступно, – это кликать по ссылке, но конечная точка, в которую вы при этом попадете, может измениться без каких-либо предупреждений, и вы не можете на это повлиять. В основе гиперссылки лежит метафункция. Из-за наличия подобных дополнительных «гиперсмыслов» объект и обзаводится когнитивным сопротивлением.
Дизайн и проектирование – понятия внушительные.
Суть этой книги в том, что в проектировании продуктов, обладающих интерактивностью, должны принимать участие проектировщики взаимодействия (interaction designers), а не разработчики программного обеспечения (software engineers). Программисты обычно сразу воспринимают это утверждение в штыки, ведь проектирование и дизайн составляют значительную часть их работы. Более того, их смертельно пугает тот факт, что теперь они будут лишены самого интересного и творческого аспекта процесса разработки и обречены писать нудный код, не получая от этого никакой радости. Это совершенно неверно. Их беспокойство произрастает из неясного понимания понятий «дизайн» и «проектирование».
Дизайн и проектирование присутствуют на протяжении всего процесса разработки программного продукта – от выбора языка программирования до подбора цвета фургона, доставляющего коробки с готовым продуктом. Ни в одном другом аспекте этого длительного и требующего полной отдачи процесса так не задействованы дизайн и проектирование, как в программировании. Программистам приходится принимать решения, связанные с дизайном и проектированием, на каждом шаге процесса разработки. Программисту нужно продумать, как осуществлять вызов одной процедуры через другую, как передавать, хранить, изменять и делать доступной информацию и сообщения о состоянии, как обеспечить валидность кода. Все эти решения, как и миллионы им подобных, – это непосредственно связанные с дизайном и проектированием решения, успешность которых зависит от того, насколько хорошо программисты используют свою рассудительность и мастерство.
Все многообразие видов дизайна и проектирования я могу легко поделить надвое. По одну сторону останутся те решения, которые непосредственно касаются взаимодействия с пользователем, а по другую – все, что к этому не относится. Когда вы встретите упоминание «проектирования взаимодействия» в этой книге, знайте, что под этим я понимаю только первую категорию решений. В отношении дизайна и проектирования, не влияющего на конечного пользователя, я применяю термин «проектирование программного продукта» (program design).
Осуществить такое разделение, основываясь исключительно на разнице в технических аспектах, представляется невозможным. Никак не получится выразить его в терминах, которыми привыкли оперировать инженеры, поскольку отличительный фактор здесь базируется на свойствах человеческой личности, а не на технических характеристиках, а инженерные правила неприменимы к людям. Например, проектировщики взаимодействия часто не придают значения выбору языка программирования для разработки программы. Тем не менее, как только от используемого языка будет зависеть время отклика программы, что, несомненно, относится к аспектам проектирования взаимодействия, проектировщику найдется что сказать.
Практически все вопросы проектирования взаимодействия лежат в плоскости выбора того, как будет вести себя программа, какой функциональностью обладать, как информировать пользователя и каким образом все это будет ему представлено. Процесс проектирования взаимодействия конечного продукта – это единственное из того, что я хочу отнять у программистов и передать в руки компетентных проектировщиков.
Взаимосвязь программистов и проектировщиков
В технологическом мире инженеров главная роль была отдана проектированию архитектуры программного продукта, а о проектировании взаимодействия на благо конечного пользователя вспоминали лишь постфактум, когда оставалось время. Одна из целей, которую я преследую в этой книге, – обозначить преимущества от смены приоритетов и добиться того, чтобы проектирование взаимодействия начали считать первоочередной задачей в процессе создания программных продуктов.
Дизайн большинства программ возникает по воле случая
Проектирование тростниковых хижин и подземных ходов происходит не всегда осознанно, исходя из возможностей камня и тростника. То же можно сказать и о программном обеспечении – его устройство подчинено неведомым законам языков программирования и баз данных. Значительное влияние на все перечисленные способы проектирования оказывают сложившиеся устои. С той лишь разницей, что строитель-проектировщик хижины сам будет в ней жить, в то время как программисты обычно не являются теми, кто использует спроектированное ими ПО.
Реальное положение дел состоит в том, что компании, которые ведут разработку программ, не содержат в штате людей, хоть что-то понимающих в проектировании пользовательского взаимодействия. Однако те же самые несведущие люди весьма неплохо разбираются в проектировании программных продуктов и имеют собственное сложившееся представление о том, что нравится лично им. В итоге получается то, что получается: дизайн, спроектированный под них самих, при этом они выбирают лишь те аспекты, которые легко и приятно реализовать в коде, и воображают, будто на самом деле все это создается для пользователя. И хотя разработчики пребывают в уверенности, что в отношении дизайна и проектирования проделан большой пласт работы, речь здесь в большей степени идет только о проектировании программного продукта, и совсем немного выполняется для проектирования пользовательского взаимодействия.
Поскольку несовершенное проектирование – это тоже проектирование, получается, что тот, кто берет на себя принятие решений о поведении программы, выполняет роль проектировщика пользовательского взаимодействия. Маркетолог ли это, настаивающий на добавлении привлекательной для него функции, или программист, пытающийся реализовать в программе удобные для него опции, – все они «проектируют».
Отличие хорошего проектирования от того, что похоже на постройку тростниковых хижин, вовсе не в инструментах или приспособлениях, которые для этого применяются, а в тех побуждениях, что им движут. Для настоящего проектировщика взаимодействия важны те цели, которых пытается достичь пользователь. Мнимые проектировщики руководствуются широким кругом любых других случайных доводов в процессе принятия решения. Просто поразительно, что к ним могут относиться персональные предпочтения, мнение близких, боязнь неизвестности, рекомендации Microsoft, промахи коллег – все может сыграть решающую роль. Но чаще всего их решения основаны на том, что будет самым простым в реализации.
Проектирование «взаимодействия» и проектирование «интерфейса»
Я предпочитаю говорить проектирование взаимодействия, а не проектирование интерфейса, потому что термин «интерфейс» предполагает, что код находится по одну сторону, а люди – по другую. А посредине есть некая прослойка, которая передает сигналы между ними. Это выглядит так, будто только интерфейс отвечает за нужды пользователя. В результате подобного отделения дизайна на уровне интерфейса программисты начинают справедливо мыслить приблизительно так: «Я могу кодить как моей душе угодно, ведь все равно интерфейс будет прикручен в самом конце». Процесс дизайна и проектирования откладывается напоследок, когда становится совсем поздно.
С помощью дизайна и проектирования интерфейса можно только «приукрасить» то поведение, которое уже заложено в программе, – это все равно что одеть в костюм от Armani Атиллу, предводителя гуннов. Так, интерфейс программы для создания отчетов позволит убрать ненужные границы таблиц с рядами цифр или устранить иные мешающие восприятию помехи, обозначить цветом важные показатели, дать визуально богатую обратную связь, когда пользователь будет щелкать по различным элементам. Несомненно, лучше такое поведение, чем вообще никакого, но для качественной системы этого отнюдь не достаточно. Microsoft затрачивает миллионы долларов на дизайн и проектирование интерфейсов, но их программные продукты так и не заслужили любви пользователей.
Поведенческое проектирование определяет, как должны себя вести и как взаимодействовать с пользователем элементы программного продукта. Если применить эту концепцию к тому же примеру с отчетными таблицами, то мы увидим, что поведенческое проектирование показывает, какими инструментами можно воспользоваться для работы с отчетом и как отразить в отчете средние и итоговые значения. Проектировщики взаимодействия начинают свою работу вовне, изучая цели, которые требуется достичь пользователю, но при этом постоянно контролируют, чтобы эти цели коррелировались с глобальными потребностями бизнеса, техническими возможностями системы и сопутствующими задачами.
Можно пойти еще дальше и затронуть область концептуального проектирования, которая исследует, что для пользователя является по-настоящему ценным и выходит на первый план. В примере с нашими таблицами концептуальное проектирование может показать, что работа над таблицей с цифрами лишь второстепенная задача для пользователя, – на самом же деле его целью является выявить тенденции и закономерности. Это означает, что вам следует задуматься не о создании инструмента формирования отчетности, а о проектировании средства отслеживания тенденций. Чтобы одновременно дать пользователям ощущение силы и удовольствия, проектировщикам взаимодействия следует изначально думать в концептуальном ключе, затем в поведенческом ключе и только потом задумываться об интерфейсе.
Что такого особенного в программных продуктах
Когнитивное сопротивление пробирается во все программные продукты, вне зависимости от простоты их внутреннего устройства, и оно же делает их куда как более сложными в использовании, в сравнении с их собратьями из эпохи механизмов. К примеру, заглянем, что лежит у меня в карманах: несколько монет, мой швейцарский армейский нож и мой автомобильный брелок. По ножу сразу видно, что это изобретение индустриальной эры: можно легко понять, из чего он состоит, как функционирует и что с ним нужно делать – вам достаточно произвести с ним пару быстрых манипуляций. Извлекая лезвие ножа, вы сможете оценить его острие и предположить, насколько оно подойдет для резки.
У ножа большой набор из шести лезвий, дополнительно прилагается зубочистка и пинцет. Для чего предназначен каждый из инструментов, мне ясно сразу. Легко, практически интуитивно я понимаю, что делать с ножом, благодаря тому, как он ровно ложится в мою руку и удобен для пальцев. Пользоваться этим ножом одно удовольствие.
Система бесключевого доступа на моем автомобильном брелоке – существо совсем другого толка. Она имеет всего две кнопки, поэтому на первый взгляд кажется проще в управлении, чем нож. Стоит обтекаемому черному кусочку пластика скользнуть в мои пальцы, как они совершенно естественно нащупывают две кнопки, чья функция предельно ясна: нужно нажать для активации. Хорошо, если бы было так, но за кнопками скрывается кремний, а не сталь, поэтому все не так просто, как кажется на первый взгляд.
Одно нажатие большой кнопки блокирует двери автомобиля и одновременно ставит его на сигнализацию. Если нажать второй раз – двери разблокируются, а сигнализация отключится. Еще одна кнопка на брелоке, чуть поменьше размером, подписана как Panic. Стоит нажать ее однократно, как автомобиль начинает тихонько переливаться трелями, и так продолжается несколько секунд. Стоит удержать нажатие чуть дольше, как тихие трели сменятся адским воем автомобильной сигнализации, то орущей, то щебечущей, то завывающей во все свои 100 децибел, возвещая на всю округу, что некий дурень вроде меня только что сотворил ужасающе глупую вещь. Хуже того, после срабатывания сигнализации кнопки маленького пластикового брелока прекращают на что-либо реагировать, так что он становится бесполезным. Единственное, как я могу положить конец этому громкому возвещению о моей явной глупости, – это дойти до моего страшно завывающего автомобиля, сгорая от стыда под взглядом каждого встречного, воспользоваться ключом для открытия двери со стороны водителя, затем вставить ключ в зажигание и повернуть его. При этом я действительно ощущаю себя болваном. Случись так, что мой автомобиль взломали и ограбили, я бы чувствовал себя подавленным и оскорбленным, но совершенно точно не болваном.
На страницах своей предыдущей книги я говорил о том, что главной целью всех, кто пользуется компьютерами, является не чувствовать себя глупыми. Я пошел еще дальше и высказал предположение, что качественные интерфейсы способны уберечь пользователя от того, чтобы не дернуть рычаг катапультирования, непонятно как оказавшийся среди постоянно используемых элементов панели управления. Рычаг катапульты – это классический пример устройства, из-за которого пользователи могут почувствовать себя глупыми, ведь он находится прямо перед ними. Если человек случайно потянет за этот рычаг, то поставит себя в весьма неудобное положение: это все равно что прийти утром в офис, забыв надеть брюки. С моим швейцарским армейским ножом проделать подобное в принципе не получится.
Я затрудняюсь даже представить, для чего мне могла бы понадобиться вторая кнопка, но еще более непонятно, почему создатели брелока упустили прекрасную возможность предоставить мне именно те функции, которые в самом деле желанны и необходимы6.
Безусловно, я ценю, что моя машина оборудована сигнализацией, но случаются ситуации, и их достаточно много, когда мне требуется просто закрыть машину и не ставить ее на сигнализацию. Когда я на несколько минут заскакиваю в Starbucks за кофе, то не нуждаюсь в таком же уровне безопасности моего авто, как, например, в аэропорту. Мне действительно хотелось бы иметь возможность открывать и закрывать машину удаленно и не включать при этом сигнализацию. Это бы мне очень пригодилось, когда я езжу по местным магазинам или подкидываю детей до школы.
Еще одной, не менее полезной и желанной опцией была бы поддержка системы запирания автомобиля с более высоким уровнем надежности. Периодически, когда я возвращаюсь к своей машине, которую до этого закрывал, выясняется, что он уже не заперт и произошла эта перемена в мое отсутствие. Этот инцидент имеет место, когда рядом с моей машиной паркуется похожий автомобиль той же марки. Его обладатель жмет на кнопку, чтобы запереть свой автомобиль и одновременно, сам того не зная, подает сигнал разблокировки моей машине, то есть фактически отключает сигнализацию, оставляя мой автомобиль на растерзание социально опасным личностям. Беспокоит то, что подобная ситуация может возникнуть там, где для этого самые «благоприятные» условия: на больших парковках, какие есть, например, в аэропорту, я могу оставить машину на несколько часов или даже дней, предоставив ее потенциальному влиянию чужих систем дистанционной разблокировки. Технология была бы более полезной, если бы я мог блокировать и ставить автомобиль на сигнализацию с помощью нее таким надежным способом, чтобы открыть и разблокировать ее было возможно лишь при моем личном участии и применении металлического ключа, вставленного в замок. Разумеется, мне известно, что такой способ есть – потому что именно так можно выключить сработавшую сигнализацию. Но увы, те, кто проектировал систему дистанционного управления, изрядно постарались, чтобы кто угодно мог снять мой автомобиль с сигнализации, несмотря на мои усилия обезопасить его.
Мой швейцарский армейский нож состоит из множества элементов и способен выполнять разные задачи, причем некоторые из его возможностей хитроумно спрятаны, тем не менее он довольно прост в изучении, предсказуем и интуитивно понятен. А вот система бесключевого доступа сложна в освоении, вызывает массу проблем и способна поставить меня в неловкое положение. Она не выполняет нужных мне задач и не позволяет контролировать собственный автомобиль и его сигнализацию на приемлемом уровне. Проще говоря, мне невыносимо взаимодействовать с этой системой. Она невообразимо плоха и вызывает во мне одну лишь ненависть.
Медведь-плясун
С другой стороны, появись передо мной возможность выбирать между ножом и системой бесключевого доступа, я в мгновение ока избавлюсь от ножа. Когда мне впервые довелось попробовать бесключевой доступ, я уже не представлял, как раньше мог обходиться без него. Это единственная наиболее удобная из всех опция в моем автомобиле, и я пользуюсь ею чаще остальных. В сравнении с ножом я применяю эту функцию в десять раз чаще. При всем ее непроработанном и неудобном устройстве она остается впечатляющим изобретением. Вообразите себе человека, который выводит на городскую площадь огромного медведя на цепи, собирает монетки со зрителей и заставляет медведя пуститься в пляс. Городские жители подтягиваются поближе, чтобы посмотреть на это невиданное зрелище – как большое неповоротливое животное неуклюже топчется на своих кривых лапах. Плясун из медведя никудышный, но зрителей впечатляет не его танцевальное мастерство, а тот факт, что он в принципе совершает пляшущие телодвижения.
Так же и с системой бесключевого доступа – впечатляет не то, что она работает без нареканий, а то, что она вообще хоть как-то работает. И тут я готов терпеливо сносить все проблемы взаимодействия, лишь бы иметь те выгоды, которые она дает мне относительно доступа к моей машине.
С открытием потенциала кремния мы получили столь изумительные возможности, что готовы с легкостью закрыть глаза на связанные с этим затраты. Оказавшись на необитаемом острове, вы вряд ли откажетесь от спасения, даже если к вам подплывет старая ржавая посудина, кишащая крысами. Между решением проблемы и отсутствием решения как такового настолько громадная разница, что мы готовы преодолевать сопряженные с этим трудности.
Сложность решения проблемы не в том, что нельзя разработать более удобное взаимодействие, а в том, что мы привыкли повсеместно соглашаться с использованием некачественных программ, принимая это как неизбежную данность. Завидев на горизонте ветхое проржавевшее спасательное судно, мы не задаем вопросов, какие там удобства, а радостно прыгаем на борт и довольствуемся тем, что имеем.
Экспертам в программном обеспечении приходится привыкать чувствовать себя комфортно при высоком уровне когнитивного сопротивления. Они с гордостью восхваляют свое умение выполнять рабочие задачи, несмотря на неудобства. У обычных же людей, кто только начинает пользоваться каким-либо программным продуктом, недостаточно профессиональных знаний, чтобы судить, как снизить уровень когнитивного сопротивления. Взамен они верят советам компьютерных умников, которые просто пожимают плечами и замечают, что для использования таких программных продуктов нужно обладать «компьютерной грамотностью». Программисты же, в свою очередь, винят во всем технологии, пытаясь объяснить пользователям, что проблемы с взаимодействием – это закономерное свойство всей техники и избежать этого не получится.
Но на самом деле это не так. Избежать сложных взаимодействий вполне возможно.
Источником когнитивного сопротивления являются не сами технологии, а те, кто управляет их разработкой. Они здесь главные, поскольку способны мыслить на языке кремниевых микросхем, и думаю, что этим свойством обладают и остальные. Они являют миру технологические артефакты, которые пытаются разговаривать с пользователем на том же языке, на котором их проектировали. Вместо того чтобы отделать салон автомобиля кожей и деревом, они предпочтут оставить на виду раскаленную сталь и скрежещущие механизмы. Будучи истинными инженерами, они больше задумываются о механизмах, нежели о кожаной отделке, потому и этот интерфейс выражается в терминах из области «реализации». Из-за этого я привык говорить, что такие продукты обладают моделью реализации.
Расплата за опции
Значительному количеству разработчиков программных продуктов неведомо, как создавать удобные в использовании программы, но вместо этого им хорошо известно, как пичкать их новыми опциями, потому они делают именно это.
Физические объекты, к которым относится мой швейцарский армейский нож, по естественным причинам не приветствуют разрастание новых опций, выходящих за пределы жизненной необходимости. Каждое новое лезвие или приспособление в моем ноже влечет для производителя дополнительные затраты. Создатель ножа отдает себе в этом отчет, поэтому каждая из вновь предлагаемых возможностей проходит этап строгого анализа на предмет необходимости до того, как будет реализована в конечном продукте. На языке инженеров это называется «отрицательной обратной связью» – то есть внутренние силы стремятся стабилизироваться и прийти в равновесие. Например, трение колес автомобиля о дорожное покрытие формирует отрицательную обратную связь в системе рулевого управления, так что, если вы отпустите рулевое колесо, оно будет стремиться вернуться к первоначальному положению.
В индустрии программного обеспечения превалирует иной подход. В связи с тем, что новые опции реализуются в будто бы неосязаемом программном коде, а не в физических материалах вроде стали, меди и пластика, у производителей, привыкших к прошлым условиям, создается впечатление, что опции достаются им почти даром. Им кажется, что программные продукты очень легко модифицировать, дополнять и внедрять в них «улучшения».
В этот самый момент я слушаю музыку Джимми Баффета с компакт-диска в моем компьютере. В небольшой программе-плеере с диска доступно множество разных опций: переход к предыдущему или следующему треку, выбор случайного трека, создание собственного плейлиста, воспроизведение в течение заданного времени, повтор воспроизведения, просмотр информации о Баффете в интернете, добавление альбома в избранное, внесение заметок к разным трекам, загрузка названий композиций из базы данных в сети, просмотр сведений о диске, создание списка избранных треков и много чего еще.
Все эти возможности, несомненно, приятны, и я бы не убирал их без лишней необходимости, но в общей своей массе они делают взаимодействие с программой крайне сложным и запутанным. Более того, когда мне нужно ответить на телефонный звонок и быстро поставить диск на паузу, я не могу найти нужную кнопку, потому что она погребена посреди всего этого огромного количества опций – бесплатных опций. Так что для меня они «бесплатными» отнюдь не являются. Какому-то незадачливому инженеру показалось, будто бы я мечтаю получить все эти бесплатные опции, однако мне просто нужен обычный плеер, в котором можно легко и быстро нажать на паузу.
Говоря о системе бесключевого доступа в моем автомобиле, я сильно сомневаюсь, что хоть кто-то из ее проектировщиков спросил себя: «Какие функции будут нужными и сколько их должно быть?» Напротив, я больше чем уверен, что какой-то младший инженер взял типовую микросхему, которая, по «счастливой» случайности, оказалась двухканальной. Один канал он приспособил для блокировки и разблокировки, а затем вспомнил, что у него есть еще один, лишний «бесплатный» канал. Этот инженер, вполне вероятно, будучи под началом инициативного менеджера по маркетингу – полного энтузиазма, но плохо информированного, – вообразил кажущуюся ему логичной схему, что выключение сигнализации вручную может для чего-то пригодиться. Наверное, он даже гордился тем, что смог предоставить дополнительную функциональность без явных затрат.
Вставить полноценный микропроцессор в ваш автомобильный брелок, микроволновую печь или мобильный телефон гораздо дешевле, нежели использовать отдельные микрочипы и электронные детали. Таким образом, новая технологическая экономика задает направление проектирования. Процесс добавления новых физических компонентов управления все еще сдерживается отрицательной обратной связью затрат на производство, но появление новых функций в программах не может сдержать уже ничего. Добавление новых программных опций представляется создателям программ делом незатратным, так что каждую предложенную опцию они считают хорошим вложением до тех пор, пока кто-то не сможет доказать обратное. В отсутствие регуляторов этого процесса продукты моментально обрастают множеством ненужных опций, что только усложняет процесс использования продукта для пользователя. Разумеется, эти функции представляются как совершенно необходимые преимущества, при этом, конечно, остается и основная, наиболее востребованная функция. Этот медведь уже начал приплясывать.
Что касается настольных компьютеров, то здесь недостаток обратной связи ослабляет их мощь. Разработчик программы воображает, что можно добавить какие его душе угодно функции и при этом они останутся «бесплатными», коль скоро их можно задействовать с помощью мыши и клавиатуры. В результате экраны заполоняют сотни непонятных значков, кнопок, элементов меню, каждый из которых должен реагировать на нажатие клавиш или на клик мыши. И как при этом пользователь должен выявить среди них незначительные опции и те, активация которых может повлечь серьезные негативные последствия?
Практически каждому коммерческому продукту свойственно усложняться с каждой последующей версией. Эволюционируя, программы получают новую функциональность и возможности, так что их интерфейс тоже обзаводится еще большим количеством элементов управления. В компьютерной прессе можно встретить такой термин, как «раздутое программное обеспечение» (bloatwear). Программы, подобные Lotus Notes, Adobe Photoshop, Intuit Quicken и Microsoft Word, так плотно набиты всевозможными опциями, что это сбивает пользователей с толку, тем более что лишь незначительная часть из них используется действительно эффективно, если вообще используется. А тем временем в этой массе всевозможных опций теряются действительно нужные и полезные.
Корпоративные программы страдают от этой проблемы еще больше, чем приложения для конечных пользователей. Компании, подобные Oracle, PeopleSoft, ADP, SAP, Siebel, разрабатывают комплексное программное обеспечение, необходимое для решения внутренних корпоративных задач. Такие программы невероятно сложно и непонятно устроены, а кроме того, перегружены различными опциями. С каждым ежегодным обновлением добавляются все новые и новые опции, а со старыми по-прежнему не представляется возможным разобраться тем, кто не пройдет многомесячное изнурительное обучение.
Поборники и потерпевшие
Медведи-плясуны заполонили мир вокруг нас. Компьютеры обещают нам такие впечатляющие возможности, что лишь немногие способны противостоять соблазну. Даже если у вас нет настольного компьютера, вы, несомненно, пользуетесь мобильным телефоном и банкоматами, а они работают на основе программного обеспечения. Нельзя просто так взять и не пользоваться компьютерами. Их цена не просто становится ниже – она стремительно падает, делая их доступными повсеместно. Множество вещей, которые мы привыкли считать механическими (или электронными), теперь обладают компьютерным разумом. Он присутствует в автомобилях, стиральных машинах, телевизорах, пылесосах, термостатах, лифтах – и это далеко не полный список.
В то время как в индустриальную эпоху уровень пользы от различных устройств был прямо пропорционален сложности взаимодействия с ними, в новом информационном мире такая корреляция отсутствует, а наблюдается лишь то, что устройства быстро становятся все более сложными, а польза от них растет куда медленнее. Настроить старинный будильник с механической начинкой всегда считалось простой задачей. А проделать то же самое с современными программируемыми часами может оказаться сложнее, чем управлять автомобилем.
Из-за высокой степени когнитивного сопротивления общество оказывается расколотым надвое. Одни впадают в отчаяние и начинают считать себя глупыми от неудачных попыток взаимодействия, а другие, наоборот, испытывают мощнейший эмоциональный подъем от того, что смогли в очередной раз преодолеть все трудности. Такие сильные переживания превращают людей в «поборников» и «потерпевших». Для первых когнитивное сопротивление становится частью образа жизни, а вторых оно вынуждает уйти в подполье и видеть в компьютерах врага. Этот разрыв становится все заметнее.
* * *
Я называю первых поборниками, или апологетами, поскольку они из кожи вон лезут, чтобы оправдать свое восхищение медвежьими плясками. Словно партийные агитаторы в нелепых шляпах и с бестолковыми плакатами в руках, они восхваляют достоинства программ и бесстыдно замалчивают недостатки, как настоящие партизаны. В сущности, к данной категории можно отнести почти всех программистов, и это логично, учитывая их заинтересованность в этом деле. Удивительно другое – как много обычных пользователей, не связанных с технологиями профессионально, тем не менее находят оправдания тем, кто каждый день вынуждает их использовать продукт с отвратительным взаимодействием. Вот что говорят они в защиту своих истязателей: «Да это же просто. Только запомнить, что надо нажать вот эти две клавиши, а потом ввести корректное название в систему. Если я вдруг забуду это название, система позволит мне легко найти его». Им невдомек, что сама фраза «система позволит найти» звучит нелепо. Отчего бы системе самой не запомнить или не поискать данные? Апологеты – это такие люди, которые будут защищать компьютер лишь потому, что он помог им выполнить не выполнимые до этого времени задачи. Они указывают на медведя-плясуна и восторженно ахают: «Глядите, он в самом деле пляшет!»
Апологеты напоминают жертв стокгольмского синдрома. Так называют тех заложников, что испытывают симпатию к своим захватчикам, объявляя без тени иронии или здравого смысла: «Он такой чудесный человек. Он даже позволяет нам пользоваться туалетом».
Апологеты маскируются, называя себя «продвинутыми пользователями». Не имеет значения, насколько сложна в использовании система или как мало реальной пользы приносит функциональность, апологет будет неизменно восхвалять лишь мощность и широкий набор опций очередного гаджета, словно не замечая сложностей в его реальном применении.
От одной из моих коллег, работающей в сфере мобильных телефонов, я услышал фразу о том, что инженеры делают использование телефонов невероятно сложным, добавляя в них множество опций, которые используются крайне редко. Она назвала мобильные телефоны «мочащимися собаками». На мою просьбу пояснить, что она имеет в виду, она ответила: «Нужно слишком сильно любить собаку, которая постоянно мочится, чтобы везде таскать ее с собой».
Поражает, как удается компьютерам притягивать к себе такое огромное количество невероятно умных и высокоорганизованных людей. Те же самые люди, вероятно, увлекаются рискованными и опасными занятиями и видами спорта: горными лыжами, пилотированием, плаванием с аквалангом, игрой на бирже, альпинизмом. Участники всех этих занятий должны быть тщательно подготовлены, и даже самая крошечная невнимательность может повлечь неприятные последствия. Однако не будь эти занятия наполнены такой притягательностью, ощущением вызова, разве в этом случае их поклонники не остались бы дома у телевизора?
Сложность – это именно то, чем они так невероятно привлекают к себе. Это испытание духа, преодоление чрезвычайно трудной ситуации, в которой нельзя ошибиться. Только представьте себе, как измотанный альпинист, с которого градом катится пот, залпом выпивает банку изотоника Gatorade, чтобы восстановить утраченные силы, и с ухмылкой поясняет: «Да, парни, последний отрезок подъема был почти отвесным, у меня даже мышцы судорогой свело, пока я туда карабкался». Он получает удовольствие от подобных трудностей! Чем тяжелее испытание, тем больше удовольствия! Вот поэтому он и занимается альпинизмом!
Компьютеры оказывают на людей аналогичное вдохновляющее действие, ведь для взаимодействия с ними нужно преодолевать подобные тяжелые, безжалостные вызовы. Если вы недостаточно тренированы, чтобы постоянно оставаться на высоте, компьютер просто бросит вас лежать в пыли и жаловаться на судьбу. Только представьте себе измотанного программиста, который залпом выпивает банку кока-колы и с ухмылкой поясняет: «Да, парни, я еле разобрался! Этот сбой был вызван дурной логикой программы, причем это происходило, только когда куча превышала размер в 64 мегабайта, а иначе кеш просто не был задействован!» Для него в этом особое удовольствие!
Отсюда и возникают апологеты. Им доставляет наслаждение преодолевать тяжелые испытания и суровые препоны судьбы. Они счастливы работать в таких обстоятельствах, где за счет своих невероятных способностей они выделяются среди других. Альпинист становится апологетом, защищающим сложные и крутые горные подъемы. Компьютерный энтузиаст становится апологетом, защищающим неявное и сложное в управлении компьютерное обеспечение.
* * *
Другой фронт этого противостояния составляют потерпевшие. Они смутно осознают, что происходит нечто совершенно неправильное, но вот что именно – сказать не могут. Они не слишком хорошо разбираются в технике и взаимодействии с ней, но понимают, что проблема имеет место. Они лишь могут определить, что для них сложно, а что легко, и в таком понимании компьютеры – это сложно.
Но они, как и другие люди, не могут просто перестать использовать компьютеры – техника необходима для решения насущных рабочих задач. Стиснув зубы, они вынуждены смириться с поведением программного обеспечения, похожего на медведей-плясунов. Им в голову не приходит, что компьютеры способны вести себя иначе; им лишь известно, что каждый раз при взаимодействии с ПК они начинают ощущать себя менее уверенно, нежели в обычном состоянии. Словно крестьяне феодального строя Средних веков, они не могут изменить положение вещей, равно как и осознать, чего их лишают. Единственное, что они четко понимают, – это что их подавляют.
Апологетам свойственна такая фраза: «Поглядите, что я могу сделать на этом компьютере». Потерпевшие обычно говорят: «Наверное, я просто недостаточно умный, чтобы разобраться с этими новомодными технологиями». Апологеты произносят: «Смотрите, медведь-плясун!» Потерпевшие произносят: «Хотел бы я найти нечто, что способно плясать, и, видимо, медведь – это лучшее из всего, что я могу увидеть». К потерпевшим относится большая часть людей, кого не поражает та мощь, которую они обретают с приходом в их жизнь компьютера, а, напротив, их поражает тот факт, насколько глупыми они начинают себя чувствовать при этом.
Несомненно, все представители компьютерной индустрии, равно как и смежных индустрий, занимающихся созданием продуктов и предоставлением услуг, связанных с технологиями, принимают сторону апологетов. То, как они действуют, отражает то, как они видят мир. Они всегда готовы защищать свои изобретения, восхваляя их функциональность и производительность. А когда их спрашивают о взаимодействиях с человеком, они, словно политики, избегают отвечать на провокационные вопросы, вместо этого начиная расхваливать широкие возможности продукта, количество его новых опций и то, как много людей уже им пользуется. Они игнорируют плохое качество медвежьей пляски, но выставляют напоказ сам факт этого явления.
С быстрым повсеместным распространением интернета и упрощением доступа к нему технологический мир накрыла волна новоявленных поборников и потерпевших. Поборники восхищенно твердят, как много всевозможных сервисов и ресурсов теперь доступно через интернет, в то время как потерпевшие пристально вглядываются в экраны своих компьютеров, пытаясь сообразить, как найти что-то, представляющее для них пользу. Они вынуждены бесконечно долго ждать, пока очередной сайт загрузит массу ненужных изображений, и, даже дождавшись, теряются в ворохе сложной структуры переходов к бесполезной информации. Всемирная паутина – это, наверное, самый крупный пляшущий медведь, с которым когда-либо приходилось сталкиваться человечеству.
Как мы реагируем на когнитивное сопротивление
Реакция подавляющего числа людей на когнитивное сопротивление в большинстве своем одинакова. Они довольствуются самым малым из всего многообразия, что им доступно, и напрочь забывают про остальное. Каждый пользователь осваивает минимальный набор функций для решения базовых задач, а все прочие просто-напросто игнорирует. Апологеты восторженно расписывают свои наручные часы, которые обладают функцией синхронизации с календарем на компьютере, да только ненавязчиво упускают тот факт, что последний раз эта функция пригодилась им полгода назад. Если вы укажете им на этот нюанс, они станут яростно защищаться – но на то они и апологеты.
Мой домашний центр развлечений обладает превеликим множеством разных функций – кажется, их в нем около тысячи. Я не апологет, но определенно помешан на всяких гаджетах. Я сумел освоить несколько любезно предложенных мне возможностей центра развлечений, но пользоваться ими эффективно довольно сложно. Например, у моего телевизора есть опция «картинка в картинке» (КвК) – это выглядит как небольшой дополнительный экран в правом нижнем углу основного экрана, отображающий вещание с другого канала. Функция эта полностью программная, и ею можно управлять кнопками на пульте. Теоретически такая опция могла бы пригодиться, например, чтобы следить за футбольным матчем на маленьком экране, пока на большом идет кинофильм. После того как продавец показал мне эту функцию в магазине, мне показалось, что это удобно.
Проблема в том, что использовать эту опцию невероятно сложно. Коэффициент когнитивного сопротивления очень высок, и я не могу освоить ее на достаточном уровне, чтобы ощутить какую-то выгоду. Куда как приятнее смотреть на один экран – как в старые добрые времена, когда телевизоры не могли предложить иного. Остальные члены моей семьи не захотели и один раз попробовать эту функцию и включают ее разве что случайно. Бывает, я возвращаюсь домой и вижу, как кто-то смотрит телевизор с КвК. Завидев меня в комнате, домашние сразу же требуют отключить эту опцию.
Диагональ экрана моего телевизора составляет 55 дюймов, а еще он оснащен звуковой системой Dolby Digital и принимает сигнал со спутника, но используется он мной и моей семьей точно так же, как наш старый телевизор Motorola с экраном в 19 дюймов в далеком 1957 году. Все его новомодные опции нам без надобности.
Предсказать, какие функции каждого нового устройства будут востребованы, а какие – нет, несложно. Чем больше манипуляций потребуется сделать, чтобы воспользоваться той или иной опцией, тем меньше она будет востребована, то есть наблюдается обратно пропорциональная зависимость. Так, экран моего нового телевизора, больший по размеру, более яркий и четкий, не притязает на дополнительные действия с моей стороны, поэтому он задействован на 100 %, пока телевизор включен, и я им весьма доволен. Спутниковое телевидение – очень желанный пляшущий медведь, поэтому я смиренно выношу все трудности, связанные с переключением источника сигнала, и смотрю спутниковые каналы приблизительно один раз в неделю или около того. Больше никто из членов моей семьи не смог совладать со спутниковой системой – пришлось сделать список подсказок с нужными для включения спутниковых каналов рычажками, кнопками и настройками, заламинировать его и поместить на кофейный столик. Что касается функции КвК – для ее включения и настройки используется около десятка разных кнопок, да еще к тому же не всегда понятно, как с ней взаимодействовать, а ее поведение не отличается привлекательностью. Промучившись с ней недолго, я перестал ее включать, а остальные последовали моему примеру.
Такие последствия когнитивного сопротивления, выраженные в отказе от использования функциональности, можно наблюдать практически в каждом офисе или доме почти с каждым программным продуктом или устройством на основе ПО.
Демократизация потребительского влияния
В обществе так сложилось, что чем сложнее был устроен тот или иной механизм, тем более высокопрофессиональные операторы требовались для взаимодействия с ним. Масштабные агрегаты всегда скрывали от посторонних глаз и подпускали к ним только особым образом обученных специалистов в форменной одежде. С приходом эры информации пришли и перемены, и теперь мы ждем от любителей способности совладать с технологиями, в разы более сложными, чем когда-либо видели наши предшественники.
Все больше и больше наших инструментов обзаводятся кремниевым разумом и все больше из них оказываются в руках неопытных пользователей. Двадцать пять лет назад обработкой междугородних вызовов занимался специально обученный оператор по устному запросу. В настоящее время самые сложные междугородние вызовы совершаются любым неподготовленным человеком самостоятельно, по нажатию на кнопки.
Несколько десятилетий назад даже на автозаправочных станциях присутствовали обученные сервисные специалисты. Сегодня каждый должен сам уметь пользоваться услугами заправки – не только заправить свой автомобиль, но и оплатить услугу кредитной или дебетовой картой. Двадцать лет назад взаимодействие с банком производилось не иначе, как с помощью отдельного обученного операциониста. Сегодня же вы самостоятельно коммуницируете с банком посредством терминала на заправочной станции или через банкомат.
Процесс инженерного проектирования при создании сложной системы не делает разницы между тем, будет ли ею оперировать специально нанятый профессионал или же неподготовленный новичок, который на это не подписывался. Процесс инженерного проектирования не обладает представлениями, как работать с этими особенностями человеческого характера. Он концентрируется только на вопросах реализации продукта: «из чего это будет сделано?», «как это будет сконструировано?», «какие управляющие элементы нужны для ввода всех возможных вариантов данных?».
Во всем виноват пользователь
Так как программы используются по большей части для решения рабочих задач, жертвы некачественного взаимодействия получают за свои мучения деньги. Им приходится задействовать программы в работе, так что не в их силах от них отказаться – в их силах только молча терпеть, покуда это возможно. Они вынуждены скрывать свое раздражение и подавлять то чувство собственной глупости, которое пытается внушить им программа.
Долгие годы я смотрел на десятки руководителей в сфере разработки программного обеспечения, когда они рисовали передо мной один и тот же схематичный рисунок, отражающий их видение рынка высоких технологий. На рисунке представлена пирамида (некоторые изображают ее перевернутой), состоящая из трех уровней, каждый из которых обозначен одной, казалось бы, безобидной фразой. Поверх этой пирамиды каждый менеджер непременно рисует некую шарообразную фигуру, призванную продемонстрировать сегмент рынка, на завоевание которого нацелилась компания. Но каждый уровень пирамиды на деле обозначен эвфемизмом – фразой, несущей завуалированный оскорбительный смысл, из тех, которыми пользуются фанатики, чтобы изгнать непосвященного из тайного общества.
Вот они, эти три эвфемизма, обозначающих разные типы пользователей: «неопытный», «компьютерно грамотный» и «продвинутый».
«Неопытный пользователь» – это, в понимании компьютерной индустрии, все равно что «недалекий и некомпетентный». На самом же деле эти люди таковыми не являются – их вынуждает чувствовать себя глупыми некачественное проектирование взаимодействия. Поборники программного обеспечения не считают таких пользователей за пользователей вообще, однако это не согласуется со здравым смыслом. Только с чего бы поставщику программных продуктов пренебрегать этой львиной долей рынка ПО? Все дело в том, что такая позиция снимает ответственность за провал с менеджеров и программистов и перекладывает бремя этой вины на плечи неопытных пользователей.
Под оборотом «компьютерно грамотный пользователь» на самом деле подразумевается человек, которому причиняли боль столько раз, что он уже оброс толстой кожей и ничего не чувствует. Обладать компьютерной грамотностью – значит, что если вы вдруг потеряете документ, как Джейн из главы 1 «Загадки информационной эры», то уже не станете паниковать, а просто молча, медленно и методично начнете совершать бесполезный поиск файла в структуре файлов и каталогов, ни разу не пожаловавшись на это. Обучение компьютерной грамотности похоже на анестезию: пользователь плавно впадает в состояние полной бессознательности. В самом деле, зачем постоянно жаловаться на свою несостоятельность или ругать программу, без которой не обойтись при решении рабочих задач. Значительная часть пользователей даже не осознает, как много усилий они тратят на то, чтобы обойти несовершенства программных продуктов.
Апологеты в большинстве своем принимают компьютерную грамотность за некую награду, признак высоких достижений, вроде медали за меткость в стрельбе. Хотя куда более уместна здесь будет аналогия с Пурпурным сердцем – официальной наградой пострадавших от ранения в бою.
Продвинутые пользователи – те же апологеты. Это увлеченные технари, которые сумели преодолеть свои самые сильные инстинкты и превратились в успешных потребителей программных продуктов с высоким коэффициентом когнитивного сопротивления. Они с гордостью преодолевают такие испытания, будто пытаются влезть на скалу в Йосемитском национальном парке.
Софтверный апартеид
В Голливуде бродит старая шутка про то, что, если внезапно спросить у любого посетителя в продуктовом магазине, как у него дела со сценарием, то он, не моргнув глазом, ответит: «Прекрасно! Я как раз переделал второй акт, чтобы придать действию драматизма!» Таким же образом теперь можно шутить и про Кремниевую долину. Стоит вам выцепить из очереди в Starbucks какую-нибудь незнакомку и задать ей вопрос о том, как дела с ее сайтом, она без промедления ответит: «Прекрасно! Я как раз переделала фреймы, чтобы оптимизировать навигацию!»
Обитатели Долины забывают, как сильно они не похожи на всех остальных, так что им стоит почаще напоминать себе об этом. Среднего пользователя компьютера в этих краях далеко нельзя назвать средним в понимании обычных людей.
Программисты обычно проводят время в среде таких же технарей, как они сами, работая в анклавах вроде Кремниевой долины, 128-й окружной автомагистрали в пригороде Бостона, Исследовательского треугольника в Северной Каролине, Редмонда, штат Вашингтон, и Остина, штат Техас. Создатели программ постоянно видятся с себе подобными, когда ходят по магазинам, обедают, отвозят детей в школу, отдыхают, а с недовольными пользователями ПК они практически не пересекаются. Более того, приступы раздражения, периодически возникающие среди пользователей, неясно в чей адрес, практически теряются в множественных проявлениях энтузиазма среди интеллектуальной элиты. Мы забыли, насколько велик разрыв между нами и другими жителями страны (если не сказать – мира), в неспособности использовать интерактивные технологии без раздражения.
Мы – те, кто находится в самом сердце индустрии, – провозглашаем понятие «компьютерная грамотность», подразумевая, что людям для того, чтобы пользоваться компьютером, требуется овладеть базовыми знаниями и навыками. Нам это требование кажется несложным и даже разумным. Мы думаем, что изучить основы – не такое уж большое усилие для пользователей, в обмен на радость от всех тех преимуществ, которые дают компьютеры. Но на самом деле мы требуем от них слишком многого. Наличие фундамента пользователей, обладающих компьютерной грамотностью, безусловно, значительно упрощает процесс разработки ПО, но также и тормозит развитие и возникновение успеха в индустрии и обществе. Апологеты могли бы возразить, что перед тем, как сесть за руль автомобиля, люди обычно учат правила дорожного движения и берут практические уроки вождения, но они упускают из виду тот факт, что ошибка на дороге может стоить кому-то жизни, а работа с программным обеспечением имеет меньшую тяжесть последствий. Если бы машины не могли привести к гибели, процесс обучения вождению выглядел бы так же, как иные осваивают Excel.
Когда мы оперируем понятием компьютерной грамотности, возникает другой, гораздо более коварный эффект. Между обеспеченными людьми и малоимущими появляется демаркационная полоса. Там, где в Америке требуется знание компьютера, чтобы преуспеть на рынке труда и стать чем-то большим, нежели продавец гамбургеров, трудности, связанные с изучением интерактивных систем, удерживают многих людей от попыток получить более интересную, солидную и высокооплачиваемую работу.
Пользователей не должны вынуждать становиться компьютерно грамотными, чтобы использовать компьютер для выполнения простейших ежедневных рутинных задач. Пользователь не обязан обладать цифровым чутьем, чтобы суметь совладать с видеомагнитофоном, микроволновой печью или электронной почтой. Более того, нельзя заставлять пользователей дополнительно получать компьютерное образование для решения задач в предметной области, в которой они уже и так являются специалистами. Например, бухгалтер, уже изучивший принципы бухгалтерского учета, не должен в дополнение учиться специальным навыкам работы с компьютером, чтобы использовать его для ежедневных задач. Ему должно быть достаточно профессиональных предметных знаний.
Чем больше экономика нашего общества уходит корнями в использование информационных технологий, тем более разделенным становится наше общество, хотя мы сами того не осознаем в полной мере. Наверху оказываются люди, познавшие нюансы отличия оперативной памяти от жесткого диска. А низшим классом считаются те, кто полагает, что знание этих отличий несущественно. Ирония состоит в том, что знать, в чем тут разница, действительно несущественно для всех, кроме небольшого числа инженеров по аппаратному обеспечению. Однако значительное количество программных продуктов заставляет пользователей разбираться с файловой системой, где успех в выполнении ими рабочих задач зависит от осознания разницы между оперативной памятью и жестким диском.
Таким образом, понятие «компьютерная грамотность» представляет собой эвфемизм для обозначения социального и экономического апартеида. «Компьютерная грамотность» – это кодовое слово, по которому одна часть общества отделяется от другой.
А что же происходит с теми, кто не хочет становиться пособниками технократов и не намерен овладевать компьютерной грамотностью? Такие люди, в большинстве своем по собственному выбору, а в меньшинстве – по воле обстоятельств, вынуждены оставаться позади информационной революции. Многие технологические компании, например, отказывают кандидатам, у которых нет электронного почтового адреса. Больше чем уверен, что есть еще множество квалифицированных специалистов в своей области, кто не может устроиться на работу из-за того, что они не имеют доступа к сети интернет. Несмотря на восхваления апологетов, работа с электронной почтой на достаточном уровне эффективности сложна и требует определенного уровня компьютерной грамотности. Получается, что часть потенциальных работников отпадает. Это напоминает практику «красной черты», которую используют некоторые банки. Это незаконная процедура, и заключается она в том, что все дома какого-либо района по умолчанию принимают как неподходящие для обеспечения жилищной ссуды. И хотя красными линиями на карте якобы чертят по границам экономических областей, на самом деле в них явно прослеживаются расовые разграничения. Банковские служащие сопротивляются тому, что их называют расистами, но результаты говорят об обратном.
Программисты, которые твердят нам про компьютерную грамотность, тоже проводят красную черту, отделяя этнические группы, но мало кто видит это. Представляется очень сложным увидеть то, что на самом деле происходит, так как суть проблемы виртуозно скрывается баснями из сферы технологий. Выявить, что банковский служащий может выдавать ссуду под любой дом, достаточно легко. Но уже не так просто понять, что разработчик способен создавать программные продукты, взаимодействие с которыми будет приятно для пользователя даже из низшего социального слоя.
В нашей индустрии не принято признавать проблему отсутствия программных продуктов с качественным взаимодействием. Вокруг слишком много поборников, восторгающихся пляшущими медведями. Своими нарочитыми восторгами они душат на корню едва возникающие сомнения других в эффективности программных продуктов. До того как начать исследовать возможные решения, мы должны единогласно прийти в себя и осознать, насколько масштабна и злободневна эта проблема. Это цель нашего следующей части.
Часть II. Цена слишком высока
3. Пустые растраты
Не так-то просто, хотя иногда кажется иначе, впустую потратить миллионы долларов, но прекрасным подспорьем в этом нелегком деле может стать некачественный процесс разработки. Все дело в том, что процессу разработки не хватает одной маленькой ключевой детали: понимания, в какой момент считать продукт «завершенным». Без этого жизненно важного знания мы слепо полагаемся на произвольный дедлайн. Мы стремимся пересечь финишную черту и готовы затрачивать миллионы, лишь бы сделать это поскорее, но в очередной раз обнаруживаем, что этот финиш лишь мираж. В этой главе я постараюсь развенчать миф о следовании таким дедлайнам, что в итоге обходится слишком дорого.
Управление дедлайнами
В Кремниевой долине сложились некоторые навязчивые устои касательно времени вывода продуктов на рынок. Существует распространенное предположение, что выпустить продукт прямо сейчас гораздо лучше, нежели сделать это позже. Такая устоявшаяся необходимость служит оправданием нереалистичным амбициозным срокам сдачи и выгоранию сотрудников, занятых в проекте, но на деле это лишь прикрытие, отвлекающий маневр, за которым скрываются намного более серьезные и глубокие страхи. Любому предпринимателю прекрасно известно, что вывести на рынок раздражающий и расстраивающий пользователя продукт спустя три месяца от начала его разработки ничуть не лучше, чем выпустить приятный пользователю продукт спустя шесть месяцев.
У каждого руководителя внутри есть как минимум два схожих страха. Руководители беспокоятся о том, в какие сроки их программисты смогут завершить разработку, и сомневаются насчет того, будет ли разработанный продукт достаточно хорош, чтобы в конечном счете стать успешным на рынке. Оба этих страха исходят от присущей каждому руководителю недостаточной ясности видения, что должен собой представлять конечный продукт. Все, что они могут про него сказать, – это что продукт «должен работать на компьютере пользователя» и «он не должен приводить к сбоям». Ввиду отсутствия такого видения они не могут оценить степень завершенности продукта.
В результате таких опасений под описание продукта, который «не приводит к сбоям», подходит и тот, который разрабатывался три месяца, и тот, разработка которого занимает шесть месяцев, с той лишь разницей, что на последний требуется три лишних месяца программирования и дополнительные чудовищные затраты средств. Стоит программистам начать работу, деньги улетают стремительно. Следуя такой логике, руководитель разработки считает самым важным приступить к программированию как можно раньше и закончить тоже как можно раньше.
Сознательный руководитель разработки быстро набирает программистов в команду и велит им незамедлительно приступать к работе. Он решительно отводит на завершение проекта всего несколько месяцев с даты его начала, и команда начинает сломя голову мчаться к финишной прямой. Однако при отсутствии должного проектирования проекта оба страха руководителя остаются в силе. Понравится ли продукт потребителям – все еще не ясно, так что его успешность на рынке покрыта мраком. И так же не ясно, как должен выглядеть готовый продукт, что покрывает мраком и степень его завершенности. Чуть позже в этой книге я продемонстрирую, как проектирование взаимодействия позволяет сгладить эти проблемы. А прямо сейчас я покажу, как основательно дедлайн способен пошатнуть процесс разработки до такой степени, что худшие опасения руководителя начнут сбываться.
Как выглядит «завершенный» продукт?
Когда у нас на руках окажется детализированное описание того, как должно выглядеть готовое программное обеспечение, появится возможность сравнить наше творение с указанным описанием и получить полное представление, завершен ли продукт.
Описания бывают двух типов. Мы можем либо подробно описать физический вид требуемого продукта, либо обозначить, какова будет ожидаемая реакция пользователя на конечный продукт. Так, в сфере строительства и архитектуры план является таким документом, который удовлетворяет условиям первого типа описаний. Если же речь идет о съемке нового фильма или открытии ресторана, в своем описании мы фокусируемся на тех эмоциях и ощущениях, которые должен испытать посетитель. Проектируя программы и продукты на их основе, нам обязательно следует прибегнуть к совмещению обоих типов описаний.
К несчастью, у многих программных продуктов такие описания просто-напросто отсутствуют. Вместо этого у них есть обширные перечни функций, сравнимые со списком покупок в магазине. Однако набить корзину для покупок мукой, сахаром, молоком и яйцами – это совсем не то же самое, что испечь торт. Торт получится только в результате следования всем шагам рецепта, и то, что мы приготовим в итоге, будет выглядеть как торт и обладать знакомым нам ароматом и вкусом торта.
Мнимый пекарь, у которого есть все ингредиенты для торта, но нет нужных знаний, как этот торт испечь, только впустую проведет время на кухне и получит сомнительный результат. Потребуй мы, чтобы торт был готов к шести часам, добропорядочный пекарь выполнит задачу точно в срок, но будет ли то, что он принесет, тортом? Все, в чем мы можем быть уверены, – что продукт появится вовремя, но вот о его успешности можно только гадать.
В большинстве строительных проектов мы способны точно оценить степень готовности объекта, потому что понимаем, как выглядит завершенный проект. Мы знаем, что здание готово, потому что оно выглядит и функционирует в точности так, как это описано на планах. Если объект должен быть сдан первого июня, это не всегда означает, что в указанный срок здание будет готово. Относительная степень готовности здания может быть оценена только в сравнении текущего объекта с планом.
Без подобных планов создатели программ оказываются лишенными ясного понимания, что считать готовым продуктом, поэтому они назначают приблизительную дату завершения, а когда она наступает, просто объявляют продукт готовым. Наступило первое июня? Значит, продукт готов. «Запускаем!» – говорят они, и дедлайн становится единственной контрольной точкой степени завершенности продукта.
Разумеется, программисты и предприниматели далеко не дураки, оттого продукт не получится слишком уж оторванным от реальности. У него будет широкий набор функций, и работать он станет стабильно и без сбоев. Он даже начнет прекрасно справляться с задачами, если окажется в руках людей, сильно заинтересованных в том, чтобы так оно и было. Может статься даже так, что продукт проходил юзабилити-тестирование, при котором группа добровольцев пытается выполнять на нем задачи под наблюдением специалистов по юзабилити7. Но так как количество предпринятых разумных мер предосторожности этим ограничивается, мы все еще не можем с большой долей вероятности ответить на вопрос, будет ли продукт успешным.
Закон Паркинсона
Руководители знают, что разработка программного обеспечения идет в соответствии с законом Паркинсона: работа заполняет все время, отпущенное на нее, увеличиваясь в объеме. Если вы работаете в сфере разработки ПО, то вам, скорее всего, известно и следствие из этого закона, которое называют «правилом 90/90» (автором этого правила считают Тома Каргилла из Веll Labs): «Первые 90 % кода занимают первые 90 % времени разработки. Остальные 10 % кода занимают вторые 90 % времени разработки». Это уничижительное правило просто-напросто говорит, что даже в тот момент, когда первые 90 % кода написаны, программистам по-прежнему неизвестно, в какой стадии находится проект! Руководство прекрасно знает, что сдать проект в срок не получится, какие бы сроки ни были установлены. А учитывая то, что программисты наиболее продуктивно работают под давлением, руководители применяют дедлайн как один из рычагов воздействия на них.
В 1980-е и 1990-е годы вице-президентом по разработке в небольшой, но достаточно влиятельной компании под названием Т/Maker был Ройял Фаррос. Он говорил так: «Многие из нас устанавливали настолько жесткие дедлайны, что в них было заведомо невозможно уложиться. Такая ситуация лишний раз подтверждала одно из следствий закона Паркинсона: „Этап завершения проекта разработки требует в два раза больше времени, чем планировалось“. Я пребывал в твердом убеждении, что, если установить дедлайн, например, через шесть месяцев, на самом деле это займет год. Таким образом, если нужно было получить продукт через два года, дедлайн надо было устанавливать на один год. Такие сроки просто огорошивали, но метод срабатывал всегда».
Риджли Эверс, предприниматель в сфере разработки программного обеспечения, работая в Intuit над созданием QuickBooks, наблюдал ту же проблему. «Первая версия QuickBooks должна была выйти спустя девять месяцев. Мы правильно решили, что период разработки будет длиться столько же, сколько беременность, правда, кое в чем слегка ошиблись: срок подготовки проекта составил почти два с половиной года – как беременность слона».
Скотт Макгрегор, архитектор программного обеспечения, отмечает, что в такой ситуации применим также закон Грешема, гласящий: «Худшие деньги вытесняют из обращения лучшие». Если на рынке присутствует две валюты, то более сильную люди хранят, а тратят более слабую. В результате это выливается в то, что в обращении преимущественно остается слабая валюта. Аналогичным образом недостоверная оценка сроков реализации проекта вытесняет реалистичные прогнозы. Если все только и занимаются тем, что делают слишком оптимистичные прогнозы, взятые «с потолка», то руководитель, который пытается предлагать более долгие, но вместе с тем приближенные к реальности сроки, выглядит так, будто умышленно саботирует процесс разработки. В конечном счете на него будет оказано давление, и ему придется скорректировать свою оценку ситуации в сторону уменьшения времени работы над проектом.
Невыполнимость дедлайнов в некоторых проектах вызвана тем, что сроки устанавливают совершенно произвольно. Большинство рационально мыслящих руководителей склоняются к установке таких сроков, которые в целом кажутся достижимыми, однако ради этого приходится идти на огромные жертвы. Это все равно, как если бы пилот самолета вдруг заявил: «Прибудем в Чикаго точно вовремя, но только если сбросим весь багаж!» В своей практике я наблюдал, как руководители проектов по разработке помимо проектирования жертвуют также тестированием, функциональностью, опциями, интеграцией, документацией и даже сущностью проекта. Значительная часть из тех, кто руководит разработкой продукта и с кем мне доводилось работать, предпочтут поскорее вывести на рынок провальный продукт, не желая рисковать оказаться среди опоздавших.
Продукт, который не выйдет никогда
Руководители разработки программного обеспечения нередко предпочитают именно такой подход, потому что глубоко внутри них присутствует страх, что стоит им опоздать с выпуском продукта, и он не выйдет уже никогда. Истории о продуктах, которым так и не суждено было увидеть свет, отнюдь не безосновательны. Сначала выпуск продукта запаздывает на год, потом год превращается в два, а на третий год его настигает карающая десница высшего менеджмента или совет директоров и окончательно умерщвляет. Оттого и возникает неистовая приверженность к дедлайнам, даже если это влечет угрозу жизнеспособности продукта.
Так, в конце 1990-х годов один громко разрекламированный стартап Worlds, Inc., команда которого состояла из множества умных и способных специалистов, работал над созданием виртуального онлайн-мира, где аватары людей могли бы перемещаться по виртуальному пространству и вовлекать других аватаров в общение в реальном времени. У продукта никогда не было полного определения или описания, и после того, как на этот проект были спущены десятки миллионов долларов инвестиций, руководство стартапа благоразумно свернуло эту затею.
В начале 1990-х годов еще один стартап Nomadic Computing потратил почти 15 миллионов долларов на попытку создать новый продукт для бизнесменов, обладающих высокой степенью мобильности. К несчастью, ни один человек в компании не мог точно сказать, что это за продукт. Команда понимала, на какой рыночный сегмент она ориентируется и каким функционалом должен обладать продукт, но не имела ясной картины о целях потенциальных пользователей. Как безумный скульптор откалывает кусок за куском от мраморной глыбы, надеясь обнаружить внутри статую, так и программисты писали внушительные объемы кода, по сути своей бесполезного, который затем просто выкидывали вместе с деньгами, временем, репутацией и своей карьерой. Самой же обескураживающей потерей была упущенная возможность сделать по-настоящему желанный для пользователя продукт.
Не удалось избежать такой напасти даже корпорации Microsoft. Впервые попытавшись создать программное обеспечение для управления базами данных в конце 1980-х годов, компания затратила на это множество человеко-лет, и завершился этот проект тем, что Билл Гейтс просто-напросто милосердно его закрыл. Ударной волной прошла эта преждевременная кончина проекта по сообществу разработчиков. Последовавший за ним программный продукт Access стал совершенно новой попыткой, над которой работала другая команда разработчиков и другие руководители.
Поздний выпуск продукта – это не смертельно
Как ни странно, поздний выпуск продукта чаще всего не является таким уж фатальным для него событием. Если опоздавший продукт обладает качеством ниже среднего, то он, безусловно, имеет все шансы провалиться, но если продукт несет ценность потребителю, нарушение графика выпуска с большой долей вероятности не вызовет продолжительный негативный эффект. Для настоящего хита не важно, вышел он на месяц или даже на год позже. Microsoft Access вышел с опозданием на несколько лет, тем не менее он все еще занимает значительную долю рынка. И обратная ситуация – окажись продукт отвратительным, кто вспомнит, что он был выпущен точно в срок?
Разумеется, для некоторых массовых продуктов сроки могут быть очень критичны, например, если такие продукты приносят основную долю прибыли только в сезон рождественских праздников. Однако большинство программных продуктов, даже потребительских, не столь требовательны к срокам.
Так, компьютеру PenPoint, разработанному компанией GO в 1990 году, пророчили славу прародителя поколения носимых карманных компьютеров и основоположника революции в этом направлении. Однако в 1992 году PenPoint потерпел крах, и эстафету по перевороту индустрии носимых устройств перехватил компьютер Apple Newton. После того как и Newton не смог воодушевить пользователей, на горизонте эры карманных компьютеров забрезжила новая надежда – Magic Link от General Magic. На календаре был 1994 год. Когда продажи Magic Link также провалились, на рынке карманных компьютеров наступила мертвая тишина. Инвесторы провозгласили этот сегмент рынка бесперспективным. А потом, словно из ниоткуда, в 1996 году на рынке возник PalmPilot и в мгновение ока снискал всеобщее признание. Его создатели вступили на никем не захваченную территорию с опозданием на шесть лет. Рынок всегда готов принять качественный продукт, доносящий ценность и удовлетворяющий потребности клиентов.
Нет причин спорить, что компании, долгие годы создававшие только аппаратные устройства, сегодня прибегают к гибридной технологии, объединяя микрочипы и программное обеспечение. При этом они часто недооценивают важность программного обеспечения и пытаются подчинить процесс его разработки уже сложившимся процедурам создания аппаратного обеспечения. И такая позиция в корне неверна, ведь, как уже было описано в главе 1 «Загадки информационной эры», такие компании теперь ведут свою деятельность в сфере разработки программного обеспечения, знают они об этом или нет.
Выторговывание опций
Следствием процесса управления дедлайнами стал феномен, который я называю «выторговывание опций». Много лет назад программистов обвиняли во всех грехах из-за их привычки запутанно описывать свойства программного продукта на салфетках во время вечеринок, что, по мнению пользователей, нередко влекло за собой появление неудачного ПО. Пытаясь защититься, программисты начали выдвигать требования, чтобы руководители и маркетологи были более точными в своих запросах. Компьютерные программы работают на основе процедур, а эти процедуры с легкостью приводят к появлению новых опций продукта, так что вполне естественно, что программисты соотнесли понятие точности в запросах со списком опций. Этот список опций позволял программистам сваливать всю вину на руководителей, если продукт оказывался провальным. У них всегда находился такой ответ: «Мы здесь ни при чем. Мы добавили все опции, которых требовало от нас руководство».
Как следствие, жизненный цикл большинства продуктов начинается с документа, который имеет разные названия: «маркетинговая спецификация», «техническая спецификация» или «маркетинговые требования». Другими словами, этот документ представляет собой список желаемых опций, что-то вроде списка ингредиентов в рецепте торта. Как правило, такой документ рождается в ходе множества продолжительных мозговых штурмов, на которых руководство, специалисты по маркетингу и программисты выдумывают, какие опции сразят всех наповал, и делают краткие тезисные наброски. Излюбленным инструментом для создания списков опций обычно являются электронные таблицы, одна такая таблица может быть длиной в десяток экранов. (Одна из строк этой таблицы неизменно содержит опцию «хороший пользовательский интерфейс».) Предложения по новым опциям могут также исходить от фокус-групп, появляться в ходе исследований рынка и анализа конкурентов.
Затем этот сформированный список опций руководители передают программистам со словами: «Продукт должен быть готов к 1 июня». Программисты, конечно же, соглашаются, но с некоторыми оговорками. Они заявляют, что функций слишком много, их не получится реализовать в отведенные сроки, а потому многие возможности придется урезать, чтобы успеть уложиться в дедлайн. Так начинается старый как мир процесс торга.
Программисты проводят черту в середине списка. Все, что выше этой черты, будет реализовано, говорят они, а все, что ниже «линии смерти», откладывается на потом или вовсе игнорируется. Они ставят руководство перед выбором: дать больше времени на разработку или урезать количество опций. Несмотря на то что на разработку продукта неизбежно потребуется больше времени, чем было запланировано, руководство не хочет разыгрывать этот козырь уже в самом начале проекта, потому начинается обсуждение функциональных возможностей. На этом этапе возникает множество споров и моментов, не лишенных драматизма. Опции вымениваются на время, а время падает жертвой опций. Эта примитивная словесная борьба за выгоды так естественна для природы человека, что ни одна из сторон не испытывает неудобств. Придумываются сложные параллельные стратегии. Как отмечает Ройял Фаррос из компании Т/Maker: «Стоит обвинить какую-нибудь одну опцию в срыве дедлайна, как в список незаметно прокрадется еще с десяток других запоздалых опций». В этой битве теряется видение перспективы, столь необходимое для успешности продукта.
По рассказу Фарроса, флагманским продуктом компании T/Maker был текстовый процессор WriteNow – «идеальный программный продукт для университетов. В 1987 году количество продаж копий WriteNow университетам было больше, чем количество продаж копий Word компанией Microsoft. Тем не менее мы не смогли удержать лидерские позиции, потому что не учли одной функции, крайне необходимой текстовым процессорам для университетов, – концевые сноски, чем сильно разозлили наших самых лояльных потребителей в этом рыночном сегменте. В попытках не сорвать дедлайн мы так и не смогли включить ее в спецификацию. В результате продукт вышел точно в срок, но при этом мы потеряли целый сегмент рынка».
Программисты правят бал
Программисты всецело держат в своих руках контроль над процессом принятия решений, которые на самом деле исходят снизу вверх, хотя кажется наоборот. Именно от них зависит, как долго будет реализовываться каждая опция, поэтому они могут настоять на том, чтобы переместить какой-либо пункт списка в конец, просто заявив, что на его создание уйдет много времени. При этом, если программисты встречают размытое требование, они, в целях самозащиты, относят его к трудоемким, и часто такими требованиями оказываются весьма существенные аспекты пользовательского взаимодействия. В итоге эти аспекты оказываются внизу списка, в то время как наверх выплывают более понятные формулировки и простые в разработке элементы: меню, мастеры создания и установки, диалоговые окна. Все эти аспекты, появившиеся в ходе долгих часов анализа и тщательного обдумывания властями предержащими высокооплачиваемыми топ-менеджерами, в одночасье ставятся под сомнение односторонним решением программиста, действующего из собственных соображений или стремящегося отстоять свою территорию.
Положение руководителей в этом случае становится весьма незавидным – они могут оказывать влияние только на самые незначительные аспекты процесса разработки. Это все равно что пытаться прибавить громкость колонок, которые находятся далеко за пределами слышимости. Разумеется, контроль процесса создания и выпуска успешных программных продуктов – это необходимость для высшего менеджмента, однако, к сожалению, такое поклонение дедлайнам пренебрегает аспектами, способными привести продукт к успеху, и фокусируется на самом факте создания продукта. Мы отдаем бразды правления в руки разработчиков продукта, тем самым оставляя для руководителей лишь роль пассажиров или пассивных наблюдателей.
Бесплатный фрагмент закончился.
