Управление проектами.РУ

Управление проектами.РУ
Сообщество тех, кто умеет или хочет научиться
хорошо управлять проектами
23 апреля 2019 Все для начинающего РМа
260 0

Про Agile контракты

Юлия Бажанова
Редактор проекта, РМР, РМЕ, PRIME

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

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

Давайте кратко пройдем по каждому варианту:

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

В реальности этих схем, конечно, намного больше, но я оставила только те, которые плюс-минус применяются в России.

Кому-то, кто работает по ФЗ-44 или ФЗ-223 (государственные закупки), конечно, заключить любой контракт, по которому можно будет работать по Agile, намного сложнее (хорошо, что это не я). По опыту знакомых, вариант только один – заключаться по Fixed Price с тем подрядчиком которому ты доверяешь, писать очень размытую спецификацию, под которую потом можно будет подтащить все, что угодно, и внутри этого Fixed Price делать time&material по ставкам подрядчика. Тогда можно и с ФЗ хороший продукт сделать.

А какие вы схемы Agile-контрактов используете, какие плюсы и минусы видите? Расскажите!

комментарии

Добавить комментарий

Такой e-mail уже зарегистрирован. Воспользуйтесь формой входа или введите другой.

Вы ввели некорректные логин или пароль

Sorry that something went wrong, repeat again!

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: