Существует очень много действий, которые вы и ваша команда можете проделать, и артефактов, которые вы можете создать, проводя исследование. Эта простая таблица даст вам некоторое представление о том, что вы можете использовать. Не стоит пытаться выполнить сразу все – это излишне, но и не ограничивайтесь лишь тем, что перечислено здесь, ведь наверняка существуют и другие методы, которые больше подойдут в вашей ситуации с учетом имеющихся у вас возможностей и навыков. Главное – не просто сидеть в комнате и писать бесконечное количество историй. Это глупо.
Цель исследования – выработка одинакового понимания
Приходилось ли вам когда-нибудь работать над проектом программного продукта, где никто как следует не представлял себе картину в целом? Приходилось ли вам сталкиваться с ситуацией, когда в разгар разработки команда обнаруживала, что необходимо сделать большой незапланированный кусок работы? Когда такое случалось со мной, нередко оказывалось, что среди членов нашей команды и людей со стороны, которые сотрудничали с нами, хоть кто-нибудь да имел необходимые сведения. Чтобы избежать проблем, нам нужно было всего лишь иметь полное взаимопонимание.
Отчасти история Гэри из главы 1 как раз об отсутствии общей картины у него самого и его команды разработки. Даже сам Гэри, в голове которого родился продукт, не осознавал до конца сложности и размера этого проекта. Визуализация продукта в виде ряда простых моделей помогла ему и всем, кто ему помогал, нарисовать одну и ту же цельную картину в своем сознании.
Для некоторых создаваемых вами вещей может быть вполне достаточно достичь взаимопонимания относительно заказчиков и пользователей, а также формулировки найденного решения. Но хочу предостеречь: ваши гипотезы о том, что вы создаете, вполне могут быть неверными. Не беспокойтесь, как раз в следующей главе я собираюсь рассказать о нескольких стратегиях, которые помогут вашим исследованиям стать максимально эффективными.
Глава 15. Эмпирическое обучение через исследование
Вообще-то частично я ввел вас в заблуждение.
Многие из вас, наверное, читали предыдущую главу и другие главы перед ней, медленно закипая, так как я, очевидно, упускаю самое интересное. Сожалею об этом.
На самом деле истории, которые я рассказывал о MadMimi и Globo.com, еще не завершены. Это правда, что в обоих проектах использовались исследовательские обсуждения для выявления минимально жизнеспособного решения, но действительно ли именно это решение является жизнеспособным или нет, пока только догадки. По сути, все в этих историях – лишь догадки, пока продукт не представлен на рынок и мы не знаем, как на него реагируют пользователи и заказчики. Начальные исследовательские обсуждения, как и карты историй, помогли сделать хорошие стартовые предположения. Но для обоих проектов это было лишь начало куда более длинного пути к созданию действительно жизнеспособного продукта.
Таким образом, мы подошли к одной из крупнейших ошибок, которые обычно делают люди, – твердой уверенности, что минимально жизнеспособное решение непременно будет успешным.
Большую часть времени мы ошибаемся
Я не исключение: как и многие другие, я склонен верить, что все мои блестящие идеи будут успешными. В прошлом я много раз реализовывал решения, которые, по моему мнению, непременно должны были «взлететь», но этого почему-то не происходило. Нельзя сказать, чтобы это были какие-то значительные провалы, они просто не давали особого эффекта. В конце концов я и моя компания научились думать по-другому. Это были не только мои идеи – мы все хотели бы, чтобы функциональности, которые мы внедряем, приносили пользу. Но в конце концов оказывалось, что функциональностью, которую мы добавили, пользуются лишь пара человек, остальным она неинтересна, и все понимали, что придется прекратить ее поддержку, чтобы сохранить весь остальной продукт.
В чем я убежден – не на основании каких-то конкретных исследований или наблюдений, просто из собственного опыта неудач и сходного положения дел в других компаниях, – очень небольшая часть того, что мы создаем, будет иметь успех или реальный эффект, на который мы надеемся. Я бы сказал, не более 20 %. Более того, около 20 % созданного нами будет иметь негативные последствия, то есть, попросту говоря, навредит нашему бизнесу. Я много раз наблюдал, как организации выпускали новую, лучшую версию своего сайта, а продажи после этого падали, или предлагали заказчикам новую версию своего продукта, которую те пробовали, но затем возвращались к старой версии. Вот о каких неудачах я говорю.
Но между ними находятся около 60 % – чуть больше или чуть меньше, неважно, – которые не являются ни успехом, ни неудачей. По сути, это большая проблема: на создание этих функциональностей или продуктов мы потратили значительное количество денег, но в результате не получили ровным счетом ничего.
Исследования, опубликованные организацией Standish Croup в отчетах Chaos прошлых лет, доказывают, что от 64 до 75 % функциональностей используются редко или не используются никогда[27]. А 75–90 % всех IT-стартапов (в зависимости от того, что считать неудачей) не достигают успеха[28].
Такие данные очень демотивируют, если о них задуматься. Неудивительно: большинство организаций придерживаются стратегии «сделаем вид, что у нас все работает».
Старые недобрые времена
В старые недобрые времена я, как правило, работал примерно так. Я приносил очередную блестящую идею, или, честно признаюсь, то, что было мне предложено генеральным директором или важным заказчиком как их блестящая идея. Я дорабатывал ее, конкретизировал, корректировал. Затем я и моя команда приступали к реализации. Разработка всегда занимала вдвое больше времени, чем мы ожидали, но об этой проблеме мы поговорим в следующих главах. Мы заканчивали. Мы представляли сделанное клиентам. Мы устраивали вечеринку. Иногда вечеринка предшествовала представлению продукта. Но в любом случае в конце концов все было сделано.
Вот что происходило затем. Как правило, люди начинали жаловаться, что предъявленные нами функциональности не работают так, как бы им хотелось. Иногда ни одной жалобы не поступало (это, как мы понимали позже, объяснялось тем, что никто на самом деле не использовал функциональность). Тем не менее мы делали вид, что это и есть успех, что все хорошо. Вероятно, именно так дело обстоит в компаниях, где работают некоторые из вас. И, признаюсь честно, я сам иногда скатываюсь к такому пути в своей работе. Не говорите никому. Все-таки предполагается, что я эксперт.
Но, к счастью, есть способы работы получше.
Эмпатия, фокус, формулировка, прототип, тестирование
Несколько лет назад со мной связался один клиент и спросил, могу ли я помочь адаптировать процесс, который он назвал мышлением дизайнера. В организации этого клиента был внедрен процесс, типичный для Agile, и дела у них шли неплохо – неплохо в том смысле, что все предъявлялось вовремя и с хорошим качеством. Но, как известно, чем быстрее предъявляешь барахло, тем больше барахла получаешь. Это, конечно, звучит грубовато. Другими словами, клиент убедился, что корреляция между количеством программного обеспечения, которое они разрабатывали, и эффектом, который получали в результате, была невелика.
В то время я был известен как специалист по дизайну пользовательского взаимодействия и разработке Agile. Я подумал: «Раз я дизайнер и способен мыслить, значит, у меня есть мышление дизайнера». Но я был не прав. Это было не то, что имел в виду клиент. К счастью, я не высказал свою мысль вслух.
Мышление дизайнера – это способ работы, изначально внедренный компанией IDEO. Затем в школе дизайна Стэнфордского университета этот способ изучили и начали преподавать. В наши дни ему обучают во множестве университетов и используют во множестве компаний по всему миру.
В процессе дизайнерского мышления есть несколько этапов, которые в моем изложении выглядят многообещающе. Но на практике и я, и большинство других людей склоняемся к тому, чтобы делать прямо противоположное. Неудивительно, что нас преследуют неудачи.
Первый шаг дизайнерского мышления заключается в обеспечении эмпатии. Я бы не назвал это исследованием, что, как правило, ожидается в процессе дизайна. Название «эмпатия» выбрано потому, что в результате исследовательской работы необходимо по-настоящему осознать и прочувствовать, каково это – быть пользователем вашего продукта. Для этого нужно отправиться туда, где находятся пользователи, познакомиться с ними, понаблюдать за их работой и в идеале поработать вместе. Разумеется, если вы создаете программное обеспечение для хирургов, никто не ждет, что вы займетесь любительской хирургией, но сделайте все, что от вас зависит, чтобы ощутить себя в их шкуре. Не забывайте, что при традиционных исследованиях, особенно если это автоматические инструменты и опросы, собирающие количественные данные, мы получаем только данные, но не эмпатию.
Общайтесь с пользователями и заказчиками напрямую. Испытайте на себе те проблемы, от которых вы хотите их избавить своим решением.
Следующий шаг называется определением (фокусом). На предыдущем шаге, обеспечения эмпатии, мы многому научились, теперь нужно извлечь из него суть для того, чтобы выработать одинаковое понимание. Для этого понадобится большая совместная работа: изложение историй, передача информации и выделение главного из того, что мы узнали. После этого можно выбрать конкретных людей, имеющих конкретные проблемы, на которых мы сконцентрируемся.
На этом этапе используйте карты историй для того, чтобы отразить на них актуальное положение вещей. Включите в них детали, отражающие то, что вы видели или узнали. Сфокусируйтесь на трудностях пользователей, на том, что их раздражает или, наоборот, радует. Используйте простых персонажей, чтобы отобразить образ пользователя, который объединяет все, что вы изучили. Выберите специфические проблемы, на которых будете фокусироваться.