{"id":13764,"url":"\/distributions\/13764\/click?bit=1&hash=79976b2d7abe8a57904084c6487771aa36d771f529a5bf38263ec256faa78a49","title":"\u041a\u0430\u043a \u0431\u044b\u0441\u0442\u0440\u043e \u043e\u0442\u0440\u0430\u0441\u0442\u0430\u044e\u0442 \u0443\u043f\u0430\u0432\u0448\u0438\u0435 \u0430\u043a\u0446\u0438\u0438?","buttonText":"\u0410 \u043a\u0442\u043e \u0437\u043d\u0430\u0435\u0442?","imageUuid":"ef3e9b0f-1781-5f5e-a821-98d21c2b58eb","isPaidAndBannersEnabled":false}

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

Как не довести дело до конфликта с подрядчиком и вашим директором.

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

Фикс(-ированная оплата)

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

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

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

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

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

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

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

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

TimeMaterial или Retainer

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

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

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

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

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

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

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

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

0
Комментарии
Читать все 0 комментариев
null