Брошенный программный проект спасают в таком порядке: сначала закрепите за собой доступы (репозиторий, серверы, домен, аккаунты в магазинах приложений), затем закажите независимый аудит кода и только после этого, по его итогам, решайте, дорабатывать или переписывать. Самая частая ошибка: первым делом просить новую студию оценить, сколько стоит «просто доделать остальное». Пока код никто не открыл, любая цена остаётся догадкой. Ниже мы описываем шаги, которые проходим сами, когда принимаем чужой проект.
Почему проекты по разработке ПО остаются недоделанными?
В проектах, которые попадают к нам, причина редко сводится к чьей-то недобросовестности. Обычно несколько проблем наслаиваются друг на друга: объём работ не зафиксирован письменно и постоянно растёт, фиксированная цена этот рост не выдерживает, и разработчик постепенно отходит от проекта, на котором теряет деньги. Если систему знает один человек, достаточно его перехода на другую работу. Бывает и так, что техническая основа настолько слабая, что каждая новая функция ломает две старые и команда перестаёт продвигаться. Причину важно понять, иначе с новой командой вы попадёте в ту же ловушку.
Что закрепить за собой в первые 48 часов?
Если отношения ещё не разорваны окончательно, до любых технических споров оформите на себя следующие доступы. Если обстановка напряжённая, запросите всё одним письменным списком:
- Репозиторий исходного кода: права владельца (owner) в GitHub, GitLab или Bitbucket. Zip-архива недостаточно, история коммитов показывает, как развивался код.
- Серверы и облачные аккаунты: панель хостинга, облачный провайдер, база данных и резервные копии. Проверьте, с чьей карты оплачиваются счета.
- Домен и DNS: аккаунт у регистратора должен быть оформлен на вас.
- Аккаунты магазинов: App Store Connect и Google Play Console. Если приложение опубликовано в аккаунте разработчика, перенос планируется отдельным шагом.
- Сторонние сервисы: ключи платёжной системы, SMS, почты, карт и push-уведомлений.
- Переменные окружения, заметки по установке и дизайн-макеты, если они есть.
Если код у вас, а сервер, домен и аккаунт в магазине у кого-то другого, вы владеете не продуктом, а лишь его копией.
Получив доступы, смените все пароли и API-ключи. Это не обвинение, а обычный шаг при передаче. Если в договоре прописана передача исходного кода и исключительных прав, запрос решается гораздо проще; почему эти пункты нужны с первого дня, мы разбирали в статье о договоре на разработку ПО. Этот текст не является юридической консультацией; при споре обратитесь к юристу.
Как проходит аудит кода?
Аудит кода означает, что новая команда действительно запускает проект и смотрит, что внутри. Мнение по демо или скриншотам аудитом не считается. Хороший аудит письменно отвечает на вопросы:
- Можно ли развернуть и запустить проект на чистой машине, следуя документации?
- Какие функции реально работают, а какие существуют только на экране?
- Актуальны ли версии библиотек и фреймворка, нет ли компонентов без поддержки?
- Логична ли структура базы данных, есть ли в продакшене реальные данные и как их защитить?
- Есть ли явные уязвимости: пароли в коде, незащищённые API, экраны без проверки прав?
- Есть ли тесты, логирование ошибок и автоматический деплой?
Результат аудита: понятная оценка каждого модуля, например «надёжный», «можно исправить» или «нужно переписать». По сути это карта технического долга проекта и единственная разумная основа для следующего решения. Сколько он займёт, зависит от размера проекта; важно, чтобы аудит оценивался как отдельная ограниченная работа. Так вы узнаёте реальное положение дел, не связывая себя договором на доработку.
Дорабатывать или переписывать?
Любая новая команда инстинктивно хочет переписать всё заново: читать чужой код сложнее, чем писать свой. Поэтому принимайте решение по итогам аудита, а не по ощущениям. Грубое правило: если модель данных крепкая, а проблемы сосредоточены в отдельных модулях, продолжать с текущим кодом почти всегда быстрее. Если модель данных негодная, основной фреймворк на версии без поддержки или любое изменение что-то ломает, переписывание оказывается меньшим риском.
Чаще всего верный ответ посередине: рабочие части сохраняют, самый проблемный модуль переписывают первым, остальное улучшают постепенно. Если в системе уже есть живые пользователи и данные, поэтапный переход безопаснее, чем замена за одну ночь; шаги из нашей статьи о миграции данных из старой системы применимы и здесь.
Как передать проект новой команде?
Первый договор с новой командой делайте небольшим: аудит плюс первые критичные исправления. Вы увидите, как работает команда, и не привяжете снова всё к одному контракту. Для оставшейся работы просите письменное техническое задание, критерии приёмки и оплату по этапам. Репозиторий с первого дня остаётся в вашем аккаунте, новая команда работает в нём. Вопросы, которые стоит задать при выборе подрядчика, мы собрали в материале о выборе компании-разработчика.
Чтобы история не повторилась, вместе с передачей заведите три привычки: короткую инструкцию по установке, которая обновляется с каждым релизом, мониторинг ошибок и логирование, чтобы проблемы были видны, и команду, в которой проект знают минимум двое.
Итог
Недоделанный проект обычно не так безнадёжен, как кажется, но порядок спасения важен: сначала доступы, потом аудит, в конце решение. Не обсуждайте цену до аудита и не соглашайтесь на переписывание, которое аудит не обосновал. Если у вас на руках недостроенный проект, наша команда заказной разработки сначала изучит его и даст письменное заключение; после этого при желании вы можете запросить предложение.