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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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