Как спасти проблемный IT-проект (и когда лучше начать заново)

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

• Сроки сдвигаются снова и снова, каждый раз по новой причине.
• Каждое исправление ломает что-то другое, а одни и те же ошибки возвращаются.
• Никто не может прямо ответить, когда продукт запустится.
• Разработчик или агентство медленно отвечает или перестало отвечать совсем.
• У вас нет доступа к коду, серверам или аккаунтам.
• Новые разработчики говорят, что не могут работать с кодом, «не переписав его сначала».

Один такой сигнал означает предупреждение. Три и больше обычно значат, что проекту нужно спасение, а не очередной срок.

Например, стартап, чей фрилансер перестал отвечать и при этом держит единственный пароль от сервера, уже нуждается в спасении проекта, даже если сам код в порядке.

Первая неделя задаёт всё, что будет дальше. До любой технической работы идут четыре шага:

• Поставьте новые функции на паузу. Строить на нестабильной основе значит удорожать каждое следующее исправление.
• Верните доступы. Убедитесь, что вы контролируете код, серверы, домен и все сервисы, от которых зависит продукт.
• Запишите, что обещали и что есть. Соберите предложение, договор, макеты и список того, что реально работает сегодня.
• Придержите платежи, не привязанные к сделанной работе. Если платежи идут по этапам, поставьте следующий на паузу до появления понятного плана.

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

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

• Репозиторий с кодом и полной историей, а не zip-архив последней версии.
• Аккаунты хостинга и серверов, включая базы данных и резервные копии.
• Регистратор домена и настройки DNS.
• Аккаунты разработчика в магазинах приложений, если есть мобильное приложение.
• Сторонние сервисы: платежи, почта, аналитика, карты, ИИ-API.
• Файлы дизайна и вся документация, какая есть.

Если репозиторий находится в чужом аккаунте, попросите его передать. Документация GitHub объясняет, как при передаче сохраняются история, задачи и пул-реквесты.

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

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

• Архитектура. Как части связаны между собой и выдержит ли структура нужные вам функции.
• Качество кода. Читаемость, дублирование и то, насколько рискованно что-то менять.
• Безопасность. Типичные риски, например из OWASP Top 10, а также то, как хранятся секреты и персональные данные.
• Инфраструктура. Хостинг, развёртывание, резервные копии и мониторинг.
• Тесты и документация. Что есть, чего нет и что потребуется, чтобы это добавить.

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

В Sakura мы работаем ровно в таком порядке: сначала аудит, потом смета. Только так спасение не оценивают по обещаниям, которые код не выполняет.

Проект застрял прямо сейчас? Расскажите, что произошло. Мы начнём с доступов и аудита и честно скажем, что можно спасти.

Обычно исправлять. Старый код, который работает в продакшене, хранит годы мелких исправлений реальных проблем, и переписывание выбрасывает их вместе с плохими частями.

Джоэл Спольски объяснил это в известном эссе Things You Should Never Do. Он назвал переписывание кода с нуля «самой худшей стратегической ошибкой, которую может совершить софтверная компания», на примере Netscape: переписывание заняло почти три года, пока конкуренты уходили вперёд.

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

Даже когда побеждает переписывание, его редко нужно делать сразу целиком. Паттерн Strangler Fig от Мартина Фаулера описывает замену системы по частям: новые части строятся рядом со старыми, пока старый код нельзя будет отключить.

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

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

Если прежняя команда не идёт на контакт, не ждите её. Верните аккаунты, которыми управляете вы, начните аудит с тем, что есть, и ведите письменную запись того, что и когда вы запрашивали.

Когда вердикт ясен, работайте в строгом порядке. Сначала запуск, потом улучшения:

• Стабилизация. Исправьте критические ошибки, из-за которых продукт падает, теряет данные или не принимает платежи.
• Сценарии для запуска. Доделайте только то, что нужно продукту для выхода; всё остальное ждёт.
• Развёртывание и мониторинг. Чтобы релизы стали рутиной, а проблемы были видны раньше, чем о них сообщат пользователи.
• Запуск. Реальные пользователи покажут, какие из оставшихся проблем действительно важны.
• Улучшения. Проходите остаток списка в порядке влияния на бизнес.

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

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

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

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

Если вы сравниваете предложения на само спасение, действуют те же правила, что и для любого проекта. В статье «Фиксированная цена или почасовая оплата» объясняем, когда какая модель подходит.

Спасённый проект даёт шанс ввести те меры защиты, которых не хватило в первый раз:

• Права. Репозиторий, хостинг, домен и аккаунты в магазинах приложений остаются на вашу компанию.
• Документация. Пишется по ходу работы, чтобы продукт больше никогда не зависел от одного человека.
• Этапы. Платежи следуют за результатами, которые можно проверить, например за рабочей сборкой на тестовой ссылке.
• Порядок изменений. Новые запросы оцениваются и согласуются до того, как за них кто-то возьмётся.
• Поддержка после запуска. Понятный план исправлений и обновлений, например ежемесячный план поддержки.

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

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