Полная версия
Психбольница в руках пациентов. Алан Купер об интерфейсах
Вообще говоря, я считаю, что мы живем при новой экономике. Более того, я думаю, что доткомы никогда не были ее частью. Напротив, они стали последним вздохом старой экономики, экономики производства.
В промышленную эпоху, до появления программ, продукты создавались из реальных материалов – из атомов. Затраты на добычу, плавку, приобретение, транспортировку, нагрев, формовку, сварку, окраску и снова транспортировку преобладали над всеми прочими расходами. В бухгалтерском учете эти расходы называются «переменными затратами», поскольку они различны для каждого продукта. «Фиксированные затраты», как вы, наверное, догадываетесь, очевидным образом не меняются и включают такие затраты, как корпоративное администрирование или начальная стоимость завода.
Классические правила управления бизнесом обусловлены производственными традициями промышленной эпохи. Однако эти правила не учитывают новые реалии эпохи информационной, в которой продукты уже не создаются из атомов, а состоят в основном из программного кода, из наборов битов. А биты не подчиняются тем же экономическим правилам, что атомы. Некоторые фундаментальные истины остаются справедливыми и для новой экономики. Цель любого бизнеса – стабильная прибыль, и есть лишь один законный способ получать ее: продавать товары или услуги дороже, чем обходится их создание. Из этого следует, что есть два пути повышения прибыльности: снижение затрат или рост прибыли. В старой экономике лучшим способом было снижение затрат. В новой экономике куда лучше работает рост прибыли.
Сегодня наиболее нужные и дорогие продукты состоят (полностью или почти полностью) из программного обеспечения. Они не требуют сырья. У них нет стоимости производства. Они не требуют затрат на транспортировку. Не требуют литья, обработки, покраски. Вот она, реальная разница между экономикой промышленной эпохи и экономикой эпохи информационной: в информационную эпоху практически или совсем отсутствуют переменные затраты, тогда как в позднюю промышленную эпоху именно эти затраты были главным фактором. Очевидно, что именно отсутствие переменных затрат делает новую экономику новой.
Зарплата программистов в вашем штате – фиксированные затраты или переменные? Один час работы программиста нельзя связать с одной продажей продукта – один и тот же код можно продавать много раз. Вложение в программирование можно амортизировать продажей миллионов копий продукта – точно так же, как продажа продуктов, созданных на заводе, амортизирует вложения в этот завод.
Стоимость создания программ не переменна, но и не фиксирована тоже. Разработка программ – это непрерывный процесс для компании, приносящий прибыль, и это совсем не то же самое, что строительство завода. Высокооплачиваемые строители завода после завершения работ уходят на другую рабочую площадку. Программисты стоят гораздо дороже плотников и сварщиков и никогда не исчезают, потому что, по всей видимости, их работа никогда не кончается. Кто-то может сказать, что программирование – это научно-исследовательские работы, и сходство действительно есть. Однако же научно-исследовательская работа – это гипотезы и эксперименты, призванные оценить теоретическую жизнеспособность продукта, и они происходят совсем не так, как настоящее создание продуктов. Эта мысль подтверждается тем, что традиционный бухгалтерский учет разделяет исследования/разработку и ежедневную деятельность, приносящую прибыль. Создание программ не попадает ни в одну из этих категорий учета, приемлемых для прежних предприятий.
Да, этим маленьким терминологическим несоответствием можно было бы и пренебречь как придиркой, уместной в беседе счетоводов за кружкой пива, но в действительности оно оказывает огромное влияние на финансирование разработки программ, на управление проектами по разработке и, что самое важное, на то, как к разработке программ относятся топ-менеджеры.
Программисты создают приложения, а руководители создают потоки прибылей и структурные подразделения. Программисты оценивают свой успех по качеству продукта, а руководители – по прибыльности вложений. Эту прибыльность они оценивают на языке математических терминов, позволяющем учитывать фиксированные затраты, переменные затраты, затраты на корпоративное администрирование, исследования и разработку, но, к сожалению, не описывающем подходящие модели для программ и программирования. Бухучет – основной язык бизнеса, и перечисленные категории настолько фундаментальны для всех оценок предпринимательской деятельности и коммуникации в бизнесе, что современные руководители полностью их усвоили. Программирование для них – еще одна статья корпоративных расходов, которую следует причислить к одной из существующих категорий. На практике большинство руководителей расценивают программирование как производственный процесс, имеющий переменные затраты. (Для целей налогообложения в большинстве компаний-разработчиков ПО программирование проходит по статье исследований и разработок, но во всех остальных отношениях расценивается как деятельность с переменными затратами.) Это худший выбор из всех возможных, поскольку он наносит серьезный ущерб процессу принятия бизнес-решений.
В промышленную эпоху основным преимуществом была массовость, которая позволяла снижать цены и делать продукцию доступной для широких слоев населения. Покупатель при этом получал функции, которые ранее были не доступны или доступны для богатых людей, поскольку производились вручную. Компании конкурировали в области продажных цен, непосредственно связанных с переменными затратами – затратами на производство и доставку. В информационную эпоху доступность продукции по разумным ценам считается обстоятельством само собой разумеющимся. В конце концов, программы можно распространять через интернет – практически бесплатно и почти не прилагая усилий.
Как вы помните, бизнес может повышать доходность за счет роста прибыли или сокращения расходов. Другими словами, предприятие может увеличивать инвестиции в области фиксированных затрат, повышая качество продукции и укрепляя таким образом ценовые позиции, или же снижать переменные затраты, что означает снижение стоимости производства. В старой, «атомной» экономике снижение затрат давалось легко и было эффективным и предпочтительным. Сегодня же руководители, ставящие программирование на одну доску с производством, воображают, будто снижение стоимости программирования дается так же легко и оказывается таким же эффективным. К сожалению, старые правила больше не действуют.
Поскольку производство программ сопровождается незначительными переменными затратами, снижение этих затрат не дает преимущества в бизнесе. С точки зрения бухгалтера зарплаты программистов – переменные затраты, однако в действительности их зарплаты представляют собой долгосрочные вложения, фиксированные затраты. Снижение стоимости программирования и снижение стоимости производства – разные вещи. Первое можно сравнить, скорее, с раздачей работникам дешевых инструментов, чем со снижением зарплат. Компании, заказывающие разработку в других странах с целью снижения зарплат, просто не понимают сути дела.
Более того, единственно возможный вариант для экономического подъема – это повышение качества и, как следствие, привлекательности продукта или услуги, а повышения качества невозможно добиться, сокращая затраты на проектирование и программирование. Правда в том, что в исследования, анализ, планирование и проектирование следует вкладывать больше времени и денег, чтобы полученный результат лучше соответствовал потребностям потребителя.
Разумеется, такой подход требует мышления, непривычного для предпринимателей XXI века. Им следует не снижать затраты на создание каждого объекта в отдельности, а повышать затраты на создание всей совокупности объектов. В этом суть новой экономики, и именно об этом говорит Питер Друкер.
Современные фармацевтические компании, разрабатывающие высокотехнологичные лекарства, имеют кое-что общее с новой экономикой программного обеспечения. Действительная стоимость производства одной таблетки минимальна, однако разработка лекарства может обойтись в миллиарды долларов и продолжаться более десяти лет. Подъем после выхода на рынок нового волшебного препарата может длиться до бесконечности, а вот выпуск недоработанного препарата способен принести только катастрофический спад. Фармацевтические компании знают, что снижение издержек на разработку – нежизнеспособная стратегия.
Как и разработка лекарственных препаратов, разработка ПО совсем не похожа на строительство завода. Завод – физический актив, который принадлежит компании, а работников завода, как правило, легко заменить другими. Неосязаемые, но невероятно сложные паттерны мыслей, составляющие программное обеспечение, обладают ценностью только вместе с написавшим код программистом. Ни одна компания не может себе позволить относиться к программистам так же, как к заводу. Программисты требуют постоянного внимания и поддержки, причем гораздо большей, чем любой завод.
Чаще всего пытаются сэкономить на архитектуре программного продукта, а эта часть проектирования (во время которого изучаются пользователи, определяются сценарии работы, проектируется взаимодействие, определяется форма, описывается поведение) выполняется человеком. Конечно, иногда проектированию уделяют слишком большое внимание, но сокращение этой фазы пользы точно не приносит. Каждый доллар и каждый час, потраченные на архитектуру, принесут десятикратную экономию на этапе программирования. Кроме того, вложения в достаточно качественное проектирование сделают ваш продукт привлекательным, а это означает, что продукт принесет больше прибыли. Его привлекательность станет основой для вашего бренда, создаст возможности для повышения цен, сделает клиентов лояльными, подарит вашему продукту более долгую и плодотворную жизнь. И хотя здесь нет экономии средств, вы получаете большое преимущество в смысле качества. По иронии судьбы лучший способ увеличить прибыльность в информационную эпоху состоит в том, чтобы больше потратить.
К сожалению, в руководителях живет практически неистребимое желание расходовать на программирование поменьше времени и средств. Они не считают тактику сокращения затрат устаревшей и не понимают, что сокращение инвестиций в программирование крайне негативно влияет на качество, привлекательность и прибыльность продукта в долгосрочной перспективе. Разумеется, простым повышением затрат не добиться улучшений. Зачастую ситуация даже ухудшается, если деньги вкладываются бездумно, без анализа и правильного руководства. Мой первый наставник, Дэн Хоакин (Dan Joaquin), любил повторять, что старую истину «получаешь то, за что платишь» нужно поменять на «не получаешь того, за что не платишь». Действия без планирования всегда чреваты риском потратить слишком много. Фокус в том, чтобы потратить правильное количество денег, а для этого нужно разбираться в управлении созданием программного обеспечения. Еще для этого нужны процессы, обеспечивающие руководителей пониманием и информацией для принятия верных решений. Дать компаниям такие процессы – цель этой книги.
В буме доткомов участвовали компании с бизнес-моделями, полностью ориентированными на снижение переменных затрат. Хотя многие доткомы рекламировали преимущества онлайн-покупок, их сайты, тяжеловесные и неудобные, были плохой альтернативой обычной поездке в торговый центр. Основатели доткомов просто лучились от восторга (и пресса, кстати, тоже), потому что им удалось создать предприятия розничной торговли с невероятно низкими переменными затратами. Феерический провал этих предприятий, несомненно, доказывает, что информационной эпохой правят иные экономические правила, чем промышленной эпохой.
В старой экономике более низкие переменные затраты приводили к более широкому распространению товара и снижению розничных цен. Это двойное преимущество было выгодно покупателям, а покупатели – фундамент экономического успеха промышленной революции. В новой экономике успех бизнеса зависит от способности дать потребителю что-то новое и более качественное. Реальное качество каждого шага транзакции – от просмотра страниц до сравнения товаров – должно быть ощутимо более высоким для пользователя. Гораздо приятнее сделать покупку обычным путем, чем продираться через 11 экранов и в конечном итоге выяснить, что все равно придется звонить в компанию. Покупки в сети становятся совершенно ненужными и непривлекательными, если требуется набрать свое имя, свой адрес и ввести информацию о кредитной карте три или четыре раза, а затем обнаружить, что сайт не позволяет купить все необходимое и все равно придется ехать в обычный магазин, сделанный из атомов. Сегодня простое снижение цены на продукт уже не дает гарантии успеха.
Компания Pets.com, специализирующаяся на продаже корма для собак через интернет, не предлагала более качественный корм, как не предлагала и шопинг, более приятный, чем в обычном зоомагазине; она не предлагала новую информацию, новые возможности, новую уверенность. Она предлагала лишь дешевую доставку, складирование и торговлю (все это переменные затраты) на сайте Pets.com. Компания применила классическую тактику снижения затрат, характерную для промышленной эпохи, проигнорировав фундаментальные принципы новой экономики. Конечно, это было еще не первое дыхание новой экономики, но для старой это были последние судороги. Я совершенно убежден, что любой товар можно продавать через интернет успешно и прибыльно. Для этого всего лишь нужно, чтобы в онлайн-магазине было намного приятнее покупать, чем в конкурирующих розничных сетях, и цена здесь – всего лишь один из факторов. Есть лишь один способ добиться этого: архитектуру системы следует создавать с целью максимально удовлетворить конечного пользователя. Нельзя относиться к любому аспекту проектирования и создания программного обеспечения как к производственному процессу – это повлечет за собой провал. Проектирование и программирование – это неподходящие цели для традиционных методов сокращения затрат. Конечно, можно потратить на создание программ слишком много времени и денег, но опасность потратить меньше необходимого гораздо серьезнее.
Скорее всего, эта опасность вам знакома и удивления не вызывает, но большинству топ-менеджеров крупных компаний сама идея кажется неприемлемой. Эти руководители до сих пор работают по моделям бухучета, вошедшим в моду в эпоху паровых машин, тогда как все аспекты жизни их компаний – функционирование, принятие решений, коммуникации и финансы – полностью зависимы от программного обеспечения. Термины и понятия, которыми оперируют эти руководители, не учитывают уникальную природу бизнеса в эпоху, когда инструменты и продукты торговли являют собой неосязаемые переплетения битов вместо железнодорожных составов, груженных сталью.
Корпорации уже нанимают проектировщиков взаимодействия и начинают применять целеориентированный подход, однако качество программных продуктов не слишком улучшилось. Более того, высокие затраты на программирование и жесткий процесс создания программ никуда не делись. Почему?
Перемены невозможны, пока топ-менеджеры компаний не осознают, что проблемы с программами – это не технические сложности, а важные бизнес-вопросы. Наши проблемы останутся неразрешенными до тех пор, пока мы не изменим процесс и организацию.
Компании живут не только по устаревшим финансовым моделям, но еще и по негодной организационной модели. Эта модель скопирована с научной, в ней создание программы смешивается с планированием и решением инженерных задач. Такова природа исследований. Прискорбно, что эта парадигма без предупреждения была перенесена в неизменном виде в мир бизнеса, где ей не место.
Корни всех современных производственных дисциплин уходят в доиндустриальные времена. Всех, кроме дисциплины программного обеспечения, которая возникла, когда индустриализация уже закончилась. Только программирование вышло сразу из университетской среды, где время исследований не ограничивалось, студенческой рабочей силы было хоть отбавляй, о прибылях вообще не говорили, а неработающая программа могла сойти за весьма удачный эксперимент. Неслучаен тот факт, что Microsoft, IBM, Oracle и другие ведущие компании-разработчики ПО расположены в «кампусах». Университетам не нужны прибыли, они не стараются успеть создать привлекательный и полезный продукт к определенному сроку.
Любой бизнес, не связанный с программным обеспечением, начинается с исследований и заканчивается распространением продуктов или предложением услуг. Компания тщательно планирует время между этими двумя событиями, осознавая, что преждевременный выпуск непродуманного продукта опасен как для банковского счета, так и для репутации. Руководители знают, что время, размышления и деньги, вложенные в планирование, обернутся крупными дивидендами – отлаженным и быстрым процессом производства, популярностью и прибыльностью конечных продуктов.
Во всех других конструкторских дисциплинах инженеры создают стратегию, а ремесленники претворяют ее в жизнь. Инженеры не строят мосты сами, этим занимаются монтажники. Только в области программного обеспечения перед инженером стоит задача создать собственно продукт. Только в области программного обеспечения перед «монтажником» стоит задача определить, как следует создавать продукт. Только в области программного обеспечения эти две задачи решаются не последовательно, а одновременно. Однако компании-разработчики ПО, похоже, не осознают существования такой аномалии. Инженерное дело и конструкторское дело так тесно пересекаются, что специалисты и руководители их не разделяют и, вероятно, не различают. Планированием любого рода здесь пренебрегают или откладывают его до тех пор, пока не станет слишком поздно. Считается нормальным откладывать решение очень сложных инженерных проблем до момента, когда экономически станет накладно откатываться к фазе проектирования, потому что полным ходом пишется код для коммерческой версии продукта.
Проектирование архитектуры следует начинать на ранних стадиях инженерного планирования. Более того, именно оно должно быть движущей силой на этих стадиях, но такие разработки обычно откладываются до момента старта проекта и ведутся параллельно с созданием кода, поэтому не занимают должного места в процессе конструирования продукта. Компании нанимают проектировщиков взаимодействия и обучают специалистов по юзабилити создавать персон, однако работа этих людей почти не влияет на стоимость разработки и качество завершенного продукта.
Решение проблемы – в руках президентов и генеральных директоров корпораций. Делегируя решение своим техническим директорам или вице-президентам по разработке, они поступают неверно. Эти достойные исполнители – технари, а проблема не техническая. Как сказал Друкер, инструменты для бухгалтерии, на которые полагаются директора компаний, попросту не отражают истинной природы этих компаний. Нельзя ведь на основе точных показаний спидометра утверждать, что автомобиль движется в нужном направлении. В мире бизнеса цифровых технологий такой подход не может быть эффективным.
Одна из серьезных проблем применения неверных методов бухучета и организации для разработки программ состоит в том, что руководители не видят, сколько денег, израсходованных на программирование, потрачено впустую. Точная система показала бы, что из каждого доллара около пятидесяти центов тратится неправильно и что еще два или три доллара требуется, чтобы исправить проблему, вызванную этим некорректным вложением средств. В любом другом бизнесе подобная статистика вызвала бы революцию, однако отрасль программного обеспечения продолжает жить в состоянии блаженного неведения.
За последние тринадцать лет моя компания Cooper проконсультировала сотни компаний. Мои талантливые проектировщики создали для большинства клиентов «чертежи» продуктов, позволяющие коренным образом изменить ситуацию, но лишь немногие сумели воспользоваться всеми полученными преимуществами. В большинстве этих компаний проектирование взаимодействия и архитектуру программ считают лишь рекомендацией, в этих компаниях последнее слово всегда остается за программистами и инженерами. Ни один из президентов этих компаний не имеет ни малейшего представления о том, что происходит в офисах инженеров, и потому расписание ужимается безо всякой причины. Программисты постоянно работают в условиях дефицита ресурсов, и прежде всего – времени на хорошее программирование, а также времени, чтобы определить, где вообще требуется программирование. Они вынуждены защищаться, отвергая советы, и изворачиваться, общаясь со своими менеджерами.
На мой взгляд, существует два типа исполнителей: инженеры и боящиеся инженеров. Первые множат знакомые проблемы, поскольку их точка зрения безнадежно затуманена конфликтом интересов. Вторые множат проблемы, поскольку не умеют говорить на языке программистов. И я не имею в виду языки Java и С#. Я имею в виду, что у предпринимателей и программистов нет общих инструментов и общих целей. Хомо сапиенс делегирует человеческие проблемы Хомо логикус, не осознавая, что решение могло бы оказаться куда лучше в случае применения – на исполнительном уровне – уместных финансовых и организационных моделей.
У компаний есть прекрасная возможность сдвинуться с мертвой точки и сосредоточить усилия на удовлетворении потребностей клиентов, а не на программах, на персонах, а не на технологиях, на выгоде, а не на программистах. Я с нетерпением жду, когда появится просвещенный руководитель, который ухватится за эту возможность и навсегда изменит способ создания программного обеспечения, подав смелый и успешный пример.
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.
Часть I. Компьютерная неграмотность
1. Загадки информационной эры
Что будет, если скрестить компьютер и самолет?
Декабрь 1995 года. Самолет авиакомпании American Airlines совершает вылет по регулярному рейсу 965, следуя из Майами в колумбийский город Кали. Подлетая к взлетно-посадочной полосе, пилот «Боинга-757» должен был выбрать радиомаяк ROZO, чтобы определить ее координаты. Воспользовавшись бортовым навигатором, пилот ввел первую букву названия радиомаяка – R. Навигатор незамедлительно вывел список ближайших радиомаяков, названия которых начинались с R, – пилоту оставалось лишь выбрать нужный. Он выбрал самый первый, ориентируясь на указанные рядом с названием, казалось бы, верные координаты маяка. К несчастью, это оказался маяк ROMEO, который находился в 212 километрах к северо-востоку. Рейс же летел в южном направлении, а в момент выбора маяка вошел в долину, которая тянулась с севера на юг, так что отклоняться от курса было крайне рискованно. Ориентируясь на показания бортового навигатора, пилоты приступили к корректировке курса в направлении востока, а спустя несколько минут «Боинг-757» на высоте 3000 метров врезался в вершину гранитного утеса. Погибли 152 пассажира и 8 членов экипажа. Выжили только четверо пассажиров, все из них получили тяжелые травмы. Как обычно бывает в подобных ситуациях, причиной крушения самолета, объявленной Национальной комиссией по безопасности, был человеческий фактор. Бортовой навигатор, который использовали пилоты для ориентировки, отобразил верные данные, только не те, что нужны были для успешной посадки самолета в аэропорту Кали. Фактически человеческий фактор действительно имел место – ведь именно пилот выбрал маяк, совершив роковую ошибку, однако общая оценка ситуации позволяет утверждать, что вины пилота здесь не было.
На передней панели бортового навигационного компьютера самолета был показан радиомаяк, на который ориентировался рейс, и индикатор отклонения от курса. Если курс взят верно, стрелка будет указывать в центр шкалы, но правильность выбора самого маяка не проверяется. Внешний вид индикатора одинаков как в ситуации посадки, так и при возможном крушении. В данном случае навигатор отобразил данные о верно взятом курсе, но не учел, что неверно выбранный маяк может стать причиной катастрофы.
* * *Полнота и точность передаваемых данных может быть абсолютной, но при этом повлечь трагический исход из-за их некорректности в текущей ситуации. При взаимодействии с компьютерами это происходит повсеместно, а ведь в современном мире все сложнее найти сферу, в которой бы не применялись компьютерные устройства. Начиная от пассажирских самолетов и заканчивая потребительскими товарами и услугами – везде используются компьютеры и везде их применение сопровождается характерным способом взаимодействия и поведения.
