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

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

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

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

Вообще-то частично я ввел вас в заблуждение.

Многие из вас, наверное, читали предыдущую главу и другие главы перед ней, медленно закипая, так как я, очевидно, упускаю самое интересное. Сожалею об этом.

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

Таким образом, мы подошли к одной из крупнейших ошибок, которые обычно делают люди, – твердой уверенности, что минимально жизнеспособное решение непременно будет успешным.

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

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

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

Исследования, опубликованные организацией Standish Croup в отчетах Chaos прошлых лет, доказывают, что от 64 до 75 % функциональностей используются редко или не используются никогда [27]. А 75–90 % всех IT-стартапов (в зависимости от того, что считать неудачей) не достигают успеха [28].