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

Глава 13. Начните с возможностей

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

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

Обсуждайте свои возможности

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

• для кого она. На этом уровне чаще всего упоминаются разные группы пользователей, заказчиков или целевой сегмент рынка;

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

• что представляет собой идея. У нас могут быть соображения о том, какими должны быть продукт или функциональность. Об этом следует поговорить;

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

• каков ее размер. На этом уровне, даже если размах идей велик, мы можем сделать осторожные оценки времени на разработку, пусть даже они и не будут особенно точными. Лучше всего рассмотреть данную возможность в сравнении с чем-то, что мы уже делали раньше: «Это звучит похоже на ту, другую функцию, которую мы выпустили в прошлом релизе. На нее потратили несколько недель, значит, и эта займет примерно столько же». Для принятия решения о том, стоит ли продолжать работу над идеей, полезно знать, сколько времени займет ее разработка – дни, недели или месяцы.

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

После анализа: выбрасываем или продолжаем думать

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

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

У вашей группы может быть недостаточно информации для принятия решения «да» или «нет». Если это так, составьте список того, что нужно выяснить, и соберите нужную информацию.

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