В этой статье я продолжаю развивать тему практической применимости 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-внедренцы:
- Важно установить хороший контакт с заказчиком, чтобы он захотел сотрудничать. Тогда появляется шанс договориться про удобную форму контракта.
- На старте, чаще всего, заключаются рамочные соглашения, и дальше уже доп. соглашениями уточняем условия.
- Удобно, когда проект внедрения спокойно перетекает в сопровождение на абонентской плате – в такой ситуации исчерпывающий сбор БФТ на старте перестает быть критичным: в случае необходимости, доделается в процессе, главное –понять архитектуру.
В комментариях интересно услышать, в первую очередь, не сожаления, почему это невозможно, а размышления, что из этих подходов можно использовать на практике. Ну, и дополнения из вашего опыта – что еще я забыла упомянуть.
Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах
