Оплата розробки етапами: як графік платежів захищає клієнта

Що таке оплата етапами — і чим вона не є

Графік оплати етапами ділить ціну проєкту на частини, прив’язані до етапів роботи. Замість того щоб платити все наперед або щомісяця оплачувати години, ви платите в міру того, як продукт набуває форми.

Типові альтернативи такі:

• 100 % наперед. Просто для підрядника, весь ризик — на вас.
• Погодинна оплата. Ви щомісяця платите за години. Гнучко, але загальна сума не зафіксована, і ви платите за зусилля, а не за результат.
• Оплата після завершення. Весь ризик на підряднику, тож поза невеликими завданнями ця схема рідко працює: підрядник фінансує весь проєкт і закладає це в ціну.
• Етапи. Ціна фіксована й поділена на частини. Якщо все зроблено правильно, ризик розподілено пропорційно зробленій роботі.

Ключові слова в останньому пункті — «зробленій роботі». Графік «30 % на старті, 40 % посередині, 30 % наприкінці» — це оплата етапами лише за назвою. Середній платіж не прив’язаний ні до чого, що ви можете перевірити.

Три умови, за яких оплата етапами справді захищає

1. Етап — це результат, а не дата чи обсяг зусиль

«Розробка — 40 %» — це чорна скринька. «Акаунти й профілі: реєстрація через пошту та Google, редагування профілю, скидання пароля, перегляд користувачів в адмінці» — це етап. Його можна відкрити, спробувати й сказати «так» або «ні».

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

2. У кожного етапу є правила приймання

Вам треба знати:

• у якому вигляді роботу передають на перевірку (тестова збірка, посилання, гілка в репозиторії);
• скільки часу у вас на перевірку;
• що вважається підставою повернути роботу;
• що буде, якщо ви нічого не відповісте.

Без цього приймання щоразу перетворюється на переговори.

3. Гроші йдуть слідом за прийманням

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

Як це влаштовано в EVA-X

Ми працюємо так у кожному проєкті, тож ось подробиці — так, як їх описують наші умови.

• Договір підписується онлайн. Він фіксує ціну, ділить обсяг робіт на модулі й задає графік оплати: одразу повністю або етапами.
• Перший платіж вноситься до початку роботи, і відлік термінів починається з дня, коли він надійшов.
• Платежі потрапляють у резерв проєкту. У рахунок вартості модуля вони зараховуються, лише коли ви цей модуль приймаєте. У кабінеті видно, скільки ви сплатили, скільки зараховано за прийняті модулі й скільки лишається в резерві.
• На перевірку кожного модуля — 7 календарних днів. Ви приймаєте його або повертаєте на правки з мотивованим переліком конкретних невідповідностей, описаних так, щоб їх можна було відтворити. Правки, що приводять модуль у відповідність до погодженого обсягу, безоплатні.
• Якщо ви мовчите весь строк перевірки або починаєте користуватися модулем у робочому середовищі, він вважається прийнятим. Це звичайна й чесна умова, але про неї краще знати заздалегідь.
• Повернення коштів можливе з невикористаної частини резерву. Якщо проєкт зупиняється достроково, роботу, вже виконану за незавершеними модулями, оплачують і передають вам, погоджені з вами витрати, які неможливо повернути, вираховують, а решту повертають.

Чесне уточнення: резерв проєкту — це наш облік передоплати, яку ще не зароблено. Він не є ескроу, довірчим управлінням, депозитом чи окремим рахунком, і третя особа його не тримає. Він дає вам умову договору, за якою гроші вважаються заробленими лише після приймання, і кабінет, де видно, у якому стані кожен платіж.

Як стежити за платежами під час проєкту

Навіть за добрих умов ведіть власний простий облік. Для кожного платежу записуйте, за який модуль він, коли модуль передали на перевірку, коли ви його прийняли чи повернули на правки і скільки ще лишається в резерві. Перш ніж оплатити наступний рахунок, звірте свої записи з тим, що показує підрядник. Це десять хвилин на місяць, зате будь-яка суперечка згодом зводиться до порівняння двох таблиць, а не двох спогадів.

Якщо проєкт веде кілька людей з вашого боку, домовтеся, хто саме приймає модулі. Приймання має юридичну вагу — за нашими умовами воно має силу підписаного акта приймання-передачі, — і гроші після нього зараховуються підряднику. Краще, щоб модулі приймала одна відповідальна людина, а не той, хто першим відкрив лист.

Порівняння поширених схем оплати

Що перевірити в договорі з поетапною оплатою

Перед підписанням пройдіться договором із такими запитаннями:

• Кожен етап — це модуль з описом чи відсоток від фази?
• Скільки триває строк перевірки і що відбувається, коли він минає?
• Що таке безоплатні правки, а що — запит на зміни? Виправлення того, що не відповідає погодженому обсягу, має бути безоплатним. Нові побажання мають свою ціну. Договір повинен чітко розділяти одне й друге.
• Що буде з передоплатою, якщо проєкт зупиниться? Хто платить за роботу в процесі і як її рахують?
• Коли права на код переходять до вас? Зазвичай після повної оплати, іноді модуль за модулем у міру оплати. Детальніше — у статті кому належить код.
• Скільки часу на оплату рахунку і що буде, якщо ви запізнитеся? Робота може стати на паузу — знайте умови.
• Яка гарантія на прийняту роботу? Наприклад, протягом якого часу після приймання підрядник безоплатно виправляє відтворювані дефекти.

Пастки, які лише здаються захистом

Маленький перший платіж і величезний останній. Здається безпечним, доки не зрозумієте, що весь цей час роботу фінансує підрядник — і в нього є всі причини економити чи затягувати, щоб захистити себе. Збалансований ризик тримає в роботі обидві сторони.

Приймання прив’язане до «запуску». Якщо останній платіж чекає на запуск, який залежить від вашого маркетингу, ваших текстів чи вашого акаунта в App Store, підрядник на нього не впливає — і починаються суперечки.

Етапи, які не можна перевірити окремо. Клієнт не перевірить «готовий бекенд» без інтерфейсу. Групуйте роботу в модулі, якими людина може скористатися.

Оплата за «відсоток готовності». «Проєкт готовий на 60 %» — це думка. Модуль або прийнято, або ні.

Ні слова про запити на зміни. Без зрозумілого процесу кожна нова ідея посеред проєкту стає суперечкою, чи вона «вже входила».

Чого графік оплати не виправить

Оплата етапами обмежує суму, яка перебуває під ризиком. Але сама собою вона не робить проєкт успішним.

• Розмитий обсяг робіт. Якщо в договорі модуль описано як «керування користувачами», приймання перетвориться на суперечку, що саме туди входить. Бути точним треба до підписання. У цьому допоможе стаття про те, як описати проєкт, щоб його точно оцінили.
• Повільні рішення з вашого боку. Якщо три тижні ніхто не може перевірити передану роботу, графік не допоможе — проєкт просто стоїть. Призначте одну людину, яка ухвалює рішення й відповідає на запитання команди.
• Не той підрядник. Добрий графік зі слабкою командою дасть вам слабкий продукт, просто частинами. Дивіться на вже зроблені роботи, а не лише на умови договору.
• Відсутність тестових даних і доступів. Якщо для перевірки модуля потрібні ваші реальні товари, тексти чи доступ до платіжного сервісу, підготуйте їх заздалегідь. Інакше строк перевірки мине, а перевірити буде нічого.

Як оплата етапами захищає й підрядника

Графік, що захищає лише одну сторону, не працює. Підрядник, не певний, що йому заплатять за готову роботу, закладатиме запас в оцінку, сповільнюватиметься або перестане відповідати. Збалансовані умови тримають на вашому проєкті добру команду:

• перший платіж покриває старт роботи;
• строк перевірки з мовчазним прийманням не дає модулю місяцями лежати без перевірки;
• чіткі запити на зміни не дають обсягу безкоштовно розростатися;
• гроші, що зараховуються після приймання, означають, що за роботу, яка пройшла перевірку, підрядник гарантовано отримує оплату.

Коли читаєте умови підрядника, такі пункти — не тривожний сигнал. Саме вони дають йому змогу взагалі зафіксувати ціну.

Приклад добре побудованого графіка

Для умовного застосунку для бронювання з вебадмінкою графік за модулями може виглядати так:

1. Акаунти й профілі: реєстрація, вхід, профіль, скидання пароля.
2. Каталог і пошук: послуги, фільтри, картки.
3. Бронювання й оплати: календар, оформлення, квитанції, повернення коштів.
4. Адмінка: керування послугами, бронюваннями й користувачами, базові звіти.
5. Запуск: збірки й сторінки в App Store та Google Play, налаштування робочого середовища.

Кожен модуль може відкрити й спробувати людина, яка не є інженером. Кожен має свою ціну в договорі, тож ви завжди знаєте, за що саме платите. Коштуватимуть модулі по-різному: у бронюванні й оплатах більше логіки та крайніх випадків, ніж у профілях, тож і частка ціни в них більша. Це нормально, і це ще одна причина прив’язувати платежі до модулів, а не до рівних відрізків часу.

Якщо порівнюєте моделі договору, прочитайте фіксована ціна чи погодинна оплата і статтю про критерії приймання робіт. Щоб побачити, як ваш продукт розбивається на модулі, з термінами й фіксованою ціною, опишіть його в оцінці або почитайте про нашу розробку програмного забезпечення на замовлення.