Time & Materials или Fixed Price: осознанный выбор контрактной модели

В разработке программного обеспечения на заказ наиболее широко используются две модели оплаты труда: Time and Materials (T&M) и Fixed Price (FP).

Time and Materials
(англ. время и материалы)
предполагает почасовую оплату труда и израсходованных
ресурсов, где стоимость за час фиксирована, а общее количество
часов — нет. Таким образом,
общая стоимость проекта
остается неизвестной до его окончания.

Fixed Price
(англ. фиксированная цена) — это тип контракта, в котором устанавливается фиксированная цена на продукт,
услугу или результат. При этом, оплата
не зависит от фактических ресурсных
и временных затрат подрядчика,
а определяется до начала работ
на основании анализа требований
и технического задания.

Очевиден ли выбор? Интуитивные предпочтения заказчика — на стороне контрактов с фиксированной стоимостью, поскольку это позволяет уменьшить объем неопределенности, в избытке сопровождающей любой ИТ-проект. Кроме того, такой формат взаимоотношений более привычен для российского рынка ввиду низкого уровня доверия к подрядчикам, в то время как T&M чаще используется западными компаниями как наиболее экономичный вариант.

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

FP vs T&M

Как выбор модели определяет проектные приоритеты и распределение рисков между заказчиком и исполнителем

Проектные ресурсы

Соответствие запланированному бюджету
Степень вовлеченности заказчика

Соответствие запланированному бюджету

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

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

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

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

Чтобы контролировать расходы, бюджет может ограничиваться верхней планкой расходов ресурсов (англ. not to exceed (NTE), не превышать). Кроме того, в зависимости от проработанности общего состава работ при оценке дается вилка расходов с нужным процентом вероятности, что позволяет понять примерный итоговый бюджет.

Финансовый риск ложится на заказчика. Если в ходе работ выяснится, что реализация требует дополнительных затрат, то это отразится на итоговом счете. Поэтому для работы по Т&М заказчику требуется большая уверенность в компетентности компании-разработчика: в его умении предвидеть все риски и в точности его оценок.

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

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

Многие компании предоставляют сниженный почасовой рейт при работе по T&M, поскольку финансовые риски берет на себя заказчик.

Time & Materials или Fixed Price: осознанный выбор контрактной модели

Степень вовлеченности заказчика

Минимизация затрат на управленческие задачи. Ресурсное распределение и менеджмент проекта осуществляется на стороне исполнителя.

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

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

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

Скорость реализации

Гибкость планирования поставок
Соблюдение сроков

Гибкость планирования поставок

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

Гибкость подхода позволяет контролировать как скорость работ (размер команды), так и планы на ближайшие поставки в соответствии с приоритетами заказчика.

Соблюдение сроков

Сроки закреплены в договоре.

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

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

Возможен быстрый старт работ.

Качество результата

Востребованность и удобство использования продукта
Управление изменяющимися требованиями
Качество кода

Востребованность и удобство использования продукта

Принятие ключевых решений при дефиците информации. При составлении документации нужно максимально подробно предусмотреть пользовательские требования, возможности масштабирования, развития и прочее. Этот тип контракта лучше всего подходит для проектов с минимальной степенью неопределенности. Если он используется при создании принципиально новых продуктов, то для проверки исходных гипотез сначала выпускается MVP (minimal viable product) — минимально жизнеспособный продукт с самым основным функционалом.

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

Управление изменяющимися требованиями

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

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

Качество кода

Легче ошибиться с выбором подрядчика. Существует риск «зонтичного обобщения»: ошибки, исходящей из ожидания, что все потенциальные подрядчики, предоставивщие вам оценку, оценивали один и тот же состав работ и предусматривали одни и те же риски. На самом деле, это не так. Глубина проработки функционала, точность его оценки относительно скорости исполняющей команды, правильность интерпретации ваших исходных требований, а главное, тщательность проработки рисков — все это напрямую зависит от компетентности подрядчика.

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

Как выбрать?

Что для вас важнее: контроль над процессом
или над итоговым бюджетом?

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

Потребность в инструменте: срочная или планируемая?

Если в отсутствие необходимого программного обеспечения бизнес несет существенные издержки и решение нужно было «еще вчера», то следует предпочесть T&M, потому что такой контракт дает возможность быстрого старта и прогрессивного наращивания функционала. Для FP необходим этап аналитики и многоэтапного описания и утверждения проектной документации, что лучше подходит для проектов с запланированной исследовательской и проектировочной фазой.

Когда принимать решения: до старта разработки или по ходу проекта?

Чем больше неопределенности присутствует в проекте, тем большая гибкость потребуется в его разработке. Если подробных спецификаций еще нет, то нужно либо провести аналитиз требований, проверку реализуемости концепции, и другие необходимые подготовительные работы, либо начать разработку по T&M, уточняя требования по ходу разработки.

2003

2024

Программные технологии /

отзывчивый

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

Мягкова Ирина, руководитель службы управления проектами

Программные технологии /

максимально

Мы обратились в компанию «Программные технологии» с задачей разработать сложную информационно-аналитическую систему для сбора и анализа лесоустроительной информации. Компания «Программные технологии» предоставила нам выделенную команду разработчиков, которые смогли максимально быстро погрузиться в новую для них предметную область и предложили эффективные решения для наших комплексных задач. Сейчас разработанная система успешно проходит опытную эксплуатацию сразу в нескольких филиалах ФГУП «Рослесинфорг».

С. В. Шимов, первый заместитель директора филиала

Программные технологии /

оперативный

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

Евгений Дачкин, начальник управления ИТ

Программные технологии /

партнёр

Мы долго искали партнёра по разработке бизнес-приложений и очень довольны, что выбрали компанию «Программные технологии». Не часто встретишь столь профессиональное отношение к делу и умение выстроить эффективные коммуникации со всеми участниками проекта, где бы они ни находились. Вместе с нашими партнёрами мы однозначно планируем дальнейшее сотрудничество с компанией «Программные технологии».

Олег Могильницкий, совладелец Servicing Australia Pty Ltd