Есть момент, когда таблица сравнения уже перестаёт помогать. В ней появились веса, дополнительные критерии и ещё одна колонка. Оба варианта всё равно неудобны. Хочется найти последний факт, после которого выбор сделает себя сам.
В инженерной работе это особенно соблазнительно. Мы привыкли проверять гипотезы и устранять неизвестность. Но данные не выбирают за нас, сколько задержки продукта стоит дополнительная надёжность и какую сложность команда готова обслуживать следующие полгода.
Допустим, можно быстро адаптировать существующий модуль или потратить месяц на новый. У первого варианта останется известное ограничение. У второго — риск не успеть и недооценить миграцию. Исследование полезно, пока способно изменить выбор. Пятая встреча с прежними аргументами уже ничего не исследует.
Назвать цену вслух
Я бы записал решение человеческим языком: сейчас используем старый модуль, потому что функция нужна к определённому событию; ограничение принимаем на такой-то объём; за метрикой следит конкретный человек; при достижении порога возвращаемся к замене. Это честнее, чем объявлять старый модуль «оптимальной архитектурой».
В такой записи остаётся место для ошибки. Мы можем неверно оценить рост нагрузки. Но будущей команде будет понятно, на каких предположениях стоял выбор. Ей не придётся угадывать, были предшественники ленивыми или знали что-то важное.
Отдельно стоит проверить, на кого легла принятая цена. Руководитель легко соглашается на временную сложность, если разбирать её будет дежурный инженер. Поэтому в обсуждении нужен человек, которому достанется эксплуатация. Его участие не делает решение единогласным, зато мешает записать чужой вечер в бесплатные ресурсы проекта.
Иногда честный выбор включает отказ от части задачи. Запустить один сценарий сейчас, ещё два оставить на потом. Для этого придётся признать, что желаемый объём не помещается в срок, вместо того чтобы искать архитектуру, волшебным образом отменяющую ограничение.
Скорость решения зависит и от пути назад. Изменить текст уведомления обычно проще, чем публичный контракт API. Удаление данных нельзя считать обратимым только потому, что в плане есть слово «бэкап»: восстановление нужно проверить. Осторожность должна соответствовать реальной цене последствий.
Мне нравится вопрос: какая информация ещё нужна и когда мы её получим? Если ответа нет, а цена ожидания растёт каждый день, пора признать, что дальнейшая задержка тоже стала выбором. Просто его никто не подписал.
Ответственность здесь не в обещании никогда не ошибаться. Она в готовности назвать причину решения, следить за последствиями и вовремя менять курс, не переписывая задним числом собственную уверенность.
Чего мы боимся больше — ошибиться или взять ответственность?
