Модели оплаты при работе с диджитал студиями

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

Самая враждебная схема. Студия хочет сделать меньше работ, подрядчик вставить работ побольше.

У вас, как у менеджера на душе спокойно, агентство обозначило сроки и сумму работ. Но данная схема изначально толкает вас на конфликт, и с агентством и с вашим директором. Как все происходит в реальной жизни? Оказывается, что в ТЗ не учтено множество мелочей или даже крупных блоков.

Например, в ТЗ есть строчка “Авторизация”, подрядчик ее воспринимает ее, как самую простую авторизацию, но после подписания объявляется программист со стороны заказчика и говорит, что в нашей компании несколько юридических лиц и для каждого юридического лица отдельная авторизация для его сотрудников.

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

Кто же виноват – директор, менеджер, студия? Виноват тот, кто продавил тему фикса. На вашем проекте всегда всплывет, что-то новое, чего не было в техническом задании. Или же в момент разработки поменяются требования к проекту или же приоритеты разработки – это происходит всегда.

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

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

В целом можно применять для очень маленьких задачек.

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

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

У вас есть не супер маленький проект, и вы понимаете, что в нем куча неопределенностей, если даже не представляете, то поверьте, всплывет множество всего в процессе разработки, даже если у вас есть ТЗ на 100 страниц (чем больше страниц, тем больше неопределенностей всплывет).

Как эффективно работать в этом формате?

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

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

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

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

Наша тегешечка