Переход с подрядчика на внутреннюю ИИ-команду требует быстро забрать доступы, домены, исходники и закрепить правила поддержки без споров и простоя.
Самый опасный момент в таком переходе не сам уход подрядчика, а ложное чувство, что проект уже под контролем компании. На практике у подрядчика часто остаются вещи, без которых система не живет: доступ к домену, учетные записи в облаке, репозиторий с кодом, база паролей, аналитика, почта для уведомлений и даже право выпускать обновления.
Проблема в том, что это не всегда видно заранее. Пока все работает, кажется, что передача пройдет спокойно. Но в день смены команды внезапно выясняется, что новый специалист не может войти в продакшн, продлить домен, выпустить исправление или восстановить сервис после сбоя.
Именно поэтому переход с подрядчика на внутреннюю ИИ-команду часто сопровождается не одной, а сразу несколькими потерями:
Отдельный риск в том, что подрядчик и заказчик часто по-разному понимают слово "передача". Для компании это полный контроль. Для подрядчика это может быть архив с частью файлов и один созвон на прощание. Если заранее не проверить границы ответственности, спор почти неизбежен.
Часто всплывает и еще одна неприятная вещь: проект вроде бы создан для компании, но технически живет на чужих аккаунтах. Домен оформлен на сотрудника подрядчика, сервер оплачен с его карты, исходники лежат в его личном репозитории, а важные письма приходят на его адрес. Формально продукт есть, но управляет им не владелец бизнеса.
Особенно больно это проявляется там, где изменения идут быстро. Если внутренняя команда должна сразу поддерживать и развивать продукт, ей нужен не "результат работ", а вся система управления целиком: доступы, история решений, исходники, правила релизов и понятная схема поддержки.
Цель перехода простая: не просто сменить исполнителя, а вернуть компании реальное управление проектом. Когда это не зафиксировано с самого начала, день передачи превращается в день сюрпризов.
При переходе с подрядчика на внутреннюю ИИ-команду важнее всего не "материалы по проекту", а контроль над критичными точками. Если в первый день у вас нет owner-доступов, проект все еще фактически не ваш, даже если подрядчик прислал инструкции и архивы.
Сначала соберите короткий список того, без чего продукт может остановиться или стать недоступным:
Важно забирать именно права владельца или администратора, а не скриншоты, пароли в чате и не "временный вход через созвон". Скриншот не дает контроля, а общий пароль без смены и подтверждения доступа создает риск: в любой момент что-то перестанет работать, и вы не поймете, кто может это исправить.
Отдельно проверьте, кто управляет доменом и DNS. Часто сайт уже перенесен, код есть, сервер работает, но домен оформлен на подрядчика или на его старую почту. В такой ситуации одна запись DNS может остановить сайт, почту и часть интеграций сразу.
После этого заберите доступ к репозиторию, серверу и базе как к одной связке. Исходники без сервера бесполезны для быстрого восстановления. Сервер без базы не даст проверить данные и резервные копии. База без документации по окружению тоже создает паузу в работе.
Если часть продукта собирали на платформе вроде TakProsto, проверьте не только доступ к самому проекту, но и право владельца на деплой, хостинг, экспорт исходников, домен и snapshots. Это особенно важно, если внутренняя команда будет дальше развивать проект своими силами.
Еще в первый день зафиксируйте ответственных с обеих сторон. Достаточно простого списка: кто передает доступы, кто принимает, кто проверяет, что все открывается и работает. Без этого передача быстро превращается в хаос, где каждый думает, что нужный доступ уже у кого-то есть.
Когда начинается переход с подрядчика на внутреннюю ИИ-команду, больше всего проблем возникает не в коде, а в правах доступа. Если не собрать все в одну понятную схему, часть сервисов останется привязанной к чужим людям, а часть - просто выпадет из поля зрения.
Начните с единого реестра. В нем должны быть все сервисы, которыми живет проект: хостинг, репозиторий, аналитика, домен, почта, базы данных, рекламные кабинеты, push-сервисы, платежные системы, хранилища файлов, чат-платформы и инструменты вроде TakProsto, если команда уже использует их в работе. У каждого пункта зафиксируйте три вещи: кто владелец аккаунта, у кого есть доступ и как этот доступ выдан.
Дальше важно развести роли. Не всем нужен полный контроль. Простая схема обычно работает лучше всего:
Так меньше путаницы и меньше риск случайно сломать рабочий сервис. Частая ошибка - оставить всем уровень admin "на всякий случай". Через месяц никто уже не помнит, кому и зачем его дали.
После этого меняют пароли, перевыпускают ключи и включают двухфакторную защиту везде, где это возможно. Особенно это важно для почты, домена, репозитория и облачной инфраструктуры. Если подрядчик работал через общие логины, их лучше убрать сразу и заменить на личные учетные записи с понятными ролями.
Отдельно проверьте почты бывших исполнителей. Если доступы завязаны на личный адрес подрядчика, компания в любой момент может потерять вход, подтверждения или сброс пароля. Все критичные учетные записи должны быть привязаны к корпоративной почте, которой управляет сама компания.
В конце нужен не отчет, а живая проверка. Новый owner должен войти в каждый важный сервис, пройти двухфакторную защиту, открыть настройки и убедиться, что может добавить или убрать пользователя без помощи подрядчика. Если это не получается, значит доступ еще не передан до конца.
Хороший признак простой: любой ключевой сервис можно открыть, понять, кто им владеет, и безопасно передать дальше внутри команды.
При переходе с подрядчика на внутреннюю ИИ-команду больше всего сбоев бывает не из-за кода, а из-за чужих кабинетов. Сайт может работать, но одна пропущенная учетка у регистратора домена или в почте для восстановления - и команда теряет контроль над продлением, уведомлениями и критичными настройками.
Начните с домена. Важно не только знать имя регистратора, но и проверить, у кого есть доступ к личному кабинету, кто указан владельцем и кто может менять DNS-записи. Если подрядчик держит домен на своем аккаунте, это риск: без передачи прав внутренняя команда не сможет быстро перевести сервис, обновить записи или выпустить новый сертификат.
Не менее важна служебная почта. На нее приходят письма о продлении домена, сбоях, счетах, восстановлении паролей и предупреждениях о безопасности. Частая ошибка - оставить такие уведомления на личной почте менеджера подрядчика. После передачи у вас должна быть отдельная корпоративная почта, к которой есть доступ у ответственных сотрудников, а не у одного человека.
Вот что стоит сверить в первую очередь:
Отдельно проверьте платежные кабинеты. Если автопродление домена, SSL или облачного сервиса привязано к карте подрядчика, проект может остановиться в самый неподходящий день. Лучше заранее перевести все регулярные платежи на компанию или на внутренний финансовый аккаунт.
Если у проекта есть мобильное приложение, посмотрите, кому принадлежат кабинеты в магазинах приложений и push-сервисах. Без этого команда не сможет выпускать обновления, отправлять уведомления и проходить проверки. То же касается сертификатов, ключей подписи и SSL: их нужно не просто получить, а проверить срок действия и место хранения.
Хороший ориентир такой: у внутренней команды должны быть не только логины и пароли, но и подтвержденное право владения каждым внешним аккаунтом. Если любой важный сервис все еще оформлен на подрядчика или бывшего сотрудника, передача еще не завершена.
Если проект переходит от подрядчика к внутренней команде, мало получить архив с кодом. Нужен полный рабочий комплект: сам продукт, история изменений, данные, инструкции и подтверждение прав на все, что в нем используется. Иначе через неделю может оказаться, что приложение есть, а собрать, обновить или законно развивать его нельзя.
Первое, что стоит забрать, это главный репозиторий вместе с историей коммитов. История нужна не для формальности. По ней новая команда поймет, какие части менялись чаще всего, где были срочные исправления и какие решения уже пробовали раньше. Если отдают только zip-файл с последней версией, это тревожный знак.
Сразу попросите все, без чего код не запускается в реальной работе:
Важно получить не только текущую базу, но и понятную схему данных. Даже простой документ с описанием таблиц, связей и критичных полей сэкономит много часов. Если в проекте есть загружаемые файлы, медиа, документы клиентов или логи, уточните, где именно это хранится и как переносится отдельно от базы.
Хорошая передача включает хотя бы базовое описание архитектуры: из каких сервисов состоит система, что от чего зависит, какие внешние интеграции есть, где находятся очереди, кэш, почта и платежи. Это особенно важно, если внутренняя команда будет быстро подхватывать развитие продукта, в том числе через ИИ-инструменты вроде TakProsto. Без карты системы ускорение быстро упирается в догадки.
Отдельно проверьте права. Подрядчик должен подтвердить, кому принадлежат исходный код, дизайн-макеты, тексты, иллюстрации, доменное имя библиотек с платной лицензией и все кастомные материалы. Частая ошибка - считать, что раз проект оплачен, то все права уже автоматически переданы. На практике это нужно видеть в договоре, актах или отдельном письме.
Небольшой пример: компания получила код интернет-сервиса, но не забрала конфигурацию сборки и резервные копии. В итоге новая команда открыла репозиторий, но не смогла поднять рабочую версию и откатиться после ошибки. Формально передача состоялась, а по факту проект оказался без страховки.
Хороший ориентир простой: новая команда должна суметь развернуть проект, понять его устройство и безопасно внести первое изменение без помощи подрядчика. Если это пока невозможно, комплект передачи еще не полный.
При переходе с подрядчика на внутреннюю ИИ-команду больше всего проблем возникает не из-за кода, а из-за неясных правил. Если после передачи случится сбой, все должны понимать, кто принимает инцидент, кто имеет право что-то менять и в какие сроки ждать ответ.
Сначала назначьте одну точку входа для всех обращений. Это может быть дежурный сотрудник, руководитель продукта или отдельный чат поддержки. Главное, чтобы не было ситуации, когда письмо ушло подрядчику, сообщение осталось у менеджера, а команда узнала о проблеме слишком поздно.
Полезно сразу зафиксировать базовые правила:
Отдельно пропишите, что подрядчик еще обязан закрыть после передачи. Например, исправить известные дефекты, ответить на вопросы по архитектуре, помочь с первым релизом или подстраховать команду в течение двух недель. Если это не записать, подрядчик будет считать проект переданным, а внутренняя команда - что помощь еще включена.
Важно различать обычный релиз и хотфикс. Обычные изменения лучше выпускать по расписанию, с понятным порядком проверки и согласования. Хотфиксы нужны для срочных ошибок, но и для них должен быть короткий регламент: кто одобряет правку, кто выкатывает, кто проверяет результат и в каком случае делается откат.
Откат надо обсуждать заранее, а не в момент аварии. Если в проекте есть снапшоты, резервные копии или быстрый возврат к прошлой версии, это нужно описать простыми шагами. Для команды это снижает риск, а для бизнеса сокращает простой.
Все инструкции лучше хранить в одном месте, а не по чатам и личным заметкам. Там должны быть схема сервисов, список ответственных, порядок запуска, частые ошибки и уже найденные решения. Если команда использует платформу вроде TakProsto для быстрой доработки и выпуска новых версий, эти правила особенно важны: скорость помогает только тогда, когда понятно, кто и как поддерживает результат.
Хорошее правило простое: любой новый человек в команде должен за 15 минут понять, куда писать при инциденте, как выпустить исправление и где найти последнюю рабочую инструкцию.
Переход с подрядчика на внутреннюю ИИ-команду лучше делать не одним рывком, а короткими этапами. Главная цель проста: новая команда уже может работать сама, а старая еще не отключена слишком рано.
Начните с полной описи всего, что вообще держит проект в рабочем состоянии. Сюда входят домены, хостинг, репозитории, базы данных, панели аналитики, почта, платежные сервисы, доступы к магазинам приложений, документация, резервные копии и контакты ответственных.
Дальше нужен понятный порядок действий.
Если проект работает без остановки, делайте передачу в тихие часы, но не ночью без дежурных. Например, сначала переведите права на репозиторий и staging, убедитесь, что внутренняя команда выпускает тестовую сборку, и только потом переносите доступ к production.
Полезно заранее назначить одного человека, который подтверждает каждый этап. Тогда не будет ситуации, когда домен уже у компании, а почта для восстановления все еще привязана к бывшему подрядчику.
Такой порядок заметно снижает риск сбоев и делает передачу доступов от подрядчика управляемой, а не хаотичной.
Хороший пример - компания с корпоративным сайтом и внутренним сервисом для обработки заявок. Сайт приводит клиентов, а сервисом каждый день пользуются менеджеры. Полная пауза даже на несколько часов бьет и по продажам, и по работе команды, поэтому передачу сделали поэтапно.
Сначала внутренняя ИИ-команда получила доступы только на чтение: к регистратору домена, почтовой панели, репозиторию, хостингу и базе данных. Подрядчик в это время продолжал обычную поддержку. Это сняло главный риск: новая команда успела посмотреть, как все устроено, не ломая рабочую систему.
Потом разделили передачу на три шага:
Самое важное сделали еще до переключения. Команда заранее проверила бэкапы не по отчету подрядчика, а руками. Открыли архивы, подняли тестовую копию базы, убедились, что сайт запускается, а во внутреннем сервисе видны реальные заявки, роли сотрудников и журнал действий. Если резервная копия не разворачивается, пользы от нее почти нет.
После этого переключение прошло в тихое окно вечером. Сначала обновили DNS, затем перевели деплой на новый контур, а старый оставили в режиме быстрого отката. Для сотрудников почти ничего не изменилось: сайт открывался как обычно, а внутренний сервис был недоступен только несколько минут во время финальной синхронизации данных.
Отдельно оставили короткое окно поддержки от подрядчика на 7-14 дней. Это не значит, что он продолжает всем управлять. У него остается узкая роль: ответить на вопросы по старым настройкам, помочь, если всплывет забытый cron, внешний ключ или нестандартный скрипт.
Такой сценарий показывает простую вещь: пауза не обязательна. Если заранее забрать контроль над доменом, кодом, данными и проверить восстановление из бэкапов, переход с подрядчика на внутреннюю ИИ-команду можно провести почти незаметно для бизнеса.
Самая частая ошибка при переходе с подрядчика на внутреннюю ИИ-команду - поверить таблице с доступами и не проверить ее руками. В документе может быть написано, что доступы переданы, но по факту часть учетных записей уже не работает, часть привязана к личной почте бывшего менеджера, а часть есть только у подрядчика.
Проверять нужно не список, а вход в каждый критичный сервис. Если команда может зайти в репозиторий, но не может выпустить обновление или восстановить пароль, передача еще не завершена.
Вторая ловушка - забрать код и успокоиться. Исходники без настроенного деплоя, переменных окружения, ключей, токенов, сертификатов и инструкций по сборке часто бесполезны. На бумаге проект передан, а на деле никто не может выкатить даже маленькое исправление.
Это особенно болезненно, если продукт уже работает с клиентами. Например, внутренняя команда получает архив с кодом, но не знает, где хранятся секреты для базы данных, кто управляет сервером и как откатить неудачный релиз.
Отдельная проблема - почты для восстановления и оплаты. Их часто забывают сменить, потому что сервис продолжает работать и кажется, что спешить некуда. Но первый же платежный сбой, истекший сертификат или попытка сброса пароля быстро показывает, кто на самом деле контролирует проект.
Если домен, облако, аналитика или магазин приложений завязаны на старую почту подрядчика, риск остается высоким даже после формальной передачи. То же касается карт, подписок и аккаунтов, с которых списываются деньги за инфраструктуру.
Еще одна опасная схема - оставить одного человека владельцем всего. Даже если это ваш сотрудник, такой подход создает точку отказа. Если человек уходит в отпуск, увольняется или просто недоступен, команда теряет управление важными частями проекта.
Вот что чаще всего стоит проверить в первую очередь:
Последняя ошибка - закрыть контракт до финального теста передачи. Пока не проведен реальный прогон, передача доступов от подрядчика не подтверждена. Нужен простой контрольный сценарий: войти во все ключевые сервисы, собрать проект, развернуть тестовую версию, выпустить маленькое изменение и убедиться, что поддержка теперь действительно у внутренней команды.
Если хотя бы один из этих шагов не проходит, процесс еще не закончен. Формальное подписание акта в такой момент почти всегда обходится дороже, чем несколько дополнительных дней на проверку.
Если переход с подрядчика на внутреннюю ИИ-команду нужно закрыть без сюрпризов, проверьте не только документы, но и реальное управление проектом. Передача считается завершенной только тогда, когда компания сама может войти, запустить, оплатить и восстановить систему без помощи бывшего исполнителя.
Вот короткий чек-лист, который стоит пройти в конце передачи:
После этого назначьте один день на контрольную проверку. В этот день внутренняя команда должна выполнить типовые действия без подрядчика: зайти в ключевые сервисы, выпустить небольшое обновление, проверить почту, платежи и резервные копии.
Если хотя бы один важный доступ остается у внешней стороны, переход еще не закончен. Особенно часто забывают про домен, сервис отправки почты, push-уведомления, магазин приложений и платежные аккаунты.
Если новую ИИ-команду нужно запустить быстро, начните с малого пилота. Например, в TakProsto можно собрать простой внутренний сервис через чат, выгрузить исходники и сразу оставить домен, доступы и управление на стороне компании.
Такой пилот удобен не как замена всему проекту в один день, а как безопасная проверка новой модели работы. Вы быстро увидите, как команда ставит задачи, кто отвечает за поддержку и хватает ли вам внутренних процессов для следующего этапа.
Лучший способ понять возможности ТакПросто — попробовать самому.
