10 типов аджайл-контрактов

Источник: https://www.agilesoftwaredevelopment.com/posts/10-agile-contracts/

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

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

  • Какая структура контракта?
  • Как контракт справляется с изменениями объема (требований)?
  • Как он распределяет риски и вознаграждение между заказчиком и исполнителем?
  • Какую модель взаимоотношений с клиентами он развивает?Конкурентную (моя победа — это ваш проигрыш), сотрудничество (мы все выиграли), безразличная (мне все равно, выигрываете вы или проигрываете) или зависимая (либо я выигрываю, либо вы проигрываете).

Предлагаю рассмотреть ряд возможных контрактов и посмотрим, как они работают с проектами разработки в парадигме Аджайла и Скрама:

  • «Контракт на спринт»
  • Фиксированная цена / фиксированный объем
  • Время и материалы
  • Время и материалы с фиксированным объемом и потолком затрат
  • Время и материалы с переменным объемом и потолком затрат
  • Поэтапное развитие
  • Положения о бонусах / штрафах
  • Фиксированная прибыль
  • «Деньги даром, изменения бесплатно»
  • Совместные предприятия

Контракт на спринт

Работая со скрам-командами, я обнаружил, что метафора «Контракт на спринт» помогает понять (а иногда и укрепить) отношения между владельцем продукта и разработчиками.

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

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

Риск: Скрам-проект можно рассматривать как серию мини-проектов с фиксированными параметрами: время (длина спринта), объем (бэклог спринта), качество (определение готовности, DoD) и стоимость (стоимость команды в день * длительность спринта). Различаться может только объем, который измеряется каждый спринт.

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

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

Фиксированная цена / фиксированный объем

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

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

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

Отношения: могут развиваться от конкурентных к безразличным. Заказчик как правило хочет получить больше, а поставщик — сделать меньше. Исполнитель хочет, чтобы клиент был доволен, поэтому обычно он уступает.

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

Время и материалы (Time&Material)

Структура: Работаем в течение периода (например, месяца), затем отправляем заказчику счет. Исполнителю это нравится, потому что риски лежат на заказчике.

Объем задач: априори не фиксирован. Рано или поздно заказчик перестает платить, и проект подходит к концу.

Риски: 100% несет заказчик. У исполнителя мало стимулов для снижения затрат. Возможно, необходимы будут дополнительные усилия на то, чтобы выставлять счета, которые соответствуют реальным расходам.

Отношения: безразличные. Исполнитель счастлив, когда приходит больше работы, потому что больше работы означает больше денег.

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

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

Объем: То же, что и фиксированная цена, фиксированный объем.

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

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

Время и материалы с переменным объемом и ограничением по затратам сверху

Структура: то же, что и время и материалы, за исключением того, что потолок по затратам ограничивает финансовые риски клиента.

Объем: так же, как и проект с фиксированной ценой и фиксированный объемом.

Риски: бюджет будет исчерпан без достижения необходимой бизнес-ценности для клиента. Клиент не получит всего, о чем просит.

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

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

Разработка этапами

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

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

Риск: риск клиента ограничен квартальными затратами на разработку.

Отношения: сотрудничество. И заказчик, и поставщик заинтересованы в том, чтобы каждый выпуск был успешным, чтобы было одобрено дополнительное финансирование.

Подсказки: венчурные капиталисты часто работают по этой схеме. Это хорошо сочетается с подходом «время и материалы с переменным объемом и ограничением по стоимости сверху». Я довольно успешно работал по этой модели. Мы просто указали цель выпуска, почасовую ставку и потолок затрат в коммерческом контракте. Заказчик предоставил владельца продукта. Все остальное было определено в контрактах спринтов.

Соглашение о бонусах / штрафах

Структура: Поставщик получает бонус, если проект завершается досрочно, и платит штраф, если он приходит с опозданием. Размер бонуса или штрафа зависит от задержки.

Изменения объема: трудно принимать, потому что изменения потенциально могут повлиять на дату доставки, что, безусловно, недопустимо.

Риски: есть ли у клиента стимул для досрочного завершения? Аргументы в пользу рентабельности инвестиций должны быть убедительными и прозрачными. В противном случае заказчик получит более дешевое решение, чем больше времени это займет.

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

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

Фиксированная прибыль

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

Объем фиксирован.

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

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

«Деньги даром, изменения бесплатно»

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

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

Риск: общий. Обе стороны заинтересованы в досрочном завершении проекта. У клиента меньшие затраты, у поставщика более высокая маржа.

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

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

Объем: определен в соответствии с потребностями партнерства.

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

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

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

Контракт «Деньги напрасно, изменения бесплатно» превращает преимущества Скрама и процессов гибкой разработки в конкурентное преимущество.

Посредством установления приоритетов и постепенного увеличения ценности бизнеса вероятность полного отказа резко снижается. Это преимущество передается заказчику.

Кроме того, это модель сотрудничества, поэтому она предлагает обеим сторонам стимулы для снижения затрат.

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

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

Форма контракта закладывает важную основу для успешного проекта. И Аджайл-манифест оказывается прав: работа с заказчиком важнее контракта. Итак, что бы вы ни делали, сохраняйте конструктивные и доверительные отношения с клиентами!

Share

Сертифицированный скрам-мастер, тренер и коуч Сфера интересов: Развитие команд и организаций, тренинги и обучение