Как оплачивать услуги в ИТ: разбираемся с моделями Fixed Price и Time & Materials

Меня зовут Влад Кармаков, я CEO Siberian.pro — компании по мобильной и веб-разработке с цифровым управлением. Мне интересно делиться собственным опытом и обсуждать важные проблемы, с которыми сталкивается каждый предприниматель. В этой статье расскажу про типы контрактов на разработку ПО.

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

В мире ИТ компании используют две основные формы оплаты: Fixed Price и Time & Materials. Разберемся в них подробнее.

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

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

• Вы предоставляете подробное техническое задание. Оно должно быть максимально детальным и включать в себя тип приложения, цели и задачи, описание функционала, макет дизайна и другие важные параметры. С составлением ТЗ также могут помочь наши аналитики за дополнительную плату.
• Компания-разработчик оценивает ТЗ, озвучивает стоимость и сроки. Чаще всего этот этап затягивается, так как исполнитель запрашивает дополнительные данные для принятия решения. Если сумма и сроки вас устраивают, вы заключаете договор и вносите аванс.
• Далее приложение разрабатывается в течение указанного срока. На выходе вы получаете готовый к запуску продукт, проверяете и тестируете его. В конце рассчитываетесь с компанией.

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

Представим, что у вас готово ТЗ по разработке мобильного приложения для App Store. Вы точно знаете, что не будете его менять, и сразу же подписываете контракт. Но в процессе разработки внезапно понимаете, что функционал решает не все потребности клиента, и его необходимо дорабатывать. Что дальше? Либо вы оставляете продукт, как есть, рискуя получить сырое решение, либо решаете внести коррективы.

Если менять условия, то:

• Сдвигаются сроки. Нужно заново согласовывать ТЗ, подписывать дополнительные соглашения. Чтобы не растягивать время и избежать штрафов за не вовремя выполненную работу, часто разработчики вынуждены ускориться и отодвинуть качество на задний план.

• Увеличивается цена, так как меняется объем работ, который изначально был «железно» утвержден. Это неприятно любому клиенту.

• У меня есть подробное ТЗ, которое я не буду менять?
• Насколько точно я или моя команда представляет конечный результат, который нужен на выходе?
• Интересы моей целевой аудитории не поменяются, пока будет разрабатываться продукт? Он будет востребован?

Пока вы формулируете ответы, посмотрим на еще один способ взаимодействия с компанией-разработчиком.

Time & Materials — противоположность предыдущему варианту. Здесь оплачивается время, потраченное на разработку вашего ПО. Эта система гибкая и позволяет создавать и продумывать продукт в процессе, подгонять его под ваши цели, ориентироваться на рынок и желания конечного пользователя. И она учитывает возможные риски.

• Вы приходите к разработчикам с идеей приложения. У вас может отсутствовать подробное ТЗ к продукту — для старта это не нужно. Команды аналитики и дизайна помогают сформировать видение продукта.
• Затем проект разбивается на этапы, а этапы — на задачи. Каждая задача оценивается отдельно. Согласовывается и утверждается профиль и количество специалистов, фиксируется их почасовая ставка.
• Детали обсуждаются в процессе. На любом этапе вы вносите изменения: добавляете, убираете и корректируете. Из-за отсутствия жестких временных рамок изменения реализуются легче. Разработчики предлагают, как лучше реализовать тот или иной функционал, и это позволяет развивать продукт.
• Разработка идет поэтапно. Примерные сроки каждого этапа и релиз мы обсуждаем заранее — например, договариваемся, что MVP приложения (минимально жизнеспособный продукт) будет готов через 1 месяц. Для удобства платежи разбиваются: заканчивается этап — вы его оплачиваете. Компания приступает к следующему этапу, и так до создания финального продукта.
• Даже после релиза работа над приложением продолжается: добавляются новые функции с учетом пожеланий пользователей и решаются проблемы.

Взаимодействие T&M происходит максимально открыто и прозрачно как для вас, так и для разработчиков за счет того, что:

• Компания-разработчик использует принципы AGILE. Такие, как Scrum, чтобы разделить проект на несколько коротких отрезков — спринтов. После каждого этапа вы получаете промежуточные версии приложения, оцениваете и тестируете работающий функционал.
• Для компании важно выполнить каждый этап качественно за оптимальное время, чтобы выстроить доверительные отношения с вами и продолжить работу.
• Компании используют специальные программы для контроля за выполнением работ и учетом времени по каждой задаче. Вам предоставляют доступ для полного отслеживания всех параметров. Например, мы пользуемся сервисом Jira.
• Вы погружаетесь в процесс разработки: участвуете в обсуждении, согласовании и утверждении конкретных нюансов, видите, что происходит с продуктом на каждом этапе и куда он движется. Это помогает держать руку на пульсе и вовремя реагировать на любые изменения.

• У вас средний или большой сложный проект,
• Нет детального ТЗ или четкого представления о приложении,
• Отсутствуют жесткие сроки,

• Нет строгого ограничения по бюджету,
• Продукт нужно поддерживать и постоянно развивать.

Возьмем для примера приложение, где на старте функционал определен не полностью. В контракте Fixed Price сумму завышают изначально, чтобы учесть все риски. Основной упор делается на сдачу проекта в срок. При формате T&M стоимость идет без наценки, и можно отслеживать бюджет на каждом конкретном этапе. При таком подходе вы получаете задуманное приложение по более оптимальной цене, потому что определяете приоритеты и можете повлиять на расходы на всех этапах работы. Как ни странно, часто итоговая стоимость выходит меньше, чем по контракту Fixed Price.

Именно поэтому не советую выбирать форму Fixed Price, если вы хотите сэкономить бюджет. Работайте в рамках нее, когда она подходит вам по остальным описанным мной критериям. Если исходить из уровня вложений в бизнес, мы чаще рекомендуем T&M. Благодаря гибкости этого подхода удается разрабатывать проекты, которые больше отвечают запросам пользователей и виденью клиентов. А это значит, что вы не делаете приложение «в стол», а отправляете его на рынок, чтобы покорять пользователей и получать прибыль.

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

Мы в Siberian.pro разработали 220+ мобильных приложений, веб-сервисов и цифровых экосистем для бизнеса в разных нишах. Если вы хотите запустить или улучшить свой продукт — пишите мне в личные сообщения или на почту [email protected]. Готовы стать вашим цифровым партнером!