К этому моменту у организации, выпускающей высокотехнологичные продукты, все идеи и замыслы описаны и распределены в порядке приоритетности. Если идея попала в верхнюю часть списка, менеджер продукта первым делом проводит беседу с заинтересованными сторонами, в результате чего замысел, так сказать, обрастает плотью, и «вырисовывается» ряд основных «требований», или технических условий. Иногда эти требования представлены в виде пользовательских историй (user stories), а иногда больше напоминают по форме техническое задание или функциональное описание. Их цель – донести до дизайнеров и инженеров, что именно им нужно создать.

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

В любом случае инженеры, как правило, разбивают работу на итерации – отрезки времени, которые в процессе Scrum называются спринтами. Для превращения замысла в готовый продукт может потребоваться, скажем, от одного до трех спринтов. Желательно, чтобы в спринт входило тестирование качества, в ином случае специальная команда уже после окончания разработки проводит тестирование готового продукта, чтобы убедиться, что новая идея работает так, как рекламировалось, и не порождает других проблем с предыдущей версией продукта (так называемое регрессионное тестирование).

Как только компания получает зеленый свет от команды тестировщиков, начинается релиз новой идеи для реальных клиентов.

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

Хорошо, пусть большинство команд работают так, но почему это обязательно становится причиной стольких проблем? Давайте-ка расставим все точки над «и» прямо сейчас, чтобы ясно понять, почему этот распространенный повсеместно метод приводит к неудачам при создании софта.

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

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