Программисты правят бал

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

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

Опции – не всегда залог успеха

На самом деле пользователи не слишком нуждаются в большом количестве опций, хотя часто кажется, что это не так. Такое утверждение неоднократно доказывают истории взлетов и падений различных программных продуктов. Пользователям важно лишь то, насколько удобно решать нужные им задачи с помощью конкретного продукта. В редких случаях опции тоже могут пригодиться при решении задач, но чаще случается так, что опции только затрудняют работу и запутывают пользователя. Более того, опции, польза которых неочевидна, заставляют пользователей чувствовать себя глупыми. Если рассмотреть предыдущий пример с компьютером PalmPilot, мы увидим, что этот продукт предлагал гораздо меньше опций, чем провальные Magic Link от General Magic, Newton от Apple и компьютер PenPoint. Продукт PalmPilot стал успешным благодаря участию в разработке проектировщиков, которые полностью сосредоточились на потребностях целевой аудитории.

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

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

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

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

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

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

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

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

И напротив, если продукт терпит крах, никто не желает копаться в его останках и выявлять причины неудачи. Любое оправдание будет на руку игрокам, окажись у руководства и разработчиков возможность перекинуться на реализацию нового высокотехнологичного проекта, которых вокруг превеликое множество. Таким образом, повода расстраиваться из-за неудачи нет. Однако неприятная особенность нежелания разбираться в причинах неудач заключается в том, что все участники молча признают невозможность спрогнозировать успех, считая, что в индустрии высоких технологий все зависит лишь от удачи и случая. Это явление, в свою очередь, положило начало подходу к инвестированию, которое инвесторы называют spray-and-pray («стреляй куда придется и молись, чтобы попало»): небольшие суммы денежных средств вкладываются во множество предприятий, а затем остается лишь надеяться на то, что хотя бы одно из них окажется успешным.

* * *

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

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

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

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

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

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

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

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