Тендеры и лиды
Информация
Проект сдали, акт подписали, система работает. Через год отношения с подрядчиком заканчиваются — он закрылся, вырос из маленьких проектов или вы просто решили сменить команду. И тут выясняется, что домен зарегистрирован на разработчика, сервер оплачивается с его карты, код лежит в его личном репозитории, а в договоре написано, что вам предоставлена лицензия, а не исключительные права.
Система работает, но распоряжаться ею вы не можете. Ни переехать к другому подрядчику, ни доработать своими силами, ни даже продлить домен без чужого участия.
Это не редкий сценарий из страшилок. Так происходит почти всегда, когда при сдаче проекта никто не составил список того, что заказчик должен получить на руки. Разбираем этот список по пунктам — с деталями, о которых обычно вспоминают слишком поздно.
По общему правилу Гражданского кодекса (статья 1296) исключительное право на программу, созданную по заказу, принадлежит заказчику. Но с важной оговоркой: «если договором не предусмотрено иное». И договоры подрядчиков нередко предусматривают иное.
На что смотреть в договоре:
«Исключительное право переходит к заказчику» — то, что нужно. Вы можете дорабатывать систему, передавать её другим исполнителям, регистрировать.
«Заказчику предоставляется право использования» или «неисключительная лицензия» — права остались у подрядчика. Вы пользуетесь системой, но менять её или отдавать другой команде без согласия исполнителя не можете.
Право подрядчика пользоваться программой. Даже когда исключительное право перешло к заказчику, та же статья 1296 оставляет подрядчику бесплатную простую лицензию: он вправе использовать программу для собственных нужд, если договор этого не исключает. Если система содержит ваши коммерческие секреты, это стоит оговорить явно.
Готовые компоненты подрядчика. Многие студии собирают проекты на собственных наработках и оставляют права на них себе. Это нормально, если в договоре прямо сказано, какие части ваши, а какие — лицензия, и что лицензия бессрочная.
Отдельный нюанс для государственных и бюджетных заказчиков: если систему планируется включить в реестр российского программного обеспечения, правообладателем должен быть сам заказчик. С лицензией на руках этого не сделать.
Архив с исходниками, переданный в последний день, — это лучше, чем ничего, но ненамного. Без истории изменений новая команда не поймёт, почему код устроен именно так, а что-то может в архив просто не попасть.
Что должно быть:
Репозиторий на аккаунте заказчика — в корпоративном GitLab, GitHub или любом другом месте, где владелец организации вы, а не разработчик.
Полная история коммитов, а не один коммит «final».
Все части системы: серверная часть, интерфейс, мобильные приложения, скрипты развёртывания, миграции базы данных.
Никаких секретов в коде. Пароли и ключи в репозитории — это и дыра в безопасности, и признак того, что часть настроек живёт только в голове разработчика.
Простой тест: попросите новую команду развернуть систему с нуля только по репозиторию и документации. Если без звонка прежнему подрядчику не получается — передача не закончена.
Самая неприятная категория потерь, потому что каждая из них выглядит мелочью, пока не понадобится.
Домен. В зоне .ru администратор домена — тот, на кого он зарегистрирован. Если это частное лицо-разработчик, продлить или перенести домен без его участия не получится. Домен должен быть зарегистрирован на юрлицо заказчика.
Сервер и облако. Аккаунт у хостинг-провайдера или в облаке — на заказчике, оплата — с его счёта. Если сервер оплачивает подрядчик и перевыставляет счёт, при расставании придётся переезжать, иногда срочно.
Аккаунты разработчика в магазинах приложений. Самый неочевидный пункт. Если мобильное приложение опубликовано в App Store, Google Play или RuStore с аккаунта подрядчика, для пользователей это приложение подрядчика. Перенос между аккаунтами возможен не всегда и занимает время, а новое приложение с нуля означает потерю всех установок и отзывов. Аккаунт разработчика регистрируется на компанию заказчика до первой публикации.
Внешние сервисы. Почтовые рассылки, SMS-шлюзы, карты, платёжные системы, нейросетевые API, аналитика. Ключи и договоры с ними — на заказчике. Особенно платёжные системы: деньги должны приходить на ваш счёт по вашему договору, а не через прослойку.
Административные учётные записи. Главная учётка администратора системы, доступ к базе данных, к серверу, к почте, с которой система отправляет письма. Всё с паролями, которые вы сменили после передачи.
Толстая проектная документация по ГОСТ нужна не всегда. Но минимальный набор нужен всем:
Как устроена система: из каких частей состоит, как они связаны, какие внешние сервисы использует.
Как развернуть с нуля: пошагово, с требованиями к серверу.
Как обновлять: порядок выкладки новой версии и отката.
Интеграции: с какими системами идёт обмен, в какую сторону, что делать, если обмен остановился.
Инструкции для пользователей и администраторов.
Проверяется так же, как код: по документации должен разобраться человек, который систему не делал.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13752 тендера
проведено за восемь лет работы нашего сайта.
Фраза «бэкапы настроены» ничего не гарантирует, пока из них никто не восстанавливался. Уточните:
где хранятся резервные копии и на чьём аккаунте;
как часто они делаются и сколько хранятся;
когда последний раз из них восстанавливали систему — и получилось ли.
Если подрядчик хранит копии у себя, после расставания у вас их не будет.
Система может использовать платные библиотеки, шрифты, темы оформления, лицензии на программное обеспечение. Если они куплены на подрядчика, при расставании вы рискуете остаться с системой, которая формально нарушает чьи-то права или перестанет обновляться.
Попросите список всех платных компонентов с указанием, на кого оформлена лицензия и до какого числа она действует.
Даже идеально переданный код не заменяет понимания, почему система устроена именно так. Если всю логику знает один человек у подрядчика, это риск независимо от того, насколько хороши ваши отношения.
Что помогает:
Журнал изменений: что, когда и зачем меняли. Через год это единственный способ понять, можно ли удалить странное поле или оно держит половину отчётов.
Передача знаний вашей ИТ-службе или новой команде: несколько встреч с разбором архитектуры и типичных задач.
Гарантийный период после сдачи, в течение которого подрядчик исправляет ошибки и отвечает на вопросы.
В договоре закреплена передача исключительных прав, а не лицензия.
Код в репозитории на аккаунте заказчика, с полной историей.
Систему можно развернуть с нуля по репозиторию и документации без участия подрядчика.
Домен зарегистрирован на юрлицо заказчика.
Сервер и облако — на аккаунте заказчика, оплата с его счёта.
Аккаунты разработчика в магазинах приложений оформлены на компанию заказчика.
Договоры и ключи внешних сервисов, включая платёжные, — на заказчике.
Все административные пароли переданы и сменены.
Есть документация: устройство, развёртывание, обновление, интеграции, инструкции.
Резервные копии хранятся у заказчика, восстановление проверено.
Есть список платных компонентов и лицензий с владельцами и сроками.
Проведена передача знаний, согласован гарантийный период.
Лучше всего внести этот список в техническое задание или договор с самого начала: тогда он становится частью приёмки, а не просьбой в последний день.
Система, которую вы не можете передать другой команде, принадлежит вам только на бумаге. Права на код проверяются по договору, а не по обещаниям. Доступы — по тому, на кого они оформлены. Документация и резервные копии — по тому, работают ли они без подрядчика.
Мы в CodinLab передаём заказчику исходный код, документацию и все доступы в рамках каждого проекта и включаем эти пункты в критерии приёмки — так проще работать и нам, и тем, кто будет развивать систему после нас.
