Не так давно переделывала у себя всю схему контрактования так, чтобы проекты, которые идут по Agile, можно было запускать быстрее, попробую в этом посте собрать всю информацию.
Итак, если разложить все известные мне схемы контрактования по единой шкале, то получится следующее:
Давайте кратко пройдем по каждому варианту:
- Fixed Price (фиксированная стоимость) – самый безопасный вариант для заказчика, фиксированная цена, фиксированный объем, фиксированные сроки. Получить что-то сверх спецификации не выйдет, поменять в процессе разработки – тоже (ну или сильно задержит работы). Agile тут не может существовать как класс. Подходит, когда все понятно, вероятность изменений предельно мала (такое бывает?) и подрядчика мы пока не знаем или по какой-то причине ему не доверяем.
- Fixed Price MVP + TM next stages (фиксированная стоимость до получения минимально жизнеспособного продукта, и дальше time&material для последующих стадий разработки) – делаем первую версию продукта по той же фиксированной стоимости с условиями из п.1. Если в ходе разработки MVP подрядчик себя достойно зарекомендовал и мы стали друзьями, дальше может быть и Agile c time&material и прочими приятными вещами.
- Fixed Budget (фиксированный бюджет) – предполагает наличие некоего видения продукта и основной функциональности, и фиксированного количества денег, которые можно на этот продукт потратить. А дальше владелец продукта уже вместе с подрядчиком определяют конкретный функционал, который можно сделать за эти деньги.
- Team Per Sprint / $ per Story Points (Команда на спринт / $ за сторипоинты) – вообще это две разные схемы, но я их объединила в одну, так как ни разу вторую в работе не видела (только слышала, что кто-то использует, среди моих знакомых таких нет в силу того, что единое понимание сторипоинта у заказчика и подрядчика – это очень большая редкость). По факту это выкуп команды или “мощностей” подрядчика в определенном объеме. Если в предыдущих схемах за результат ответственность нес подрядчик, то тут она начинает плавно перемещаться на сторону заказчика, это как раз середина шкалы. То есть за качество команды и ее совместную работу все еще отвечает подрядчик, а за постановку задач – уже заказчик.
- Cost+ (Outstaffing) (Аутстаффинг) – не совсем законно в России, но все используют. Выкуп уже не команды или объемов, а конкретных людей, которые работают на ваш проект. Их мотивация, постановка задач и т.д. теперь полностью в ведении заказчика, фактически это почти сотрудники в штате. Из практики – в штате люди все равно себя не чувствуют, выстроить правильные отношения в такой команде обычно очень сложно, но можно.
- T&M with Cap (time&material с “кепкой” или с верхним ограничением) – оплата подрядчику за время (ну или время + потраченные материалы, но это редкость) по часам или по дням с верхним ограничением бюджета. Надо очень сильно доверять подрядчику и понимать его способности и способности его людей, чтобы работать по этой схеме, но в случае если звезды сошлись – эффективность разработки продукта растет в разы.
- T&M (time&material) – редкость на рынке, мало кто все-таки тратит деньги совсем без ограничения. У меня на одном очень крупном проекте такой опыт был, и не очень позитивный, так как в процессе выяснилось, что мы с подрядчиком на берегу не договорились о большом количестве нюансов типа простоев команды и проч., что выливалось в неэффективно потраченные деньги. Единственное, что меня извиняет, наверное – это то, что это было почти 10 лет назад, в самом начале моей карьеры как РМа.
В реальности этих схем, конечно, намного больше, но я оставила только те, которые плюс-минус применяются в России.
Кому-то, кто работает по ФЗ-44 или ФЗ-223 (государственные закупки), конечно, заключить любой контракт, по которому можно будет работать по Agile, намного сложнее (хорошо, что это не я). По опыту знакомых, вариант только один – заключаться по Fixed Price с тем подрядчиком которому ты доверяешь, писать очень размытую спецификацию, под которую потом можно будет подтащить все, что угодно, и внутри этого Fixed Price делать time&material по ставкам подрядчика. Тогда можно и с ФЗ хороший продукт сделать.
А какие вы схемы Agile-контрактов используете, какие плюсы и минусы видите? Расскажите!
Добавить комментарий