Приложение работает, пользователи оформляют заказы, а новая команда не может назвать стоимость даже небольшой доработки. Исходники вроде бы есть. Документации нет. Прежний разработчик отвечает: «Там все понятно, просто откройте проект».
В такой ситуации я бы начинал с короткого технического обследования. Его задача — выяснить, можно ли воспроизвести сборку, проверить работу продукта и безопасно подготовить следующее обновление. По итогам должен появиться список подтвержденных фактов, препятствий и работ для входа в проект.
Отсутствие документации само по себе не означает, что приложение нужно переписать. Но обещать поддержку по фиксированным условиям до проверки тоже рано. Сначала нужно понять, чем новая команда действительно сможет управлять.
Ниже — рекомендуемый порядок проверки для заказчика. Это не история конкретного клиента: пример отчета в статье условный.
Какой вопрос должна решить проверка
Вместо задачи «посмотрите код и скажите, насколько все плохо» сформулируйте три вопроса:
- Можем ли мы собрать приложение из переданных исходников и проверить его работу?
- Что мешает подготовить и выпустить следующее обновление?
- Какие работы нужны до начала регулярной поддержки, а какие можно отложить?
Обследование не обязано сразу охватывать каждую строку кода. Согласуйте платформы, версию продукта, основные сценарии и глубину проверки. Android-клиент, iOS-клиент и серверная часть — отдельные области: успешная проверка одной не подтверждает состояние остальных.
Организация передачи и список доступов уже разобраны в чек-листе смены подрядчика. Здесь речь о другом: какие доказательства получить от команды после того, как материалы переданы.
1. Установить, какой код соответствует работающему приложению
Первый результат — не оценка качества архитектуры, а понятная отправная точка: версия в магазине, идентификатор сборки, соответствующая версия исходников и окружение.
В репозитории могут лежать незавершенные изменения, а опубликованное приложение — собираться из другой ветки. Если соответствие не удалось подтвердить, это отдельное ограничение проверки. Его нельзя заменить предположением «скорее всего, последняя версия».
Попросите зафиксировать, откуда взят код и что именно проверялось. При следующем обсуждении это избавит от ситуации, когда заказчик и разработчик говорят о разных версиях продукта.
2. Воспроизвести сборку на другом рабочем месте
Открывающийся проект еще не означает, что команда может выпустить обновление. Нужна сборка в подготовленном окружении с зафиксированными версиями инструментов и зависимостей.
Полезный результат этого шага:
- Получен устанавливаемый тестовый экземпляр приложения либо записана конкретная причина остановки.
- Сохранена инструкция с версиями инструментов и необходимыми настройками.
- Перечислены приватные библиотеки, сервисы и доступы, без которых сборка не повторяется.
- Секреты вынесены из инструкции: в ней указаны ответственный и место защищенного хранения.
Например, сообщение «проект не собирается» слишком общее. «Сборка останавливается при загрузке приватной библиотеки; доступ к ее хранилищу остался у прежнего подрядчика» уже позволяет определить следующее действие.
Тестовая сборка и готовность к публикации — разные результаты. Для Android документация отдельно описывает debug- и release-сборки и их подпись. Успешная установка тестовой версии не подтверждает возможность обновить приложение в магазине. Документация Android.
3. Проверить несколько сквозных сценариев
Выберите действия, от которых зависит работа бизнеса. В приложении доставки это может быть путь от входа до появления заказа у оператора. Во внутреннем сервисе — от назначения роли сотруднику до выполнения доступного ему действия.
Проверять нужно не только экран. Если приложение показало «Заказ оформлен», но сервер не сохранил заказ, бизнес-сценарий не завершен.
Зафиксируйте для каждой проверки:
| Поле | Что записать |
|---|---|
| Условия | Версия приложения, окружение, тестовая роль |
| Действия | Короткая последовательность шагов |
| Ожидаемый результат | Что должно произойти в приложении и связанных системах |
| Фактический результат | Что произошло и где это подтверждено |
| Ограничения | Что не проверяли и почему |
Проверки оплаты, рассылок и создания заказов проводите в согласованном тестовом режиме. Если тестового окружения нет, сначала определите безопасный способ проверки. Не отправляйте реальные заказы или уведомления клиентам ради демонстрации работоспособности.
4. Убедиться, что есть путь к следующему релизу
Команда должна понимать, кто подписывает сборку, кто загружает ее в магазин, кто принимает решение о выпуске и как проверяется обновление.
Смена подрядчика не всегда требует переноса приложения между аккаунтами. Если владельцем аккаунта остается ваша компания, сначала разберите необходимые роли и доступы. Если меняется именно аккаунт владельца приложения, это отдельная процедура: например, у Apple есть условия передачи и действия, связанные с возможностями конкретного приложения. Порядок передачи приложения у Apple.
Не нужно выпускать обновление всем пользователям только ради завершения обследования. Достаточность тестового выпуска и оставшиеся непроверенные этапы согласуйте заранее. В отчете должно быть ясно: что команда уже продемонстрировала, а что пока только предполагает сделать.
Как выглядит полезный отчет
Ниже — условный образец, а не результаты обследования реального проекта. Его можно использовать как структуру задания подрядчику.
| Проверка | Наблюдение в условном примере | Значение для поддержки | Следующее действие |
|---|---|---|---|
| Версия кода | Для Android найден тег опубликованного релиза; для iOS соответствие не подтверждено | Выводы по Android нельзя переносить на iOS | Запросить у прежней команды сведения о сборке iOS |
| Сборка | Android собирается на новом рабочем месте | Можно проверять изменения в тестовой версии | Сохранить инструкцию и настройки окружения |
| Выпуск обновления | Тестовая сборка установлена, доступ к публикации не проверен | Готовность к релизу еще не подтверждена | Проверить роли и процедуру подписи |
| Оформление заказа | Тестовый заказ появился на сервере; уведомление не проверялось | Основная цепочка проверена частично | Согласовать проверку тестового уведомления |
| Восстановление сервера | Инструкция и результаты проверки резервной копии не предоставлены | Возможность восстановления неизвестна | Отдельно определить объем проверки инфраструктуры |
К таблице стоит добавить ответственных, зависимости и оценку следующего этапа. Если оценка пока невозможна, укажите, каких данных не хватает. Формулировка «все плохо, надо переписать» без наблюдений и альтернатив не помогает принять решение.
Три возможных решения после обследования
Начать поддержку. Проверенные части системы позволяют выполнять согласованный набор задач. Известные ограничения записаны, обязанности сторон определены.
Сначала восстановить управляемость проекта. Например, наладить сборку, получить недостающие доступы или подготовить тестовое окружение. Это отдельный этап с результатом и бюджетом, а не неопределенное «погружение» внутри месячного пакета.
Отдельно оценить глубокую переработку. Если ограничения мешают нужным бизнесу изменениям, попросите сравнить варианты: устранить конкретные препятствия, заменить часть системы или разработать новую версию. В сравнении должны быть стоимость, риски перехода и влияние на пользователей. Одного возраста технологии для такого решения недостаточно.
За что платить на первом этапе
Предметом оплаты лучше сделать согласованную проверку и ее результаты: инструкцию сборки, протокол сценариев, список препятствий и план работ. Не обещание найти абсолютно все проблемы.
Обследование не равно полному аудиту безопасности, нагрузочному тестированию или проверке восстановления всей инфраструктуры. Если эти работы нужны, их объем следует оговорить отдельно. Иначе одинаковое слово «аудит» в двух предложениях будет означать разные услуги.
После обследования запросите отдельно оценку входа в проект и условия регулярного сопровождения. Как сравнивать состав работ и расходы, разобрано в статье о стоимости поддержки мобильного приложения.
С чего начать, если приложение уже нужно передавать
Подготовьте ссылку на приложение, описание ближайшей задачи и список имеющихся материалов. Пароли, ключи подписи и выгрузки клиентской базы для первого обращения не нужны.
Я руковожу Mobecan. Если вам нужна команда для сопровождения существующего приложения, можно обсудить передачу на поддержку. Начать разговор стоит с границ проверки и ожидаемого результата: что новая команда должна подтвердить до того, как возьмет ответственность за обновления.