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

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

Праздновать победу рано

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

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

4. Минимизируйте объем работы и составьте план

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

Я знаю, вы думаете: «А что тут страшного-то?»

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

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

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

Ресурсов всегда будет не хватать

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

В главе 3 вы прочитали о том, как в Globo.com использовали карты, чтобы уложиться в жесткие временные рамки. Компания сконцентрировалась на дедлайне, чтобы выделить достаточный для успеха объем работы. Затем бэклог был разбит на части: все, что не было необходимо для достижения нужного результата, отбросили. Таким образом появилось предположительное минимально жизнеспособное решение. И это не была грубая, слабо очерченная версия большой идеи – это было в самом деле блестящее решение, точно нацеленное на достижение необходимого результата к выборам в Бразилии. Ребята из Globo.com были уверены, что эта работа принесет пользу их бизнесу, рекламодателям, телевизионным компаниям и клиентам. Они подумали обо всех своих пользователях и были уверены, что делают для них что-то нужное. А разделив карту на части, они сформулировали решение, которое можно было реализовать силами своих команд за имеющееся время. Сочетание ценности, полезности и реалистичности для конкретных пользователей, заказчиков и задач и является жизнеспособным решением.

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

Мы можем сразу же применить этот подход не только к первому, но и ко второму и к третьему релизам, чтобы обеспечить и их жизнеспособность. Но мы знаем: как только первый релиз выйдет в свет, мир изменится (и это хорошо). Это автоматически означает, что нам нужно будет пересмотреть свои будущие релизы с точки зрения новых условий, которые мы создали.

Секрет расстановки приоритетов

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

Он известен немногим – во всяком случае, люди ведут себя так, словно ничего о нем не знают. Впрочем, быть может, они прикидываются тупицами с каким-то умыслом?..

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

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