Контракты Agile: как заключать договора в условиях расползания содержания

25.09.18

Управление проектом - Agile

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

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

Краткое содержание предыдущих серий на ту же тему можно посмотреть вот здесь:  Что такое Agile mindset или, говоря по-русски, пронырливый образ мысли

 

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

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

Аксиома №1. Agile-подходы рекомендуются, в первую очередь для тех проектов, которые слишком сложны и размыты, чтобы их можно было реализовать при помощи «классических» подходов к проектному управлению. Если мы можем четко собрать требования на старте – то Agile городить, собственно, незачем, «водопад» дешевле и проще.

Аксиома №2. Чтобы Agile заработал, должна сложиться атмосфера сотрудничества, добропорядочности и взаимного доверия между заказчиком и исполнителем. Для создания подобной атмосферы требуются встречи, предпроекты, позитивный опыт сотрудничества. И получается, увы, не всегда. Если такой атмосферы нет, то Agile точно не взлетит. 

Аксиома №3. Agile редко предлагает самое дешевое решение. Но чаще всего предлагает решение, наиболее гибко подстраивающееся под запросы клиента. И позволяет получать результат в тех условиях, в которых более традиционные методологии часто вообще не работают.


Итак, варианты контрактов.

Перевернутый треугольник – Inverted triangle 

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

Agile, как не трудно догадаться, переворачивает все с ног на голову.

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

А где гарантии у заказчика? Вдруг мы вообще ничего не сделаем, а деньги и время потратим. Гарантии у заказчика при Agile, на самом деле, еще выше, чем при водопаде. Потому что исполнители регулярно выдают, в идеале, работающие инкременты, в худшем случае –работающие прототипы, и заказчик может «потрогать» и опробовать результаты работ. И еще раз, см. аксиому №2 – у нас должно быть налажено сотрудничество. Мы начинаем с установления базового доверия, и только после этого предлагаем варианты контрактов.

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

 

«Деньги за просто так и ваши изменения бесплатно» (Джефф Сазерленд)

Ваши изменения бесплатно

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

Комментарий: На всякий случай предупреждаю: если вы работаете по 44 ФЗ, то изменения в контракт после того, как тендер уже проведен, не могут превышать 10%. Считается, что иначе вы ущемляете права участников конкурса, которые его проиграли. Но, во-первых, не все работают по 44 ФЗ (к счастью), 10% – это тоже много, и вообще, дьявол в деталях. Это я просто предупреждаю. 

Деньги за просто такКак используются фичи

А где же здесь Деньги за просто так? А вот они. Исполнитель, не будь дурак, читал про принцип Паретто, что 20% усилий приносят 80% результата. А возможно, читал и исследование, которое говорит о том, что примерно половина фич в программном обеспечении вообще никогда не используется (кстати, некоторые из руководителей проектов внедрения Инфостарта оценивают число неиспользуемых фич не в 45%, а во все 60%). В общем, через несколько итераций (а мы помним, что в Agile мы стремимся делать небольшие релизы), заказчик решает, что имеющегося функционала ему достаточно для счастья. Так вот, по принципу «Деньги за просто так», заказчик имеет право в любое время необоснованно прекратить работы по контракту. При этом он оплачивает уже выполненные работы и заранее оговоренную неустойку (например, 10-20% от невыполненных работ) исполнителю в качестве компенсации. 

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

Пакеты работ с фиксированной ценой

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

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

 

Контракты по опыту российских Agile-практиков

Дабы расширить свой опыт за счет коллег (и заодно добавить еще один аргумент тем, кто «не верит, что так бывает»), я провела небольшой опрос в сообществе Agile Russia – кто и какие контракты применяет при работе с внешними заказчиками.

Ответы были следующие:

 


Если вкратце, вот что ставят во главу угла отечественные Agile-внедренцы:

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


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


Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах 

См. также

Agile Бесплатно (free)

В статье рассмотрены практики, применяемые при разработке по методологии Agile.

13.05.2024    3554    0    Dimbayyyy    9    

11

Лидерство Личная эффективность Agile Анализ потребностей и поиск решений Бесплатно (free)

В семнадцатом выпуске второго сезона подкаста Радио “Аналитик“ обсудили, что из себя представляет модель Кеневин, чем и в каких ситуациях она может быть полезна тем, кто работает в сфере ИТ и не только.

19.04.2024    591    0    Radio_Analyst    0    

5

Agile Бесплатно (free)

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

28.07.2023    2527    0    olegminkov    4    

7

Agile Руководитель проекта Россия Бесплатно (free)

Продукт команды №7, 6 поток (курс Марии Темчиной «Управление ИТ-проектами. Agile. Практический курс Agile-лидера»)

13.06.2023    1499    8    dimbasbear    1    

2

Agile Бесплатно (free)

На конференции Infostart Event 2021 Post-Apocalypse выступил директор практики БИТ:ERP компании Первый БИТ Глеб Стальной. В ходе доклада он рассмотрел трансформацию проектного подхода в продуктовый, рассказал про имплементацию «современных» практик DevOps и продемонстрировал инструменты для разработки, взаимодействия с бизнесом и клиентами, применяемые в его команде.

27.02.2023    2562    0    glebushka    2    

14

Agile Бизнес-аналитик Руководитель проекта Бесплатно (free)

Это один из вопросов, которые мне задают довольно часто. Ну да, Эджайл, Скрам, технологии, методологии,  красивые слова. Но где вы видели это в реальности в 1С внедрениях????

06.12.2021    4323    0    MariaTemchina    49    

13

Agile Бесплатно (free)

Есть сообщество в Facebook'е и Инстаграм, которое публикует жизненные комиксы про внедрение гибких технологий на практике - Comic Agile.

01.04.2021    3876    0    MariaTemchina    18    

16

Agile Руководитель проекта Бесплатно (free)

Коллеги, приглашаем поучаствовать в опросе - Agile в проектах внедрения 1С: реально работает или это миф? Интересен практический опыт!..

12.03.2021    8482    0    MariaTemchina    86    

27
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. vaskomain 26.09.18 14:41 Сейчас в теме
Замечательная статья, но немного из своей практики agile в 1С с 2009 года - касательно аксиом:
1. "водопад" дешевле и проще - ограничение данной аксиомы: водопад дешевле и проще, если вы раньше не работали с agile. Когда большой опыт работы по agile, думаешь зачем вообще нужен водопад? Не могу найти случаев, когда он был бы полезнее в принципе. Когда очень большой опыт, понимаешь, что водопад - это просто-напросто одна слишком большая итерация, а по сути agile - это по факту ускоренный водопад.
2. Атмосфера сотрудничества - при отсутствии атмосферы сотрудничества, не взлетит и водопад. Но agile при отсутствии атмосферы сотрудничества лучше - 1) вы раньше уйдете с проекта, и займетесь чем-то полезным другим. 2) Снижается риск того, что заказчик не заплатит по итогу проекта (это уже видно по результату первых спринтов в agile) 3) С психологической точки зрения если в самом начале видишь проблемы и прерываешь работу, нет выгорания участников проекта, чем когда один большой водопадный проект, в ходе которого проблемы растут большим комом и сотрудники начинают демотивироваться
3. Agile редко предлагает самое дешевое решение. Вот за что люблю agile, так за экономию бюджета (часто). Когда показываешь заказчику, что за счет гибкости сделали 70% функций от бюджета, и все собственно говоря уже летает (early delivery), то он говорит, а нафига нам еще 30% низкоприоритетных? Мы и без них обойдемся. С другой стороны, если в ходе первых спринтов выясняется, что прогноз из-за меняющихся требований оказывается в разы больше, можно раньше остановить проект из-за снижения ожидаемой отдачи и сэкономить деньги на этом
AlenaR; RustIG; crtru; glebushka; Krio2; Alexsur; Vladimir Litvinenko; MariaTemchina; +8 Ответить
4. MariaTemchina 1620 03.10.18 21:20 Сейчас в теме
(1) Спасибо за комментарий, очень конструктивно и по делу. Наконец, дошли руки ответить

1. "водопад" дешевле и проще - ограничение данной аксиомы: водопад дешевле и проще, если вы раньше не работали с agile.

Соглашусь с вами, что, возможно, я зря написала здесь слово "аксиома". Ибо у каждого проекта и у каждой команды своя история. Что я имела в виду? Agile часто предполагает переделки уже сделанного, более внимательное вникание в детали и т. п. По моему опыту, как раз водопад позволяет нередко довольно дешевое решение получить... Но, увы, не всегда подходящее...

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

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

2. Атмосфера сотрудничества - при отсутствии атмосферы сотрудничества, не взлетит и водопад.

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


3. Agile редко предлагает самое дешевое решение. Вот за что люблю agile, так за экономию бюджета (часто).

Повторюсь, у каждого своя история. В моей практике специалисты, готовые работать по Agile часто оказываются дороже, например.
2. acanta 26.09.18 16:39 Сейчас в теме
Agile - это либо тянуть кота за хвост по наименьшей цене либо постоянно и непрерывно разрабатывать достаточно большие блоки автоматизации.
Проблема в величине блока, который имеет смысл автоматизировать для конкретного разработчика.
Там, где Agile может создавать какую-то иллюзию внедрения, водопад - это просто первоапрельский розыгрыш.
5. MariaTemchina 1620 03.10.18 21:24 Сейчас в теме
(2)
Проблема в величине блока, который имеет смысл автоматизировать для конкретного разработчика.

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

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

А можно и по-другому сказать. Там, где водопад в принципе невозможен, потому что требования крайне размыты и методы технической реализации вообще не понятны, Agile может дать возможность получить [хоть какой-то] результат.
3. Valerych 26.09.18 17:48 Сейчас в теме
В качестве дополнения.

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

И вот на полях кастомизации Agile резко повышает свои шансы на применимость.
В какой-то мере (а иногда и добрых 100%) старая добрая почасовка по кастомизации еще времен 1С 77 есть прямое воплощение Agile.
Конечно, при почасовке хватало do&fix (тяп-ляп), может в абсолютном выражении даже в большинстве случаев.
Но совсем нередко обычная почасовка приносила успех, очаровывала клиентов, давала результат как раз тем, что мы вдохновенно читаем в манифесте принципов Agile.
Тут тебе и сотрудничество и взаимодействие и работающий продукт и готовность к изменениям, и было же немало случаев, когда все это выполнялось сходя из принципа "не отрицая важности того, что справа", т.е. оставляя задокументированные результаты, выстроив процессы внедрения по схеме почасовки и т.п.

В такой почасовке рождались примеры применимости гибких методов даже для случая "безжалостной" кастомизации (это когда типовая медленно становилась мини-отраслевым решением).

Но почасовка не обязательна, любое послепроектное сопровождение и развитие системы вполне может быть организовано в соответствии с принципами Agile, разве что перед Заказчиком возникнет задача реинжиниринга таких мастшабов, что придется вспоминать старый добрый водопад+прототипы.
RustIG; dunpil; MariaTemchina; +3 1 Ответить
6. MariaTemchina 1620 03.10.18 21:28 Сейчас в теме
(3) Да, Valerych, согласна с вами - действительно, принципы давно применялись толковыми командами и до появления Agile манифеста. Плюс Agile в том, что интуитивные находки превратились в используемую и тиражируемую технологию.

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


Проекты внедрения иногда тоже можно делать по Agile. Вопрос, действительно, в том числе в масштабах бедствия.
7. FB_1811930315551820 10.10.18 15:57 Сейчас в теме
А еще у Agile есть одна интересная ниша - спасательного круга для проектов, утонувших в классическом водопаде. Когда после мучительной агонии большого проекта у заказчика остаются обломки в виде недопиленных (и плохо документированных) кастомных модулей, покрывающих какую-то часть бизнес-процессов, недообученных пользователей и скептически настроенного руководства, а глобальные планы "МЫ АВТОМАТИЗИРУЕМ ВАМ ВСЕ" со сроком исполнения 6-12 месяцев отвергаются прямо с порога. Вот в такой обстановке Agile заходит "на ура", потому что первые (пусть и скромные) результаты можно увидеть уже через месяц.
RustIG; Valerych; crtru; +3 Ответить
8. MariaTemchina 1620 10.10.18 15:59 Сейчас в теме
Да, соглашусь! Вообще, неоднократно сталкивалась с точкой зрения, что "первая команда", пришедшая автоматизировать, часто терпит крах, а "вторая команда", пришедшая исправлять недоделанное - часто гораздо успешнее.

Метафору "проекты, утонувшие в водопаде" с вашего позволения возьму на вооружение
9. FB_1811930315551820 11.10.18 15:29 Сейчас в теме
(8) С тем, что "спасатели" чаще более успешны, чем "первопроходцы" - соглашусь. Но причина, имхо, не столько в разнице между командами, сколько в разнице субъектов "Заказчик ДО краха первого проекта" и "Заказчик ПОСЛЕ". Во втором случае резко снижается административный апломб ("Я всегда прав, по определению"), формальность подхода к сотрудничеству ("Вы же специалисты - вот и сделайте мне конфетку из того, что есть"), и так же резко повышается ответственность при выполнении своей части работы ("Еще одного провала моя карьера точно не выдержит"), и готовность прислушиваться к рекомендациям этих самых специалистов ("В прошлый раз мы уже попробовали реализовать ВСЕ наши хотелки, не особо вникая, о чем нас там предупреждает Исполнитель")...
А метафорой - пользуйтесь на здоровье, конечно. У меня их еще много ))
RustIG; Valerych; MariaTemchina; +3 Ответить
10. RustIG 1720 14.08.19 15:57 Сейчас в теме
(0) контракты по классической схеме и по гибким методологиям подразумевают знание программного продукта - и там, и там надо оценивать объем работ и трудоемкость каждой задачи, каждого функционального блока. Если программный продукт новый для Исполнителя для внедрения, то оценить объем работ и трудоемкость будет невозможно при любых методологиях. так ведь?
а без этого понимания рамочный договор нельзя будет составить... получается, что чем больше внедренец и разработчик знает программный продукт, тем легче оценить объем работ и трудоемкость задач.
Оставьте свое сообщение