Читать интересную книгу Психбольница в руках пациентов - Алан Купер

Глава 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 рассуждает о проблеме следования за клиентами в контексте иных услуг, услуг по консультированию. Разумеется, сфера услуг значительно отличается, и Дэвид применяет иную терминологию. Он противопоставляет продажу умения решать проблемы и продажу прошлого опыта. Эти варианты он называет, соответственно, «мозг» и «седая голова» (опыт).

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