Проблема не в этом. Как переосмыслить задачу, чтобы найти оптимальное решение - Томас Веделл-Веделлсборг

велик соблазн зависнуть на вопросах вроде: «Хм, а как мне его назвать? Поможет ли фокус-группа? Каким мороженым лучше торговать? А как насчет декора – возможно, стоит нанять профессионального дизайнера?» В случае технических проблем соблазн еще больше: «Можем ли мы создать этот потрясающий гаджет, о котором я мечтаю? Нашей инженерной лаборатории нужно всего восемь лет, чтобы разработать прототип».

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

Чтобы избежать таких ситуаций, нужно сделать последний шаг в процессе рефрейминга – спланировать, как вы проверите, верно ли поставлена проблема, посредством тестирования в реальном мире. Это похоже на план действий, но с особым акцентом на проверке того, в правильном ли направлении вы движетесь. Этот шаг завершает (данный) раунд рефрейминга и переводит вас в режим решения.

Вот четыре конкретные тактики, которые можно использовать для проверки проблем:

1. Описать проблему заинтересованным сторонам.

2. Обратиться к внешним экспертам.

3. Придумать трудный тест.

4. Претотипировать решение.

1. ОПИШИТЕ ПРОБЛЕМУ ЗАИНТЕРЕСОВАННЫМ СТОРОНАМ

Бывший переговорщик ФБР Крис Восс специализировался на переговорах об освобождении заложников. Имея дело с вооруженными захватчиками, он использовал простую, но мощную технику под названием «навешивание ярлыков». Вот как Восс описывает ее:

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

Восс не начинает разговор с попытки убедить их сдаться: «Вы не сможете убежать, поэтому бросайте оружие и выходите, иначе вам будет плохо!» Вместо этого он начинает с описания их страхов, выражая их конкретно и открыто – то есть навешивая на них «ярлыки»:

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

Как указывает Восс, когда вы точно описываете тревожащую человека проблему, это оказывает на него мощное воздействие. Команда PfizerWorks использовала тот же принцип в своих плакатах: показывая, что она понимает реальные проблемы сотрудников («Я должна подготовить эти документы за 18 часов?!»), она создавала доверие и открывала двери для сотрудничества. По словам Восса, использование этой техники помогло разрешить бесчисленное множество ситуаций с заложниками. (Он также замечает, что, если вы неправильно поняли проблему, всегда можно сказать: «Я не говорил, что это действительно так. Я просто сказал, что мне так кажется».)

Встречи по исследованию проблем

Этот метод полезен не только в переговорах. Самый простой и дешевый способ проверить правильность постановки проблемы – просто описать ее тем людям, которых она затрагивает.

Например, в мире стартапов профессор Стэнфордского университета Стив Бланк рекомендует проводить «встречи по исследованию проблем», на которых предприниматель встречается со своими потенциальными клиентами и описывает им проблему, которую он пытается решить. Суть не в том, чтобы продать свою идею, а в том, чтобы проверить, резонирует ли она с потребностями клиентов. По словам Бланка, «ваша цель – слушать, а не говорить».

Мастерская Startup Cisco

Я также видел, как этот метод используется в корпоративной среде – а именно в компании Cisco, где сотрудники Озеас Рамирес Ассад, Эдгардо Себаллос и Эндрю Африка создали внутрикорпоративную мастерскую Startup Cisco для быстрого тестирования инновационных идей.

«Люди в Cisco постоянно предлагают идеи новых продуктов и другие технические инновации, – говорит Озеас, – но раньше у компании не было механизма, чтобы быстро протестировать эти идеи и посмотреть, действительно ли они соответствуют потребностям наших клиентов. Поэтому мы организовали специальную мастерскую, сфокусированную именно на этом».

К методу быстрой проверки проблем с участием заинтересованных сторон команда пришла с подачи внешнего консультанта Стива Лигуори, который опирался на свой опыт работы с GE:

Во многих компаниях существует твердое правило: никогда ничего не показывать клиентам, пока продукт не станет безупречным. Инженеры предлагают: «Мы можем создать такой-то продукт». Эта идея проходит валидацию в зале заседаний высшего руководства, которое решает: «Нравится нам эта идея или нет?» Затем клиентам несколько лет твердят: «Мы готовим для вас отличное решение», – но хранят разработку в строжайшей тайне. В конце концов доведенный до совершенства продукт выводится на рынок, а клиенты говорят: «А почему он не делает этого? И этого тоже?» В результате продукт не продается и компания во всем обвиняет своих маркетологов и продавцов, которые «не умеют продавать».

Вначале нечто подобное происходило и в мастерской Startup Cisco. По словам Озеаса,

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

Для этого Озеас и его команда решили привлекать клиентов к исследованию идей уже на раннем этапе:

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

В одном случае ветеран Cisco Хуан Казила предложил многообещающую идею для газо- и нефтеперерабатывающих заводов. Но прошло больше года, а проект застрял во внутренних процессах Cisco, поэтому Казила присоединился к мастерской Startup Cisco, чтобы попытаться сдвинуть дело с мертвой точки:

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

В тот же день Казила переговорил по телефону с тремя клиентами: «Не сталкиваетесь ли вы с данной проблемой на своих перерабатывающих предприятиях? Регулярно? И во сколько вам это обходится?»

Выяснилось, что все три клиента сталкивались с этой проблемой и были очень заинтересованы в ее решении. Вооружившись этой информацией, Казила отправился к руководству и запросил ресурсы для реализации проекта: через два часа он получил положительный ответ. На момент написания этой книги проект идет полным ходом и уже проходит тестирование на предприятиях одного из крупнейших клиентов Cisco в Латинской Америке.

2. ОБРАТИТЕСЬ К СТОРОННИМ ЭКСПЕРТАМ

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