Как доделать незавершённое приложение, если ушла команда
Доделать незавершённое приложение после ухода команды можно, но требуется технический аудит, после которого выбирают между доработкой и переписыванием. Вот пошаговый план.
Наняли команду, заплатили аванс, видели демо — а потом разработчики пропали, отвечают раз в неделю или заявили, что «больше не могут продолжать». Это не редкость. По данным Standish Group, лишь 29,7% IT-проектов укладываются в срок, бюджет и план качества; ещё 49,2% сталкиваются с серьёзными проблемами, а 21,1% проваливаются полностью Standish Group CHAOS Report. При этом текучка в IT — самая высокая среди профессиональных секторов: около 13,2% в год по исследованию LinkedIn LinkedIn research via Coderio. Для разработчиков ПО эта цифра ещё выше — примерно 23% Boundev.ai. Мы в Softwhere.uz специализируемся на спасении заброшенных IT-проектов — в прошлом месяце, например, разбирали кейс мобильного агрегатора доставки еды из Ташкента с бюджетом около $18,000, где команда из трёх человек исчерпала аванс, не запустив бэкенд.
Ключевые выводы
- Проекты, которые прежняя команда называла «на 80% готовы», в нашем опыте требуют в среднем 14 недель до production-ready состояния.
- Технический аудит кода занимает 3–5 рабочих дней и стоит $800–$2,500 — это обязательный шаг перед любыми решениями.
- Доходчивый мусор, который работает у пользователей, побеждает идеальный код, которого не существует.
- Спасение проекта обычно обходится на 30–70% дороже первоначальной сметы, но в 2–3 раза дешевле переписывания с нуля.
- Новый разработчик выходит на полную продуктивность через 3–6 месяцев — агентство с опытом rescue сокращает этот срок до недель.
Почему разработчики бросают проект посреди работы?
Причины редко связаны с недобросовестностью. Чаще всего это комбинация: команда недооценила сложность, исчерпала бюджет, внутри возникли конфликты, или ключевой человек ушёл — и с ним ушла вся экспертиза. Семь из десяти разработчиков уходят в течение двух лет, а среди middle-специалистов эта текучка максимальна Rockstar Developer University. Для вас как заказчика это означает: даже если новая команда честная, она может просто не осилить проект.
Мы не раз видели, как стартап нанимал трёх junior-разработчиков под руководством «техлида» без опыта управления. Через четыре месяца деньги кончились, а архитектура приложения не выдерживала нагрузки даже в тесте. Разработчики бросили проект не потому, что плохие — а потому что система сломалась раньше, чем они успели её починить.
Насколько плоха моя ситуация на самом деле?
Скорее всего, лучше, чем кажется — но хуже, чем вам говорили. Главная ловушка: разрыв между «выглядит готовым» и «работает у реальных пользователей». В нашей практике аудита проекты, которые прежняя команда оценивала в 80% готовности, в среднем требовали ещё 14 недель до production-ready состояния.
Это не значит, что вас обманывали. Разработчики искренне верили, что «осталось чуть-чуть». Но финальные 20% — это интеграция платежей (Payme, Click, Uzum в Узбекистане), обработка ошибок, push-уведомления, модерация контента, адаптация под старые Android-версии. Всё это не бросается в глаза на демо, но без этого приложение не пройдёт даже мягкий запуск.
Что делать в первые 48 часов?
Прекратите платить, если ещё платите. Соберите всё, что имеете: исходный код, доступы к репозиториям, серверам, API-ключи, документацию, переписку. Проверьте, кому принадлежат домен, аккаунты в App Store и Google Play.
Затем — технический аудит. Не пытайтесь сразу нанимать новых разработчиков в штат. Сначала нужно понять, во что вы вложили деньги. Это занимает 3–5 рабочих дней и стоит $800–$2,500 в зависимости от размера кодовой базы. Результат — честный отчёт: что работает, что мусор, и три варианта дальнейших действий.
Мы рекомендуем проводить аудит сторонней командой, а не той, которая потенциально будет доделывать. Иначе конфликт интересов неизбежен: «всё плохо, давайте перепишем» — удобная позиция для продажи большего объёма работ.
Как понять, в каком состоянии на самом деле код?
Запросите у прежней команды доступ к Git-репозиторию. Если его нет — это уже красный флаг, но не приговор. Проверьте, собирается ли проект на чистой машине: склонируйте, установите зависимости, запустите. Если этот процесс занимает больше дня — архитектура хрупкая.
Смотрите тесты: есть ли они вообще, проходят ли. Смотрите документацию API: актуальна ли, есть ли она. Смотрите, какие внешние сервисы зашиты в код — возможно, вы платите за SaaS, о котором не знали.
Один наш клиент обнаружил, что прежняя команда использовала пиратскую лицензию на библиотеку карт — пришлось срочно мигрировать на открытую альтернативу. Другой узнал, что бэкенд хостился на личном аккаунте разработчика, который после ухода удалил инстанс. Бэкапов не было.
Нанимать новую команду в штат или отдать агентству?
Новый разработчик выходит на полную продуктивность в среднем через 3–6 месяцев Rockstar Developer University. Замена middle-разработчика обходится до 2x его зарплаты с учётом найма, онбординга и потерянной продуктивности Boundev.ai. В условиях Узбекистана, где рынок разработчиков перегрет, найм в штат — лотерея со сроками.
Агентство с опытом rescue даёт три преимущества: уже сложившуюся команду, стандартизированный чек-лист из 47 пунктов для оценки кодовой базы, который мы применили в 12 проектах за 2024 год, и финансовую ответственность по договору. Минус — выше ставка в час. Плюс — предсказуемый срок и результат.
Мы считаем, что для rescue-проектов штатный найм оправдан только если у вас уже есть сильный технический директор, который сможет оценить кандидатов. В противном случае вы рискуете нанять человека, который через три месяца уйдёт — и цикл повторится.
Как выглядят реалистичные сроки и бюджет на спасение проекта?
Возьмём гипотетический пример, близкий к нашей практике. Мобильное приложение-маркетплейс для Узбекистана: iOS и Android, бэкенд на Node.js, админ-панель, интеграция с Payme и Click.
Прежняя команда оценила проект в $22,000, получила $16,000 авансом, сделала визуально приличное приложение — но бэкенд не выдерживал 50 одновременных пользователей, чаты теряли сообщения, а push-уведомления не работали на Android 10+.
Аудит: 4 дня, $1,800. Вывод: фронтенд приемлем, бэкенд требует рефакторинга авторизации и очередей сообщений, админ-панель — переписывания.
Спасение: 10 недель, $18,000–$24,000. Итого клиент потратил $16,000 + $21,000 = $37,000 — на 68% больше первоначальной сметы, но приложение вышло в продакшн.
Альтернатива — переписать с нуля: типичный маркетплейс среднего размера в Центральной Азии стоит $35,000–$70,000, 4–6 месяцев минимум. При этом вы теряете время, которое уже вложили, и рискуете столкнуться с теми же проблемами на новой команде.
А если код — полный мусор, переписать с нуля?
Эмоциональная ловушка: «Этот код — помойка, я не хочу с ним иметь дело». Мы понимаем. Но работающая помойка, которую тестируют пользователи, побеждает идеальный код, которого не существует.
В одном rescue-проекте мы наследовали бэкенд на PHP с 12-уровневой вложенностью if-else, без тестов, с комментариями на трёх языках. Миграция на чистую архитектуру заняла бы 5 месяцев. Вместо этого мы изолировали критичные модули, обернули их API, и через 8 недель клиент получил первых платящих пользователей. Через полгода — уже с выручкой — переписали ядро без спешки.
Переписывание с нуля оправдано, только если: (1) технология устарела настолько, что не поддерживается, (2) код невозможно запустить локально, (3) бизнес-логика настолько запутана, что править её дороже, чем воспроизвести. В остальных случаях — эволюция, не революция.
Как не допустить такого в будущем?
Три практических правила, которые мы вывели из десятков rescue-проектов.
Первое: владейте артефактами. Репозиторий на вашем аккаунте GitHub/GitLab, серверы на вашей учётной записи AWS/Google Cloud, домен на вашем регистраторе. Не на «нашем сервере разработчика» — на вашем.
Второе: требуйте промежуточные релизы. Каждые две недели — работающая версия, которую вы можете установить и потрогать. Не «скриншот в Telegram», не «ещё чуть-чуть и покажем».
Третье: фиксируйте бюджет поэтапно. 30% — дизайн и прототип, 30% — MVP с критичным функционалом, 40% — после приёмки MVP. Если команда не может показать работающий этап — следующий транш не перечисляется.
И ещё одно, с чем мы не согласны с распространённым советом: «всегда начинайте с MVP». Для рынка Узбекистана и соседних стран это часто вредно. Здесь пользователи сравнивают ваше приложение с крупными игроками — Wildberries, Uzum, Яндекс.Еда. «MVP» без нормальной доставки, отслеживания заказа и поддержки выглядит как подделка. Лучше сузить функционал до одного города или одной категории, но сделать её качественно — чем запускать «минимальный» продукт, который никто не вернёт использовать.
Может ли ИИ ускорить доделку проекта?
ИИ помогает, но не творит чудес. В нашем опыте нейросети ускоряют на 15–25% задачи, где понятна архитектура: написать тесты к существующему модулю, сгенерировать boilerplate для нового экрана, найти очевидные баги в логике.
Но для rescue-проектов ключевая проблема — не скорость написания кода, а понимание, что этот код делает и почему сломан. ИИ не может прочитать «контекст в голове у ушедшего разработчика». Он не знает, что костыль в строке 847 связан с особенностью API банка, которая нигде не документирована.
По данным Pertama Partners, 80% проектов с ИИ не достигают запланированной бизнес-ценности — примерно вдвое чаще, чем обычные IT-проекты Pertama Partners. Мы видим причину: компании ожидают, что ИИ заменит понимание предметной области, а он лишь усиливает его при наличии.
Практический вывод: ИИ-инструменты в руках опытной rescue-команды — плюс. ИИ как «волшебная кнопка, которая сама всё починит» — минус.
Как выбрать команду для rescue, которой можно доверять?
Смотрите на три сигнала. Первый: они просят аудит перед сметой. Если агентство готово назвать цену, не заглянув в код — они либо необоснованно оптимистичны, либо закладывают огромный риск-коэффициент, который вы заплатите.
Второй: у них есть кейсы rescue с контактами предыдущих клиентов. Не «мы делали приложения», а «мы доделывали брошенные проекты, вот человек, с которым можно поговорить».
Третий: они говорят «нет». Команда, которая соглашается на любые сроки и любой бюджет, либо не понимает сложность, либо планирует «потом разберёмся». Мы регулярно отказываем в rescue, если аудит показывает, что проект дешевле переписать — и объясняем, почему.
Остались вопросы?
Если разработчики бросили проект, и вы не знаете, с чего начать — начните с аудита. Не с найма, не с переписывания, не с паники. С фактов.
Мы в Softwhere.uz делаем технический аудит брошенных проектов за 3–5 дней. После него вы получите честный отчёт и три варианта: доделать, переписать, или заморозить. Никаких обязательств продолжать с нами.
Хотите примерную оценку стоимости rescue вашего проекта? Калькулятор стоимости даст диапазон за 2 минуты. Или напишите нам напрямую — отвечаем в течение дня.
Частые вопросы
Как понять, что разработчик реально ушёл, а не просто тянет время?
Если ответы редеют до раза в неделю, дедлайны сдвигаются без объяснений причин, а демо постоянно «завтра» — это уже фактический уход, как бы ни назывался статус. Поставьте жёсткий ультиматум: работающий билд до конца недели, или расторжение. Реальная команда, которая просто в трудностях, согласится на прозрачность. Ушедшая — продолжит обещания.
Можно ли судиться с бывшей командой разработчиков?
Технически — да, если есть договор и нарушения. Практически — редко окупается. Суд в Узбекистане по IT-спорам затягивается на месяцы, а исполнение решения ещё дольше. Лучше направить энергию и бюджет на спасение проекта. Исключение: если прежняя команда удерживает ваши активы (домен, код, аккаунты) — тогда юрист нужен сразу.
Что если у меня нет исходного кода?
Проверьте все возможные места: GitHub, GitLab, Bitbucket — возможно, репозиторий есть, но доступ потерян. Проверьте серверы развёртывания: иногда там лежат собранные версии, из которых можно реверс-инжинирить. В крайнем случае — decompile мобильного приложения, если оно у вас установлено. Это не даёт полноценного кода, но позволяет восстановить API-спецификацию и дизайн. Дороже, чем иметь исходники, но не смертельно.
Нормально ли чувствовать, что проект хуже, чем говорила старая команда?
Абсолютно нормально — и почти всегда правда. Разрыв между «показали на демо» и «работает в продакшне» огромен. Это не значит, что вас обманывали; скорее, сами разработчики недооценивали оставшийся объём. В нашем опыте проекты «на 80%» требуют в среднем 14 недель до готовности. Это статистика, не ваша неудача.
Стоит ли рассказывать инвесторам или клиентам, что случилось?
С инвесторами — да, и как можно раньше, с планом. Инвесторы ненавидят сюрпризы больше, чем проблемы. «Команда ушла, мы нанимаем rescue-агентство, вот аудит, вот сроки, вот бюджет» — лучше, чем месяцы молчания и очевидная паника.
С клиентами — зависит от стадии. Если приложение ещё не запущено — незачем создавать тревогу. Если уже в использовании — честность с конкретикой: «технические работы, возобновим 15 августа». Главное — не обещайте сроки, которые не можете обосновать.
Источники
- Standish Group CHAOS Report via Gitnux — 29,7% проектов укладываются в срок/бюджет/качество, 49,2% имеют серьёзные проблемы, 21,1% проваливаются полностью
- LinkedIn research via Coderio — текучка в IT 13,2% в год, 32% IT-специалистов планируют сменить работу в ближайшие 12 месяцев
- Boundev.ai — текучка разработчиков ПО ~23%, замена middle-разработчика до 2x зарплаты
- Rockstar Developer University — 7 из 10 разработчиков уходят в течение двух лет, пик текучки среди middle-инженеров; выход на полную продуктивность нового разработчика 3–6 месяцев
- Pertama Partners — 80% проектов с ИИ не достигают бизнес-ценности, вдвое чаще обычных IT-проектов
Готовы начать свой проект?
Наша команда опытных разработчиков готова помочь вам создать потрясающие мобильные приложения, веб-приложения и Telegram-боты. Давайте обсудим требования к вашему проекту.
