Scaled Agile Framework, SAFe — фреймворк Agile-разработки, разработанный Scaled Agile Inc., по сути база знаний по реализации бережливой Agile-разработки в корпоративных масштабах. Ниже вольный пересказ оригинальной статьи «Budgets — Scaled Agile Framework».

Гибкая разработка программного обеспечения и традиционный учет издержек не сочетаются.
— Рами Сиркиа (Rami Sirkia) и Маарит Лаанти (Maarit Laanti)

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

Разберемся с терминами. Что такое портфель? В SAFe нет понятия проект, но есть определенная иерархия для обозначения большого количества взаимосвязанных между собой команд. Первый уровень — это «Программа». Несколько «Программ» объединены в Value Stream, которые в свою очередь объединяются в «Портфели». По численности сотрудников это могут быть целые подразделения — тысячи человек.

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

Чем плох традиционный учет издержек проекта?

1. Ориентированное на издержки бюджетирование порождает множество сложностей

Для большинства предприятий процесс бюджетирования выглядит так:

Традиционное проектно-ориентированное бюджетирование и модель учета издержек (ЦЗ – это центр затрат).

Предприятие организовано в виде «центров затрат», каждый из которых тратит финансовые или человеческие ресурсы, выделенные на проект (основная статья расходов) для достижения определенного результата. Но это создает целый ряд трудностей:

1. Для составления бюджета проекта необходимо планировать множество индивидуальных бюджетов — по одному на каждый центр затрат.
2. Команды вынуждены принимать тщательно взвешенные решения на ранних этапах, когда объективных данных для настолько детального долгосрочного планирования еще недостаточно. Если команды не знают весь масштаб работ, то как определить, сколько нужно нанять новых сотрудников и в какой момент?
3. В организации, где есть функциональные подразделения, работники выделяются на проект на определенный срок, а потом возвращаются назад и переходят на другой проект. Если срываются сроки хотя бы на одном проекте, начинают страдать и все остальные.
4. Такая модель имеет еще один недостаток: она вынуждает менеджеров функциональных подразделений или центров затрат изначально планировать полную загрузку сотрудников на длительный срок. Это значит, что если появляется незапланированное изменение или новый проект, выбить под него ресурсы очень сложно. О какой гибкости может быть речь? Цитируя автора книги книги Donald Reinertsen, Principles of Product Development Flow: Second Generation Lean Product Development: «Разработка продукта при 100% загрузке — это экономическая катастрофа».
5. Такая модель препятствует совместной работе отдельных сотрудников и команд дольше, чем длится реализация одного проекта. Кроме экономических потерь, это снижает скорость обмена знаниями, производительность команды и уровень вовлеченности сотрудников. Разумеется, о том, чтобы команда сидела вместе не может быть и речи.

2. Проектные ограничения «тормозят» компанию

Проблемы не заканчиваются и после запуска проекта. Настоящие потребности бизнеса и планы проекта быстро меняются, но не проекты — их бюджет и персонал утверждены и не подлежат изменениям.

Проектное финансирование подавляет возможность адаптации в соответствии с изменениями.

В результате организация не имеет возможности внести изменения, которые бы соответствовали потребностям бизнеса, без дополнительных издержек и перераспределения персонала. Издержки накладываются, а экономика предприятия страдает. Стоимость задержки (цена, связанная с неисполнением ожидаемых результатов вовремя) возрастает.

3. Происходят задержки, ситуация усугубляется

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

Выход за рамки учета издержек проекта в SAFe

1. Финансирование Value Streams, а не проектов

Что предлагает нам SAFe взамен? Первый этап — это делегирование ежедневных решений о затратах (и связанных с ними решений о ресурсах) на тех, кто непосредственно создает эти решения. Это реализуется посредством назначения бюджета каждому Value Stream, как показано на рисунке ниже.

Прим. ред. Пояснение сложных терминов SAFe, описывающих организационные подразделения:

• Value Stream, VS – это цепочка действий, которые предприятие использует для создания решения, обеспечивающего непрерывный поток ценности для клиента. Цепочка создания ценности позволяет определить бизнес-цели, организовать команды и целые подразделения, чтобы реализовать конечную ценность для клиента. Это организационное подразделение включает один или несколько менее крупных подразделений — Agile Release Trains.
• Agile Release Train, ART – это долгосрочная команда Agile-команд, которая совместно с заинтересованными лицами разрабатывает и поставляет решения инкрементально и итеративно внутри ограниченного по времени интервала времени. ART позволяет согласовать команды с общей бизнес- и технологической миссией.

Рабочие бюджеты (распределенные траты, персонал и прочие ресурсы) назначены для каждого VS.

• Заинтересованные лица VS, включая Release Train Engineer (RTE) (прим. ред. – лидер и коуч в ART, который отвечает за его процессы, фасилитацию встреч, эскалацию блокеров, помогает в управлении рисками, поставке ценности и непрерывном совершенствовании; грубо говоря, это главный Скрам-мастер на уровне ART всех Скрам-мастеров команд внутри ART) и руководство портфеля программы (Program Portfolio Management) имеют возможность назначить бюджет для тех ресурсов и персонала, которые необходимы для текущего бэклога и дорожной карты.
• Поскольку VSs и реализующие их ARTs являются долгосрочными, то вовлеченные в совместную работу люди сотрудничают в течение длительного времени. Это положительно сказывается на рабочей атмосфере: команда становится сплоченной, происходит обмен знаниями и увеличивается производительность.
• VS сами становятся владельцами ресурсов, поэтому в случае изменений могут быстро адаптироваться к новой ситуации. Участники могут переходить из одной команды в другую, даже из одного ART в другой — без необходимости получения разрешений c уровня выше VS и ART.
• Бюджет при этом остается под контролем. В большинстве случаев затраты на инкремент программы (Program Increment, PI) (прим. ред. – временной интервал, за который ART поставляет инкремент ценности в виде работающих и протестированных программного обеспечения и систем; обычно длится от 8 до 12 недель) фиксированы или легко предсказуемы, поэтому все заинтересованные лица знают об ожидаемых тратах предстоящего периода, вне зависимости от того, над каким функционалом идет работа. В том случае, если разработка функционала занимает больше времени, чем планировалось, это не оказывает влияние на бюджет: такие решения носят локальный характер и не относятся к уровню бюджета или программы, как показано на рисунке.

Фиксированный бюджет на PI. Когда работа занимает больше времени, чем планировалось, ресурсы не перемещаются, а бюджет не претерпевает изменений.

2. Наделение полномочиями органов управления Value Stream

Этап №1 — это огромный шаг вперед. Если оставить бюджет за скобками, то организация по-прежнему должна следить за тем, чтобы VSs создавали действительно нужные продукты. Это является основной причиной для создания проектов. SAFe предоставляет такую возможность, но не через проекты, а посредством полномочий и ответственности менеджмента решений и продуктов. Для обеспечения доступности, вся поступающая работа выполняется, хранится и распределяется в соответствии с приоритетами в решении и в бэклогах программ, как показано на рисунке.

Прозрачное принятие решений относительно рамок на стороне менеджмента решения и продукта.

Рабочие задачи берутся в работу из бэклога в порядке экономических приоритетов WSJF (прим. ред. — Weighted Shortest Job First, способ назначения приоритетов работам, при котором предпочтение дается работам с более короткой длительностью выполнения и более высокой стоимостью задержки), таким образом, чтобы кураторы были уверены в разумности и логичности принятия такого решения, а также в привлечении нужных участников.

3. Предоставление объективных и последовательных подтверждений движения к цели

Принцип SAFe №5: «Вехи определяются только объективной оценкой работы систем» является следующей частью картины. Недостаточно разделить бюджет на части, соответствующие VSs. Все участники процесса должны получать быструю обратную связь о том, куда направляются инвестированные средства. В SAFe для этого предусмотрены демонстрации каждый квартал а, при необходимости, каждые две недели. Участниками являются все заинтересованные лица: заказчики, руководство портфеля программы, представители бизнеса, менеджмент релизов и сами команды. Любой куратор может подключиться к этим демонстрациям, чтобы убедиться в том, что работа идет в правильном направлении и соответствуют потребностям заказчика на каждом этапе. Если это не так, то выделение ресурсов может быть приостановлено.

4. Утверждение инициатив уровня Эпик (Epic)

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

Эпики требуют утверждения.

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

5. Финансовое управление с динамическим бюджетированием

В заключении следует отметить, что в основном VSs обладают самоорганизацией и самоуправлением, однако они не создаются автономно и не могут осуществлять собственное финансирование. Именно поэтому руководство портфеля программы уполномочено устанавливать и изменять бюджеты потоков добавленной стоимости в рамках портфеля. Чтобы соответствовать изменениям, финансирование будет корректироваться с течением времени — в зависимости от динамики бизнеса, как показано на рисунке.

Бюджеты VS со временем динамически корректируются.

Как правило, бюджеты могут корректироваться два раза в год. Если корректировка происходит реже, то расходы устанавливаются на слишком долгий промежуток времени, что ограничивает гибкость. Если корректировка происходит чаще, то предприятие может быть весьма гибким, однако персонал будет чувствовать себя неуверенно. Это создает чрезмерную неопределенность и делает невозможным следование даже краткосрочным планам.

Что в итоге?

Традиционный подход выглядит так:

• Основной единицей разработки является проект.
• Люди «идут» к работе, а не работа «идет» к людям.
• Приходится выполнять заведомо неопределенные задачи.

Результат такого подхода:

• Повышенные издержки.
• «Мы» против «них».
• Ниже пропускная способность и производительность.
• Низкая мотивация.

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

5 основных этапов на пути к новому состоянию:

1. Финансирование VS, а не проектов.
2. Выделение полномочий органам управления VS.
3. Предоставление объективных и последовательных подтверждений движения к цели.
4. Утверждение инициатив уровня Эпик.
5. Финансовое управление с динамическим бюджетированием.

В результате:

• Полный контроль общих расходов.
• Нет неожиданностей для бюджета.
• Выше пропускная способность.
• Выше мотивация.

Если вам интересны материалы по трансформации процессов в крупных компаниях, рекомендуем группу Enterprise Agile Russia в Facebook. Будем обсуждать подходы к масштабированию, такие как SAFe и LeSS.