Что вы забираете при расставании с подрядчиком: код сайта, база, макеты, доступы, документация

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

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

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

Расставание — не единственный повод. Тот же список нужен, когда новый ИТ-директор требует инвентаризацию, когда меняется юридическое лицо, когда безопасность проводит аудит подрядчиков. Никто не ссорится — просто надо забрать своё, и оказывается, что «своё» никто не описывал.

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

И наблюдение: подрядчик, спокойно обсуждающий передачу на первой встрече, почти всегда передаёт нормально. Ответ «мы же не собираемся расставаться» сообщает главное.

Дальше — что вы забираете и каким действием убеждаетесь, что забрали то самое, а не похожее. Проверки подобраны так, чтобы их выполнил один сотрудник ИТ-службы за день.

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

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

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

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

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

Пример из нашей практики — кабинет агента для медицинской группы EMC. Обращения шли вперемешку по почте, телефону и мессенджерам, сроки плыли, данные дублировались. Сервис собрали из двух модулей: агент подаёт заявку с документами и видит статус, сотрудник клиники получает задачу с учётом загруженности и области экспертизы; плюс чат и роли. Срок подготовки заключения сократился на 60%.

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

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

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

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

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

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

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

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

Можно прислать договор целиком: смотрим только разделы про права, доступы, передачу и приёмку. Чаще всего дело кончается тем, что человек возвращается к своему подрядчику с четырьмя-пятью вопросами, — ради этого статья и написана.

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