Концептуальная целостность – важное достоинство

Приняв чек, вы отдаете бразды правления клиенту. У клиента могут быть деньги, однако клиент не обладает двумя важнейшими качествами: 1) он не заботится о ваших интересах и 2) не знает, как проектировать ваш продукт.

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

Если продукт разрабатывается под дудку покупателя, он мутирует от версии к версии, вместо того, чтобы расти упорядоченно. В конечном итоге продукт состоит из несовместимых фрагментов и случайно подобранных возможностей, продукт становится, по выражению Джона Зикера (John Zicker), «собачьим завтраком». Каждому клиенту приходится продираться через продукт, находя возможности, которые ему нравятся, избегая возможностей, которые ему не подходят, и все без исключения клиенты находят, что пользоваться продуктом становится все сложнее и сложнее с каждой новой версией. Некоторые известные компании создают продукты настолько сложные, что даже решение простейших задач требует многомесячной подготовки. Появляются целые бизнес-направления для установки, настройки, сопровождения, обучения работе с этими монстрами. Клиенты могут покупать собачьи завтраки, но вряд ли кто-то сможет влюбиться в данный продукт. Такой продукт не хотят покупать, что, как я показывал в главе 5 «Нелояльность клиентов», делает вас весьма уязвимой мишенью конкурентов.

Фаустова сделка

Такой переход от компании, ведомой определенным видением, к компании, идущей на поводу у клиентов, можно рассматривать как превращение производственной компании в обслуживающую. В замечательной книге «Managing the Professional Service Firm» (Управление компанией профессиональных услуг) Дэвид Майстер^[42] рассуждает о проблеме следования за клиентами в контексте иных услуг, услуг по консультированию. Разумеется, сфера услуг значительно отличается, и Дэвид применяет иную терминологию. Он противопоставляет продажу умения решать проблемы и продажу прошлого опыта. Эти варианты он называет, соответственно, «мозг» и «седая голова» (опыт).

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

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

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

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

Это та же смертельная спираль, в которую попадает тот, кто идет на поводу у клиента, только теперь это компания, предоставляющая услуги.

Сделаем выводы. Идущий на поводу у клиента получает легкие деньги сразу, но перестает расти и ставит крест на собственных перспективах. Он отказывается от своей роли лидера.

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

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

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

Прогнозирование

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

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

Принятие ответственности

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

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

Затраты времени

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

Удержание управления

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

Поиск основы

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

Одной из побочных выгод целеориентированного проектирования является набор персонажей: перечень конкретных типов пользователей. Этот документ оказывается значительным подспорьем при необходимости реагировать на запросы пользователей. Прежде всего, определите, какому персонажу может послужить новая возможность, а затем – является ли этот персонаж одним из ведущих. Если так, можете отнестись к запросу всерьез. Если нет, добавление этой функции приведет к отставанию, независимо от того, сколько денег вы получите. Если к вам в офис придет клиент и предложит $100000, чтобы вы выбросили свою систему бухгалтерского учета или подожгли ящики с бумагами, сделаете ли вы это?

Семь раз отмерь

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

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

Разрешить непроектировщикам выкидывать возможности? Все равно, что разрешить пассажиру перерезать провода в самолете. Такая вивисекция делается наугад или основывается на каких-то не имеющих к делу отношения качествах вроде цвета изоляции или расстояния от кресла этого пассажира. Могут быть перерезаны и нужные провода. Можно просто отключить свет для места 22А, а можно вывести из строя двигатели. Проектировщики же режут возможности так, как режет создатель самолета: не затрагивая те провода, которые нужны для полета.

Производство фильмов

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

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

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

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

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

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

Сегодня создавать программы так же сложно, как фильмы, однако процесс разработки по преимуществу игнорирует этот факт. Мне встречаются в основном команды разработчиков, которые тратят несколько дней или недель (максимум) на планирование и проектирование, затем от 6 до 18 месяцев – на программирование, затем всего пару месяцев занимаются отладкой, тестированием и документированием. Подозреваю, нам многому следует научиться у киноиндустрии. Если бы мы больше времени тратили на стадию подготовки, на проектирование, то смогли бы сэкономить массу дорогостоящего времени программистов.

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

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

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

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

Хорошая сделка

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

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

Кроме того, проектировщики взаимодействий должны фиксировать свои предложения в письменной форме.