Пользовательские истории. Искусство гибкой разработки ПО - [77]

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

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

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

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

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

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

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

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

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

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

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

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

Получайте обратную связь из тестирования с пользователями и заказчиками

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

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

Пересмотрите свое решение и предположения

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

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

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

В подходе Lean Startup самая большая ошибка – завалить этап обучения.

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

Истории и карты историй

Вы можете спросить: «А какое отношение к этому имеют истории и карты историй?» Это хороший вопрос.