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

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

Вот как я рекомендую применять стратегию Lean Startup, работая сегодня.

Да, с догадок.

В старые недобрые времена вы так или иначе оперировали догадками, просто притворяясь, что это не так. В процессе проектирования вы не должны допускать догадок, но другого пути не было, поэтому вы их допускали, но притворялись, что ничего такого не было. Поэтому просто перестаньте притворяться.

На самом деле это ведь не просто догадки. Отчасти что-то берется из опыта, отчасти из интереса к теме, понимания смысла того, что вы делаете, и, конечно, отчасти из предположений, но таким образом и запускается процесс. Я суммирую свои предположения и догадки о том, кто мои пользователи, обычно составляя простые прототипы. Я описываю, как, по моему мнению, они работают сейчас, составляя карты историй по состоянию на сегодняшний день. Все это я делаю совместно с другими людьми, у которых есть непосредственный опыт работы с пользователями и заказчиками. А в некоторых ситуациях на этом этапе я привлекаю к работе пользователей и заказчиков напрямую. Поэтому фактически многие догадки моей команды не являются догадками по сути. Но и исследованием в точном смысле слова их назвать нельзя. На такую работу уходит от нескольких часов до нескольких дней – ни в коем случае не недели или месяцы.

После того как у всех нас появилось одинаковое представление о пользователях программного продукта и о проблемах, на которых мы концентрируемся, можно предположить, каковы будут возможные решения. Мы снова используем принципы дизайнерского мышления – выдвигаем и рассматриваем несколько независимых решений, но стараемся как можно быстрее прийти к соглашению о том, какое решение будет самым лучшим. Иногда одно решение выбрать не получается и приходится брать в работу несколько. Не следует переоценивать важность этого этапа, так как, очевидно, мы в любом случае делаем какие-то ошибки.

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

То же самое нужно сделать в отношении нашего решения. Следует подумать, какой реакции на него мы ожидаем от своих пользователей и как, по нашему мнению, они будут использовать это решение. Мы формируем в уме какие-то гипотезы о возможных путях взаимодействия пользователей и нашего продукта. Мы также обсуждаем технические риски – то, что может поставить под угрозу реализацию нашего решения.

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

Именно здесь заметны наибольшие отличия.

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

Вот пример из жизни моих друзей из некоммерческой организации под названием ITHAKA. Они работали над продуктом под названием JSTOR. Если в последние десять лет вы учились в каком-нибудь американском колледже, то, скорее всего, пользовались JSTOR в библиотеке, чтобы найти статьи или книги для заданного вам реферата.

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

Вот какие предположения о студентах они сделали.

• Работают из кофеен и общежитий.

• Не знают, что могут подключиться к JSTOR из этих мест.

• Или знают, но думают, что это очень трудно.

Вот какие предположения были сделаны о решении.

• Интуитивно понятное.

• Студентам должно быть очевидно, что у них есть полный доступ к JSTOR без необходимости присутствовать в библиотеке.

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

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

Вот несколько страниц из дизайнерского комикса JSTOR.

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

Минимально возможное для тестирования решение – то, что Lean Startup называет минимально жизнеспособным продуктом. Да, Эрик Райс знает, что это не полноценный продукт. Но если ваша цель – обучение, это самый маленький продукт, который вы можете создать, чтобы научиться чему-то.

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

JSTOR просил студентов и аспирантов уделить немного времени исследованию, после чего в течение 30–60 минут их спрашивали, как они справляются со своими задачами сегодня, так что команда могла подтвердить свои предположения относительно проблем, которые решали ее члены. А после показывали дизайнерский комикс и просили высказать свое мнение об идее решения.

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

Запустив свои тесты, ребята из JSTOR обнаружили, что у многих студентов не было тех проблем, которые они предполагали. Обычно такого рода новости расстраивают, ведь никто не любит оказываться неправым. Но с точки зрения подхода Lean Startup это прекрасные новости. Прекрасные потому, что ошибочное направление обнаружилось всего за несколько дней, а не после многих недель командной работы над созданием программного обеспечения.

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

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