Начнем с изучения основных причин того, почему многие усилия по созданию новых продуктов терпят крах. В подавляющем большинстве компании любого размера, в самых разных уголках земного шара применяют один и тот же основной метод работы, и, должен отметить, он совсем не похож на то, как работают лучшие и успешные.
Хочу сразу предупредить, что дальнейшее обсуждение может показаться вам несколько удручающим, особенно если вы во многом узнаете в моем рассказе свою компанию, но даже если это так, настоятельно прошу вас не бросать чтения.
Итак, на рис. 6.1 схематически представлен процесс, который по-прежнему используют большинство компаний при создании продуктов. Воздержусь от разглагольствований и поучений — сначала просто опишу его.
Рис. 6.1. Основные этапы создания продукта
Как вы видите, все начинается с идей. В большинстве компаний они поступают изнутри — от руководителей, ключевых заинтересованных сторон или собственников бизнеса — либо извне — от нынешних или потенциальных потребителей. В любом случае разным подразделениям нужно от вас много чего.
Затем большинство компаний определяют приоритеты для этих идей с помощью дорожной карты (roadmap), что делается по двум причинам. Во-первых, они хотят, чтобы люди работали над самыми важными вещами, а во-вторых, им хочется иметь возможность спрогнозировать, когда что будет готово.
Для этого в компании обычно проводится ежеквартальное или ежегодное совещание по планированию; на нем руководство рассматривает и оценивает идеи и обсуждает дорожную карту продукта. Но чтобы определить приоритетность идей, нужна оценка каждой из них в той или иной форме. В одних компаниях приняты формальные процедуры, в других — неофициальные; как бы там ни было, все сводится к необходимости ответить на два вопроса относительно каждой идеи: сколько денег она принесет или какую ценность обеспечит? Сколько денег или времени уйдет на ее реализацию? Далее эта информация используется для составления дорожной карты, обычно на следующий квартал, но иногда и на целый год.
К этому моменту у организации, выпускающей высокотехнологичные продукты, все идеи и замыслы описаны и распределены в порядке приоритетности. Если идея попала в верхнюю часть списка, менеджер продукта первым делом проводит беседу с заинтересованными сторонами, в результате чего замысел, так сказать, обрастает плотью, и «вырисовывается» ряд основных «требований», или технических условий. Иногда эти требования представлены в виде пользовательских историй (user stories), а иногда больше напоминают по форме техническое задание или функциональное описание. Их цель — донести до дизайнеров и инженеров, что именно им нужно создать.
Как только требования собраны в пакет, команде дизайнеров пользовательского опыта (если таковая имеется) предлагают спроектировать взаимодействие, разработать графический дизайн и, если речь идет о физическом устройстве, промышленный дизайн. И наконец, требования и спецификации по дизайну передаются инженерам-программистам. Тут-то на сцену обычно выходит методология Agile.
В любом случае инженеры, как правило, разбивают работу на итерации — отрезки времени, которые в процессе Scrum называются спринтами. Для превращения замысла в готовый продукт может потребоваться, скажем, от одного до трех спринтов. Желательно, чтобы в спринт входило тестирование качества, в ином случае специальная команда уже после окончания разработки проводит тестирование готового продукта, чтобы убедиться, что новая идея работает так, как рекламировалось, и не порождает других проблем с предыдущей версией продукта (так называемое регрессионное тестирование).
Как только компания получает зеленый свет от команды тестировщиков, начинается релиз новой идеи для реальных клиентов.
Большинство компаний самых разных размеров, когда я встречаюсь с ними в первый раз, работают именно таким образом на протяжении многих лет. При этом они постоянно жалуются на отсутствие инноваций и на то, что на превращение идеи в реальный продукт в руках потребителя уходит слишком много времени. Вы вряд ли станете спорить с тем, что, несмотря на упомянутую методологию Agile и практически всеобщее утверждение о гибком подходе к разработке программного обеспечения, только что описанный процесс очень уж напоминает каскадную модель, или, как ее еще называют, «водопад». Впрочем, справедливости ради надо сказать, что инженеры-программисты обычно используют agile-методы так часто, как только могут, учитывая более широкий каскадный контекст.
Хорошо, пусть большинство команд работают так, но почему это обязательно становится причиной стольких проблем? Давайте-ка расставим все точки над «и» прямо сейчас, чтобы ясно понять, почему этот распространенный повсеместно метод приводит к неудачам при создании софта.
Далее вашему вниманию предлагается список моей топ-десятки самых больших проблем, которыми чреват такой подход. Имейте в виду: все это очень серьезные проблемы; даже одна из них может свести к нулю усилия всей команды. Тем не менее для многих современных компаний характерны несколько, а то и они все.
Мы не можем знать, сколько денег заработаем, потому что это всецело зависит от того, насколько правильным и удачным будет наше решение. Если команда проделает отличную работу, она может оказаться невероятно успешной и изменит весь дальнейший ход деятельности компании. Но, к сожалению, многие замыслы продуктов в конечном счете не приносят компании ровным счетом ничего. И это вовсе не преувеличение! Буквально ничего (это определяется в результате A/B-тестирования).
Как бы там ни было, при разработке продуктов всегда нужно знать, чего мы не можем знать, а на этом этапе мы просто не можем знать, сколько заработаем на той или иной новой идее.
Точно так же мы понятия не имеем, во что нам обойдется создание нового продукта. Без фактического решения проблемы инженерам чрезвычайно сложно предсказывать какие-либо результаты. Большинство опытных разработчиков на этом этапе откажутся давать даже приблизительную оценку, но некоторых из них заставляют или убеждают пойти на компромисс и дать прогноз по типу размеров футболок: просто сообщите нам, каковы шансы этой идеи — «маленькие, средние, большие или очень большие». Очень уж хочется иметь дорожные карты с приоритетами, а для этого нужна какая-нибудь система для оценки идей и замыслов. Поэтому люди играют в бессмысленную игру с оценками.
Но тут возникает проблема, возможно, самая серьезная, на которую все закрывают глаза. Я называю это двумя неприятными правдами о продукте.
Первая истина заключается в том, что по крайней мере половина идей не сработают. Это может произойти по целому ряду причин. Чаще всего потребители попросту не придут от них в такой же восторг, как мы. И, как следствие, не выберут наш продукт. Иногда они решают использовать его и пробуют, но отказываются от него из-за чрезмерной сложности, а переход чреват такими проблемами, что овчинка выделки не стоит. А иногда проблема бывает в том, что потребителям продукт, возможно, и понравился бы, но его создание требует намного больше усилий, чем мы думали, поэтому тут уже мы решаем, что не можем позволить себе таких трат.
Словом, я вам обещаю: половина идей из дорожной карты никогда не оправдают ожиданий. (Лучшие команды исходят из предположения, что минимум три четверти идей не сработают так, как им хотелось бы.)
Впрочем, будто этого мало, есть и вторая неприятная правда. Она заключается в том, что для доведения идей, даже с уже подтвержденным потенциалом, до момента, когда они будут приносить необходимую ценность для бизнеса, обычно требуется несколько итераций. Мы называем это соотношением «время — деньги».
Один из самых важных уроков, которые я выучил за годы работы с программным продуктом, состоит в том, что обойти эти обстоятельства невозможно, будь ты хоть ста пядей во лбу. А ведь мне посчастливилось работать со многими исключительно хорошими продуктовыми командами. Так что я могу точно сказать: все зависит от того, как вы справляетесь с ситуацией.
Как известно, ключевой принцип Lean-системы (системы бережливого производства) — это сокращение потерь (отходов), а одной из худших форм таких потерь считается проведение проектирования, изготовления, тестирования и развертывания функции или продукта с тем, чтобы в конце этого долгого пути узнать, что это совсем не то, что нужно пользователю. И вот парадокс: многие команды убеждены, что применяют Lean-принципы, а между тем используют описанный мной базовый процесс. И тут я указываю им на то, что они проверяют свои идеи одним из самых дорогих и самых медленных способов из всех известных.
Учитывая все вышесказанное, стоит ли удивляться, что так много компаний тратят ценные ресурсы, получая столь жалкую отдачу. А я предупреждал, что то, что я скажу, может огорчить вас. Но я все равно говорю об этом, потому что очень важно в полной мере понимать, почему ваша компания должна изменить подход к работе — если, конечно, она работает так, как я описал.
У меня для вас есть и хорошая новость: лучшие команды работают совершенно иначе, и мы можем у них этому поучиться.