Однажды заказчик пришёл с задачей, которая звучала как пара часов работы “Просто добавь кнопку - нажал, выгрузил данные, всё”. Я открыла код и поняла, что эта кнопка стоит не пару дней, а недель - и это если повезёт..

Сложнее всего оказалось не сделать, а объяснить так, чтобы услышали.

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

Архитектурное объяснение я попробовала и оно не зашло. Слои, связи, зависимости: всё правильно, всё мимо.

Что работает вместо “красивого кода”

Я перестала объяснять как устроено и начала объяснять что произойдёт. Не “тут монолитная структура без инверсии зависимостей”, а конкретно: - эта кнопка затрагивает три модуля, которые никто не трогал два года - если что-то сломается, то мы не узнаем сразу, потому что тестов нет - следующая фича после этой будет стоить столько же в лучшем случае.

Заказчик услышал третий пункт. Именно его.

Нетехнический человек воспринимает разработку примерно так: “нажал кнопку -> произошла магия -> получил результат”. Это не незнание - просто другая роль. Заказчик и не должен думать об архитектуре, это моя работа. Значит, говорить на его языке - тоже моя.

Как я считаю стоимость следующей фичи

Со временем сложился свой фреймворк. Не из учебника, а из разговоров, где меня не понимали, пока я не поменяла подход.

Три вещи, которые я оцениваю перед тем, как называть сроки: 1. Базовая сложность: сколько займёт в идеальных условиях, на нормальной архитектуре. 2. Архитектурный коэффициент - во сколько раз реальность дороже идеала. Код без тестов, с жёсткими связями между модулями - это 2-4× к оценке. Не абстракция: вот здесь нельзя менять, не затронув вот это. Рисую буквально на бумаге. 3. Риск-налог - что может пойти не так. Что сломается, насколько быстро заметят, сколько займёт починка. Не чтобы напугать, а чтобы показать, что “быстро” и “надёжно” здесь в противоречии.

Когда эти три числа стоят рядом - разговор меняется. Заказчик видит, что не “разработчик тормозит”, а “вот цена, вот риск, вот выбор”.

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

Что осталось в голове

Техдолг - это не технический вопрос. Это финансовый.

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

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

А вы как объясняете техдолг тем, кому важен результат, а не архитектура? Есть формулировка, которая сработала лучше всего?