Какими должны быть контракты в Agile

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

…выберите перспективного поставщика и ждите, что он поставит продукт в соответствии с требованиями, согласованными сроками и бюджетом. Однако, этот традиционный подход почти всегда ведет к провалам, за каждым из которых — весьма эффектное прожигание денег налогоплательщиков.
— Jason Bloomberg, Forbes, Fixing Scheduling with Agile at the VA

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

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

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

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

И что действительно было нужно, так это более гибкий (Agile) подход к контрактам, в котором обе стороны получают выгоду как в ближайшей, так и в долгосрочной перспективе.

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

Крупные компании используют несколько подходов в работе со сторонними вендорами, у которых они заказывают сложное программное обеспечение. Обычно эти подходы варьируются между «жестко фиксированным бюджетом» (Fixed Price) и «оплатой по факту» (Time & Material), а также вариациями, находящимися между этими крайностями. Рисунок ниже описывает эти подходы, а также критерии, по которым риски в них делятся между сторонами.

Подходы в работе со сторонними вендорами

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

Контракты с жёстко фиксированным бюджетом

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

Контракты с жёстко фиксированным бюджетом создают «железный треугольник»

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

Однако этот подход имеет также и обратные стороны:

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

Кроме того, чтобы получить фиксированную цену, многие критичные решения принимаются, когда проект ещё находится на раннем этапе в конусе неопределённости (см. принцип №3 SAFe: «Предполагайте изменчивость, сохраняйте возможности»).

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

Но хуже всего то, что в момент подписания такого контракта экономические интересы сторон становятся противоположными:

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

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

Контракты с оплатой по факту

Понятно, почему многие в индустрии хотят двигаться в правую сторону спектра. Но правая граница, представляющая «оплату по факту», которая с первого взгляда может показаться исключительно гибкой и соответствующей методологии Agile, тоже таит в себе сложности. Клиент в данном случае может рассчитывать только на своё собственное доверие. Доверие, безусловно, очень ценно, и мы опираемся на него в методологии бережливой разработки (Lean), но в моменты недопонимания между сторонами, изменений на рынке или технических условий, а также экономических моделей у клиента или поставщика доверие могут отодвинуть на задний план.

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

Сложности могут возникнуть и на стороне заказчика. Например, в ходе разбора полетов по результатам провального проекта Стивен В. Уоррен (Stephen W. Warren), ответственный исполнитель и директор по ИТ в департаменте по делам ветеранов США, отметил, что, по словам руководителя проекта, проект никогда не был в кризисе, так как каждый год они полностью расходовали свой бюджет, что позволяло им сохранять финансирование на следующий год. Критерием успешности для них было то, будут ли они продолжать получать финансирование, а не то, будут ли они способны поставить требуемый функционал.

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

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

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

Такой тип Agile-контракта потенциально позволяет:

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

Контракт с управляемыми инвестициями на основе подхода SAFe

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

Предварительные соглашения

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

Фаза предварительных соглашений для контракта с управляемыми инвестициями на основе подхода SAFe

Прим. ред. Program Increment, PI или инкремент программы — это временной интервал, за который программа поставляет инкремент ценности в виде работающих и протестированных программного обеспечения и систем. Обычно длится от 8 до 12 недель.

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

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

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

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

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

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

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

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

Далее начинается непосредственно разработка, как описано на рисунке ниже.

Исполнение контракта с управляемыми инвестициями по основе подхода SAFe

Описание активностей на каждом из этапов:

• Подготовка к PI 1. Клиент и поставщик совместно прорабатывают содержание и логистику первой встречи по планированию инкремента программы (примечание: в некоторых случаях бывает удобно включать планирование PI 1 в фазу предварительных соглашений, несмотря на то, что это потребует от сторон существенных инвестиций).
• Планирование PI 1. Планирование первого инкремента программы является основополагающим событием для всей программы. В рамках этой сессии ключевые участники со стороны клиента и поставщика планируют первый инкремент на уровне итераций. Подробнее про то, как проходит эта сессия, см. в статье «PI-планирование в SAFe».
• Исполнение PI 1. В зависимости от контекста представители клиента участвуют на разных уровнях проведения итерации; как минимум непосредственное присутствие клиента требуется на каждой системной демонстрации (System Demo). Однако для больших рабочих процессов (Value Streams) множественные системные демонстрации могут быть заменены на демонстрации решения (Solution Demo), которые глубже интегрированы в процесс и могут проводиться чаще, чем по результатам PI.
• Оценка PI. С этого момента завершение каждого инкремента программы означает ключевой этап проекта как для клиента, так и для поставщика. На каждом из этих этапов проводится демонстрация, а также комплексная оценка решения. Собираются и анализируются согласованные метрики проекта, а также принимается решение о следующих инкрементах программы. Все это происходит во время обязательной в конце каждого PI сессии инспекции и адаптации, чтобы осознать прогресс и спланировать улучшения на предстоящий инкремент. В этот момент клиент может решить сохранить финансирование на текущем уровне, увеличить его, уменьшить или даже начать его сворачивать в зависимости от того, была ли достигнута требуемая ценность продукта. После этого стартует планирование следующего инкремента, и входными данными для него являются результаты и решения, принятые по итогам оценки предыдущего. Подробнее про финансовое управление с динамическим бюджетированием см. в статье «Бюджетирование в SAFe».

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