Учитесь обращать плохие новости в хорошие

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

Джеймс Хескетт, У. Эрл Сассер и Кристофер У. Л. Харт. «Революция сферы обслуживания»

Стоит перестать относиться к неприятным новостям как к стихийному бедствию и начать воспринимать их как признак назревших перемен, и они перестанут быть вам страшны. Вы будете на них учиться. Поверьте мне, мы в 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. Применяйте технические средства для максимально оперативного доведения собранных «плохих новостей» до кого следует.

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