Приложение работает, но договориться о следующем релизе все сложнее. Исправления затягиваются, оценки непонятны или команда больше не может заниматься проектом. Вы находите другого разработчика — и выясняется, что ссылки на Git недостаточно для продолжения работы.
Передача приложения завершена, когда новая команда может самостоятельно собрать его, проверить основные сценарии, выпустить обновление и восстановить сервис при сбое. Архив исходников — только одна часть этой работы. Еще нужны доступы, серверная часть, настройки интеграций и понятная ответственность на время перехода.
Ниже — порядок, который я рекомендую использовать заказчику при смене команды. Это чек-лист организации передачи, а не история конкретного перехода клиента Mobecan.
Сначала определите, что именно вы передаете
Смена подрядчика не обязательно означает перенос серверов, смену аккаунтов в магазинах или переписывание приложения. Если инфраструктура и аккаунты принадлежат вашей компании, новой команде может быть достаточно отдельных доступов с нужными ролями.
Разделите три задачи: передать сопровождение, устранить накопленные проблемы и развивать продукт. Если смешать их в одну оценку, трудно понять, за что вы платите и в какой момент новая команда принимает ответственность.
На первой встрече зафиксируйте:
- Какие версии приложения опубликованы и какая версия исходников им соответствует.
- Что сейчас не работает и какие обращения пользователей остаются открытыми.
- Какие ближайшие изменения обязательны, а какие можно отложить.
- Кто исправляет аварии, пока новая команда знакомится с проектом.
- Как вы поймете, что приемка завершена.
Что запросить у действующей команды
Удобно вести один реестр: объект, владелец, ответственный за передачу, статус доступа и результат проверки. Пароли и ключи в этот реестр не включайте — указывайте место их защищенного хранения.
| Что передать | Что должна проверить новая команда |
|---|---|
| Репозитории мобильного приложения и серверной части | Есть история изменений, отмечена версия последнего релиза, доступны все необходимые зависимости |
| Инструкция по сборке | Приложение собирается на новом рабочем месте, а не только на ноутбуке прежнего разработчика |
| Аккаунты магазинов приложений | Назначенные роли позволяют выполнять нужные действия; понятны владелец и порядок выпуска обновлений |
| Подпись приложения и процесс релиза | Есть рабочий способ подписать и загрузить следующую сборку, определены ответственные за ключи и сертификаты |
| Серверы, домены, DNS, базы данных | Известны владельцы, платежи, окружения, зависимости и порядок восстановления |
| Интеграции | Понятно, кто отвечает за авторизацию, оплату, СМС, push, CRM и другие подключенные сервисы |
| Дизайн и продуктовая документация | Доступны исходные макеты, правила поведения экранов и согласованные требования |
| Мониторинг и аналитика | Новая команда видит ошибки, важные события и может отличить сбой от обычного поведения |
| Список задач и известных дефектов | Зафиксированы приоритеты и ограничения, которые нельзя принять за новые ошибки подрядчика |
Особенно важно проверить внешние зависимости: приватные библиотеки, закрытые пакеты, оплачиваемые сервисы и задания, которые запускаются по расписанию. Проект может успешно собираться и при этом перестать отправлять уведомления после отключения старого аккаунта.
Почему передача только мобильного кода не решает задачу
В нашем приложении «Вкус и Лосось» есть вход по СМС и через Telegram, уведомления о статусах заказа, корзина и бонусная программа. Это пример того, насколько мобильный интерфейс связан с другими частями продукта.
При приемке приложения с подобными сценариями мало увидеть каталог на экране. Нужно проверить всю цепочку: вход, оформление заказа, передачу данных, обновление статуса и уведомление. Работающий экран еще не доказывает, что заказ дойдет до оператора.
Это не описание смены подрядчика в «Вкус и Лосось»: публичный кейс здесь иллюстрирует состав системы, который необходимо учитывать при сопровождении.
Проведите контрольную сборку и проверку сценариев
Попросите новую команду собрать приложение из переданного репозитория в подготовленном окружении и установить тестовую версию. Результат стоит зафиксировать: версия кода, настройки окружения, найденные препятствия и способ их устранения.
Проверяйте сценарии, от которых зависит работа бизнеса. Для приложения доставки это может быть вход, выбор адреса, корзина, заказ, оплата и статус. Для внутреннего сервиса — права сотрудников, создание заявки, согласование и передача данных в учетную систему.
Проверки проводите на тестовых данных и в тестовых интеграциях, где это возможно. Действия с реальной оплатой или отправкой заказов требуют отдельного согласованного сценария: случайная заявка на кухне не помогает приемке.
После сборки нужен небольшой контролируемый выпуск. Изменение может быть минимальным, но команда должна пройти весь путь до доставки обновления: подготовка, проверка, загрузка, согласование и наблюдение после выпуска. Доступ к исходникам сам по себе этого не подтверждает.
Аккаунт магазина и подрядчик — разные вещи
Если аккаунт разработчика остается у вашей компании, не нужно автоматически переносить приложение в аккаунт нового исполнителя. Сначала проверьте, можно ли решить задачу назначением ролей.
Когда действительно меняется аккаунт владельца приложения, применяется отдельная процедура магазина. У Apple это перенос приложения в App Store Connect, у Google — перенос между аккаунтами разработчиков. Требования и связанные сервисы проверяют перед переносом: передача репозитория не заменяет эти процедуры.
Не передавайте личную учетную запись сотрудника вместе с паролем. Назначайте отдельные учетные записи, а право управлять доступами сохраняйте у ответственного представителя вашей компании.
Переключайте ответственность поэтапно
Сначала подтвердите доступы и работоспособность тестового окружения. Затем согласуйте первый выпуск и план возврата к рабочему состоянию. Только после приемки отключайте ненужные доступы прежней команды и меняйте использовавшиеся совместно секреты по согласованному плану.
Резкая смена всех ключей в начале перехода может остановить интеграции. Бесконечное сохранение общих доступов тоже оставляет неопределенность: непонятно, кто внес изменение и кто отвечает за инцидент.
На период передачи назначьте одного координатора со стороны бизнеса. В документе должны быть дата начала ответственности новой команды, канал аварийных обращений и порядок действий, если прежний подрядчик уже недоступен.
Нужно ли переписывать приложение
Смена команды сама по себе не является основанием для переписывания. Сначала нужна диагностика: что мешает сборке и выпуску, где возникают сбои, какие части сложно менять и почему.
Попросите сравнить три варианта: принять проект с текущими ограничениями, постепенно исправлять проблемные части или заменить конкретный компонент. Для каждого нужны состав работ, риски, ограничения и влияние на ближайшие задачи бизнеса.
Если исходники не собираются, это еще не доказательство необходимости полной переделки. Причиной могут быть отсутствующие настройки, зависимости или доступы. Сначала нужно отделить нехватку материалов от проблем архитектуры.
Как оценивать стоимость передачи
Оценку полезно разбить на четыре части: инвентаризация, восстановление сборки и окружения, проверка сценариев, первый выпуск. Дальнейшие исправления и новые функции учитывайте отдельно.
Обоснованная оценка объясняет, что команда уже проверила, каких данных не хватает и какие допущения использует. Универсальная цена за «приемку любого приложения» без знакомства с проектом мало говорит о конечном объеме работ.
Если документации нет, предусмотрите ее восстановление в объеме, необходимом для сопровождения. Для первого этапа важнее рабочая инструкция по сборке, карта сервисов и порядок релиза, чем большой документ, который никто не проверил на практике.
Чек-лист перед завершением передачи
- У компании есть контроль над репозиториями, инфраструктурой и аккаунтами магазинов.
- Новая команда воспроизвела сборку опубликованной версии или зафиксировала и объяснила отличия.
- Основные пользовательские сценарии проверены, известные дефекты перечислены.
- Подтверждены резервное копирование и способ восстановления; для критичных данных проведена проверка восстановления в изолированной среде.
- Пройден согласованный процесс выпуска обновления, определены ограничения отката.
- Настроены наблюдение за ошибками и канал для инцидентов.
- Есть список оставшихся рисков, ответственные и очередность работ.
- Завершена передача ответственности и пересмотрены доступы.
Если несколько пунктов остаются неподтвержденными, передачу лучше считать незавершенной и явно описать, кто закрывает эти пробелы.
Если вы планируете сменить команду
Начать разговор с Mobecan можно со ссылок на приложение в магазинах, описания текущей проблемы и ближайших задач. Пароли, исходники и данные пользователей в первом сообщении не нужны.
Обсудить передачу приложения команде Mobecan. Определим, какие материалы нужны для оценки и что проверить перед началом сопровождения.
Если вы пока выбираете между готовым продуктом и собственной разработкой, прочитайте разбор на примере приложения доставки.