45 дней сериалов
и фильмов по промокоду:
VC45 Активировать 18+

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

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

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

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

Вариант №1: полная предоплата

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

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

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

Вариант №2: полная постоплата

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

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

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

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

Вариант №3: постоплата за выполнение конкретного этапа работ

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

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

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

Вариант №4: 50/50

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

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

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

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

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

Вариант №5: привязка к этапам, но с оплатой фиксированными долями

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

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

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

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

Бонусный вариант №6: привязка к датам

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

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

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

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

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

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

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

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

{ "author_name": "Денис Гордиенко", "author_type": "self", "tags": [], "comments": 4, "likes": 5, "favorites": 37, "is_advertisement": false, "subsite_label": "life", "id": 184281, "is_wide": false, "is_ugc": true, "date": "Sat, 05 Dec 2020 15:03:00 +0300", "is_special": false }
45 дней сериалов и фильмов по промокоду VC45
Активировать
Условия подписки Яндекс.Плюс: clck.ru/FMQND. 45 дней подписки Яндекс.Плюс — бесплатно, далее автопродление — 199 руб./мес. с указанием данных банковской карты. Предложение до 31.12.2020г. Только для новых пользователей, ранее не оформлявших подписку Яндекс.Плюс. Условия просмотра на КиноПоиск: ya.cc/4y4UX
18+
0
4 комментария
Популярные
По порядку
0

Коллеги, вы будете смеяться, но то , что написано уважаемым автором - это настоящая критика капитализма.
(по официальной истории капитализму более 500 лет, в России капитализм развивается с 1992 года - 28 лет чистыми).
Куда смотрят защитники теории "рыночек всё порешает" ?
Более 25 лет заказчики не могут выбрать СПОСОБ отдавать свои деньги исполнителям !
Куда это годится?
Если это не "кризис капитализма" в чистом виде - то что это?
Сколько ещё несчастным заказчикам мучиться с проблемой оплаты своих хотелок?
Что посоветуют "диванные эксперты"?
(написано под впечатлением от собственных проблем с разработчиками CRM (1994 год) - начало и с разработчиками системы проката глянцевых журналов (2014 год).
Годы идут - в России ничего не меняется (с).

Ответить
0

Не очень понял смысл такой статьи - а если оплата 30/70 или 40/60 (аванс/остаток) это еще два варианта чтоли?
С календарными сроками тоже как-то далеко от реальности, обычно это регулируется 'due date' в инвойсе или его российском аналоге - в течение месяца обычно, не дольше.
В крайнем случае заказчику сообщается что работа над проектом приостанавливается до момента оплаты.

Вообщем исходя из моего опыта вот самые банальные варианты ( именно про проекты ):
1. Аванс-остаток
15-30% берется авансом, остальное - по приемке и сдаче работ
Обычно для мелких и средних проектов. 15% аванса от проекта на 2-3 млн долларов конечно никто не даст в здравом уме )
2. Оплата по факту ( та самая полная постоплата )
Да, это про гос.проекты в первую очередь. Госприемка, ГОСТы, провод платежа от 28 декабря итд и тп - все тут. 
Коммерческие большие проекты стараются так не делать, разбивают на этапы обязательно.
3. Оплата по этапам
Суть тут в том что каждый этап достаточно большой, чтобы проходить отдельно процесс приемки и тестирования. Обычно это про полгода работ, не меньше.
По итогам приемки могут быть доработки, как бесплатные ( недоработки, баги ) так и платные - новый функционал.
Отличие от предыдущего пункта тут в том что следующий этап может быть другим, с другим ТЗ, другими работами и исходя из этого - с другими сроками и бюджетом.

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

Ну и помимо проектной работы ( довольно редкой ) куда чаще бывает обычная почасовка на чужих проектах,  банальный аутстафф.

Ответить
0

Придумал себе другой способ. Есть оговоренная сумма за проект и оговоренная сумма в час. Тоесть проект разбивается на примерное количество часов. Оплата раз в неделю в зависимости от отработанных часов вместе с отчетом что сделано. (по факту разработчик свободен выбирать сколько и когда он будет работать)
Оплачивается так пока не коначатся часы или проект.
Тоесть если по факту удалось завершить проект за меньшее число часов - оплачивается оставшаяся сумма чтобы всего равнялась изначально оговоренной.
Или если кончился лимит часов а разработка проболжается - последний платеж задерживается до окончания разработки.
Пока вроде работает.

Ответить
0

предоплата

Ответить

Комментарии

null