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

Подрядчик бросил разработку

Подрядчик перестал отвечать, сорвал сроки или закрылся. Продукт наполовину готов, документации нет, и непонятно, что из сделанного вообще работает. Часто неизвестно даже, где лежит актуальная версия кода и на кого оформлены серверы.

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

Продукт устарел и перестал развиваться

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

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

Продукт падает, и непонятно почему

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

Сначала даём продукту «зрение»: логи, мониторинг, алерты. Потом находим и закрываем причины падений по приоритету — от тех, что стоят денег, к косметическим.

Аудит отвечает на три вопроса: можно ли продукт безопасно развивать, что мешает ему работать стабильно и сколько стоит привести его в порядок. Для этого смотрим не только код.

• Код и архитектура: как устроены модули и связи между ними, где дублируется логика, какие части никто не сможет поддерживать.
• Зависимости: устаревшие библиотеки и фреймворки, известные уязвимости в них, совместимость с текущими версиями iOS и Android.
• Безопасность: хранение паролей и ключей, права доступа, защита персональных данных и соответствие 152-ФЗ.
• Инфраструктура: где и как развёрнут продукт, есть ли резервные копии и проверялось ли восстановление из них.
• Сборка и релизы: можно ли собрать приложение из репозитория, автоматизирован ли выпуск, кто владеет ключами подписи.
• Данные и интеграции: обмен с CRM, 1С, платёжными и внешними сервисами — что работает, что падает молча.
• Продукт: ключевые сценарии пользователей, аналитика, отзывы и обращения в поддержку.

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

1. Находка — что именно обнаружено и где: модуль, файл, сервис, настройка.
2. Почему это проблема — объяснение без жаргона, понятное владельцу продукта.
3. К чему приведёт — риск для бизнеса: потеря данных, простой, уязвимость, рост стоимости доработок.
4. Рекомендация — что сделать и примерная трудоёмкость.
5. Приоритет — критично, важно или можно отложить.

Пример записи — иллюстрация формата, а не находка из реального проекта:

Находка

Ключи доступа к платёжному сервису хранятся в коде мобильного приложения.

Почему это проблема

Ключи можно извлечь из опубликованного приложения.

К чему приведёт

Посторонние смогут выполнять операции от имени вашего аккаунта у платёжного провайдера.

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

Перенести операции на сервер, выпустить новые ключи, старые отозвать.

Приоритет

Критично — исправить до следующего релиза.

В конце отчёта — сводка: общее состояние продукта, три–пять главных рисков и план работ по этапам. Отчёт остаётся у вас, и с ним можно идти к любой команде, а не только к нам.

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

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

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

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

Мы не обсуждаем качество работы прошлой команды в оценочных терминах — описываем факты и последствия. Вам нужны решения, а не виноватые.