Закон успешных инноваций: Зачем клиент «нанимает» ваш продукт и как знание об этом помогает новым разработкам

Возьмем, к примеру, Тодда Данна, который массу времени размышляет о том, какие инструменты необходимы врачам, чтобы хорошо выполнять свою работу. Будучи директором по инновациям в Intermountain Healthcare Transformation Lab[23], Данн отвечает за стимулирование инноваций и продвижение их во все уголки компании, включая переосмысление подходов к общепринятым практикам ухода за пациентами. Но одним осенним днем несколько лет назад он ступил на незнакомую территорию: стал пациентом, за которым ухаживал его работодатель. Данн слишком долго лечил больное колено и, наконец, решил обратиться за консультацией к ведущему хирургу-ортопеду Intermountain. За время работы он много раз бывал в смотровых кабинетах компании, но теперь, став пациентом, воспринимал их совсем иначе. «Я сидел в той комнате на мятой бумажной подстилке в ожидании врача и думал про себя, кто это все придумал? Эта шуршащая бумага неудобна, ощущение, что вот-вот соскользнешь на пол. Она шуршит, стоит только шевельнуться. Вроде бы и маленькая деталь, а все равно мешает расслабиться. Пробуждает тревожность», – вспоминает Данн.

Реализовав за свою карьеру сотни инноваций, он сразу же понял, что бумага была предназначена для выполнения одной функции – не дать кушетке запачкаться. Но с точки зрения пациентов такая подстилка только усиливала ощущение уязвимости. К тому моменту, как доктор Холмстром вошел в кабинет, Данн под воздействием стерильного освещения в комнате, рентгеновских снимков, зловеще развешанных на доске, и приглушенных звуков шагов в коридоре пребывал на грани истерики.

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

В качестве ответа Холмстром подъехал на стуле к компьютеру. Как он пояснил, набирание текста не только отнимает слишком много времени, но и вынуждает отворачиваться от пациента (пусть даже на несколько минут) при объяснении диагноза. Он не хотел так вести себя с пациентами. Ему важно было поддерживать визуальный контакт, помогать людям расслабиться, убедить, что они в хороших руках. В этот момент важнее оказывалось не использование современных компьютерных технологий, а установление контакта и ободрение встревоженного человека. «Мы разработали крутейшее программное обеспечение, которое, как нам казалось, поможет этому врачу в работе, а он предпочел "нанять" листок бумаги и ручку, – вспоминает Данн. – До меня наконец-то дошло: мы разработали всю эту комнату с функциональной позиции, но совершенно упустили из виду эмоциональное сопровождение».

Данн и его команда к тому моменту уже изучали теорию работ для придания ускорения своей инновации, но этот визит в качестве пациента наглядно продемонстрировал важность понимания сложной работы со всеми ее функциональными, эмоциональными и социальными аспектами. Каким бы навороченным ни было программное обеспечение, оно не давало полной картины.

Личный опыт Данна в качестве пациента помог ему осознать недостатки общего инновационного процесса, действующего в Intermountain. С самого начала Intermountain переложила на специализированное программное обеспечение практически все функции в больнице, от заказа врачами анализов и последующих процедур для пациентов до составления графика работы и распределения по кабинетам. Нередко программное обеспечение, поясняет Данн, разрабатывалось после того, как врачи собирались в конференц-зале и опрашивались на предмет того, что бы они хотели иметь. Аналитики записывали все просьбы и передавали их инженерам, которые, в свою очередь, разрабатывали решение, отвечающее описанию врачей. Основное предположение, по словам Данна, состояло в том, что «врач всегда прав или в состоянии объяснить свои действия достаточно подробно, чтобы выполнить "работу", в помощи с которой он нуждается». Поэтому каким программное обеспечение, по их словам, должно быть, таким инженеры его и делали.

Но почему-то слова врачей не всегда соответствовали тому, что они в действительности хотели. И они упускали целевого клиента – пациента. Слишком часто проекты, требующие масштабных обновлений или исправлений, откладывались или вообще отменялись. «Мы долго руководствовались творческим подходом, – говорит Данн. – Но все равно ничего особо не выходило. Я осознал, что мы анализируем людей. Мы могли многое рассказать об их поведении – что происходит сперва, что потом и так далее. Но мы не анализировали работу».