Модели оплаты при работе с диджитал студиями
Как не довести дело до конфликта с подрядчиком и вашим директором.
Вы менеджер и вам дали выбор подрядчика на разработку личного кабинета, сайта, мобильного приложения. Вы нашли в интернете несколько студий и они предлагают разные форматы работы.
Фикс(-ированная оплата)
Самая враждебная схема. Студия хочет сделать меньше работ, подрядчик вставить работ побольше.
У вас, как у менеджера на душе спокойно, агентство обозначило сроки и сумму работ. Но данная схема изначально толкает вас на конфликт, и с агентством и с вашим директором. Как все происходит в реальной жизни? Оказывается, что в ТЗ не учтено множество мелочей или даже крупных блоков.
Например, в ТЗ есть строчка “Авторизация”, подрядчик ее воспринимает ее, как самую простую авторизацию, но после подписания объявляется программист со стороны заказчика и говорит, что в нашей компании несколько юридических лиц и для каждого юридического лица отдельная авторизация для его сотрудников.
Первый шаг менеджера в этом случае пойти к подрядчику и сказать, что вы обещали авторизацию, то авторизируйте за те же деньги срок, но агентство сопротивляется. Менеджер в данный момент опасается пойти к своему директору и сказать, что на этапе разработки ТЗ не учел такую сложную авторизацию и теперь подрядчик говорит о том, что надо прописывать дополнительные работы за дополнительные деньги. Или же менеджер опасается пойти к директору и сказать, что выбрал подрядчика, который не учел все нюансы авторизации. То есть остается виноватым в любом случае менеджер, что либо неправильно составил проект, либо выбрал неэкспертного подрядчика, либо довел до суда.
Кто же виноват – директор, менеджер, студия? Виноват тот, кто продавил тему фикса. На вашем проекте всегда всплывет, что-то новое, чего не было в техническом задании. Или же в момент разработки поменяются требования к проекту или же приоритеты разработки – это происходит всегда.
Адекватно, конечно же, на новые неучтеннные работы выставлять новые счета и акты. Но из плодотворной работы ваша работа превратится в бюрократию и тыканье в ТЗ. Также студии выгодно интерпретировать работы в ТЗ, как можно меньшими объемами, а заказчику, наоборот вставить работ побольше.
Данный формат работы мы не советуем, негибкий, ведущий к конфликту. Часто такие контракты заканчиваются долгим судом, болезненной сменой подрядчика, конфликтом с вашим директором.
В целом можно применять для очень маленьких задачек.
TimeMaterial или Retainer
Совместил эти два понятия, чтобы вас на запутать. В time material вы платите по факту часов работы каждого специалиста, который работал на проекте, в retainer, вы оплачиваете команду разработку на месяц вперед. Похожие схему примерно с одинаковой философией.
В таком формате и подрядчик и заказчик стремится сделать продукт крутым. Подрядчик мотивирован тем, чтобы с ним не расстались и плодотворно работали над проектом. Заказчик получает свободу в гибкости постановок задачи и отсутствии бюрократии.
У вас есть не супер маленький проект, и вы понимаете, что в нем куча неопределенностей, если даже не представляете, то поверьте, всплывет множество всего в процессе разработки, даже если у вас есть ТЗ на 100 страниц (чем больше страниц, тем больше неопределенностей всплывет).
Как эффективно работать в этом формате?
Запросите примерную оценку проекта. Но главное узнайте, сколько будет стоить разработка в месяц. Бизнес-процессы меняются каждый день, все время что-то всплывает, меняются приоритеты. Но вы будете знать, что у вас есть команда, которая в любой момент будет выполнять актуальные задачи, а не то что было написано в ТЗ пол года назад.
Вам не придется оправдываться перед директором, что всплыло что-то новое и теперь бюджет увеличен. Вы просто развиваете проект по ранее оговоренному бюджету в месяц без зависимости от всплывших подробностях, изменениях в бизнес-процессах, также вы не утопаете в бюрократии.
Наверняка у вас есть выделенный бюджет на весь проект. Вы опасаетесь, что потратите его и не добьетесь конечного результата. Но работая по гибкой схеме вы получаете наиболее актуальный продукт, так как ваш бюджет был потрачен на самые необходимые задачи, а не то, что пол года назад было прописано ТЗ.
В идеале посчитать сколько вам данный проект приносит прибыли каждый месяц и понять сколько стоит команда разработки. При рентабельности запускать проект и развивать его.