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

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

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

Начали появляться новые подходы к разработке, такие как Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming и многие другие. Эти подходы, в свою очередь, черпали вдохновение в других быстрых практиках начиная от бережливого производства и заканчивая практиками армейской подготовки.

Общим для этих подходов была концепция гибкости, или часто можно услышать Agile (англ, гибкость[20]). Основная идея этой концепции – короткие циклы поставки. Важно обратить внимание, что ключевое слово здесь «поставки». Подразумевается, что не реже чем раз в месяц жизнь пользователей становится лучше.

Запуская Scrum в Альфа-банке, мы решили, что будем работать спринтами, но каждая роль будет эти две недели заниматься своим артефактом и передавать его на следующий – производственный – этап. Например, сначала аналитики две недели пишут ТЗ, затем дизайнеры две недели делают макеты по ТЗ, затем фронтенд-разработчики две недели верстают макеты, затем бэкенд-разработчики две недели делают серверную часть, потом тестировщики две недели ее тестируют…

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

Побочным эффектом становится необходимость отслеживания всех промежуточных артефактов. На инвентаризацию уходило очень много времени, при этом было очевидно, что половина артефактов безвозвратно утратила актуальность, но они все равно мешались в бесконечных колонках Trello. Позднее мы узнали, что такой подход называется Scrum-fall: Scrum + Waterfall, и обычно он порождает массу проблем с производством и культурой – команда разделяется на этажи, каждый занят своим артефактом и не ориентирован на заботу о результате и пр. Я помню это удивительное чувство освобождения, возникшее, когда мы перешли в режим, в котором все делают все в одном спринте. Артефакты порождались и утилизировались в спринте и их не нужно было учитывать. Команда работала сообща и принимала решение о необходимости артефакта и качестве его проработки, а самое главное, от идеи до релиза проходило две недели.

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

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

Такой карго-культ[21], помимо противоречия бережливому принципу втягивания, может посадить сразу несколько видов потерь – перепроизводства, лишних запасов и пр.

Более подробно о гибком подходе Agile и лучшем известном способе организации цикла поставки Scrum будет рассказано подробнее в п. 3.1 и 3.2.