Нет ничего более постоянного, чем временное
Обычно «временное решение» — это что-то быстрое, простое и сделанное на скорую руку. Такое решение редко приносит счастье заказчику и почти никогда — удовольствие исполнителю. Чаще всего временно внедряется мелкая деталь, что с первого взгляда кажется неважной и не стоящей глубокого анализа. Но именно такие они со временем вырастают в полноценные архитектурные чудовища под названием «исторически так сложилось», которые изрядно пьют кровь всех, кто с ними сталкивается.
Почему же компании принимают эти временные решения и всё-таки выделяют на них время и деньги?
На уровне бюджетов и стратегий о них обычно вообще не знают. Временные решения рождаются на уровне групп и отдельных команд. И чаще всего причина банальна — сроки. Решение нужно принимать здесь и сейчас, а времени на анализ просто нет. На больших проектах к этому добавляется страх перед какой-нибудь одной «большой задачей» — той самой, решение которой непонятно ни команде, ни менеджменту. На этого монстра закладывается большая часть проекта, проводятся бесконечные встречи и обсуждения. Весь менеджмент обращает на нее внимание. В итоге на остальные задачи время урезается до минимума. И их решение уже выбирается не из категории «правильно или неправильно», а из гораздо более практичной — «можно быстро сделать или нет?».
Скрытый текст
Каждую задачу можно сделать невыполнимой, если провести достаточное количество совещаний.
Поначалу такие решения честно помечаются как «временные» и «неправильные». В таск-трекере появляется тикет на переделку, на каждом дейлике умные люди вздыхают и потирают руки «поскорее бы переписать». То есть формально — всё под контролем. Но со временем все: и исполнители и заказчики привыкают к этой архитектуре. Исполнители со стороны бизнеса, работающие с этим функционалом, потихоньку меняются, и процессы компании начинают выстраиваться вокруг костылей.
И вот однажды в разработку прилетает задача: «Все пропало! Срочно переделайте механизм, работа встала!». Команда тратит время на фикс «бага», потому что это быстрее, чем исправлять архитектуру решения целиком. Но каждый новый патч, каждая правка только увеличивает стоимость возврата к нормальному решению. Поддержка превращается в постоянную борьбу: всё больше ручного труда, всё больше специализированных экспертов, которые должны держать систему на плаву. И чем дольше это длится, тем больнее для будущих поколений команды.
Знакомо каждому, не так ли?
Временные решения как системная проблема
В чём разница между реальным временном решении и скрытым архитектурным долгом? На словах — почти никакой. В реальности — принципиальная.
Настоящее временное решение всегда имеет план превращения в правильное. И это не «когда-нибудь переделаем», а конкретный сценарий: что именно будет заменено, при каком событии и за счёт каких ресурсов. Если такого плана нет, решение не временное. Оно просто ещё не успело стать постоянным.
Задумайтесь честно: вы знаете план выхода из всех своих «временных решений»? Или максимум — тикет без даты и ответственного?
Временные решения имеют склонность расти и превращаться в постоянные, потому что сроки не заканчиваются никогда. Люди не успевают осмыслить одно временное решение, как в бэклог уже прилетает ещё тридцать три задачи «на подумать». Архитектура не успевает переварить последствия, а команда — зафиксировать, что именно пошло не так. Каждое следующее решение принимается уже с учётом предыдущего костыля. Так временное решение обрастает зависимостями, проверками, исключениями — и перестаёт быть чем-то отдельным. Оно становится частью системы. А систему, как слова из песни, не выкинешь.
Скрытый текст
Но если в компании хватает рабочих ресурсов, но все равно полно костылей, то это уже вопрос культуры, а не архитектуры. Система лишь отражает то, что считается нормой в команде.
Если посадить свежего сотрудника рядом с выгоревшим, через полгода вы получите двух выгоревших сотрудников. С решениями ровно та же история. Токсичность в архитектуре — это не абстракция. Она напрямую влияет на процессы, сроки и качество новых решений. Когда в компании нормально жить с «временными» костылями без срока годности, это становится стандартом. Новые люди быстро учатся не задавать лишних вопросов, а процессы подстраиваются под текущую реальность. В такой среде временные решения не просто выживают — они размножаются.
Легко сказать «сделаем временную заглушку». Намного сложнее потом объяснять, почему вся логика компании держится на этой заглушке.
Пара кейсов из жизни, когда временное решение помогло и когда нет.
Кейс №1: Две системы, один короб и хаос на три года.
Компания инициировала переход с одной ИС на другую. В рамках перехода понадобилось отслеживать движения коробов с товаром внутри компании в новой системе. В старой такой сущности прос��о не существовало — движения конкретных коробов не отслеживались, только расходные ордера с фактом отгруженного товара. Как переносить? Важный и сложный процесс движения коробов, в новую систему, когда в старой он фиксируется кое-как. Временное решение было, на первый взгляд, великолепно в своей простоте: «Мы, по логике заказчика, на лету подменим ссылки документов в обмене данных, немного поколдуем с аналитикой и получим для какого короба делаются изменения». В общем сделаем все то, что заказчик и так делает в голове. Запланировали, что жить такое временное решение будет полгода максимум, пока не переедем полностью на новую систему.
Что могло пойти не так?
Спустя три года старая система не умерла, а временная логика с подменой документов проросла в десятки процессов. Теперь, чтобы это исправить, нужно не просто переписать обмен документа, а разобрать и пересобрать целый пласт бизнес-логики, который включает в себя: склад, логистика, закупки, е-ком и розницу. Стоимость правки выросла в десятки раз.
Это классическое временное решение, ставшее фундаментом — выдернуть его, не обрушив половину процессов, уже невозможно.
Кейс №2: Делай легко, делай играючи, кайфуй.
У конкретного заказчика была понятная задача: часть процессов передать внешнему подрядчику. Для этого требовалось реализовать интеграцию со сторонним сервисом. Сложность задача была в том, что реализовать интеграцию нужно было в максимально кратчайшие сроки, так как время на обработку товара было крайне ограниченным. У подрядчика было понятное API, с нашей стороны мы знали четкий объем необходимых работ. Команда быстро сделала рабочий прототип "на коленке", который снял остроту проблемы. А потом, без аврала, заменила его на чистую, полноценную интеграцию. Решение сработало именно как временное: оно купило время, не создав монстра.
Почему один случай — провал, а другой — успех?
Понятность задачи. Во втором случае всё было ясно: API, данные, процесс. В первом — задача была сформулирована как «как-нибудь связать несвязуемое, чтобы не переделывать все». Это не задача, а головная боль в чистом виде.
Заказчик и критичность. Интеграция с партнером была видима и критична для бизнеса. Её нельзя было бросить. А «подмена ссылок для упаковочных листов» — это «внутренняя кухня», которую бизнес не видит. Такие задачи первыми попадают под сокращение, когда речь заходит о рефакторинге.
Возможность снять давление. В успешном кейсе после внедрения прототипа критичность задачи упала, и появилось время на нормальное решение. В провальном — давление только росло: система ветвилась, хаос накапливался, но «тушить пожар» новыми костылями всегда казалось быстрее, чем заниматься профилактикой.
Главный урок:
Временное решение выживает только там, где есть конкретный заказчик, который заинтересован в его смерти. Нет заказчика — нет и шансов, что «времянку» когда-нибудь заменят. Она просто станет частью пейзажа.
Чек-лист. Три вопроса, которые спасут вашу архитектуру
Прежде чем согласиться на «времянку», задайте эти три вопроса команде и менеджеру:
1. А оно точно нужно? Бизнес действительно не может жить без этого костыля прямо сейчас? Или мы просто боимся сказать «нет» и потратить время на нормальное решение?
Половина «срочных» временных решений нужна не бизнесу, а чтобы отчитаться о закрытии тикета в спринте.
2. Мы знаем, как сделать правильно? У нас есть четкое понимание, как должна выглядеть архитектура итогового решения? Все ли блоки мы можем реализовать?
Если правильное решение непонятно, то «временное» — это не решение, а отсрочка провала. Вы не покупаете себе время, а закладываете мину.
3. Мы назначили дату переделки? Конкретно когда и при каких условиях мы это переделаем? Что за событие станет триггером? (закрытие квартала, выход нового модуля) Кто ответственный?
Без ответа на этот вопрос «временное» автоматически становится «постоянным».
Если на любой из трех вопросов ответ — «нет», внедрять временное решение НЕЛЬЗЯ. Точка.
Особенно если его продвигает «безумный менеджер», которого поджимает срок сдачи.
Важно помнить: он не отвечает за архитектуру. Не отвечает за технический долг. Не будет сидеть ночами, разбираясь в спагетти-коде из ваших «времянок». Отвечаете за это всё — вы.
Поэтому ваша задача — не просто соглашаться, а профессионально оценивать риски и говорить «нет» там, где цена «да» окажется фатальной для проекта. Иногда самое правильное временное решение — это потратить время сейчас, чтобы не хоронить его потом.
