5 вариантов оплаты за разработку

Денис Гордиенко, генеральный директор Bright Mobile, о способах оплаты разработки приложения

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

Сначала разберём самые крайние случаи.

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

Простая, но эффективная проверка «на вшивость»: если он получил 100% оплаты за простейшую задачу, которую ему сделать – раз плюнуть, а затем сливается, смысла с ним работать дальше нет. А если же после получения предоплаты, наоборот, сразу садится и показывает свою мотивацию, стремясь выполнить задачу скорее – я с ним сработаюсь: у него правильное отношение к работе.

Когда будете нанимать фрилансера, попробуйте такой тест – она очень хорошо покажет, кинет ли он вас в будущем или нет и насколько он вообще заинтересован в вас как в заказчике. Деньги не большие, даже если кинет, то рассматривайте, как покупку страховки от кидалова на бОльшую сумму.

Это слишком идеальная история – такое я видел только в госконтрактах, когда ставится бюджет, например, х3 рыночной цены. И я говорю не про распил: там нужна страховка, дополнительные программисты на каждую задачу, и деньги начисляются только через 1,5 месяца спустя подписание последнего акта.

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

Люди понимают, да им и самим нужно перед высшим начальством отчитываться, поэтому платежи скорее всего разобьют по 2-3 месяца и попросят составить объём работ, чтобы они могли проверять и выплачивать деньги по окончании каждого этапа.

Так мы плавно перешли к третьему варианту...

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

Можно разделить даже сами этапы: например, оплачивать дизайнеру каждые 5 макетов. С моими дизайнерами у меня как раз такая договорённость: обычно в приложении 20-30 экранов, но я принимаю работы по 5. Получил, сверил с ТЗ, сделал внутреннюю проверку, согласовал с клиентом, клиент одобрил/внёс правки, дизайнер их сдал, передал исходники – и после этого он получает оплату за первые 5 экранов.

В принципе, если человек заинтересован в работе, и это не первый с вами заказ, а потому знает, что вы его не кинете, обычно к такому он отнесётся адекватно. Никому не нужны деньги прямо здесь и сейчас, все понимают, что можно подождать, и в постоплате исполнитель ничего плохого не увидит. Разумеется, только при коротких дистанциях: если вы предложить работать и ждать месяц, такой вариант напрягает, а два-три дня – пожалуйста.

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

Разработчику невыгодно из-за того, что он может сделать весь проект целиком, а в конце мошенником оказывается заказчик – требует сверх ТЗ, шантажирует оплатой и не выдаёт оставшуюся сумму. Здесь получить вторую часть поможет только суд, а это дело долгое и тяжёлое.

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

50/50 можно применять, если Вы бьёте на этапы: например, у того же дизайнера можно заказать 20 экранов, разделить работу на этапы по 5 штук, присылать за них предоплату, а остальное – когда всё будет готово. Сразу же отправить предоплату за следующие 5 экранов и т.д.

Однако если этапы стоят разных денег, можно ошибиться: каждый из них нужно разделить пополам, объединить с половиной предыдущего (или следующего) и отправлять верную сумму. Чтобы никто не ошибся, лучше договориться работать или по полной предоплате, или по полной постоплате этапа, и всем будет проще. А если боитесь, что сумма слишком большая, делите её ещё на несколько частей, главное, чтобы все чётко понимали, где сейчас осуществляется работа, и оплата была чётко согласованной.

Очень простой вариант для финансового учёта и собственного понимания.

У меня таких этапов пять: оплата поделена на пять частей, соответственно, имеется четыре этапа работы. Сначала отправляются 20% предоплаты, затем мы делаем каркасы, согласовываем, вносим изменения в ТЗ, далее серверная часть и админка, затем следующие 20% ну и т.д. пока работа не будет выполнена, а деньги выплачены.

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

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

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

Представьте: разработка сайта – 5 месяцев, и каждый месяц, вне зависимости от того, сделал ли исполнитель что-нибудь или нет, клиент обязан ему выплатить часть суммы – это прописано в договоре. И только последняя сумма привязывалась к концу разработки, когда будет подписан финальный акт о выполненных работах.

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

Он просто обязан выплачивать в определённые календарные сроки выплачивать 80% всех денег и может не получить ничего. Через суд-то он, конечно, их вернёт, докажет, что работа не велась, и результата нет, но, как я уже говорил, морока ещё та. И представьте себе, у знакомого всё работало, и ситуации, что он делал, а клиент не платил, не возникало.

Клиентов у него было достаточно: то ли не читали внимательно, то ли вопрос как-то проскальзывал, то ли просто соглашались. Впрочем, у него было крупное портфолио, так что ему доверяли. Но риск того, что исполнитель забьёт – очень вероятен. Я бы не рекомендовал просто привязываться к календарной дате, либо прописал бы какие-нибудь штрафные санкции по несдаче, регламентирующие выплаты в пользу заказчика, если сроки будут нарушаться.

Есть более экстравагантные способы оплаты, например, работа за долю от проекта (или, как я её называю, за дырку от бублика); иногда платит третье лицо – заключается такой хитрый трёхсторонний договор, что подрядчику и претензий предъявить некому.

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

Сейчас собираю пул вопросов для будущих статей. Их можно оставить в комментариях