Психбольница в руках пациентов
Шрифт:
Стратегия измора не просто дорого обходится и заставляет тратить уйму времени, она омерзительна, потому что негуманна по отношению к пользователям компьютерных технологий. К несчастью, эта стратегия неплохо служит Мiсrоsоft. Компания не устает выпускать сырые, непродуманные, плохо сконструированные и спроектированные продукты на потеху индустрии и осмеяние наблюдателей, как пристрастных, так и беспристрастных. Однако пока специалисты отпускают язвительные замечания, Мiсrоsоft продолжает поддерживать свои первые попытки вторыми, третьими, четвертыми, пятыми, наконец, одиннадцатыми версиями. Такие
Стратегия измора эффективна, только если применяется компаниями, обладающими железобетонным именем, кучей времени, выдержкой игрока в покер и неисчерпаемыми финансами. До сих пор ни один участник компьютерной индустрии не проявил все эти качества на уровне, соответствующем уровню Мiсrоsоft.
Впечатляющий коммерческий успех Мiсrоsоft плох тем, что многие не столь крупные компании пытаются повторить ее успех, действуя такими же методами. В долгосрочной перспективе подобная стратегия часто заканчивается плачевно, что показал пример Netscape, однако она продолжает традицию надругательства над конечными пользователями.
Игрока, применяющего стратегию истощения, вполне можно победить, но только не подобным подходом. В конце концов, независимо от уровня вашей компании, денег у Microsoft больше. Следует наносить массированные удары по слабому месту Microsoft, а именно в области процесса разработки, ставящего программирование перед проектированием взаимодействия. Мiсrоsоft дважды ущербна в том смысле, что многие люди в компании занимают должность «проектировщика» и выполняют функции, связанные с проектированием. Как показывают выдержки из книги Фреда Муди (см. главу 8 «Отмирающая культура»), культура Мiсrоsoft уже привязалась к неэффективному «проектированию постфактум». Любая компания, готовая заниматься реальным проектированием взаимодействия, сможет побить Мiсrоsоft.
Глава 13
Управляемый процесс
Полагаю, большинство менеджеров, руководящих созданием продукции, основанной на программном обеспечении, в действительности не имеют четкого представления о том, как распознать лучший и наиболее успешный продукт и как создавать такие продукты. Как следствие, они руководствуются своим страхом, а значит, шутят с огнем. Они действуют ловко, но не владеют ситуацией и рискуют обжечься, отвлекшись даже на секунду. В этой главе я расскажу о дилемме, перед которой оказывается технический руководитель, и покажу, как укротить огонь при помощи проектирования.
Кто на самом деле самый влиятельный?
Как понять, чьему совету следовать, а чей можно игнорировать? Мне приходилось встречать руководителей, поведение которых не сильно отличалось от поведения собак на перекрестке. На забитом автомобилям и перекрестке эти собаки яростно лают, пытаясь бежать сразу во всех направлениях. Руководство говорит: «Пусть будет похоже на Outlook 98». Маркетологи говорят: «Хотя бы на уровне конкурентов». Отдел продаж говорит: «Этот клиент требует вот такую функцию». Программисты говорят: «Необходимо сохранять совместимость – делаем, как в последней версии». Кому
Руководители разработки продукта стараются соглашаться со всеми участниками процесса. Влияние программистов несоразмерно, потому что они владеют кодом, а потому их целям отдается обычно наибольший приоритет. Но есть и еще одна группа, потребности которой, казалось бы, имеют высший приоритет. Это клиенты. В конце концов, сколько бы участников ни вносили свои предложения, только клиент держит в руках чек. Ни один деловой человек не оставит это без внимания!
Смертельная спираль: на поводу у клиента
Приняв этот чек, вы превращаетесь в компанию, «ведомую клиентами». Идея звучит симпатично и широко реализуется, однако является ошибочной. Вы начинаете откровенно играть с огнем. В восьмидесятые годы IBM очень гордилась статусом компании, ведомой клиентами. Тогда IBM владела практически всем компьютерным бизнесом, в масштабах более серьезных, чем сегодня Microsoft, однако сейчас, оставаясь крупной компанией, IBM – лишь одна из многих, но никак не лидер.
Обычно новая компания основывает свой первый продукт на каком-то технологическом новшестве. Этот первый продукт проектируется, исходя из внутренних представлений о том, как все следует делать. На этом этапе клиенты компании еще не проявляют большой заинтересованности, поэтому их советы бессвязны. Но как только продукт появляется на рынке, заинтересованность клиентов начинает увеличиваться, поскольку они вкладывают в продукт свое время и энергию. Естественно, что от них приходят запросы по изменениям и добавлениям.
Существует большая разница между тем, чтобы выслушивать клиентов, и тем, чтобы за ними следовать. Выслушивать разумно. Подразумевается, что вы накладываете свой собственный фильтр на услышанное. Следовать требованиям клиента – плохо. То есть просто делать все то, что говорит клиент. Уже не вы играете с огнем, огонь играет с вами.
Как только производитель продукта позволяет своим клиентам диктовать, какие возможности будут в продукте, происходит очень серьезная, но практически незаметная перемена. Компания перестает быть производителем продуктов, изобретающим вещи, которые можно продавать клиентам, и становится обслуживающей компанией, выполняющей работу по запросам клиентов. Каждый в компании ощущает эту тонкую перемену и реагирует совершенно верно, выступая за интересы клиентов сильнее, чем за какие бы то ни было другие.
Сегодня многие компании, создающие корпоративное программное обеспечение, такие как Oracle и SAP, в начале девяностых пережившие взрывной рост в ходе замены старых архитектур новыми клиент-серверными, заново испытывают кошмар клиентского управления, идя по стопам IBM. Представив новую технологию, эти так называемые ЕRР-компании (Еnterprise Resource Planning, планирование ресурсов предприятия) стали прислушиваться к своим клиентам. Они начали добавлять возможности, затребованные клиентами, не соотнося их с более масштабными долговременными планами.