ка показывает истории, которые находятся в работе в текущем спринте, вместе с задачами по предъявлению, в рамках которых программисты и тестировщики обрабатывают различные технические детали, необходимые для успешного воплощения идей истории в работающее ПО.
В работе Эрика с бэклогом в виде карты историй есть еще одна хитрость, доказывающая прозорливость команды: высота верхнего среза. Как только Эрик и его команда заканчивают работу над очередным срезом и отправляют его партнерам по разработке – они называют их бета-заказчиками, – они перемещают вверх стикеры из нижнего среза. После этого следующий релизный срез обсуждается более детально: команда проговаривает все «что, если…», чтобы обнаружить проблемы и внести недостающие детали. Обсуждаются также некоторые идеи для следующего релиза, в результате этой дискуссии большая идея может быть разбита на две-три более мелкие. И в конце концов устанавливается высота этого среза, чтобы расставить приоритеты и определить, что следует брать в работу первым.
Теперь вы поняли, какие это умные ребята?
Повторяйте до жизнеспособности
Эрик мог бы запустить весь этот процесс, сразу оттолкнувшись от идеи минимально жизнеспособного процесса, но он намеренно для начала построил меньше минимума, чтобы затем добавлять понемножку каждый месяц. От партнеров по разработке постоянно поступает обратная связь – как из прямого обсуждения с ними (субъективная), так и из анализа данных (объективная).
Эрик намеревается продолжать в том же духе и дальше, обеспечивая медленный, но постоянный рост проекта и внедрение улучшений, пока его партнеры по разработке не начнут реально использовать продукт в ежедневной работе. Кроме того, Эрик надеется, что эти люди в конце концов порекомендуют продукт другим – настоящим заказчикам. Лишь когда это произойдет, Эрик будет уверен, что создал минимальный и жизнеспособный продукт. И только тогда его можно будет без опаски выпустить на рынок, где он, вне всяких сомнений, станет успешно продаваться. Если Эрик с ребятами попробуют продать продукт до этого момента, то, очевидно, будут иметь дело с толпой разочарованных клиентов, ведь с этими людьми не были установлены личные отношения на протяжении процесса разработки, и поэтому они настроены далеко не так снисходительно.
Как делать не надо
Эрик мог взять свой самый последний, лучший прототип, разбить его на составляющие и начать разрабатывать один фрагмент за другим. Несколько месяцев спустя он был бы готов что-то выпустить и только после этого узнал бы, верны ли его смелые предположения и догадки. И скорее всего, они бы оказались неверны. Можете мне не верить, но чаще всего бывает именно так.
Вот простая иллюстрация, нарисованная моим другом Хенриком Нибергом, – здесь отлично показана ситуация, когда из-за неверной релизной стратегии с каждым выпуском пользователь получает нечто, что не может использовать, пока в последнем релизе не выпустят наконец что-то полезное.
Хенрик предлагает вот такую альтернативную стратегию.
Если я планирую свои релизы по этому принципу, то с каждым выпуском люди получают что-то, что могут реально использовать. Если я, как в этом простом примере, хочу передвигаться на большие расстояния, да еще и таскать с собой какие-то вещи, а вы даете мне скейтборд, я, конечно, буду не слишком доволен. Я скажу вам, как сложно будет уехать далеко на этой штуке, хотя, уверен, есть и любители кататься на скейтборде по автомобильным дорогам. Если вы хотели мне угодить, то, возможно, несколько огорчитесь, но ваша настоящая цель – исследование. Поэтому все нормально: вы узнали, что я хотел бы иметь возможность путешествовать на более дальние расстояния и, кроме того, делать это с комфортом.
По мысли Хенрика, таким образом, дело доходит до выпуска велосипеда, с помощью которого я получаю возможность передвигаться, более соответствующую моим потребностям. А получив мотоцикл, я действительно могу видеть, что ваши идеи работают, – я еду и получаю от этого удовольствие. Таким образом, это и есть минимально жизнеспособный для меня продукт. Если мне очень понравился мотоцикл, возможно, следующим шагом будет его улучшение до более крупной и быстрой модели, скажем, Harley-Davidson, а до спортивного автомобиля дело не дойдет (у меня как раз наступил кризис среднего возраста, поэтому мысль о Harley-Davidson мне очень нравится). Но принять это решение можно только после того, как я опробую мотоцикл и мы оба получим определенный опыт.
Рассматривайте каждый релиз как эксперимент и помните о том, что хотите узнать.
Но что с другими пользователями, которые хотят путешествовать подальше или имеют детей? Этот сегмент рынка не удовлетворит ни один этап из перечисленных выше.
Всегда помните о вашей основной целевой аудитории, заказчиках, пользователях, а также результатах, которые надеетесь получить. Обеспечить потрясающий результат для всех типов пользователей очень нелегко, поэтому фокусируйтесь.
Эмпирическое обучение
По сути, мой друг Эрик применил то, что в методологии Lean Startup называют стратегией эмпирического обучения. Эрик знал, что проблемы, которые он решает, пользователи и заказчики, которым он стремится помочь, и даже его собственные решения – только предположения и догадки. В основном это были обоснованные предположения, но все-таки предположения, а не факты. Поэтому Эрик и начал работу по выделению этих предположений, а затем их проверке, продвигаясь от проблем заказчиков и пользователей к уже существующим решениям. На каждом этапе он что-то делал или создавал с конкретной целью – проверить определенные предположения.
Эрик выполнил основную часть из цикла «создание – обратная связь – извлечение опыта», описанного Эриком Райсом. По определению Райса, каждый выпущенный релиз является минимально жизнеспособным продуктом, но, как вы могли заметить, он не был таковым в глазах конечных пользователей и заказчиков, по крайней мере пока не был. Поэтому мне нравится уточнение для определения МЖП Райса – минимально жизнеспособный продукт-эксперимент (МЖПэ). МЖПэ – самый маленький продукт, который можно создать, чтобы что-то изучить. В результате я пойму, что же в действительности жизнеспособно с точки зрения основных заказчиков и пользователей.
В ходе этой работы Эрик использовал множество инструментов и техник, хотя изложение историй с использованием слов и картинок помогало ему уже давно. Задействовав карту, с помощью которой были организованы истории, он смог удерживать в голове своих заказчиков, пользователей и этапы их работы с приложением по мере того, как продукт итеративно улучшался и повышалась его жизнеспособность.
Мне нравится термин «исследование продукта» – он отлично описывает то, что мы делаем на этом этапе. Наша цель пока не в том, чтобы что-то создать, – скорее убедиться, что мы создаем правильную вещь. Как оказалось, разработать что-то и дать заказчикам этим какое-то время попользоваться – лучший способ убедиться, что проект развивается в верном направлении. Я позаимствовал определение исследования у Марти Когана[10], а мое определение включает практики Lean Startup и Lean User Experience, практики «мышления дизайнера» и множество других идей. Мое понимание того, что нужно делать на этапе исследования, постоянно развивается, но цель остается неизменной: как можно быстрее убедиться, что работа над продуктом идет в правильном направлении.
Ставьте минимальные эксперименты
Если мы договорились, что наша цель – изучение, то можем создать лишь то, что минимально необходимо для изучения, сконцентрировавшись на том, что хотим узнать. Если вы учли этот принцип, то, вероятно, создаваемое на ранних этапах с целью исследования не может быть продуктом вообще. Скорее даже, если у вас выйдет что-то похожее на продукт, вы, очевидно, сделали слишком много.
Рассмотрим пример. Допустим, я владелец продукта в компании, которая создает ПО для крупных сетевых магазинов. Мне очевидно, что мои продукты будут работать на основе большой базы данных в Oracle. Но также я знаю, что иметь дело с разработчиками базы данных – сущее наказание: они рассматривают, как под микроскопом, каждый мой шаг. Порой, чтобы внести самое простое изменение, требуется неделя работы, а то и больше. Это, разумеется, значительно замедляет работу моей команды. Конечно, ребят, работающих с базой данных, можно понять, ведь от этой базы зависит работа всех других приложений и пропустить какие-то проблемы с ней слишком рискованно. У них есть хорошо налаженный процесс оценки и внесения изменений в базу, он просто занимает слишком много времени.
Самая рискованная часть для меня – убедиться, что мы делаем правильный продукт. Поэтому мы и создаем ранние версии ПО, используя простые базы данных, хранящие данные в памяти. Конечно, они не способны масштабироваться, и поэтому мы никогда не смогли бы выпустить ранние версии для широкой аудитории. Но проводимые на начальных стадиях эксперименты с минимально жизнеспособными продуктами (сейчас мы их даже не называем так) позволяют проверить наши идеи на небольшом количестве пользователей, задействуя в то же время реальные данные. После серии итераций с пользователями, найдя решение, которое, по нашему мнению, будет работать, мы вносим изменения в реальную базу данных и отключаем приложение от базы с данными в памяти. Специалистов по базам данных такой способ тоже устраивает, ведь они знают, что мы вносим изменения лишь после того, как убедимся в верности своего решения.
Резюме
Гэри использовал карту, чтобы избавиться от ловушки плоского бэклога и увидеть свой продукт целиком, а затем сконцентрироваться на том, для кого он предназначен и чем должен быть.
В Globo.com использовали карту для координации разработки большого плана несколькими командами, а также выделения части продукта, которая, по их мнению, могла быть жизнеспособным решением.