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

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

Мне нравится термин «исследование продукта» – он отлично описывает то, что мы делаем на этом этапе. Наша цель пока не в том, чтобы что-то создать, – скорее убедиться, что мы создаем правильную вещь. Как оказалось, разработать что-то и дать заказчикам этим какое-то время попользоваться – лучший способ убедиться, что проект развивается в верном направлении. Я позаимствовал определение исследования у Марти Когана[10], а мое определение включает практики Lean Startup и Lean User Experience, практики «мышления дизайнера» и множество других идей. Мое понимание того, что нужно делать на этапе исследования, постоянно развивается, но цель остается неизменной: как можно быстрее убедиться, что работа над продуктом идет в правильном направлении.

Ставьте минимальные эксперименты

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

Рассмотрим пример. Допустим, я владелец продукта в компании, которая создает ПО для крупных сетевых магазинов. Мне очевидно, что мои продукты будут работать на основе большой базы данных в Oracle. Но также я знаю, что иметь дело с разработчиками базы данных – сущее наказание: они рассматривают, как под микроскопом, каждый мой шаг. Порой, чтобы внести самое простое изменение, требуется неделя работы, а то и больше. Это, разумеется, значительно замедляет работу моей команды. Конечно, ребят, работающих с базой данных, можно понять, ведь от этой базы зависит работа всех других приложений и пропустить какие-то проблемы с ней слишком рискованно. У них есть хорошо налаженный процесс оценки и внесения изменений в базу, он просто занимает слишком много времени.

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

Резюме

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

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

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

Глава 4. План своевременного завершения

Это Аарон и Майк. Они работают в компании под названием Workiva, где выпускают ряд продуктов на основе платформы Wdesk. Эта организация помогает другим большим компаниям решать серьезные задачи и является одной из крупнейших компаний типа «программное обеспечение как услуга», о которых вы, скорее всего, никогда не слышали.

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