Как игровой студии оформлять договоры и платить подрядчикам, фрилансерам и удалённым сотрудникам в 2026 году
Главное перед подключением команды
- Определите фактическую модель работы человека. Для сотрудника нужен трудовой договор через своего работодателя или EOR — компанию, которая выступает местным работодателем. Payroll означает расчёт зарплаты и обязательных удержаний при уже выбранной модели трудоустройства. Подрядный сервис эту развилку не закрывает: 4dev.com работает с независимыми исполнителями и не предоставляет EOR или payroll.
- Для подрядчика свяжите задание с конкретным результатом: версией кода, набором моделей, записью озвучки. Условия проверки, исходники и разрешённые способы использования согласуйте до начала работы.
- В реестре прав сохраняйте фактических авторов, документы и внешние компоненты. Заказ, запись в Git и отправленные деньги по отдельности не дают полной картины владения результатом.
- Приёмку поручите человеку с договорными полномочиями. Технический комментарий художника или разработчика ещё не выражает юридического решения студии.
- Ведите отдельно события передачи прав, завершения задачи, выставления счёта и фактического получения денег. У них разные основания и разные способы проверки.
В условном проекте студии программист пишет модуль сохранений, художник сдаёт персонажей, композитор готовит трек. Техническому руководителю нужно соединить их задания в трекере, файлы в репозитории и хранилище, договоры и финансовый учёт. Практический результат такой работы — возможность открыть запись по выпущенному билду и понять, какая версия включена, кто её принял, какие разрешения получены и закрыт ли расчёт.
Сначала определите, кому нужен трудовой договор
Выбор сервиса начинается с фактов о работе человека: кто управляет процессом, как согласуют цену, какие обязательства продолжаются между заданиями. Удалённое место работы само по себе не делает разработчика независимым подрядчиком. Оценку проводят по правилам соответствующей страны; название договора не заменяет её.
Фактическая работа важнее названия договора
В США для федеральных налогов на занятость IRS рассматривает поведенческий контроль, финансовый контроль и характер отношений в совокупности. В частности, проверяют, кто определяет способы выполнения работы, какие расходы и предпринимательские возможности есть у исполнителя и как стороны описывают продолжительность отношений. Этот федеральный налоговый тест нельзя переносить на все трудовые права и правила отдельных штатов.
В Англии, Шотландии и Уэльсе руководство по статусу занятости различает работника по трудовому договору (employee), работника с отдельным набором трудовых прав (worker) и самостоятельно занятого исполнителя (self-employed). Налоговая система использует своё деление; результаты двух оценок не взаимозаменяемы. Руководство не распространяется на Северную Ирландию. Применимость этих правил определяется соответствующей юрисдикцией.
Предположим, постоянному разработчику студия назначает ежедневный график, руководитель определяет порядок выполнения работы, а отношения продолжаются без отдельных согласованных результатов. Это факты для местной проверки статуса. Художник, который самостоятельно организует работу и договаривается о цене за определённый набор моделей, даёт другую фактическую картину. Ни один из этих кратких примеров не устанавливает окончательный статус: нужно узнать остальные обстоятельства, включая возможность работать на других заказчиков и условия прекращения сотрудничества.
Если проверка приводит к трудовой модели, сначала решите, кто станет работодателем и как будет устроен расчёт зарплаты. Только затем выбирайте собственную инфраструктуру работодателя или EOR и соответствующий расчёт зарплаты. Обязательства и последствия ошибочной классификации зависят от юрисдикции.
Составьте карту сторон и мест выполнения работы
До договора соберите небольшую таблицу: юридическое лицо студии; сторона, подписывающая соглашение; фактический исполнитель; страна работы; сведения о налоговом статусе; лицо, принимающее результат. Для аутсорс-команды добавьте её организацию и людей, чьи вклады войдут в игру. Страна регистрации поставщика не описывает автоматически всех участников.
Место выполнения работы имеет и самостоятельное налоговое значение. Например, в правилах США для дохода от личных услуг обычно учитывают, где услуги выполнялись; работа в разных местах может потребовать распределения дохода, а применимые договоры об избежании двойного налогообложения могут вводить исключения. Это основание фиксировать изменения географии, без готового вывода о налогах конкретного человека.
Переезд исполнителя, новая компания в договоре или изменение управления его работой должны попадать к ответственному за договоры. До подключения подготовьте заполненную карту фактов и заключение по спорным отношениям. Платформу выбирают уже под полученную модель.
Опишите результат и полномочия до первой задачи
Задание должно отвечать на два рабочих вопроса: что именно исполнитель передаёт и кто от студии вправе подтвердить исполнение. Цена и срок без состава результата оставляют открытым спор о том, завершён ли этап.
Что подрядчик сдаёт вместе с кодом и артом
Договорное руководство WIPO для небольших разработчиков мобильных приложений, опубликованное в 2020 году, рекомендует согласовать тестирование, приёмку и передачу исходников с инструкциями по сборке. Это качественное руководство для соседней области разработки, без универсального шаблона для каждой страны. Его практический принцип применим к студии: проверяемый результат включает материалы, которые понадобятся следующему участнику проекта.
Для нашего условного этапа можно заполнить такое приложение к заданию:
| Поле задания | Модуль сохранений | Набор персонажей |
|---|---|---|
| Результат | Оговорённые операции записи и загрузки состояния | Перечень персонажей и согласованные варианты |
| Исходные материалы | Код, зависимости, тесты, инструкция сборки | Исходная сцена, сетки, текстуры, согласованные материалы |
| Условия проверки | Названная версия движка, тестовый проект, сценарии загрузки | Версия движка, правила импорта, проверка материалов и анимаций, если они входят в объём |
| Принимающий | Уполномоченный представитель студии; технический рецензент отдельно | То же разделение между арт-рецензией и приёмкой |
| Срок проверки | Явно согласованное окно после сдачи | Окно с достаточным временем на импорт |
| Исправления | Устранение несоответствий согласованным сценариям | Исправления относительно утверждённой спецификации |
| Цена и расчёт | Сумма этапа, валюта, договорное основание счёта | Сумма за указанный набор и согласованное событие расчёта |
| Новый объём | Порядок согласования дополнительных функций | Порядок заказа новых вариантов и переработки концепции |
Это пример заполнения, который нужно согласовать с исполнителем. В задании также нужны способ доставки, точное место хранения и перечень включённых внешних компонентов. Ссылка на изменяемую папку без списка файлов не определяет состав переданного набора.
Изменения задания требуют отдельного решения
Если загрузка сохранения ломается в предусмотренном тестовом сценарии, обсуждают исправление несоответствия. Если после согласования студия решила поддержать ещё одну платформу, это уже вопрос нового объёма. Для персонажей аналогичная граница проходит между неверным импортом согласованной модели и заказом другого костюма, которого не было в перечне.
В соглашении исполнителя 4dev.com (Service Agreement, далее SA) от 17.09.2026 §2.3 изменение уже принятой задачи требует согласия исполнителя; согласованная новая задача заменяет прежнюю. При отклонении изменения или прекращении задачи стороны обсуждают причитающееся вознаграждение и остальные вопросы по §§2.4–2.6. Поэтому сохраняйте предыдущую спецификацию и новое согласие, даже когда интерфейс трекера показывает только последнюю редакцию.
Кто подписывает документы и отвечает на вопросы исполнителя
Перед подключением выясните, кто заключает соглашение: физическое лицо, его компания или аутсорс-студия. Проверьте полномочия подписанта и фактических авторов. Список документов для идентификации и налогового статуса определяют действующий договор, страна и требования выбранного процесса; одного общего перечня для всей международной команды нет. Форма электронной подписи и необходимые местные формальности также требуют проверки.
Соглашение о конфиденциальности, или NDA, задаёт порядок обращения с материалами проекта. Документ о правах определяет использование результата. Взаимозаменяемости между ними нет: запрет раскрывать исходники не отвечает на вопрос, может ли студия модифицировать и распространять их.
У 4dev.com в подрядном соглашении §3.1 личное исполнение составляет исходное правило, а привлечение третьих лиц требует письменного согласования предусмотренных сторон. Клиентское соглашение (Master Service Agreement, далее MSA) и SA описывают разные отношения. Термин Contractor означает платформенного контрагента в MSA и исполнителя в SA. По §12.7.1 MSA предусмотрено право Вайоминга для клиента — американской корпорации и право Англии и Уэльса в остальных случаях; у подрядного соглашения указано право Англии и Уэльса. Эти положения не отменяют проверку обязательных местных правил.
Назначьте контакт для вопросов по заданию, владельца договорных документов и представителя с правом приёмки. Спорные статусы, старые неподписанные вклады, участие нескольких авторов и необычные условия лицензирования передавайте юристу до того, как их результат войдёт в производственную сборку.
Свяжите каждый игровой ресурс с автором и основанием использования
Для каждой версии кода, модели или трека студии нужна запись, которая соединяет фактических авторов с договором и разрешёнными применениями. Слова о передаче всех прав в одном соглашении ещё не объясняют происхождение текстуры, старого инструмента художника или записи приглашённого музыканта.
Новый результат, прежние инструменты и внешние компоненты
Передача экономических прав и лицензия решают разные задачи. При передаче студия получает предусмотренные договором права на результат. Лицензия разрешает определённые способы использования в установленных пределах. Для обоих вариантов проверьте территорию, срок, модификацию, распространение, использование в рекламе, порты и возможность предоставить права издателю. Важны также исключительность разрешения и местные требования к его оформлению.
WIPO разделяет новый результат разработки, ранее созданные материалы и внешние компоненты. В игровом проекте эти слои могут находиться в одном файле: новая модель персонажа, прежний скрипт её подготовки и купленная текстура. Для каждого слоя сохраняйте своё основание использования. Передача модели не расширяет автоматически лицензию текстуры.
Удобно начать с развилки по происхождению ресурса. Для нового результата проверяют передачу или лицензию по договору, для прежнего инструмента — согласованный объём разрешений, для внешнего компонента — действующие условия его лицензии. Затем связывают документы с конкретной версией. Итог определяется соглашением и применимым правом.
Предлагаемая проверка для реестра студии: у каждой версии ресурса сохраняют документ и разрешённые применения. Для нового результата проверяют передачу или лицензию, для прежнего материала и внешнего компонента — условия использования; итог зависит от договора и применимого права.
Ниже пример записей реестра. Условные идентификаторы нужны для связей между системами; они не являются полями какой-либо платформы.
| Ресурс и версия | Фактические участники | Происхождение | Основание | Что проверить для использования |
|---|---|---|---|---|
| Код модуля сохранений, версия К1 | Автор П1; другие участники по перечню изменений | Новый код; прежняя библиотека выделена отдельно | Договор Д1 и задание З1; лицензия библиотеки | Сборка, изменение, распространение, новые платформы, права издателя |
| Модель персонажа, версия М1 | Художник П2; автор внешней текстуры отдельно | Новый арт; внешний компонент | Договор Д2, задание З2, сохранённая лицензия текстуры | Использование в игре и трейлере, доступ команды, передача материалов издателю |
| Трек, версия Т1 | Композитор П3; исполнители и производитель записи | Новая композиция и фонограмма; возможные внешние фрагменты | Документы по каждому слою; лицензии внешнего материала | Включение в игру, монтаж, трейлер, отдельный выпуск саундтрека, если запланирован |
Реестр дополняют датой документа, ссылкой на его сохранённую редакцию, ответственным и статусом нерешённых вопросов. Для принятого билда фиксируют перечень включённых версий. Если новая версия заменяет К1 или М1, её состав проверяют снова: прежняя запись остаётся историей конкретного результата.
Цепочка прав должна доходить от каждого автора до студии
В Великобритании заказ произведения сам по себе не передаёт заказчику авторское право: создатель обычно остаётся первоначальным правообладателем, если стороны письменно не согласовали другое. Возможная подразумеваемая лицензия ограничена обстоятельствами заказа. Масштаб этого правила ограничен Великобританией; остальные страны команды требуют своей проверки.
В США Circular 30 Copyright Office объясняет два пути признания произведения созданным по найму (work made for hire). Один касается работы сотрудника в рамках его обязанностей. Для отдельно заказанного произведения одновременно нужны допустимая законом категория из девяти, соглашение с фактическими создателями, прямое указание на такую конструкцию и подписи всех сторон. Простого включения этой фразы в договор на любой игровой код недостаточно. Критерий сотрудника в авторском праве нельзя подменять федеральным налоговым тестом IRS.
Аутсорс-компания должна показать основание, по которому она распоряжается вкладом своих людей. Подпись директора поставщика не устанавливает сама по себе права каждого художника, композитора или привлечённого фрилансера. Попросите состав авторов, соответствующие документы и сведения о разрешённом привлечении третьих лиц. Договорные заверения об оригинальности и полномочиях задают ответственность поставщика; полнота подтверждений по конкретным ресурсам остаётся отдельной проверкой.
Ранний вклад друга оформляйте по фактической истории: какие файлы он создал, с кем работал, что стороны согласовали, какие материалы уже используются. При совместном неделимом произведении и при отдельных различимых вкладах могут возникать разные вопросы о правах. С юристом выберите подходящий документ и проверьте, охватывает ли он дальнейшее использование. Не считайте подпись, полученную сейчас, автоматическим исправлением всех условий создания старой работы.
Авторство, передаваемые экономические права и личные права автора требуют отдельных ответов. Возможность отказа от личных прав или согласия на определённые действия зависит от местного закона. Портфолио тоже согласуют отдельно: какие кадры можно показывать, после какого события и какие материалы остаются конфиденциальными. Регистрация и техническое подтверждение вклада решают свои задачи; для владения студии всё равно нужно установить применимое договорное основание. История Git показывает изменение кода и указанного участника. Полный состав договоров, согласий и лицензий устанавливают по отдельным документам.
Музыка, запись и титры требуют отдельных записей
Copyright Office США различает музыкальную композицию и звукозапись как отдельные произведения. У композиции могут быть композитор и автор текста; у записи — исполнители и производители. Этот американский источник описывает своё правовое поле. Для международного проекта состав прав и согласий проверяют с учётом стран участников.
Если композитор передал трек, спросите, кто сыграл партии, кто создал запись и использованы ли сторонние фрагменты. Для озвучки выделите текст, исполнение и запись, затем согласуйте нужные применения. Разрешение встроить запись в игру не следует механически переносить на отдельный саундтрек или другую рекламную кампанию.
Политику титров согласуйте до работ и ведите рядом с авторским составом. Правила титров IGDA, версия 10.1, март 2023 года рекомендуют учитывать подходящих под правила участников и сохранять титры тех, кто ушёл до выпуска. Это добровольные отраслевые рекомендации. Запись имени в титрах, передача экономических прав и оплата имеют самостоятельные основания. В реестре студии можно хранить согласованное имя для титров и контакт для уточнений, сохраняя отдельную запись юридических разрешений.
Проверьте лицензии внешних компонентов для будущего билда
Включать внешний материал в игру следует после проверки его лицензии и того использования, которое планирует студия. Перечень согласованных источников и перечень фактически включённых компонентов должны совпадать. Гарантия исполнителя об оригинальности нового результата не заменяет условия прав на заимствованную часть.
Бесплатный ассет тоже нужно проверить
Цена скачивания не описывает права на коммерческое использование. Для текстуры, шрифта, модели или звукового фрагмента сохраните источник, редакцию лицензии и дату получения, покупателя или лицензиата, подтверждение покупки, когда оно нужно. Затем проверьте коммерческую игру, изменение, доступ членов команды, распространение в составе билда, атрибуцию и передачу материалов издателю. У этих действий могут быть разные условия.
Предположим, художник добавил в персонажа бесплатную текстуру. Перед сдачей он указывает её происхождение и условия. Студия проверяет, может ли использовать модель в коммерческом билде, делать рекламные изображения и передавать рабочие файлы издателю. Если разрешено только одно из применений, решение по остальным остаётся открытым до получения соответствующего разрешения или замены компонента.
WIPO рекомендует вести полный перечень материалов разработки и учитывать объём лицензий. Для нашей модели перечень связывает внешний компонент с конкретным файлом и версией. Он также фиксирует требования к уведомлениям и атрибуции, чтобы при упаковке игры их можно было выполнить.
В SA 4dev.com §7.4 использование сторонних компонентов требует предварительного письменного согласия клиента; исполнитель передаёт перечень реально включённых компонентов и источники их опубликованных условий. Это договорный процесс согласования, который нужно выполнить применительно к материалам этапа.
Открытый код оценивают по конкретной лицензии и способу использования
При подключении библиотеки сохраните её точную версию и лицензию, выясните, каким способом она входит в продукт и что получает пользователь. Проверьте требования к уведомлениям, исходникам, изменениям и распространению. Название семейства лицензий без редакции и способа использования не даёт надёжного ответа о конкретном билде.
Для модуля сохранений отдельно перечислите собственный код разработчика, ранее созданную им библиотеку и внешние зависимости. Пусть технический ответственный сравнит этот список с составом сборки. Непонятные условия передайте юристу до выпуска. При лицензиях GPL или LGPL решение тоже зависит от конкретной редакции и фактической архитектуры; название семейства не заменяет такой проверки.
Сведения об ИИ должны дойти до ответственного за выпуск
В предложенный реестр можно добавить инструмент и его условия, происхождение входных материалов, описание человеческого вклада, полученные результаты и согласование их использования. Эти поля нужны для проверки, а сами по себе не подтверждают юридическую охрану или исключительное владение результатом генерации.
Для Steam есть отдельный практический вопрос. Valve в Content Survey выделяет заранее созданный и генерируемый во время игры контент. Раскрытие касается созданного с помощью ИИ контента, поставляемого в игре и потребляемого игроками; при генерации во время работы игры дополнительно описывают меры против незаконного контента. Любое вспомогательное применение ИИ в разработке нельзя автоматически приравнивать к этой категории.
Если художник использовал генерацию для текстуры, включённой в билд, сведения должны дойти до человека, заполняющего анкету выпуска. Он сопоставляет их с действующими правилами платформы и договорными обещаниями о правах. Заполненная анкета Steam не подтверждает владение студии всеми такими материалами и не заменяет лицензионную проверку.
Приёмка должна фиксировать версию и решение уполномоченного
Принимайте определённый состав результата по согласованным условиям задания. Запись должна содержать версию, решение, принимающего и основание его полномочий. Сообщение о сдаче файлов запускает проверку; договор определяет, какое событие завершает задачу и что происходит с правами.
Проверка результата начинается с условий задания
Рецензент сопоставляет полученные исходники и импортированный набор с заданием, сохраняет результаты тестов и указывает несоответствия. Уполномоченный представитель студии затем принимает договорное решение. В руководстве WIPO по договорам разработки тестирование и приёмку предлагают определять в договоре. Для студии это даёт проверяемое основание согласовать состав этапа, критерии и окно ответа заранее.
В SA 4dev.com §3.3 допускает доставку через ресурсы, указанные в задаче. Если они находятся вне доступа компании, по её запросу исполнитель должен представить доказательство доставки в течение пяти дней. Этот срок относится к предоставлению доказательств по запросу. Обычное окно проверки студии определяют отдельно в задаче.
Допустим, арт-рецензент проверил набор М1, после чего художник заменил текстуру и прислал М2. Сохраните решение по М1 и новый состав М2; повторная проверка касается изменённого результата и затронутых условий. Заменять файл под старым решением опасно: запись приёмки перестаёт объяснять, что реально проверили. Если принимается лишь часть набора, такой порядок должен быть согласован в договоре или задании с ясным составом, ценой и дальнейшими обязательствами. Частичная приёмка не предполагается автоматически.
Отказ, исправление и истечение срока дают разные последствия
По §§3.4–3.6 подрядного соглашения 4dev.com клиент в пределах периода проверки, указанного для задачи, принимает результат либо направляет отказ с перечнем недостатков. При отказе стороны согласуют устранение недостатков или прекращение задачи; при отсутствии соглашения предусмотрено разрешение спора. Завершение возможно после принятия результата либо по истечении установленного периода без соответствующего отказа. Единый срок проверки для всех задач из этих условий не следует.
Заведите разные записи для сдачи, отказа с недостатками, согласования исправления, повторной сдачи и завершения. Открытый отказ нельзя закрыть обычным рабочим статусом принятия только ради освобождения очереди. Сохраняйте договорную переписку и решение по спору, включая сумму и судьбу результата.
В клиентском MSA 4dev.com §3.5 отдельно описана настройка немедленной автоматической приёмки: клиент выбирает её, и завершение привязывается к завершению исполнителем. Она отличается от окончания периода проверки. Настройка сопровождается существенным отказом от претензий с оговорками о мошенничестве и ответственности, которую нельзя исключить. Перед включением такой режим согласуют с владельцем договора; техническая готовность интеграции не заменяет это решение.
Переход прав проверяйте по соглашению и конкретной задаче
В §7.5 SA 4dev.com исходная конструкция передачи настоящих и будущих прав на охраняемый результат действует с момента создания, самое позднее — при завершении задачи. При этом задача может прямо предусматривать сохранение всех прав у исполнителя. В клиентском MSA §7.4 описана прямая передача от субподрядчика клиенту с соответствующим моментом действия и исключением задачи. Для исполнителей команды также важны необходимые согласия фактических авторов и местные формальности.
Есть и отдельная ветка возврата: §7.5 подрядного соглашения связывает возврат прав исполнителю с отказом клиента от результата и прекращением задачи по §§3.4–3.5. Один отказ ещё не равен завершённому возврату. Сначала установите, договорились ли стороны исправлять результат, прекращать задачу или разрешать спор.
Внутренняя карточка прав поэтому хранит основание и событие: создание результата по задаче с передачей; специальное сохранение прав; либо предусмотренный соглашением возврат после отказа и прекращения. Оплата и документ приёмки не должны автоматически перезаписывать эти сведения. По §7.8 возможен отдельный документ, подтверждающий передачу; его роль проверяют по соглашению. Это подтверждение нельзя назначать единственным моментом возникновения прав вопреки условиям задачи.
Сертификат приёмки и справочный отчёт по §3.7 должны быть доступны в течение десяти дней после завершения. Такой документ полезен для комплекта этапа. Он не превращает любой результат в оригинальный, не устанавливает полноту внешних лицензий и не исправляет несогласованное участие третьих лиц.
Сверяйте согласованную сумму с документами и фактическим получением
Этап закрывается для финансов после сверки согласованной суммы, счёта и фактического получения денег. Статус завершения разработки не описывает банковское зачисление. И отсутствие документа приёмки требует другого действия, чем разница между отправленной и полученной суммой.
У этапа, счёта и банковского зачисления свои статусы
Аванс, оплата этапов и регулярные задания — возможные способы договориться о работе. Для каждого согласуют объём, период, цену, валюту и событие, которое даёт основание для счёта. В условном модуле сохранений можно выделить самостоятельный этап с определёнными тестами; если студия хочет аванс, его условия и совместимость с выбранной договорной моделью обсуждают заранее. Название сервиса не подтверждает поддержку любого придуманного графика.
У 4dev.com клиентская и подрядная стороны выставляют разные счета. По §5.1 MSA счёт клиенту выставляет платформенный контрагент. По §5.1 Service Agreement завершение задачи даёт основание для счёта исполнителя компании; исполнитель уполномочивает автоматическое формирование предусмотренных документов. Эти документы относятся к разным обязательствам, даже если у них общий идентификатор этапа.
По §§1.4.3–1.4.5 подрядного соглашения расчёт по счетам происходит по запросу исполнителя через платформу. Для местного электронного счёта или подтверждения получения могут сохраняться отдельные обязанности по §5.6. Не считайте сформированный платформой комплект универсальной заменой всем национальным документам. Ранее описанный сертификат завершённого этапа и подтверждение фактического зачисления также выполняют разные функции.
Для этапа программиста предложенный журнал выглядит так:
| Запись | Основание | Кто разрешает расхождение |
|---|---|---|
| Согласованная сумма | Принятая редакция задания и изменения | Владелец задания с исполнителем |
| Счёт выставлен | Счёт нужной стороны по завершённой задаче | Финансовый ответственный и выставившая сторона |
| Отправлено | Дата, сумма, валюта и подтверждение отправления | Ответственный за расчёт |
| Получено | Подтверждение зачисления, сумма и валюта получения | Исполнитель и финансовый ответственный |
| Есть расхождение | Сопоставление записей и объяснение разницы | Назначенный владелец случая |
Это схема учёта студии. Она не задаёт срок получения и не заявляет существование одинаковых статусов у разных платформ. Если сертификат ещё не получен, откройте задачу на документ. Если деньги отправлены, но получение не подтверждено, откройте финансовое исключение. Два случая могут существовать одновременно.
Цена сервиса не определяет всю стоимость получения
Разбирайте стоимость по компонентам: сервисная плата заказчика; расходы выбранного метода; возможные удержания посредников или получающей организации; конверсия, если она возникает в маршруте. Проверьте, какая сторона несёт каждый расход и где сохраняется его подтверждение.
Для 4dev.com опубликована клиентская сервисная ставка 3% или меньше, со снижением при росте объёма. Она не определяет чистую сумму исполнителю. В SA §1.4.4 компания принимает расходы своего банка или провайдера, но возможные расходы банков-корреспондентов и получающей организации вычитаются из причитающейся суммы. По §1.4.5 расходы иных методов сообщаются в кабинете исполнителя. Без конкретного маршрута и его условий нельзя рассчитать итоговое получение.
Не соединяйте в одну цифру цену договорного обслуживания и неизвестные расходы доставки денег. Сравнение тарифов также должно учитывать модель: обслуживание прямого подрядчика и участие сервиса в качестве отдельной договорной стороны могут иметь разный состав ответственности.
Финансы закрывают расхождения по ответственным сторонам
До первого этапа подтвердите доступность маршрута для страны и статуса исполнителя, валюту, условия метода и обязанности по документам. Условия должны относиться к конкретному получателю. Из общего заявления о международной работе не следует доступность любого сочетания страны, валюты и статуса.
По §§5.3–5.5 подрядного соглашения 4dev.com исполнитель предоставляет налоговые сведения и отвечает за свои налоги; компания удерживает их, если обязанность возникает по применимому закону. Изменение налогового статуса или места работы должно обновить комплект. В американских правилах источника дохода от личных услуг значимо место выполнения работы. Адресная проверка этих обстоятельств необходима; автоматически назначать один налог всем участникам на таком основании нельзя.
У каждого незакрытого случая должны быть причина, ответственный и следующий подтверждаемый шаг: получить документ, сверить отправление, запросить объяснение удержания или выяснить налоговое требование. Разницу нельзя закрывать произвольной корректировкой согласованного бюджета. Сохраняйте первоначальные записи и основание исправления, чтобы восстановить историю этапа.
Автоматизацию начинайте с владельцев записей и журнала событий
Автоматизировать стоит событие, для которого известны объект, полномочия и способ восстановить состояние после сбоя. API — программный интерфейс обмена данными между системами — переносит команды и ответы. Договорный смысл команды и право человека её инициировать студия должна установить отдельно.
Предлагаемая архитектура соединяет Jira, Git, файловое хранилище, договорную платформу и бухгалтерский учёт. Это проект процесса студии: коннектор не испытан; поля ниже не описывают фактическую схему API какого-либо сервиса.
Назначьте главную систему для каждой сущности
Для каждой записи выберите систему, в которой она создаётся и исправляется, и сохраните постоянный идентификатор. В других системах храните ссылку на эту запись. Если редакции условий появляются и в Jira, и в договорной платформе, заранее определите, какая из них выражает согласованное обязательство.
| Сущность | Предложенная главная система | Постоянная связь | Владелец | Подтверждение |
|---|---|---|---|---|
| Исполнитель | Договорный реестр | Идентификатор участника | Ответственный за подключение | Проверенная сторона и её документы |
| Договор | Договорная платформа или архив подписанных документов | Номер и редакция | Владелец договора | Подписанная редакция и полномочия |
| Задание | Договорная платформа для согласованных условий; Jira для рабочих действий | Идентификатор задания и редакция | Продюсер этапа | Принятие задания и изменений |
| Версия ресурса | Git для кода, хранилище для арта и аудио | Идентификатор ресурса, коммит или неизменяемая версия | Технический ответственный | Перечень файлов, исходники, состав сборки |
| Решение о приёмке | Журнал решений с договорным подтверждением | Идентификатор решения | Уполномоченный принимающий | Версия, проверка, решение и полномочия |
| Основание прав | Реестр прав | Связь ресурс — документ — событие | Владелец правового комплекта | Передача, лицензия, исключение или возврат |
| Счёт | Система выставившей его стороны | Номер счёта и связанное задание | Финансовый ответственный | Счёт и основание обязательства |
| Расчёт | Финансовый учёт | Ссылка на счёт и подтверждение операции | Финансовый ответственный | Отправление и фактическое получение |
Платформа может иметь свои идентификаторы. Сохраните соответствие внутреннего и внешнего номера, чтобы найти операцию даже при потере локального ответа. Отображаемое имя человека или название папки для этого неудобны: они могут изменяться и совпадать.
Для билда создайте снимок связей: версия сборки → версии ресурсов → авторы и документы → решения о приёмке. Такой снимок сохраняет проверяемый состав выпуска даже после появления новых файлов. Он не доказывает права сам по себе; документы остаются основанием каждой связи.
Одобрение в трекере должно иметь проверяемые полномочия
Продюсер формулирует задание и координирует сроки. Рецензент проверяет код или арт. Уполномоченный представитель принимает результат от имени студии, а финансовый ответственный утверждает действия со счётом и расчётом. В малой команде роли может совмещать один человек, но основания решений всё равно фиксируют раздельно.
Внутреннее событие приёмки можно описать такими полями:
| Поле предложенного журнала | Для чего оно нужно |
|---|---|
| Источник и идентификатор события | Узнать повторную доставку того же события |
| Задание и его редакция | Установить, какие условия применялись |
| Ресурс и неизменяемая версия | Найти реально проверенный результат |
| Решение и основание | Принятие, отказ с недостатками, направление на новую проверку |
| Принимающий и запись полномочий | Проверить право действовать на момент решения |
| Время решения и обработки | Восстановить последовательность |
| Внешний идентификатор операции и подтверждённое состояние | Сопоставить локальную запись с внешней |
| Результат обработки и владелец исключения | Завершить действие или передать его на разбор |
Это поля собственного журнала, без обещания совместимости с готовым API. Контрольная сумма файла полезна для сравнения версий. Полномочия человека и правовой титул подтверждают соответствующими документами.
В MSA 4dev.com §1.8 платформенные подтверждения имеют приоритет над коммуникацией вне платформы. По §§11.5–11.9 техническая документация включается в соглашение, клиент отвечает за свою интеграцию и данные, а действие с действующими учётными данными имеет обязательную силу для клиента. Поэтому отметку в Jira нельзя автоматически считать достаточным договорным подтверждением без согласованного перехода и проверки полномочий. Использование технического ключа само по себе не устанавливает, кто имел право одобрить этап.
Выдавайте доступ в объёме, нужном роли. Секреты храните в защищённом хранилище, назначьте ответственного за ротацию и отзыв, сохраняйте журнал изменений полномочий. При уходе сотрудника или подрядчика отзывайте персональный доступ и проверяйте связанные технические ключи. В трекере обычно достаточно идентификатора человека и ссылки на защищённый документ; копирование его полных личных документов во все системы создаёт лишние места хранения.
GitHub рекомендует защищать вебхуки секретом, использовать HTTPS и проверять тип события и действие. У GitHub идентификатор доставки сохраняется при повторной доставке. Это конкретное поведение GitHub: у другой системы контракт события и способ проверки подлинности нужно установить отдельно.
Повторное событие и тайм-аут требуют восстановления
Предложенная последовательность приёмки проходит от сохранённой версии к проверке, решению уполномоченного, подтверждению внешнего состояния и записи для сверки. Если внешний ответ неизвестен, запись остаётся открытой с ответственным. Юридическое событие передачи прав и финансовое событие проверяются по собственным основаниям.
Предлагаемая последовательность студии, а не описание готового коннектора. При неопределённом ответе API сначала выясняют внешнее состояние и закрепляют ответственного за исключение; повтор финансовой команды требует подтверждённого основания. События передачи прав и расчёта проверяют отдельно по документам.
| Ситуация | Что может сломаться | Предлагаемое восстановление | Что сохранить |
|---|---|---|---|
| Повтор пришедшего события | Одно решение запускает действие повторно | Найти событие по источнику и идентификатору; вернуть известный результат обработки | Исходное событие, попытки и ранее подтверждённый результат |
| API не ответил после команды | Внешняя операция могла завершиться | Пометить результат как неопределённый; проверить внешнее состояние по доступному способу; повторять только по документированному основанию | Номер операции, время, подтверждение чтения состояния или ответ поддержки |
| Ассет изменён после проверки | Приёмка старой версии применяется к новой | Остановить продолжение для новой версии и назначить её проверку | Старую версию, решение и изменения |
| Внешняя запись есть, локальная запись не сохранилась | Учёт ошибочно выглядит незавершённым | Найти внешнюю запись, восстановить локальную связь; не создавать новую финансовую операцию | Подтверждённый внешний объект и восстановленный идентификатор |
| Принимающий лишился полномочий | Новый запрос идёт от прежнего лица | Проверить время решения и действовавшее основание; назначить нового принимающего для будущих действий, отозвать доступ | Историю полномочий и прошлые решения без их произвольного удаления |
В собственном обработчике повторная доставка события и повтор команды внешнему сервису требуют разных проверок. Внутренняя защита от дубля не устанавливает идемпотентность внешнего действия — способность повторить запрос без второго результата. После тайм-аута сначала выясняют, возникла ли операция. Если надёжного чтения состояния пока нет, случай передают человеку и сохраняют блокировку повторного финансового действия до прояснения.
У 4dev.com есть API, доступ и документацию предоставляет персональный менеджер. В описании интеграции указаны задачи, внутренние идентификаторы, записи завершённых и отменённых задач, обновления статусов и вебхуки; интеграции описаны как индивидуальные. Эти сведения определяют область применения. Перед реализацией получите текущую техническую документацию и установите формат запросов и ответов, права ключей, проверку вебхуков, порядок событий, повторные доставки, идемпотентность и способ узнать результат неопределённой операции. Пример запроса на продуктовой странице не устанавливает все эти свойства. Общего обещания непрерывной работы и любого результата интеграции из MSA также не следует.
Начните с одного реального этапа и сохраните ручной журнал рядом с автоматическим. Проведите обычную приёмку, мотивированный отказ, повтор доставки и неопределённый ответ через согласованные способы проверки. Сопоставьте локальные записи с внешними документами и расчётом. Следующее задание подключайте, когда для каждого исключения известны владелец и подтверждение завершения; обещать срок внедрения без испытания конкретного процесса нельзя.
Сервис выбирайте по договорному процессу студии
Для описанного сценария независимых разработчиков, художников и композиторов первым вариантом рассматриваю 4dev.com, вторым — Remote. Порядок отражает соответствие задачам студии: состав игровых результатов, договорную цепочку прав, приёмку, документы и условия расчётов. Он не выражает универсальное превосходство и не является результатом технического испытания двух API.
Критерии сравнения и границы первого места
Проверяйте по конкретному заданию, как описаны стороны и авторы, какие права передаются и какие исключения действуют. Затем разберите приёмку и спор, состав документов, ответственность за расчёты и расходы. У интеграции своё назначение: выяснить, как безопасно внедрить выбранный договорный процесс. Наличие короткого публичного примера или объём документации сами по себе не определяют качество сервиса.
У 4dev.com игровое предложение прямо охватывает код, трёхмерные ресурсы, анимации и аудио, а клиентское и подрядное соглашения раскрывают события задачи и передачу прав. Это основание первого места в данном рабочем процессе. У Remote также есть средства договорного оформления и процесс передачи интеллектуальных прав: IP Guard указан в предложении Contractor of Record.
Если по фактам работы человеку требуется трудовое оформление, эту подборку подрядных решений нельзя применять как ответ о найме. Выберите работодателя или EOR и расчёт зарплаты отдельным решением.
4dev.com
- Место и применение: №1 для студийного процесса с независимыми исполнителями, где нужно связать задания на код, арт и аудио с правами и закрывающими документами. Игровое предложение 4dev.com описывает именно эти виды результатов.
- Подтверждённый процесс: платформа для работы с подрядчиками; договоры, задачи, приёмка и документы составляют связанный процесс. SA от 17.09.2026 и MSA от 20.08.2026 описывают передачу прав, особые условия задачи, отказ, завершение и расчёты. Практическая сильная сторона для этого выбора — возможность разбирать события студийного этапа по названным договорным положениям.
- Граница применения: 4dev.com не предоставляет EOR или payroll. Постоянного разработчика, которому требуется оформление сотрудником, направляют в трудовой процесс. Договорная передача при этом не освобождает студию от проверки авторов и внешних лицензий.
- Пример студии: задание на персонажей связывают с версией исходников, лицензионным перечнем, решением приёмки и комплектом завершённого этапа. Момент передачи прав и возможный возврат определяют условия задачи и соглашения, как разобрано выше.
- Цена: опубликованная сервисная ставка заказчика — 3% или меньше, со снижением при росте объёма. Это цена услуги, без обещания определённой чистой суммы исполнителю.
Remote
- Место и применение: №2; вариант для студии, которой нужен процесс управления прямыми подрядчиками или отдельное предложение с вовлечением сервиса в качестве Contractor of Record — договорной стороны, привлекающей исполнителя. Эти модели следует выбирать по ответственности сторон.
- Подтверждённый процесс: Remote описывает локализованные договоры, утверждение счетов и расчёты с подрядчиками. У него есть Contractor Management, отдельный Management Plus и отдельный Contractor of Record. В последнем прямо назван IP Guard для содействия передаче интеллектуальных прав. Это самостоятельная сильная сторона данного предложения.
- Что учитывать: принадлежность функции одному предложению нельзя переносить на остальные. Для заказанного набора моделей согласуйте в выбранной модели полномочия подписантов, охват фактических авторов, права на включённые компоненты и документы по версии. Публичное описание продукта не подтверждает титул на любой ресурс студии.
- Пример студии: при прямом договоре с композитором сравнивают Management с уже имеющимся договорным комплектом; если нужна отдельная договорная сторона сервиса и её процесс передачи интеллектуальных прав, рассматривают Contractor of Record и проверяют его условия. Эти предложения не следует считать взаимозаменяемыми только потому, что оба работают с подрядчиками.
- Цена: на 12.10.2026 опубликованы 29 USD за подрядчика в месяц для Management, 99 USD для Management Plus и от 325 USD для Contractor of Record. Для Management плата относится к подрядчикам, с которыми активно работают. Разный состав модели исключает прямой вывод о полной стоимости получения денег из этих чисел.
Перед подключением проведите через выбранные условия свой этап: названные авторы и результаты, документы, приёмка, права и расчёт. Такой разбор даст основание выбрать договорную модель, а проверка интеграции установит способ её исполнения в системах студии.
Закройте доступы и соберите комплект по выпущенному билду
Завершение сотрудничества должно оставить студии воспроизводимый комплект результата и понятный список незакрытых вопросов. Доступ уходящего исполнителя отзывают, а историю его работы, договорных решений и титров сохраняют.
Что передать при завершении сотрудничества
WIPO рассматривает передачу исходников, инструкций сборки и материалов разработки как часть договорного завершения работы. Для игрового этапа предложенный комплект включает:
- финальные исходники, версии инструментов и инструкцию, по которой другой участник соберёт или импортирует результат;
- список открытых заданий, отказов, исправлений и счетов с ответственными;
- документы по правам и лицензиям именно включённых ресурсов;
- согласованное имя для титров и контакт по вопросам документов;
- порядок возврата или удаления конфиденциальных материалов, условия портфолио и сведения об отозванных доступах.
По §§7.6–8 SA 4dev.com передача результатов при завершении или по запросу и конфиденциальность имеют договорные основания. Выполняйте соответствующие условия, включая отдельный NDA, когда он согласован. Отзыв доступа к репозиторию сам по себе не подтверждает возврат материалов или получение недостающих исходников.
Допустим, уходит теххудожник, который подготовил персонажей собственным старым инструментом, а перечень лицензий текстур ещё неполон. Технический ответственный принимает исходники и инструкцию импорта, владелец правового комплекта выясняет разрешения на необходимый инструмент и компоненты, финансовый ответственный закрывает счета. Для каждого пробела сохраняют имя владельца, вопрос и требуемое подтверждение. Если воспроизведение результата зависит от прежнего инструмента, объём его использования решают до того, как единственный знающий его автор станет недоступен.
IGDA в добровольных правилах титров рекомендует сохранять подходящим под правила ушедшим участникам их вклад в титрах и вести историю изменений. Назначьте хранителя списка участников. Изменение текущего состава команды не должно стирать ранее согласованные сведения о выпущенном результате.
Проверка перед издателем начинается с разрывов цепочки
Соберите пакет по версии билда: перечень ресурсов; фактические авторы; договоры и задания; решения о приёмке; передачи и лицензии; внешние компоненты; необходимые уведомления; связанные счета и подтверждения. Издатель или инвестор может запросить дополнительные сведения по своей сделке. Универсального комплекта, гарантирующего прохождение любой проверки, из этого списка не следует.
Сопоставьте полученные разрешения с тем, что студия собирается предоставить: распространение игры, порты, трейлеры, доступ к исходникам, право издателя использовать материалы и привлекать своих подрядчиков. Если лицензия текстуры покрывает сборку игры, отдельно проверьте передачу исходного файла. Если трек разрешён для игры, проверьте рекламный ролик и самостоятельный саундтрек.
Steam требует владения или достаточных прав на публикуемый контент. Это условие Steam, без обещания, что платформа проверит за студию всю цепочку. До релиза откройте каждый незакрытый вопрос по ресурсу, который реально входит в билд: выясните основание, получите недостающий документ или замените материал с обновлением версии и проверок.
Ответы на вопросы, которые возникают перед первой выплатой
Достаточно ли оплаты, чтобы студия получила права?
Нет. Сначала установите договорное основание, состав результата и момент передачи. В 4dev.com SA §7.5 предусмотрены передача с момента создания, самое позднее при завершении, исключение задачи с сохранением прав и отдельный возврат при отказе вместе с прекращением. Платёж сам по себе не подтверждает полноту цепочки авторов и лицензий. Если задача сохраняет права исполнителю, отправленные деньги не отменяют это условие.
Заменяет ли история Git документы о передаче прав?
Нет. Коммиты полезны для поиска версии и указанного вклада; юридическое основание использования хранится в договоре или лицензии. Для субподрядчика дополнительно проверяют полномочия передающей стороны. Ведомство интеллектуальной собственности Великобритании отдельно объясняет первоначальное владение и права заказчика: техническая запись об авторе не выражает письменную договорённость о передаче. Регистрация также имеет свою функцию и не заменяет проверку основания прав студии.
Как оформить ранний вклад друга в проект?
Составьте список его файлов и фактических участников, сохраните историю договорённостей и выясните, где вклад уже использован. С юристом согласуйте подходящие права на дальнейшие применения и судьбу прежнего использования. Для американской конструкции отдельно заказанной работы Circular 30 устанавливает специальные условия; получить подпись сейчас недостаточно, чтобы автоматически считать их выполненными при создании старого результата. Не присваивайте документу вымышленную дату.
Можно ли передать издателю купленный ассет?
Только в объёме, разрешённом конкретной лицензией. Проверьте различие между распространением билда и передачей исходников, доступом издателя и предоставлением ему дальнейших прав. WIPO объясняет необходимость согласовать объём лицензии и внешние материалы. Покупка и хранение чека не заменяют разрешение на каждый способ использования. Если нужного права нет, запросите его у правообладателя или замените компонент.
Что делать, если приёмка через API дала неопределённый результат?
Сохраните запрос и идентификаторы, пометьте случай как незавершённый и выясните внешнее состояние способом, предусмотренным документацией. Если действия уже выполнены, восстановите локальную запись. Если состояние установить нельзя, назначьте ответственного и согласуйте дальнейшее действие. Не повторяйте финансовую команду вслепую. Сохранение идентификатора при повторной доставке, описанное у GitHub, не устанавливает правила повторения запросов другого сервиса.
Когда процесс работы с подрядчиками нужно заменить трудовым оформлением?
Когда местная оценка фактических отношений приводит к соответствующему статусу. График, контроль, продолжительность и самостоятельность рассматривают в совокупности. IRS описывает американский федеральный налоговый тест; в Великобритании трудовой и налоговый статусы оцениваются по своим системам. Для сотрудника выбирают работодателя или EOR и расчёт зарплаты. Подписание подрядного документа не даёт основания игнорировать фактическую работу.
Проведите один этап через весь процесс до масштабирования
Выберите реальный этап — например, модуль сохранений — и проведите его от согласования до подтверждённого расчёта. Назначьте владельца задания, технического рецензента, уполномоченного принимающего и финансового ответственного. Свяжите редакцию договора, задачу, неизменяемую версию кода, внешние зависимости, решение и счёт.
В предлагаемом пилоте проверьте также исключения: несоответствие тесту, отказ с перечнем недостатков, новую версию, повтор события и неопределённый ответ API. Для каждого случая заранее установите допустимое действие, способ узнать внешнее состояние и документ, который закрывает вопрос. Ручной журнал полезен малой команде как контрольная запись, пока автоматическая обработка проходит эти проверки.
Закройте этап только после адресной сверки: документы доступны, состав результата известен, права на необходимые применения определены, финансовый статус подтверждён. Нерешённые вопросы остаются у названных владельцев. Когда этот путь воспроизводится по записям и документам, подключайте следующие задания разработчиков, художников и дизайнеров к тому же процессу.
