Разработчик закрыл задачу в трекере, а заказчик не может собрать релиз: исходники остались в личном репозитории исполнителя. Статус «готово» не объясняет, что именно сдано, где лежат файлы и с какого момента работу можно проверять. Эти вопросы лучше решить до первого платежа.
Речь прежде всего о договоре, подчиненном российскому праву. Если исполнитель находится в другой стране, отдельно проверьте применимое право, налоги, передачу прав и возможность исполнить договоренности в выбранной юрисдикции.
Что считать результатом задания
Фрилансеру нередко поручают отдельные задачи: написать модуль, исправить ошибки, подготовить дизайн-систему или провести аудит кода. Общий порядок сотрудничества можно закрепить в договоре, а задания оформлять приложениями либо согласовывать в указанной системе. При этом нужно определить, кто вправе ставить задачи, как их утверждают и без каких сведений работа не начинается.
В задаче на разработку стоит описать не только нужную функцию, но и то, что исполнитель передаст заказчику: исходный код, конфигурации, инструкции по развертыванию, тесты и документацию, если они нужны для проекта. Описание в трекере может быть частью задания, когда стороны согласовали такой порядок и сохранили историю изменений. Без истории после правок в карточке трудно установить первоначальный объем работ.
- Границы задачи: что входит в стоимость, а что согласовывается отдельно.
- Критерии проверки: рабочие сценарии, совместимость и согласованные требования к качеству.
- Способ передачи: репозиторий, ветка, формат файлов и необходимые доступы.
- Изменения: кто утверждает новые сроки и цену до начала дополнительных работ.
Фраза «доработать до полного удовлетворения заказчика» не заменит проверяемых критериев. Если задача исследовательская и итог заранее неизвестен, лучше описать действия исполнителя, состав отчета и пределы его обязательства, а не обещать определенный технический эффект.
Приемка без бесконечных правок
Чтобы заказчик мог начать проверку, ему нужно понятное уведомление о сдаче. Например, стороны договариваются, что исполнитель пишет на определенный адрес и прикладывает ссылку на коммит, сборку или макеты. С получения такого сообщения отсчитывается срок проверки. Он должен позволять заказчику протестировать результат, а исполнителю — узнать, принято ли задание и что требуется исправить.
Замечания полезно привязывать к согласованным требованиям: указать, при каких действиях воспроизводится ошибка, где она обнаружена и какого поведения ожидали. Если во время проверки решили добавить новую функцию, ее объем и оплату обычно согласовывают отдельно. Так исправление недостатков не смешивается с новыми пожеланиями.
Условие об автоматической приемке при отсутствии мотивированных замечаний может помочь не затягивать процесс. Но его последствия зависят от формулировки, характера работ и применимого права. Такое условие не заменяет передачу результата: если заказчик не получил файлы или доступ к ним, молчание не снимает вопрос о фактическом исполнении. Храните вместе с актами версии заданий, уведомления о сдаче, замечания и подтверждения их устранения.
Если работа идет короткими итерациями
При еженедельных спринтах можно принимать результаты по отдельности либо фиксировать отчет за период со списком закрытых задач и ссылками на версии. Тогда спор об одном модуле не мешает подтвердить остальные. При лимите часов дополнительно согласуйте учет времени и предварительное одобрение перерасхода: запись «потрачено 40 часов» не показывает, какие именно работы заказали и выполнили.
Оплата, удержания и расходы
В платежных условиях ответьте на три вопроса: сколько стоит работа, когда за нее нужно платить и кто несет сопутствующие расходы. Цена может быть фиксированной, почасовой или смешанной. При оплате по часам определите ставку, формат отчета и порядок согласования часов; при фиксированной цене — как оплачиваются дополнительные задачи и что происходит при остановке проекта.
Не стоит объявлять весь аванс «невозвратным», не разобравшись с основанием платежа и последствиями прекращения договора. Если сотрудничество закончится досрочно, придется выяснять, что уже сделано и передано, а также какие расходы возмещаются по договору и применимому праву. Заранее согласованный расчет по подтвержденным этапам и передача промежуточных материалов упрощают эту работу.
Налоговые условия зависят от статуса исполнителя и заказчика. При работе с самозанятым российской компании нужно проверить, подходит ли этот режим для конкретных отношений, и получать чек в установленном порядке. Пункт договора сам по себе не подтверждает статус исполнителя на дату выплаты. Для ИП, физического лица без специального статуса и иностранного исполнителя правила различаются, поэтому платежные условия нельзя без проверки переносить из старого шаблона.
Права на код и сторонние компоненты
Оплата разработки сама по себе не означает, что заказчик получил права на результат в нужном ему объеме. В договоре следует определить, какие результаты создаются, передается ли исключительное право или предоставляется лицензия, как определяется вознаграждение за права и с какого момента передача либо лицензия действует. В российском праве есть особенности для программ для ЭВМ и произведений, созданных по заказу; вывод зависит от предмета и условий договора.
Отдельный вопрос — материалы, которые исполнитель создал раньше: собственные библиотеки, шаблоны, фрагменты кода и инструменты. Если права на них остаются у исполнителя, заказчику может понадобиться лицензия для поддержки и изменения продукта. А права на сторонний компонент исполнитель не может передать в большем объеме, чем имеет сам. Поэтому договоритесь, чтобы он сообщал об использованных сторонних компонентах и их лицензиях до включения в проект.
Полный запрет на общедоступные библиотеки редко удобен в разработке. Полезнее согласовать правила их использования и до передачи продукта клиенту проверить требования лицензий. Заверение исполнителя о «чистоте прав» при этом не заменяет список компонентов и подтверждение происхождения существенных частей кода.
Доступы и конфиденциальность при удаленной работе
Исполнителю может понадобиться доступ к репозиторию, тестовой среде и данным проекта — но не ко всей инфраструктуре компании. В договоре или рабочем регламенте укажите, для чего разрешено использовать информацию, как выдаются и возвращаются доступы, что делать с локальными копиями и в какой срок сообщать об инциденте. На практике доступы лучше ограничивать ролью исполнителя и отзывать после завершения задачи.
Отдельно проверьте работу с персональными данными и коммерческой тайной. Если исполнитель получает доступ к персональным данным, компании нужно оценить правовое основание, меры защиты и условия поручения обработки там, где оно необходимо. Для режима коммерческой тайны одного слова «конфиденциально» в договоре недостаточно: важны меры, установленные компанией, и то, к каким сведениям исполнитель действительно допущен.
Доказательства договоренностей и завершение работы
В чате удобно обсуждать задачи, но хранить только там решения о цене, сроках и объеме рискованно. Назовите в договоре каналы связи и представителей, которые вправе согласовывать изменения. Важные решения подтверждайте так, чтобы можно было установить отправителя и содержание согласия. Если для изменения договора требуется определенная форма или подпись, ее нужно соблюсти: сообщение в мессенджере подходит не всегда.
При завершении сотрудничества одного итогового акта мало. Сверьте незавершенные задачи, переданные версии файлов, документацию по сборке, оплаченные этапы и выданные доступы. Например, в пункте о передаче можно предусмотреть размещение исходников согласованной версии в репозитории заказчика, передачу инструкций по запуску и подтверждение удаления локальных копий конфиденциальных данных в согласованном объеме. Это легче проверить, чем фразу «все материалы переданы».
Перед подписанием договора сравните его условия о задачах, приемке и правах с тем, как команда в действительности хранит код и выпускает продукт. Материал носит информационный характер и не заменяет индивидуальную юридическую консультацию.