Я слышал что лучше организовать всё с правилом "1/3" ( трети: по русски) с прописанием всего в контракте:
Получил предоплату в треть: сделали с заказчиком тех.задание/требования, хотелки и прим.вид/макет/прототип завершенного продукта/договорились по срокам.
(Не хочет платить даже на этом этапе, значит заказчик не серьезный или не платежеспособный - указать ему на это).
==> делаем ==>
Перед тем как показать всю работу: требовать вторую треть (за проделанную работу)
::if==> не понравилось? хочется все кардинально переделать(самый большой риск)? изменились хотелки (нашел лучше после того как уже все заказал/приснилось что то после утверждения деталей изначально)==> перезаключаем договор и делаем все по новой
::else ==> все нравится, уточняем последние детали, хотелки (но не кардинальные изменения, а только косметические здесь), график завершения/запуска/последнего тестирования, получаем последние необходимые детали от заказчика.
Не хочет? До свидания!
Но(примечание):: между выпуском бета-версии и до последнего варианта, код заказчику не даем, т.к. есть возможность (им) программиста кинуть после того как сделано больше 50% работы и после чего закончить что то уже легко, т.е. риск кидалова намного больше и нанять менее квалифицированного специалиста, но с меньшей з/п, есть тоже резон и мотивация
::Не хочет платить перед выпуском бета-версии вторую треть? типа "а ты сначала покажи?"
обьяснить что уже было потрачено время, ресурсы, что можно было потратить на другой проект, плюс сделана основная архитектура работы
==> делаем ==>
::перед выпуском последней версии требуем последнюю треть
__________________________________________________________________________
Сам договор по сути ничего не значит, т.к. работодатель может в любое время сказать ==> "если что то не нравится, иди в суд", зная что тот тоже занимает и время, и деньги, итд и разработчик на маленьком проекте вредли в это впряжется
Но когда вопрос поставлен таким образом "утром - деньги, вечером - стулья", риски разработчика существенно снижаются.
