Документация мобильного приложения: что получить при передаче проекта

Что должно перейти к владельцу приложения

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

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

Готовиться к передаче нужно с начала проекта

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

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

В открытом списке Futurice для передачи цифровых проектов эта работа рассматривается как отдельный небольшой этап со сроком, ответственным и проверкой результата. Это разумный подход: качественная передача требует времени на вопросы и испытания.

Исходный код должен собираться без старой команды

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

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

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

Зафиксируйте, какая версия кода и серверной части соответствует приложению, опубликованному сейчас. Если выпуск собрали из изменений, которые не попали в репозиторий, сначала восстановите это соответствие.

Аккаунты и оплата не должны принадлежать случайным людям

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

• Apple Developer, App Store Connect и Google Play Console;
• сервер, база данных, файловое хранилище и доставка файлов;
• домен, DNS и служебная почта;
• карты, SMS, вход по номеру телефона и уведомления;
• приём платежей, подписки и проверка покупок;
• аналитика, отчёты об ошибках и система поддержки.

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

Приложение нельзя передать между аккаунтами магазинов простым сообщением с паролем. У Apple есть официальная процедура передачи приложения, а Google подробно описывает, что переносится автоматически, а что придётся настроить заново. Например, отдельного внимания могут потребовать тестовые группы, отчёты, разрешения облачных сервисов и покупки внутри приложения.

Макеты и принятые решения тоже относятся к результату

Редактируемые файлы в Figma или другой системе должны соответствовать текущему приложению. Нужны не только готовые экраны, но и компоненты, состояния, иконки, шрифты, правила экспорта и подтверждения лицензий на материалы. Набор картинок PNG позволяет посмотреть дизайн, но не даёт нормально его развивать.

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

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

Серверы, данные и резервные копии нужно проверить в работе

Схема устройства проекта может быть простой, но должна объяснять, как связаны приложение, сервер, база данных, хранилище файлов и внешние сервисы. На ней отмечают рабочую и проверочную среды, а также порядок переноса изменений в рабочую версию.

Для базы данных зафиксируйте структуру, изменения схемы, сроки хранения, выгрузку и место резервных копий. Затем восстановите одну свежую копию в безопасной проверочной среде. Галочка «резервное копирование включено» не доказывает, что файл полный и пригоден для восстановления.

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

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

Порядок публикации должен быть понятен не одному человеку

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

Не пересылайте закрытые ключи и сертификаты обычной почтой. Храните их в согласованном защищённом месте, ограничьте права и замените всё, что могло попасть к посторонним. Для Google Play важно различать ключ загрузки и ключ подписи приложения. Для iOS нужно перечислить сертификаты, идентификаторы, возможности приложения и роли в App Store Connect.

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

Пять проверок перед окончательной приёмкой

Вместо формальной проверки папок выполните реальные действия:

1. Сборка. Новый разработчик создаёт рабочую проверочную версию на чистом компьютере.
2. Работа с обращением. Владелец открывает панель администратора, находит пользователя и понимает, где искать сведения об ошибке.
3. Восстановление. Команда разворачивает свежую резервную копию в безопасной среде и видит, какой объём данных мог бы быть потерян.
4. Публикация. Уполномоченные сотрудники готовят выпуск в тестовый канал и перечисляют согласования для рабочей версии.
5. Закрытие доступа. Владелец удаляет пробного пользователя или снижает его права и проверяет, что изменение можно отследить.

Руководство Catalyst по передаче проекта также ставит во главу угла возможность другой организации продолжить работу с кодом, документацией и макетами. Именно это и стоит считать критерием: не наличие файлов само по себе, а доказанная самостоятельность новой команды.

Когда нельзя подписывать окончательную приёмку

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

Тревожный признак — объёмный, но неконкретный документ. Фразы «размещено в облаке» и «аналитика подключена» не отвечают на вопросы о названии сервиса, аккаунте, проекте, администраторе, оплате и восстановлении. Одна точная строка с этими данными полезнее страницы общих слов.

Права на код, дизайн и материалы определяются договором и законодательством. Если стоимость и риски проекта значительны, юридическую часть стоит проверить с профильным специалистом. Технический список помогает найти недостающие элементы, но не заменяет договор.

Как мы организуем передачу в Appfyl

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

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

При выборе подрядчика пригодится статья о том, что спросить у студии разработки приложений. Требования к передаче стоит обсуждать до начала работы. А краткий расчёт проекта Appfyl поможет перечислить пользовательские роли и внешние сервисы, для которых затем понадобятся владельцы и доступы.

Посмотрите, как Appfyl превращает объем работ в запущенные продукты. Смотреть кейсы Appfyl.

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