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

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

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

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

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

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

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

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

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

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

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

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

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

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

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