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

Выводы

• Реакция компании на незапланированные события — хорошие или плохие — главный индикатор ее способности вести конкурентную борьбу.

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

• Чем меньше уровней в корпоративной иерархии, тем более вероятно, что работники смогут эффективно передавать плохие новости и реагировать на них.

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

• Поощряйте «оправданный риск» — эксперимент.

«Электронная нервная система»: контрольные вопросы

• Способна ли ваша «электронная нервная система» выявлять плохие новости по всей компании и быстро доводить их до общего сведения?

• Способна ли ваша «электронная нервная система» собирать необходимые данные воедино и помогать вашей команде быстро вырабатывать решения?

• Можете ли вы собирать виртуальные рабочие группы из специалистов, работающих в разных отделах и разных частях света?

Стоит перестать относиться к неприятным новостям как к стихийному бедствию и начать воспринимать их как признак назревших перемен, и они перестанут быть вам страшны. Вы будете на них учиться. Поверьте мне, мы в Microsoft немало знаем о поражениях. Еще в далекие 1980-е наш продукт для работы с электронными таблицами Multiplan не смог добиться никаких успехов в конкуренции с программой 1 -2-3 корпорации Lotus. Вторую половину того десятилетия мы провели в трудах над СУБД Omega, от которой в конце концов пришлось отказаться в 1990-м. Свою долговременную стратегию в области ОС мы строили на планах совместной с корпорацией IBM разработки системы OS/2, но в 1992 году и этому проекту пришел конец — к этому моменту Microsoft уже успела вложить в него многие сотни миллионов долларов и бессчетное число человеко-дней. В начале 1990-х нам пришлось положить на полку планы создания собственного цифрового электронного секретаря наподобие Newton, поскольку технология была недостаточно хороша. В 1993-м родился проект «Microsoft at Work», который, как мы считали, должен был революционизировать копиры, факсы и другое офисное оборудование. Из него так ничего и не вышло. А в середине 1990-х закончились полным фиаско планы трансляции по MSN шоу-программ наподобие телевизионных.

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

То, чему мы научились на неудаче с Multiplan, очень пригодилось при разработке Microsoft Excel — наиболее совершенной на момент ее выпуска на рынок в 1985 году графической программы для работы с электронными таблицами. Она и сейчас идет впереди конкурирующих продуктов. Многое из того, что мы вынесли из проекта СУБД Omega, несколько лет спустя нашло плодотворное применение в ПО Microsoft Access, ставшем самой популярной из настольных СУБД. Та современная, построенная без опоры на старый код операционная система мирового класса, которая, по первоначальному плану, должна была называться OS/2 версии 3.0, превратилась в Windows NT. А ранние опыты с малыми форм-факторами и офисными устройствами помогли нам осознать технические требования растущего рынка, на котором мы теперь предлагаем нашу операционную систему Windows СЕ. Наконец, вложения в средства массовой информации на базе Интернета позволили нам понять, что клиенты ждут от нас ориентированных на практические нужды служб, насыщенных программным продуктом, — таких, как Microsoft Expedia (туризм), Microsoft Investor (финансы) и Microsoft Sidewalk (досуг).

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

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

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

Я рекомендую использовать следующий подход к обработке жалоб и пожеланий клиентов и их интеграции в процесс разработки продукта или услуги.

1. Сосредоточьте основное внимание на самых недовольных пользователях.

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

3. Применяйте технические средства для максимально оперативного доведения собранных «плохих новостей» до кого следует.

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