Time & Material vs Fix price- какую модель оплаты выбрать?

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

Может быть не сразу понятно, какую из них выбрать, и вокруг обеих возникло много мифов.

Поэтому если вы сомневаетесь, как определить цену вашего следующего проекта, читайте дальше, чтобы узнать, на что следует обратить внимание - и почему мы рекомендуем только один из подходов (угадайте какой) - Time & Material.

Мы познакомим вас с определениями моделей фиксированной цены и модели "T&M".

Мы расскажем вам 5 мифов о соглашениях с фиксированной ценой...а также мифы о договорах "T&M"

Когда использовать тот или иной метод ценообразования проекта - сравнение двух моделей.

В простых терминах:

Фиксированная цена: Как следует из названия, это когда вы и ваше агенство по разработке договариваетесь о фиксированной сумме за весь проект (или его часть).

Время и материал (T&M): Это когда цена, которую вы платите, отражает фактическое время, затраченное разработчиками, работающими над проектом, и любыми другими людьми, такими как менеджеры проекта, руководители группы и т.д., их почасовые ставки, а также ресурсы, используемые в процессе.

Оба варианта основаны на различных предположениях и отражают совершенно разный взгляд на проекты по разработке программного обеспечения.

В случае соглашения о фиксированной цене вы, по сути, покупаете продукт по единой, фиксированной цене. Но если вы не покупаете программное обеспечение "с полки", вам нужно помнить, что это индивидуальный продукт, основанный на ваших спецификациях, требованиях и подробном объеме работ. Этот метод в основном используется компаниями, работающими по водопадной* модели, и никогда не будет хорошей идеей, если вы работаете по гибкой модели. И это может сработать, если у вас есть определенное видение и (очень) подробная спецификация, которая точно не изменится. С акцентом на "может".

С другой стороны, контракт T&M - вместо того, чтобы делать обоснованные предположения - учитывает всю динамику, которая происходит при разработке программного обеспечения, например, меняющиеся требования, обновления и вероятные риски. -> Вот почему большинство компаний, занимающихся разработкой программного обеспечения (включая нашу), отдают предпочтение модели ценообразования по принципу "Time & Material", хотя модель фиксированной цены все еще находит свое применение.

В агентстве Technaxis мы придерживаемся определенных взглядов на эффективность (и неэффективность) обеих моделей и определенно отдаем предпочтение модели "T&M". Вот несколько распространенных мифов, которые мы хотели бы развенчать, чтобы вам было легче сделать выбор при определении цены вашего следующего проекта.

Миф 1: Это предсказуемо

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

Реальность:

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

Кроме того, жесткий объем работ, скорее всего, обойдется вам дороже, потому что любые улучшения или даже исправления ошибок могут быть расценены как работы "за рамками". Это практически не оставляет пространства для маневра, так что в итоге вы фактически платите больше - и, вероятно, больше, чем заплатили бы при модели "T&M".

Кроме того, за все свое время работы, мы редко видели проект с Fix Price сданный в срок. Для нас это скорее мифическое существо при данной модели.

Миф 2: Все понимают видение и ожидания по проекту.

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

Реальность:

Если бы! Не существует такого понятия, как "отсутствие сюрпризов" (если не считать старой песни Radiohead). Очень сложно и долго создавать настолько подробную спецификацию, чтобы знать абсолютно все. Правда в том, что вы никогда не можете знать, что изменится, и риск, которому вы подвергаетесь, придерживаясь жесткого и строгого бюджета и графика, заключается в том, что в итоге вы получите продукт, не соответствующий стандартам - и не тот, который вы ожидали.

Миф 3: Все прозрачно

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

Реальность:

Давайте разберемся и приоткроем завесу тайны

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

Миф 4: Легко управлять на стороне клиента

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

Реальность:

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

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

Миф 5: Это дешевле

Вы договариваетесь о цене, и это все, что вы платите, избавляя себя от непредвиденных расходов в случае, если проект затянется.

Реальность:

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

Модель ценообразования должна быть адаптирована к способу создания программного обеспечения. Часто бывает сложно установить фиксированную цену при создании программного обеспечения с нуля.

Миф 1: Это дороже

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

Реальность:

Надеюсь, нам удалось объяснить это в первой части статьи. Поскольку time & material по своей природе является гибким, бюджет и график являются более обсуждаемыми, что в свою очередь означает меньший риск как для клиента, так и для компании-разработчика. Agile-проекты, сама природа которых более динамична, - это, по сути, единственный разумный выбор, который у вас есть.

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

Миф 2: Это непредсказуемо

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

Реальность:

Все может измениться. И соглашения о T&M не означают (и определенно не должны означать), что вам не нужно составлять объем работ, первоначальные требования и спецификации - и просто плыть по течению.

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

Миф 3: Легче начать

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

Реальность:

Отчасти это правда (по крайней мере, по сравнению с тем уровнем детализации, который вы должны проработать перед началом проекта с фиксированной ценой), но это может быть непросто. Абсолютно точно стоит потратить достаточно времени на начальном этапе, чтобы оценить уровень риска неточности в проекте (и вот как мы это делаем в Technaxis). Если вы не хотите, чтобы мифы о "дороговизне" и "непредсказуемости" оказались правдой.

Миф 4: Сложнее контролировать

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

Реальность:

В любом проекте вам абсолютно НЕОБХОДИМО знать, как вы собираетесь его контролировать. Нет смысла даже начинать его, если вы не можете или не хотите этого делать - если только вы не готовы потратить на это гораздо больше времени и денег.

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

Миф 5: Это больше работы для клиента

Вы должны принимать более активное участие в разработке проекта - а у вас просто нет времени.

Реальность:

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

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

По сути, основное сравнение этих двух моделей может выглядеть примерно так:

Очень общий ответ может быть таким:

Это зависит как от ваших потребностей, так и от подхода компании-разработчика к разработке программного обеспечения.

Но правда в том, что многие компании по разработке программного обеспечения отходят от контрактов с фиксированной ценой (за исключением, возможно, простых и быстрых проектов, которые легко оценить и которые не представляют серьезных технических проблем) и переходят к подходу "Time & Material", который позволяет всем быть более гибкими и получать более качественный конечный продукт. Следите за обновлениями. В следующей статье мы представим несколько полезных советов и раскроем лайфхаки для улучшения работы по Time & Material.