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

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

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

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

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

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

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

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

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

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

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

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

Данная бизнес-цель в сочетании с финансовыми ограничениями заставила Гэри сконцентрироваться на конкретных пользователях и их задачах, которых он решил поддерживать. Гэри не оставлял надежду создать «маркетинговый интерфейс музыкальной индустрии», давший Mimi название, но для начала решил сфокусироваться на задачах менеджера, рекламирующего свою музыкальную группу с помощью прямой электронной рассылки фанатам. Как только Гэри принял это решение, конкретные функциональности, над которыми следовало работать, стали яснее ясного.

Если вы сейчас читали внимательно, то, конечно, уже поняли, в чем секрет расстановки приоритетов.

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

Работая над MadMimi, Гэри принял взвешенное решение сконцентрироваться на достижении целей менеджеров, рекламирующих свои ансамбли. Это и была конкретная ценность, которую он поставил своей основной целью. Он не использовал абстрактное понятие «ценность для бизнеса», а совершенно конкретно определил то, что будет иметь ценность для него.

Ошибка большинства людей в том, что они пытаются сперва расставить приоритеты функциональностей.

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

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