Фото: не помню откуда
Формат моего типового договора (PDF, 310кб) нацелен на минимизацию документооборота между сторонами в условиях долгосрочного сотрудничества. Вследствие этого: текст документа фиксирует реквизиты заказчика/исполнителя и упорядочивает юридическую сторону вопроса, а под каждый (первый или очередной) этап работ по этому договору стороны составляют и подписывают техническое задание, в котором кроме технических требований фиксируются календарный план событий и промежуточные точки контроля.
Решение
Этап «открывается» техническим заданием (ТЗ) и «закрывается» актом сдачи-приёмки работ - формы задания и акта согласовываются сторонами заранее. В результате договор заключается единожды, но потребности заказчика будут удовлетворяться по мере их возникновения одним из вариантов:
• Задача есть? - Да. - ТЗ. - Выполняю работу. - Сдача, приёмка, расчёт. - Занавес.
• Задача есть? - Нет. - «Курим бамбук».
Информационное взаимодействие Сторон (формирование проекта ТЗ, обмен осциллограммами, операционный контроль и др.) предлагаю реализовать через форум технической поддержки - личная «социальная сеть» российского инженера. Её возможности позволяют создавать закрытые группы общения, доступ в которые определяется персонально мной как единственным администратором. Разумеется, варианты связи в виде email, skype, телефона также имеют место быть.
По умолчанию применяется схема взаиморасчётов «20-30-50». 20% от стоимости работ Заказчик оплачивает сразу после подписания технического задания, следующие 30% поступают на счёт Исполнителя по факту отгрузки Заказчику результатов работ (опытный образец устройства, программа под Windows, серия приборов и т.д.). Оставшиеся 50% перечисляются Исполнителю после успешных приёмо-сдаточных испытаний, состав и методика проведения которых фиксируются в техническом задании. Полный комплект конструкторской документации и «исходников» сопутствующих программ предоставляются Заказчику только после 100% оплаты.
Результат
Передача исключительных прав на созданную интеллектуальную собственность - конструкторская документация, фотошаблоны печатных плат, монтажные/компоновочные схемы, методики расчётов, исходные коды программ, руководства по эксплуатации и т.д. - оговаривается в техническом задании на этап и происходит на основании обособленного документа, отличного от акта сдачи-приёмки. Авторское сопровождение предмета разработки, а также любые иные действия, касающиеся жизненного цикла конечного продукта, возможны и даже желательны, но по условиям всё слишком индивидуально - без диалога никак.
Погрешности
Существуют тематические проекты по которым я начинаю работать сразу же после подписания договора - только на основании устной договорённости, не дожидаясь окончательного варианта ТЗ. Но сначала небольшое отступление.
Контрактное производство электроники и автоматики подразумевает работу с реальным оборудованием и в большинстве своём мои разработки являются частью какой-то сложной системы. По-хорошему, на этапе создания и отладки проекта нужны все «смежники», то есть устройства и программы, которые в той или иной степени взаимодействуют с предметом договора. Но практика диктует иные условия: технологический цикл останавливать нельзя, устройство не предназначено для работы вне системы или же для автономной работы устройства нужно огромное количество вспомогательного оборудования: охлаждение, тепловая изоляция, механическая оснастка и т.д.
Вот при таких «заморочках» вынужден помимо основной тематики разрабатывать ещё программные и/или аппаратные эмуляторы смежных устройств («допы»), чтобы при «рождении» моё творение «думало», что работает в реальном мире: что-то типа «... Видишь суслика? - Нет. - И я не вижу, а он есть ...» (С). Эмуляторы сделаны, проект отлажен, заказчик принял работы, но эмуляторы-то остались! Так вот: если один из существующих «допов» подходит под тематику очередного проекта, то комментарии излишни - адаптировать и выдать на-гора. Теперь вернёмся к основной теме.
В таких случаях задача ценообразования работ по проекту сводится к определению стоимости трудозатрат на устранение разницы между требованиями заказчика и функционалом «допа» - это осуществляется за меньший временной промежуток, нежели калькуляция всего ТЗ. В итоге: заказчик сформулировал задачу и определил сроки, исполнитель назвал цену и промежуточные точки контроля - работа началась с минимумом организационных затрат.
Обращаю внимание: начало работ без технического задания не означает его отсутствие в принципе. Да, я начал работу, но если подписанное ТЗ будет отсутствовать более 30 (тридцати) календарных дней с момента начала работ, то этот факт будет расцениваться как одобрение выполнения проекта по остаточному принципу: работы будут продолжаться, а при появлении нового заказчика с наличием технического задания этот «неоТЗованный» проект ставится на паузу. Ничего личного - это бизнес.
На практике стараюсь все свои «допы» капитализировать, поэтому риска в ситуации запуска проекта без технического задания практически нет - если заказчик нарушит устную договорённость, то «доп» в любом случае будет доработан до коммерческого вида и «уйдёт» через интернет-магазин. «...ложечки-то нашлись, но осадок остался» (С).
P.S. Представленные в «Информационном обмене» результаты являются продуктом одного из тех случаев, когда заявленная концепция «не выстрелила». С целью минимизации подобного и «шлифуются» мои принципы, да требования к заказчикам.