Глава 13 Управляемый процесс


Полагаю, большинство менеджеров, руководящих созданием продукции, основанной на программном обеспечении, в действительности не имеют четкого представления о том, как распознать лучший и наиболее успешный продукт и как создавать такие продукты. Как следствие, они руководствуются своим страхом, а значит, шутят с огнем. Они действуют ловко, но не владеют ситуацией и рискуют обжечься, отвлекшись даже на секунду. В этой главе я расскажу о дилемме, перед которой оказывается технический руководитель, и покажу, как укротить огонь при помощи проектирования.
Кто на самом деле самый влиятельный?
Как понять, чьему совету следовать, а чей можно игнорировать? Мне приходилось встречать руководителей, поведение которых не сильно отличалось от поведения собак на перекрестке. На забитом автомобилям и перекрестке эти собаки яростно лают, пытаясь бежать сразу во всех направлениях. Руководство говорит: «Пусть будет похоже на Outlook 98». Маркетологи говорят: «Хотя бы на уровне конкурентов». Отдел продаж говорит: «Этот клиент требует вот такую функцию». Программисты говорят: «Необходимо сохранять совместимость – делаем, как в последней версии». Кому верить?
Руководители разработки продукта стараются соглашаться со всеми участниками процесса. Влияние программистов несоразмерно, потому что они владеют кодом, а потому их целям отдается обычно наибольший приоритет. Но есть и еще одна группа, потребности которой, казалось бы, имеют высший приоритет. Это клиенты. В конце концов, сколько бы участников ни вносили свои предложения, только клиент держит в руках чек. Ни один деловой человек не оставит это без внимания!
Смертельная спираль: на поводу у клиента
Приняв этот чек, вы превращаетесь в компанию, «ведомую клиентами». Идея звучит симпатично и широко реализуется, однако является ошибочной. Вы начинаете откровенно играть с огнем. В восьмидесятые годы IBM очень гордилась статусом компании, ведомой клиентами. Тогда IBM владела практически всем компьютерным бизнесом, в масштабах более серьезных, чем сегодня Microsoft, однако сейчас, оставаясь крупной компанией, IBM – лишь одна из многих, но никак не лидер.
Обычно новая компания основывает свой первый продукт на каком-то технологическом новшестве. Этот первый продукт проектируется, исходя из внутренних представлений о том, как все следует делать. На этом этапе клиенты компании еще не проявляют большой заинтересованности, поэтому их советы бессвязны. Но как только продукт появляется на рынке, заинтересованность клиентов начинает увеличиваться, поскольку они вкладывают в продукт свое время и энергию. Естественно, что от них приходят запросы по изменениям и добавлениям.
Существует большая разница между тем, чтобы выслушивать клиентов, и тем, чтобы за ними следовать. Выслушивать разумно. Подразумевается, что вы накладываете свой собственный фильтр на услышанное. Следовать требованиям клиента – плохо. То есть просто делать все то, что говорит клиент. Уже не вы играете с огнем, огонь играет с вами.
Как только производитель продукта позволяет своим клиентам диктовать, какие возможности будут в продукте, происходит очень серьезная, но практически незаметная перемена. Компания перестает быть производителем продуктов, изобретающим вещи, которые можно продавать клиентам, и становится обслуживающей компанией, выполняющей работу по запросам клиентов. Каждый в компании ощущает эту тонкую перемену и реагирует совершенно верно, выступая за интересы клиентов сильнее, чем за какие бы то ни было другие.
Сегодня многие компании, создающие корпоративное программное обеспечение, такие как Oracle и SAP, в начале девяностых пережившие взрывной рост в ходе замены старых архитектур новыми клиент-серверными, заново испытывают кошмар клиентского управления, идя по стопам IBM. Представив новую технологию, эти так называемые ЕRР-компании (Еnterprise Resource Planning, планирование ресурсов предприятия) стали прислушиваться к своим клиентам. Они начали добавлять возможности, затребованные клиентами, не соотнося их с более масштабными долговременными планами.
Мне приходилось слышать от руководителей, что никакие изменения не вносятся в их продукты, пока этого не потребует клиент. Каждый клиент ведет дела немного иначе, чем все остальные, и каждый требует, чтобы ЕRР-компания внесла изменения и добавила возможности, соответствующие именно его способам ведения дел.
В ложно понятом стремлении быть полезной, компания, слепо идущая на поводу у клиентов, вынуждена делать уступки.
Компания одна, а клиентов у нее будут десятки и сотни. Если реагировать на всех (или хотя бы на самых крупных), кто возьмет на себя труд урегулирования этих противоречивых требований?
Многие из знакомых мне руководителей в области высоких технологий имеют опыт инженерной разработки и часто раньше работали программистами. Можно точно сказать, что они занимают свои посты потому, что очень хорошо знают программистов и испытывают к ним симпатию. Как показано в главах 7 «Ноmо Logicus» и 8 «Отмирающая культура», программисты в поисках ответа обращаются к функциям и возможностям. Когда клиент приходит с перечнем возможностей в одной руке и чеком в другой, технический руководитель не способен сопротивляться такому сочетанию. Вот еще одна причина, по которой столь многие организации, создающие продукты, ведут с заказчиками торги за функции, – чтобы управлять сроками разработки. Они играют с огнем, а управление, основанное на жестких сроках сдачи, гарантирует, что скорость этой игры будет только нарастать.
Концептуальная целостность – важное достоинство
Приняв чек, вы отдаете бразды правления клиенту. У клиента могут быть деньги, однако клиент не обладает двумя важнейшими качествами: 1) он не заботится о ваших интересах и 2) не знает, как проектировать ваш продукт.
Продукты, создающиеся под дудку клиентов, не обладают ясным замыслом. Такие продукты не имеют качества, которое идеолог программного обеспечения Фредерик Брукс называет «концептуальной целостностью, всепроникающим видением программы», которое, по его мнению, и есть главный ингредиент успеха. В отсутствие концептуальной целостности могут случиться две вещи: клиенты начинают контролировать проектирование вашего продукта, а вы перестаете это делать. Неважно, насколько у клиента благие намерения, он не обладает способностью воспринимать ваш продукт, как единую концептуально целостную сущность. Четкое видение ситуации – это одно из главных достоинств, и большинство компаний с трудом могут сфокусироваться на собственном бизнесе, что уж говорить о вашем. Даже выкрикивая противоречивые приказы, клиенты ожидают, что вы самостоятельно выберете правильные.
Если продукт разрабатывается под дудку покупателя, он мутирует от версии к версии, вместо того, чтобы расти упорядоченно. В конечном итоге продукт состоит из несовместимых фрагментов и случайно подобранных возможностей, продукт становится, по выражению Джона Зикера (John Zicker), «собачьим завтраком». Каждому клиенту приходится продираться через продукт, находя возможности, которые ему нравятся, избегая возможностей, которые ему не подходят, и все без исключения клиенты находят, что пользоваться продуктом становится все сложнее и сложнее с каждой новой версией. Некоторые известные компании создают продукты настолько сложные, что даже решение простейших задач требует многомесячной подготовки. Появляются целые бизнес-направления для установки, настройки, сопровождения, обучения работе с этими монстрами. Клиенты могут покупать собачьи завтраки, но вряд ли кто-то сможет влюбиться в данный продукт. Такой продукт не хотят покупать, что, как я показывал в главе 5 «Нелояльность клиентов», делает вас весьма уязвимой мишенью конкурентов.
Фаустова сделка
Такой переход от компании, ведомой определенным видением, к компании, идущей на поводу у клиентов, можно рассматривать как превращение производственной компании в обслуживающую. В замечательной книге «Managing the Professional Service Firm» (Управление компанией профессиональных услуг) Дэвид Майстер 44 рассуждает о проблеме следования за клиентами в контексте иных услуг, услуг по консультированию. Разумеется, сфера услуг значительно отличается, и Дэвид применяет иную терминологию. Он противопоставляет продажу умения решать проблемы и продажу прошлого опыта. Эти варианты он называет, соответственно, «мозг» и «седая голова» (опыт).
Продавать мозг сложно. Человек, нанимающий вас в качестве мозга, должен вам очень сильно доверять, поскольку ожидает, что вы проделаете нечто, в чем ваша компетенция еще не доказана.
Продавать опыт проще. Потенциальный клиент может увидеть, что вы уже прежде решали подобные проблемы, а значит, справитесь и с его трудностями.
Большинство начинающих консультантов продают «мозг» своим коллегам, то есть людям, доверительные отношения с которыми уже установлены. Как только консультант решает проблему клиента, то начинает приобретать опыт, что приводит к наплыву клиентов. Новые клиенты будут все менее знакомыми, изначально доверяющими консультанту все меньше. Поэтому они будут предлагать консультанту работу, требующую знаний и опыта. В конце концов, нового клиента привлек именно опыт; именно такое задание клиент склонен дать непроверенному исполнителю.
С приобретением репутации растет число клиентов, привлеченных опытом консультанта, и консультант обнаруживает, что опыт позволяет зарабатывать больше и легче. В конце концов, он ведь делает все ту же работу, что и раньше.
По мере того, как консультант все меньше продает свой интеллект и все больше – опыт, исчезают именно те качества, которые и делали консультанта ценным. И он начинает отставать. Услуга, которую он теперь предлагает, уже связана не с блестящим решением проблем, а лишь с приземленным решением задач. Популярность консультанта снижается, и его собственные клиенты начинают давать ему все более унизительные задачи. Они начинают посматривать в сторону других консультантов, идущих далеко впереди, на тех, кто продает интеллект.
Это та же смертельная спираль, в которую попадает тот, кто идет на поводу у клиента, только теперь это компания, предоставляющая услуги.
Сделаем выводы. Идущий на поводу у клиента получает легкие деньги сразу, но перестает расти и ставит крест на собственных перспективах. Он отказывается от своей роли лидера.
В этой игре тайно участвуют все. Клиентам она весьма удобна. Новые клиенты приходят и говорят: «Добавьте вот эту возможность в свой продукт, и я его куплю». Это проверка, позволяющая узнать, предоставляете ли вы услуги нужного характера. Отдел продаж вкладывает огромные усилия в такие крупные продажи, и кажется, что добавление одной маленькой возможности – небольшая цена за установление отношений с новым покупателем. Прибыль манит.
Решение, предложенное Майстером, очевидно: больше участвовать в проектах, задействующих мозг. В контексте услуг необходимо убеждать существующих клиентов, привлеченных вашим опытом, давать больше задач для мозга, и Майстер подробно описывает, как это делать. Это означает, пишет он, что придется отказываться от легких заработков на опыте в пользу более тяжелых и не столь прибыльных проектов для мозгов. Переводя решение Майстера в область разработки продуктов, мы обнаруживаем, что все запросы клиентов – это задачи для опыта, тогда как все задачи для мозга появляются внутри компании. Иными словами, ваша задача как руководителя разработки продукта – удержаться на передней линии, избегая при этом смертельной спирали, в которую вас увлекают клиенты. Ответы следует искать внутри себя, делать то, что вы делали, когда только начинали бизнес.
И это означает более тщательное прогнозирование, принятие ответственности, затраты времени, удержание управления.
Прогнозирование
Чтобы сохранить конкурентные преимущества, необходимо рассматривать краткосрочные прибыли в перспективе. Убедитесь, что ваши люди понимают, что краткосрочное планирование равносильно закладке тикающей бомбы в собственное сердце. Краткосрочной перспективы следует избегать, несмотря на возможные расходы.
Долгосрочное прогнозирование означает отказ от некоторых очень привлекательных сделок. Делать это сложно, но необходимо для выживания в будущем. По моему опыту, такие сделки редко когда действительно теряются. Если вы обладаете достаточной уверенностью, чтобы отвернуться от клиента, предлагающего деньги, клиент, вероятнее всего, больше будет вам доверять и подвергнет переоценке свои запросы. Однако такие поступки требуют воли.
Принятие ответственности
Необходимо как можно раньше обрести баланс. Нельзя руководствоваться, например, такими соображениями: «Пару лет всего с ближним прицелом поработаю, а потом переключусь на долгосрочное прогнозирование». Необходимо найти баланс в первый же день. Отложить можно ближний прицел, а вот долгосрочное планирование откладывать нельзя.
Здесь речь идет о корпоративной культуре, и в уже принятое такой культурой краткосрочное планирование очень тяжело внести изменения. Рискованно не идти к прибыльной пропасти, каковой является следование запросам клиентов, – вы вызовете огонь на себя. Черпайте мужество в том, что поступаете верно.
Затраты времени
Многие высокотехнологические компании считают за правило выпускать новые версии программ каждый год. Некоторые выпускают версии еще чаще. Это означает, что основная масса программистов работает в годичных циклах, и любая работа должна пройти путь от идеи, через проектирование, через программирование, через тестирование, к рыночному воплощению в пределах этого года. Для каких-либо новаций в проектировании этого времени недостаточно, поэтому большинство компаний стараются совместить проектирование с программированием. Как я уже подробно рассказывал, если скрестить проектирование и программирование, получается просто программирование.
Удержание управления
Самое главное для руководителя разработкой – отнять контроль над процессом у бушующего огня. Необходимо укротить этого зверя, приняв сопутствующие травмы, как неизбежность. Если выживете, то сможете начать перестраивать процесс таким образом, чтобы обрести баланс между интеллектом и опытом и сохранить в будущем это преимущества.
Поиск основы
Большинство компаний проводят очень аккуратное планирование и анализ финансовых и операционных сторон функционирования бизнеса. Что же касается продукта, они считают, что перечень возможностей – достаточно качественное планирование, хотя оно совершенно таковым не является. Разработка программного обеспечения – процесс слишком сложный, слишком дорогостоящий, слишком тяжелый, чтобы бросаться в него без тщательного планирования и прогнозирования. В контексте разработки программного обеспечения «тщательное планирование» может означать лишь проектирование взаимодействия, которым, как мы установили, довольно часто пренебрегают.
Одной из побочных выгод целеориентированного проектирования является набор персонажей: перечень конкретных типов пользователей. Этот документ оказывается значительным подспорьем при необходимости реагировать на запросы пользователей. Прежде всего, определите, какому персонажу может послужить новая возможность, а затем – является ли этот персонаж одним из ведущих. Если так, можете отнестись к запросу всерьез. Если нет, добавление этой функции приведет к отставанию, независимо от того, сколько денег вы получите. Если к вам в офис придет клиент и предложит $100000, чтобы вы выбросили свою систему бухгалтерского учета или подожгли ящики с бумагами, сделаете ли вы это?
Семь раз отмерь
Если компания идет на поводу у клиентов, это четкий симптом того, что руководители разработки продуктов верят в миф о непредсказуемом рынке. Но они не знают, хороша или плоха возможность, необходима она или же не нужна. Они просто передают бразды правления клиентам: «а почему бы и нет?» Сами они определенно этого не знают. Если клиент говорит: «Добавьте в функции разводной гаечный ключ для левшей», руководитель считает, что клиенту, наверное, что-то известно, чего он сам не знает. Руководитель верит, что именно эта возможность может волшебным образом принести продукту ошеломительный успех.
Обратная сторона медали – руководитель не имеет представления и о том, какие возможности следует убрать. Когда внешние силы ограничивают расписание, руководитель должен пожертвовать какими-то возможностями, однако понятия не имеет, какие возможности жизненно необходимы, а какие – попросту «подливка».
Разрешить непроектировщикам выкидывать возможности? Все равно, что разрешить пассажиру перерезать провода в самолете. Такая вивисекция делается наугад или основывается на каких-то не имеющих к делу отношения качествах вроде цвета изоляции или расстояния от кресла этого пассажира. Могут быть перерезаны и нужные провода. Можно просто отключить свет для места 22А, а можно вывести из строя двигатели. Проектировщики же режут возможности так, как режет создатель самолета: не затрагивая те провода, которые нужны для полета.
<< | >>
Источник: Алан Купер. Психбольница в руках пациентов. 2007

Еще по теме Глава 13 Управляемый процесс:

  1. Глава 5.УПРАВЛЯЙ БАЗОВОЙ ЗАРПЛАТОЙ. СОВЕРШЕНСТВУЙ ПОСТОЯННУЮ ЧАСТЬ ЗП
  2. Глава 2. Процесс управления маркетингом
  3. ГЛАВА 3. ВЫ — УЧАСТНИК УГОЛОВНОГО ПРОЦЕССА
  4. Глава 13. Правовые основы бюджетного процесса
  5. Глава 9. Процесс формирования предложения денег
  6. Глава 1. ИНФОРМАЦИОННЫЕ ПРОЦЕССЫ И СИСТЕМЫ В ЭКОНОМИКЕ
  7. Глава 14. Процесс изменения
  8. Глава 8. Исследование трудовых процессов и затрат рабочего времени
  9. Глава 3. ПР-процесс под рентгеном
  10. 5.2. Модуль управляемого приложения
  11. Глава 13. Процесс формирования жестокого мужчины
  12. Глава 9. Общая характеристика бюджетного процесса и его структура
  13. Глава 40. РОССИЯ - ЭКОНОМИКА В ПРОЦЕССЕ ПЕРЕХОДА
  14. Глава 6Как проходит судебный процесс
  15. Глава 6. Общие принципы и модели учета основных процессов деятельности фирмы
  16. Глава 14ОТНОШЕНИЕ К ТРУДУ И УДОВЛЕТВОРЕННОСТЬ ИМ КАК ВАЖНЕЙШИЕ ХАРАКТЕРИСТИКИ ТРУДОВОГО ПРОЦЕССА
  17. ГЛАВА 10потоки событий. марковские случайные процессы
  18. ГЛАВА 1. Процесс становления и сущность мирового хозяйства