Представьте: вам передают проект, от которого отказались две предыдущие команды. Документации нет. Ключевой разработчик то «болеет», то «ничего не знает». Кодовая база — «черный ящик», который еле дышит. А через полтора месяца — ключевое отраслевое мероприятие, где продукт должны презентовать топ-менеджменту. И вы — третья команда, которой предстоит либо выплыть, либо утонуть окончательно.

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

Первое, с чем сталкивается команда на таком проекте, — информационный вакуум. Документации по архитектуре нет. Предыдущие исполнители не передают знания. Единственные артефакты, которые попадают в руки, — медленный, нестабильный код и шлейф критики от заказчика в адрес тех, кто работал до вас.

Помимо технических проблем — а они были серьезными, включая 60-секундную загрузку страниц и потерю данных в интеграциях — проект имел жёсткую организационную специфику:

• Сложная отчётность. Заказчик требовал детальные отчёты раз в две недели по строгим шаблонам. Каждый спринт должен был сопровождаться протоколом испытаний и скриншотами каждого изменения.
• Оценки «вслепую». Задачи приходилось оценивать без полного понимания кодовой базы.
• Долгое согласование. Спринты, задачи, изменения — всё проходило через несколько уровней руководства.

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

Мы разбили работу на два направления:

1. Стабилизация критичного. Нашли самые болезненные точки — например, запросы, которые «вешали» базу данных — и временно «заморозили» их тактическими решениями вроде кэширования. Никакой магии: просто «жгут на артерию», чтобы пациент дожил до операции.

2. Форсированная разработка под мероприятие. Параллельно создавали новый функционал для презентации. Здесь нас спасли две вещи: короткие итерации и ежедневная сверка с заказчиком. Мы показывали промежуточные результаты каждый день, чтобы не уйти в сторону и не получить на финише «это не то, что мы просили».

Мероприятие прошло успешно. Проект выжил. Но мы понимали: это не победа, а лишь отсрочка. Системное лечение было впереди.

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

1. Шаблонизация и «сушка» требований  Первый месяц мы переделывали отчёты до пяти раз. Причина была том, что мы не до конца понимали «внутреннюю кухню» нормативных требований заказчика. Тогда мы сделали простую, но эффективную вещь: изучили всю нормативную базу, проанализировали комментарии, полученные за время переделок, и создали собственные шаблоны документов. Согласовали их с заказчиком один раз — и перестали тратить на это время.

2. Прозрачность  Мы помнили: мы — третья команда на проекте. Доверие не выдаётся авансом. Поэтому мы внедрили практику избыточной прозрачности на всех уровнях:

• Каждый спринт сопровождался протоколом испытаний с конкретными тест-кейсами.
• Каждое изменение в коде фиксировалось скриншотом.
• Все риски и проблемы эскалировались заранее, а не постфактум.

Через несколько месяцев заказчик перестал требовать тройной перепроверки. Он начал доверять нашей оценке.

3. Продажа рефакторинга  Самое сложное в легаси-проектах — «продать» заказчику необходимость рефакторинга. Когда бизнесу нужна «ещё одна кнопка», сложно объяснить, почему полспринта уйдёт на переписывание невидимых внутренних запросов.

Мы использовали язык бизнеса, а не разработки:

• Не «рефакторинг роутов», а «ускорение загрузки в 50 раз».
• Не «внедрение шины данных», а «гарантированная доставка данных, исключающая ручное дозаполнение».
• Не «настройка CI/CD», а «снижение риска человеческой ошибки при деплое».

Каждую техническую инициативу мы упаковывали в измеримый бизнес-результат.

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

Три главных урока, которые мы вынесли из этой истории:

1. В режиме реанимации «сначала изучить» — непозволительная роскошь. Ресёрч и разработка должны идти параллельно, иначе сгорят сроки.
2. Бюрократия — это не проблема. Поймите правила игры, формализуйте их — и трение исчезнет.
3. Доверие нужно строить. Показывайте больше, чем просят, и рано или поздно вас перестанут проверять.

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

Оставляйте заявку на консультацию.