Джефф Паттон - Пользовательские истории. Искусство гибкой разработки ПО

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

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

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

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

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

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

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

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

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

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

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