Что на самом деле должна определять передача исходного кода?

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

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

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

Код вместе с историей

Не снимок. Репозиторий с историей коммитов, ветками и тегами. История — это то, как новая команда понимает, почему сделано именно так; один сплющенный коммит удаляет это безвозвратно.

Схема базы и данные

Схема, миграции, справочные данные и восстановимая выгрузка боевых данных в описанном формате. Данные, которые нельзя восстановить, — это данные, которых у вас нет.

Конфигурация и описание инфраструктуры

Переменные окружения и назначение каждой, описание инфраструктуры, сборка и деплой, домены и сертификаты. Секреты не передаются, а перевыпускаются, и это тоже должно быть написано.

Интеграции и сторонние аккаунты

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

Документация, написанная для постороннего

Как запустить локально, как развернуть, как работают основные сценарии и где приняты неочевидные решения. Проверка документации одна: сможет ли ею воспользоваться тот, кто никогда не общался с авторами.

Тесты и то, что они покрывают

Набор тестов и честное описание того, чего он не покрывает. Первый вопрос новой команды — «что я могу менять безопасно?», и тесты — единственный ответ, который не является мнением.

Явно названная граница прав

На что вы получаете права, что остаётся переиспользуемым материалом подрядчика и что является сторонними компонентами под собственными лицензиями. Три категории, названные до сдачи.

Событие передачи и её приёмка

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

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