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

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

Серия «Библиотека программиста»

* * *

Сью, Скотту и Марти, с любовью

Благодарности

Этой книги не было бы без помощи и поддержки многих моих замечательных друзей и коллег. Некоторые из них, в частности, выполняли сложную работу со множеством требований – вычитывали и комментировали рукопись, иногда даже по несколько раз. Благодаря их комментариям я отвечал на нелегкие вопросы, предлагал новые темы, резюмировал свои убеждения, усмирял свой пыл и брал в узду свое возмущение. Еще лучше этой книге помогли стать Ким Гудвин (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.com
inmates@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 века, по мере раздувания мыльного пузыря доткомов, целые цистерны чернил уходили на продажу идеи, что в интернете существует «новая экономика». Знатоки утверждали, что продажа вещей во Всемирной паутине, где магазины строят из страниц, а не из кирпичей, принципиально отличается от привычных стилей бизнеса и что «старую экономику» уже не оживить. Разумеется, почти все компании новой экономики мертвы, финансисты, поддержавшие их, пережили шок, а эксперты, пропагандировавшие новую экономику, теперь заявляют, что то была пустая мечта. Новая-преновая линия такова, что нам суждено пока оставаться со старой-престарой экономикой.

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

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

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

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

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

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

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

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

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