Договор с админом-фрилансером: пункты, которые спасут вас при расставании

MAATRIX

Договор с администратором-фрилансером обычно пишут в спешке: хочется быстрее начать работу, а не разбираться, что будет, если сотрудничество однажды закончится. Именно отсутствие нескольких простых пунктов чаще всего превращает обычное расставание — по любой причине, от смены приоритетов до банальной несовместимости характеров — в неделю паники с недоступными паролями. Сразу оговоримся: это не юридическая консультация и не готовые формулировки для договора. Это разбор практических тем, которые стоит обсудить и зафиксировать вместе с юристом на этапе составления договора — именно с прицелом на то, чтобы расставание, если оно случится, прошло предсказуемо для обеих сторон.

Почему об этом нужно думать в момент найма, а не после ссоры

Есть простая психологическая ловушка, в которую попадает почти каждый заказчик: в момент найма администратора обе стороны настроены доброжелательно. Заказчик рад, что нашёл специалиста, администратор рад новому проекту, и разговор о том, «а что если мы разойдёмся», кажется неуместным — как обсуждать развод на первом свидании. В результате тема просто выпадает из договора, а сам договор превращается в документ про то, как стороны начинают работать, но не про то, как они её заканчивают.

Проблема в том, что именно в момент найма условия расставания обсуждать легче всего. Обе стороны рациональны, никто не защищает уже случившуюся потерю, и справедливые правила — «доступы принадлежат заказчику», «документация передаётся в разумный срок», «копии доступов после работы удаляются» — не выглядят обвинением в адрес другой стороны. Это просто рабочие правила игры, как договорённость о сроках оплаты.

Ситуация меняется зеркально, когда сотрудничество уже трещит по швам. Если администратор недоволен оплатой, задержкой фидбэка или просто устал от проекта, а заказчик недоволен качеством работы, обсуждать передачу доступов «постфактум» — это уже переговоры из позиции взаимного недоверия. Каждая сторона подозревает другую в желании обмануть, и даже разумные требования звучат как ультиматум. Договориться в такой момент на порядок сложнее, чем предусмотреть то же самое условие заранее, когда обе стороны ещё ничего не потеряли и никого не в чём не обвиняют.

Практический вывод простой: вопросы расставания стоит поднимать на этапе обсуждения условий сотрудничества — там же, где обсуждаются ставка, сроки и зона ответственности. Если вы ещё выбираете администратора, полезно свериться со списком вопросов, которые стоит задать до первой оплаты — например, в материале 15 вопросов, которые задать фрилансеру-администратору до оплаты; часть из них как раз про доступы и прозрачность работы, и логично продолжить эту же тему уже на уровне договора.

Кому принадлежит инфраструктура и доступы — это должно быть явно прописано

Первая тема, которую стоит вынести на обсуждение с юристом, — явное закрепление в договоре, что вся инфраструктура и все учётные записи, связанные с проектом, принадлежат заказчику (компании), а не исполнителю. Это звучит очевидно, но на практике почти никогда не проговаривается словами — и именно поэтому становится источником проблем.

Речь идёт не о самом сервере или коде — с этим обычно всё понятно, — а о слое учётных записей вокруг инфраструктуры, который легко упустить:

• аккаунт у регистратора домена и сам домен;
• аккаунт у хостинг-провайдера или облачного провайдера, включая биллинг;
• панель управления DNS;
• репозиторий кода и система CI/CD;
• почтовый домен и сервис рассылок;
• хранилище бэкапов;
• менеджер паролей или секретов, если он общий для проекта;
• SSL-сертификаты и связанные с ними аккаунты удостоверяющих центров.

Если хотя бы часть этого списка изначально регистрировалась на личные данные администратора «для скорости» — это нормальная практика на старте маленького проекта, но именно она превращается в рычаг давления при расставании. Подробный разбор того, что именно должно физически находиться в аккаунтах заказчика независимо от того, кто администрирует систему, есть в статье Что должно остаться у вас, а не у исполнителя: список из десяти пунктов — она хорошо ложится рядом с этим договором как техническое приложение к юридическому пункту о собственности на инфраструктуру.

Тема для юриста здесь простая: договор должен явно фиксировать, что владельцем инфраструктуры, доменов, аккаунтов и данных является заказчик, а исполнитель получает к ним доступ исключительно для выполнения работ, без права регистрировать что-либо из этого списка на себя лично без письменного согласия заказчика. Конкретная формулировка, санкции за нарушение и то, как это соотносится с законодательством в вашей юрисдикции, — вопрос к юристу, а не к этой статье.

Передача документации и доступов при завершении сотрудничества: что и в какие сроки

Вторая тема — обязательство администратора передать полную документацию и все доступы при завершении сотрудничества, причём с конкретными и разумными сроками, а не общей фразой «в разумный срок» без цифр. Формулировка вроде «исполнитель обязуется передать доступы» без срока фактически ничего не значит: у сторон в момент конфликта разное представление о том, что такое «разумно» — для заказчика это один день, для уставшего или обиженного администратора может растянуться на недели.

Есть смысл заранее обсудить с юристом, как зафиксировать в договоре два уровня:

• что именно входит в понятие «полная передача» — список категорий: пароли и ключи доступа, документация по архитектуре и конфигурации, история изменений и известные проблемы, контакты внешних поставщиков (домен, почта, платёжные системы), состояние резервных копий;
• конкретный срок, отсчитываемый от даты уведомления о прекращении сотрудничества, а не от даты, когда администратор «найдёт время».

Опыт передачи сервера показывает, что реалистичный ориентир для аккуратной передачи — порядка недели интенсивной работы, если делать это осознанно и по чек-листу, а не в последний момент. Это не юридическая норма и не готовая формулировка для договора, а просто практическое наблюдение: в материале Смена администратора: как передать сервер новому человеку за неделю разобран сам процесс передачи — какие шаги в нём есть и сколько времени реально занимает каждый. Юристу эта картина полезна, чтобы срок в договоре был не «для галочки», а действительно исполнимым для обеих сторон.

Отдельно стоит обсудить с юристом, что происходит, если срок передачи нарушен: это может быть отдельный пункт про порядок эскалации (см. ниже) или про финансовые последствия — но конкретный механизм снова оставляем на усмотрение юриста, а не додумываем сами.

Конфиденциальность и запрет хранить копии данных и доступов после завершения работы

Третья тема — конфиденциальность, причём именно в её посттерминационной части. Большинство типовых договоров с фрилансерами содержат общий пункт о неразглашении на время сотрудничества, но забывают явно проговорить, что происходит с данными и доступами после его завершения.

Есть несколько практических моментов, которые стоит поднять с юристом именно в этом разрезе:

• обязательство удалить или вернуть все копии учётных данных после завершения работы — включая записи в личном менеджере паролей администратора, сохранённые пароли в браузере, локальные бэкапы конфигураций и баз данных, если они делались для удобства работы;
• срок действия обязательства о неразглашении после окончания сотрудничества — оно логически не должно ограничиваться датой последнего платежа;
• что считается «копией» в спорных случаях — например, черновые заметки в личном блокноте администратора с фрагментами конфигурации тоже могут подпадать под это определение, и лучше явно проговорить, где проходит граница;
• механизм подтверждения удаления — устного заверения обычно недостаточно для серьёзного проекта, и юрист может предложить формат письменного подтверждения.

Это особенно важно, если администратор параллельно ведёт несколько похожих проектов: у него может физически накапливаться архив конфигураций «на всякий случай», без злого умысла, просто по привычке аккуратного специалиста. Договор — это способ явно проговорить, что для вашего проекта такая привычка неприемлема после завершения работы, а не полагаться на то, что администратор сам догадается всё удалить.

Порядок разрешения споров при передаче: эскалация вместо взаимных обвинений

Даже при хорошо составленном договоре передача может пойти не по плану: администратор считает, что передал всё нужное, заказчик считает, что чего-то не хватает, а проверить это без специальных знаний сложно. Здесь работает та же логика, что и с самим фактом расставания: договориться о механизме разрешения таких споров легче заранее, чем изобретать его на ходу в разгар конфликта.

Тема для обсуждения с юристом — предусмотреть в договоре не только сам факт обязательства передать всё нужное, но и порядок действий на случай разногласий по поводу того, передано ли действительно всё:

• кто может выступить независимой стороной для технической оценки полноты передачи — это может быть согласованный заранее сторонний специалист или организация, а не тот, кого выберет одна из сторон уже в момент спора;
• на основании чего оценивается «полнота» передачи — если в договоре заранее зафиксирован конкретный список (см. предыдущий раздел), то и оценивать проще: свести с чек-листом, а не спорить абстрактно;
• что происходит, если администратор физически недоступен — заболел, пропал, отключил телефон — сюда же логически примыкает вопрос, какие материалы должны быть доступны заказчику независимо от воли администратора именно на такой случай; практический разбор этой ситуации есть в статье Красная папка: что должно быть под рукой, если админ недоступен — она скорее про подготовку заказчика, чем про сам договор, но обе темы усиливают друг друга.

Идея эскалации к третьей стороне вместо прямого выяснения отношений между заказчиком и исполнителем — это именно то направление, которое стоит явно поставить перед юристом: как оно может быть оформлено в вашем договоре, кто может быть такой стороной, и насколько это вообще применимо в вашей юрисдикции и для вашего масштаба отношений. Для небольшого проекта полноценная арбитражная оговорка может быть избыточной, а для длительного сотрудничества с критичной инфраструктурой — вполне оправданной. Оценить это соотношение снова задача юриста, знакомого с вашей ситуацией целиком.

Как перевести эти темы в договор: чек-лист для разговора с юристом

Всё, что описано выше, — это направления для обсуждения, а не готовые пункты договора. Чтобы разговор с юристом был предметным, полезно прийти к нему с конкретным списком тем, а не с абстрактным «хочу договор с админом». Ниже — сводка тем этой статьи в формате, который удобно взять с собой на консультацию.

Дополнительно стоит спросить юриста, нужен ли отдельный акт приёма-передачи как приложение к договору — документ, который обе стороны подписывают в момент фактической передачи доступов, фиксируя, что именно было передано и когда. Это отдельная тема, которая тоже облегчает жизнь при возможном споре, но её формат и юридическую силу опять же определяет юрист, а не эта статья.

Если вы ещё только формулируете техническое задание для администратора, часть тем логично обсудить ещё раньше — на этапе постановки задачи, до подписания договора. В материале Первый наём администратора: что отдать сразу, а что не отдавать никогда разобрано похожее разделение — что можно передать сразу для удобства работы, а что стоит оставить под своим контролем с первого дня.

Частые вопросы