Agile Контракты

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

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

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

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

Традиционные подходы к контрактам на разработку и закупку систем

Покупатели часто передают разработку сложных систем на аутсорсинг поставщикам, которые могут создавать системы, необходимые для ведения их бизнеса. Существует целый ряд подходов к заключению контрактов, от договоров с фиксированными ценами до контрактов с оплатой стоимости рабочего времени и материалов (Time & Material), с прописанными шагами внутри контракта. Рисунок 1 демонстрирует различные подходы к контрактованию и показывает, как стороны разделяют риск в каждом из них.

Рисунок 1. Варианты традиционных контрактов

Контракты с фиксированной ценой (Firm Fixed-Price Contracts)

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

Рисунок 2. Контракты с фиксированной ценой создают «железный треугольник»

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

Однако у этого подхода есть много недостатков:

• Он предполагает, что потребности покупателя полностью понятны для исполнителя до начала реализации.
• Потребности покупателя должны фиксироваться на раннем этапе в требованиях, спецификациях и деталях дизайна. Это запускает традиционный подход к разработке, требующий масштабного детального проектирования до ее начала (Big Design Up-front, BDUF). Это также подразумевает соответствующие контракты.
• Контракт, как правило, выигрывает участник с наименьшими издержками, который может не обеспечить оптимальную долгосрочную экономическую ценность для покупателя.

Более того, чтобы получить фиксированные цены, важные решения принимаются слишком рано, когда еще мало известно о решении (см. Принцип #3 – Принимать вариативность; сохранять опциональность). Стороны вступают в «железный треугольник» фиксированного объема, графика и стоимости, как показано на рисунке 2. При появлении изменений и новых данных руки покупателя и поставщика оказываются связаны контрактом, в котором уже зафиксировано то, что с учетом новых данных уже никто не хочет разрабатывать или покупать именно в том виде, как было заявлено в самом начале, при написании требований и подписании контракта. Большая часть времени тратится на переговоры об изменениях в контракте, что приводит к значительным потерям.

Хуже всего то, что после заключения договора у каждой стороны возникают противоположные друг от друга экономические интересы:

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

В конечном итоге, этот тип контракта устанавливает сценарий «победил-проиграл» (win-lose), который затем влияет на все деловые отношения между заказчиком и исполнителем, как правило, в ущерб обеим сторонам.

Контракты с оплатой стоимости рабочего времени и материалов (Time and Materials Contracts)

Понятно, почему многие хотели бы в подходах к заключению контрактов сместиться по шкале вправо (рисунок 1). Однако соглашения о времени и материалах, которые хоть и расположены в правой части шкалы и на первый взгляд могут показаться очень гибкими, также имеют свои недостатки. При таком варианте заключения контракта покупателю остается рассчитывать только на доверие. Доверие является важным элементом, на который полагается Бережливое производство. Но недопонимание, изменения на рынке или в технических условиях, а также изменения в экономических моделях покупателя или поставщика могут заставить доверие отойти на второй план. В конце концов, поставщик заинтересован получать оплату как можно дольше. Это может привести к затягиванию сроков выполнения контракта со стороны поставщика. Сочетание этого подхода с использованием фазовых ворот, при которых реальный прогресс может быть известен только в конце, усугубляет проблему.

Проблемы могут существовать и на стороне покупателя. Например, во время интервью по завершению проекта Стивен У. Уоррен, исполнительный директор и директор по информационным технологиям управления по делам бывших военнослужащих, отметил, что, по словам руководителя проекта, «проект никогда не был в кризисе, поскольку каждый год они тратили весь бюджет и, таким образом, могли возобновить свое финансирование на следующий год. Индикатором успеха в то время было то, будет ли проект продолжать получать финансирование, а не то, сможет ли он доставить необходимую функциональность [1].»

Равновесный совместный подход к Agile контрактам

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

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

Характеристики такого Agile контракта:

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

Инвестиционный контракт SAFe (SAFe Managed-Investment Contracts)

Организации выиграют при переходе на Agile контракты, при которых экономика помогает как покупателю, так и поставщику. Инвестиционный контракт SAFe является одним из вариантов заключения Agile контрактов. Далее в статье мы более подробно познакомимся с этим подходом.

Предварительные обязательства

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

Рисунок 3. Этап подготовки к принятию обязательств по инвестиционному контракту SAFe

На стадии предварительных обязательств заказчик несет определенные обязанности, включая понимание основных концепций и обязательств Agile контракта, а также определение и доведение до сведения потенциального поставщика (поставщиков) более полного заявления о миссии программы.

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

Общие обязанности, показанные на рисунке 3, побуждают заказчика и поставщика к более взвешенным инвестициям, подкрепленным постоянными объективными доказательствами пригодности решения к использованию.

Эти обязанности включают в себя:

• Разработка первоначального видения и дорожной карты решения
• Идентификация минимального жизнеспособного продукта (MVP) и дополнительных фич
• Определение исходного фиксированного и переменного Интента (Намерения) Решения (Solution Intent)
• Приоритизация исходного беклога Релизного Поезда (Agile Release Train, ART) для PI Планирования
• Установление обязанностей по выполнению запланированных работ
• Создание экономических рамок, включая параметры экономического компромисса, обязательство по финансированию Интервала Планирования (количество Интервалов Планирования с гарантированным финансированием), начальные уровни финансирования и другие договорные условия

Иногда поставщику может потребоваться предоставить предварительную оценку, чтобы заручиться обязательством по финансированию Интервала Планирования по завершении. В других случаях может подойти подход «с оплатой по мере использования» (pay-as-you-go). Исходя из условий контракта, Заказчик соглашается финансировать поставщика на первых Интервалах Планирования. Это первоначальный период, на который формируются обязательства. Продолжительность зависит от контекста, но два Интервала Планирования (приблизительно 20 недель) могут быть разумной отправной точкой для начала сотрудничества.

В зависимости от контекста Заказчик может рассматривать сотрудничество с несколькими потенциальными поставщиками. Особенно, если существует потребность проверить техническую возможность реализации, это может быть сделано с помощью какого-либо контракта на проверку выполнимости реализации (feasibility contract). В рамках такой модели каждый из потенциальных поставщиков может получать оплату за свои усилия по проверке возможности достижения какого-либо результата. Также поставщики могут рассматривать подобные активности как инвестиции в рамках своего цикла продаж.

Исполнение контракта

После заключения контракта начинается разработка, как показано на рисунке 4.

Рисунок 4. Фаза исполнения инвестиционного контракта SAFe

Ниже приведен план-график выполнения работ:

• Подготовка к Интервалу Планирования – И поставщик, и заказчик потратят время и усилия на подготовку контента и логистики для первой сессии PI планирования. (Примечание: в некоторых случаях может быть целесообразно, чтобы первое PI планирование было частью этапа предварительных обязательств, хотя этот вариант требует значительных инвестиций с обеих сторон.)
• PI Планирование – Первое мероприятие «PI Планирование» влияет на всю программу. Именно здесь заинтересованные лица заказчика и поставщика планируют первый Интервал Планирования с указанием деталей на уровне итераций.
• Выполнение Интервала Планирования – В зависимости от контекста клиенты по-разному участвуют в выполнении итераций. Однако, как минимум, каждая Демонстрация Системы требует непосредственного взаимодействия с клиентом. При этом для больших решений Демонстрации Системы могут быть заменены Демонстрацией Решения с интегрированными компонентами продукта, которая может происходить чаще, чем на границах PI.
• Оценка Интервала Планирования – Каждый Интервал Планирования (PI) является важной вехой для заказчика и поставщика. Каждый Интервал Планирования проводится демонстрация решения, и решение оценивается. Согласованные метрики транслируются и анализируются, а также принимаются решения по следующим Интервалам Планирования. На мероприятии «Инспект-Адапт» (Inspect & Adapt, I&A) оценивается прогресс в разработке решения и улучшениях работы Релизного Поезда. На этом этапе клиент может принять решение об увеличении, уменьшении или сохранении уровня финансирования или сворачивании инициативы в зависимости от того, была ли достигнута достаточная ценность. После этого начинается следующее планирование PI, объем которого определяется в зависимости от результатов этого решения.

Управление рисками с помощью подхода Бережливого Стартапа (Lean Startup)

SAFe Цикл Бережливого Стартапа (SAFe Lean Startup Cycle), показанный на рисунке 5, также используется для иллюстрации того, как организации управляют значительными инвестициями в разработку продукта с помощью устойчивой Бережливой экономики.

Рисунок 5. Цикл Бережливого Стартапа для управления значительными инвестициями в разработку продукта

SAFe Цикл Бережливого Стартапа сокращает время выхода на рынок и помогает предотвратить раздувание системы ненужными функциями, которые, возможно, никогда не будут использоваться. Lean Startup также обеспечивает соблюдение цикла «построение гипотезы-разработка-измерение-обучение».

Из этого можно сделать вывод, что язык Agile контрактов модифицируется, чтобы отразить комбинацию фиксированных и переменных компонентов. MVP, определенный на этапе предварительных обязательств, может установить высокоуровневое определение фиксированного объема компонентов, который должен быть доставлен в рамках предлагаемого количества Интервалов Планирования. Помимо доставки MVP, в контракте также может быть указано количество опционных периодов, состоящих из одного или нескольких Интервалов Планирования (PI). Цель состоит в том, чтобы оптимизировать доставку приоритетных фич в каждом PI.

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

• Лучшая предсказуемость оценок, связанных с реализацией небольшого MVP по сравнению с выполнением полного списка всех требований
• Полный контроль над расходами, необходимыми для дополнительных фич, разрабатываемых инкрементально, на основе экономических результатов

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

Статья подготовлена по материалам Scaled Agile, Inc. и не является официальным переводом статьи «Agile Contracts».