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

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

Кто на самом деле самый влиятельный?

Как понять, чьему совету следовать, а чей можно игнорировать? Мне приходилось встречать руководителей, поведение которых не сильно отличалось от поведения собак на перекрестке. На забитом автомобилям и перекрестке эти собаки яростно лают, пытаясь бежать сразу во всех направлениях. Руководство говорит: «Пусть будет похоже на Outlook 98». Маркетологи говорят: «Хотя бы на уровне конкурентов». Отдел продаж говорит: «Этот клиент требует вот такую функцию». Программисты говорят: «Необходимо сохранять совместимость - делаем, как в последней версии». Кому верить?

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

Смертельная спираль: на поводу у клиента

Приняв этот чек, вы превращаетесь в компанию, «ведомую клиентами». Идея звучит симпатично и широко реализуется, однако является ошибочной. Вы начинаете откровенно играть с огнем. В восьмидесятые годы IBM очень гордилась статусом компании, ведомой клиентами. Тогда IBM владела практически всем компьютерным бизнесом, в масштабах более серьезных, чем сегодня Microsoft, однако сейчас, оставаясь крупной компанией, IBM - лишь одна из многих, но никак не лидер.

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

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

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

Сегодня многие компании, создающие корпоративное программное обеспечение, такие как Oracle и SAP, в начале девяностых пережившие взрывной рост в ходе замены старых архитектур новыми клиент-серверными, заново испытывают кошмар клиентского управления, идя по стопам IBM. Представив новую технологию, эти так называемые ЕRР-компании (Еnterprise Resource Planning, планирование ресурсов предприятия) стали прислушиваться к своим клиентам. Они начали добавлять возможности, затребованные клиентами, не соотнося их с более масштабными долговременными планами.

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

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

Компания одна, а клиентов у нее будут десятки и сотни. Если реагировать на всех (или хотя бы на самых крупных), кто возьмет на себя труд урегулирования этих противоречивых требований?

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