Scrum ускоряет проекты в два раза, сокращая расходы в два раза

Такое ЦП можно прочесть на обложке популярной красной книжки Джефа Сазерленда про Scrum. В оригинале: The Art of Doing Twice the Work in Half the Time. Дословный перевод недвусмысленно указывает на проектную деятельность. Ни о каких продуктах здесь речи нет. Тут написано "работа".

Однако, в скрам-гайде написано developing, delivering, and sustaining complex products. И далее address complex adaptive problems чтобы delivering products of the highest possible value. И когда мы читаем красную книжку, то она изобилует примерами сугубо проектной деятельности, которая чудесным образом ускоряется за счёт применения некоторых элементов Scrum-фреймворка. Однако, в конце scrum guide написано implementing only parts of Scrum is possible, the result is not Scrum.

Scrum для ускорения и удешевления проектов? Или scrum для продуктов в условиях complex adaptive problems? Или обе задачи можно эффективно решать с помощью scrum фреймворка? Тут вопросов больше чем ответов. Я опишу сейчас свое мнение, и мне очень интересно узнать мнение других на эту тему.

Scrum для неопределенности, которую невозможно снизить с помощью любого рода аналитической деятельности. Если по простому, то это такая ситуация, когда каких бы экспертов мы не приглашали, у нас все равно нет уверенности в том, какие действия нам помогут достичь желаемых изменений (outcome). Мы либо в неопределенности по части что именно делать, либо в неопределенности как это делать. Принимать управленческие решения в такой ситуации очень сложно, слишком большие риски.

Самый распространенный пример такой ситуации - стартап. Классическое определение от Эрика Риса "это предприятие по разработке новой услуги или продукта в условиях чрезвычайной неопределенности". Можно назвать стартап проектом по поиску масштабируемой бизнес-модели. Бизнес-модель, если по-простому, это проверенная работающая практика зарабатывания денег в конкретном сегменте рынка. В стартапе проектный треугольник (cost-time-scope) ломается и превращается в комбинацию из трех других элементов:

  1. Размер посевных инвестиций (budget)
  2. Давление со стороны инвестора (быстрее, ребята!!!)
  3. Желаемые изменения для бизнеса (outcome)

Стартап просто невозможно сделать без кросс-функциональной команды, которая наделена коллективной ответственностью за бизнес (outcome). Проектный менеджмент в классическом виде парализует работу такой команды начисто, поэтому тут нужен другой управленческий подход. Product Vision и стратегия основателей стартапа разбивается на факты и гипотезы, из гипотез выстраивается цепочка и появляется scope из серии малобюджетных экспериментов, целью которых является проверка работоспособности бизнес-модели. Time появляется путем деления budget на расходы на команду (capacity) с учетом доп расходов на эксперименты (в основном, это макретинговые каналы).

В итоге у нас в самом начале все же появляется проектный треугольник, однако он никак не поддается классическому проектному управлению. Каждый эксперимент может привести к изменению стратегии и даже Product Vision иногда корректируется. Каждый эксперимент - это мини-проект. А это значит, что управлять этим всем с помощью, например, диаграммы Гантта не получится - она постоянно и сильно "плывет". Вместо этого применяются инструменты гибкого управления: трэкшн-карты, канвасы бизнес-моделей, бэклоги и т.д.

Риск снижается не за счет того, что все процессы и результаты детально прописаны с самого начала, и есть проектный менеджер, который за этим строго следит. Риск снижается за счет того, что в каждой итерации бизнес-модель воспроизводится организацией целиком (!), но в разной степени готовности к запуску бизнеса. Сначала бизнес-модель воспроизводится лишь в голове основателей, когда они идут к потенциальным клиентам и проводят с ними проблемные интервью, пытаясь их проблематизировать и приземлить в них свой Product Vision. Ближе к концу "стартапа" организация воспроизводится в виде вполне понятных процессов маркетинга, продаж, обслуживания, бэк-офиса и т.д.

Всем этим занимаются не проектные менеджеры, а бизнес-трэкеры и коучи. Их функция не в том, чтобы ставить задачи и контролировать их исполнение. Их функция представляет из себя 5-й принцип Scrum: subtle control - self-control, control through peer pressure. Бизнес-трэкер должен убедиться, что команда уже пришпорена (это важно!), у них есть понимание что, зачем и как проверять, и они договорились на ближайшую итерацию. В конце итерации бизнес-трэкер заставляет команду, что называется, "вспомнить всё", сделать обзор и принять необходимые решения (по корректировке бизнес-модели, например). Затем история повторяется со следующим экспериментом, и так до тех пор, пока риски не будут снижены достаточно, чтобы можно было полноценно запускать бизнес. На этом стартап завершается, и начинается традиционное построение организации с инвестициями Round A, B и т.д.

Да, можно назвать стартап проектом. Но проектное управление к такому, с позволения сказать, проекту, не применимо. И если проанализировать работу команды основателей в стартапе, то она полностью воплощает в себе все 6 принципов Scrum, описанных двумя известными японцами в статье HBR от 1986 года. Можно ли назвать Scrum универсальным способом снижения расходов и времени в два раза на любой проект? Вряд ли. Scrum выглядит абсурдно, если риски проекта связаны не с неопределенностью, а с исполнением заранее понятной работы, которую надо просто сделать.

Бывают ли ещё проекты, в которых классическое проектное управление лучше заменить на Scrum?

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

А у вас есть примеры (может быть даже кейсы?) проектов, которые лучше делать по Scrum?