Агентство закрывается, контракт заканчивается на плохих условиях, или единственный человек, понимавший систему, просто уходит — и бизнес обнаруживает, в худший из возможных моментов, что у него никогда фактически не было ключей от того, за что он заплатил. Это не редкий пограничный случай; это предсказуемый результат того, что в начале отношений никто не спросил, что случится со всем, если эти отношения закончатся.
Доступ — первое, что нужно решить, а не последнее
У кого регистрация домена, хостинговый аккаунт, репозиторий исходного кода, ключи сторонних API, от которых зависит система — и оформлены ли эти аккаунты на имя самого бизнеса или на имя агентства, с бизнесом в роли гостя. Этот вопрос легко и немного неловко задать перед подписанием контракта и очень трудно и очень дорого решить после того, как отношения уже испортились. Правильный ответ почти всегда в том, что основное право собственности на каждый аккаунт принадлежит бизнесу, а агентство получает доступ для выполнения работы, а не наоборот.
Право собственности на код — конкретный, договорной вопрос
«Мы это построили, значит владеем этим, пока вы не заплатите нам за передачу» — законная бизнес-модель для некоторых агентств и серьёзная проблема, если бизнес не осознал, что именно на такую договорённость он согласился. Контракт должен чётко, письменно указывать, кому принадлежит получившийся код и активы, является ли это право собственности немедленным или обусловленным финальным платежом, и что происходит с этим правом, если контракт заканчивается досрочно — расплывчатая формулировка здесь не недосмотр, часто это как раз та неоднозначность, на которую позже опирается трудная передача.
Документация — то, что делает право собственности реально пригодным к использованию
Владение кодом, который никто не может прочитать, близко к владению ничем. Система без документации своей архитектуры, переменных окружения, процесса развёртывания и ключевых решений на практике эксплуатируема только тем, кто её построил — а значит, бизнес фактически не снизил зависимость от агентства, просто владея файлами, он лишь сделал эту зависимость менее заметной. Требование базовой документации передачи как результата работы, а не опциональной надбавки, — вот что превращает техническое владение в практическую независимость.
Экспортируемость — тест, раскрывающий реальную зависимость
Система, построенная на проприетарном инструментарии, которым может управлять только исходное агентство, или на платформе, делающей экспорт данных и конфигурации трудным или невозможным, создаёт зависимость независимо от того, что говорит контракт о праве собственности. Честный тест прост: сможет ли другой, компетентный разработчик подхватить эту систему и продолжить работу над ней в разумный срок, используя только то, что было передано — и если ответ реально неясен, эту неясность стоит разрешить до постройки системы, а не после ухода исходного разработчика.
Почему это дешевле всего решить до первого счёта
Каждое из этих условий — небольшие, спокойные переговоры в начале отношений и напряжённые переговоры без рычага влияния после того, как что-то уже пошло не так — попросить документацию передачи у агентства, всё ещё активно вовлечённого, стоит почти ничего; попросить её у того, что уже ушло, стоит очень дорого, если это вообще возможно.
Это соседствует с тем же решением купить, построить или настроить — правильный технический выбор остаётся правильным только если бизнес реально может продолжать эксплуатировать систему независимо от того, кто её построил.
Наша команда разработки передаёт полное право собственности, документацию и экспортируемые системы как стандарт, а не как согласовываемую надбавку — потому что клиент, который мог бы уйти чисто, но выбирает остаться, — единственный тип отношений, который стоит иметь.
