Как мы реанимируем проблемные проекты

Первые симптомы

Редкий проект может похвастаться отсутствием каких-либо проблем. У кого-то периодически заканчивается место на диске и всё падает, а узнают об этом по звонкам от пользователей. Где-то в очередной раз возвращается ошибка, которую чинили уже десять раз. А кто-то еженедельно слышит про сдвиг сроков. По отдельности разные проблемы могут быть терпимыми и даже не критичными. Плохо, когда проблемы копятся, как снежный ком, а команда не воспринимает их всерьёз и не предлагает системных решений. Без должного подхода рано или поздно любой проект парализует ворохом нерешённых вопросов. В такой ситуации владелец проекта часто задумывается о смене подрядчика, а также, нередко, и о создании системы «с нуля».

Почему так происходит?

ИТ-процессам мало где учат. По данным опроса Stack Overflow (2024), 66% разработчиков имеют высшее образование, но 45% освоили профессию прямо на работе. Курсы рассказывают про алгоритмы и языки, а не про то, как выстроить процесс, чтобы проект не превратился в хаос. ACM — главная международная ассоциация в области компьютерных наук — институционально разделяет Computer Science и Software Engineering как разные дисциплины, признавая этот разрыв на уровне учебных программ.

Индустрия молодая и быстро меняется. По данным IBM, период «полураспада» технических навыков в разработке ПО сократился до 2,5–5 лет. Специалисту легко отстать и начать разработку проекта на уже устаревшем стеке технологий.

Много охотников за быстрыми деньгами. Демпинг на старте, продукт сдан с компромиссами — и проект становится миной замедленного действия для последующей поддержки и развития.

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

Наш подход

За 20+ лет опыта работы мы научились подхватывать «проблемные» проекты и «реанимировать» их. Что же обычно идёт не так и как мы это решаем?

Подробности ниже.

Сроки постоянно срываются

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

Наши подходы:

• Детализированный состав работ. Всегда понятно, что именно будет сделано.
• Причины отклонений. Если уходим от плана — сообщаем конкретику, а не просто говорим «нужна ещё неделя».
• Фиксация проблем, требующих системных решений. Решаем насущные проблемы оперативно, но сообщаем и ставим в план на будущее полноценное решение.

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

Не понимаю, на что уходит время

Подрядчик что-то делает каждый день, но из недели в неделю владельцу продукта не понятно, есть ли реальное движение. Отчёты либо отсутствуют, либо состоят из фраз «работаем над задачами».

Мы настраиваем на проекте максимальную прозрачность:

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

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

Сайт тормозит и падает под нагрузкой

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

Чтобы избежать проблем в будущем, мы предпочитаем измерять производительность инструментально на разных уровнях, что позволяет замечать замедления намного раньше — и до релиза, и после. Для проверки производительности до релиза мы проводим нагрузочное тестирование, а также запускаем автоматические тесты, замеряющие производительность (бенчмарки). После релиза в дело вступает мониторинг, который неустанно следит за показателями системы, а также отправляет уведомления, если что-то выходит за рамки нормы.

Каждое изменение что-то ломает

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

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

Всё держится на одном человеке

На некоторых проектах можно услышать: «Он ушёл в отпуск, давайте подождём». Если проект завязан на одного человека — жди беды.

Мы решаем это документацией, но без фанатизма. Документация часто устаревает на следующий день после того, как её написали. Настоящий источник правды о том, как работает система, — сам её код. Гораздо лучше, если проект следует общепринятым стандартам, а часть документации формируется напрямую из кода. А всё, что выходит за рамки, — фиксируется в документации.

Любая мелочь оценивается в дни и недели

От технических специалистов часто можно услышать: «Чтобы сделать X, нам сначала нужно…» — и дальше много технических деталей. Это проявление технического долга, и на «проблемных» проектах его становится так много, что каждое новое изменение даётся всё тяжелее.

Технический долг нельзя победить, его можно только возглавить: как можно раньше фиксировать и ставить в план работ. Это ежедневная работа. Фраза «нам сначала нужно…», к сожалению, никуда не уходит. Но она будет меньше стопорить процесс, ведь часть работы над техническим долгом в нормально функционирующей системе уже сделана (фиксация, обсуждение, оценка).

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

Выводы

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