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

reasons

Типичные причины: подрядчик не справляется с темпом или качеством, выросли цены, изменились приоритеты, команда распалась, или вы сознательно начинали с агентства и строите штат. Причина влияет на срочность, но не на суть: передача — это всегда про активы, доступы и знания.

checklist

  1. Репозиторий с полной историей. Код на аккаунте заказчика, все ветки, актуальное состояние. Если репозиторий у подрядчика — переносится в первую очередь.
  2. Доступы. Консоли сторов, серверы и хостинг, базы данных, аналитика, пуш-сервисы, домены, платёжные кабинеты. Каждый доступ — смена владельца или добавление новой команды с последующим отключением старой.
  3. Документация. Как развернуть проект локально и на сервере, как устроена архитектура, как публикуются релизы. Если документации нет — её написание становится отдельной задачей передачи.
  4. Дизайн-исходники и бренд-материалы в исходных форматах.
  5. Реестр сторонних сервисов: что используется, тарифы, где оплачивается, когда продлевается.
  6. Список известных проблем: техдолг, баги в бэклоге, «костыли», о которых знает только старая команда.
  7. Контекст продукта: дорожная карта, гипотезы, договорённости с партнёрами и сторами.

audit

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

parallel

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

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

Обсудить передачу →

Калькулятор выручки

Открыть калькулятор

Концепция приложения — бесплатно

Получить концепцию

Частые вопросы

Бывший подрядчик не отвечает и не отдаёт доступы — что делать?

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

Новая команда говорит, что проще переписать с нуля — верить?

Иногда это правда, чаще — нежелание разбираться. Требуйте обоснование: аудит с конкретными аргументами (технология мертва, архитектура не масштабируется, дешевле переписать, чем чинить). Сравните стоимость и сроки обоих путей.

Сколько времени занимает нормальная передача?

При наличии доступов и минимальной документации — две-четыре недели. Если документации нет и контекст только в головах старой команды — до двух месяцев.

Нужно ли сообщать пользователям о смене команды?

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

Редакция MysticodeКоманда Mysticode