Частая боль тимлида - объяснить бизнесу, что нужно заниматься техническими задачами. Бизнес не понимает слов “плохая архитектура” и “рефакторинг” - это звучит как чёрное заклинание, тёмное техническое колдовство.

Бизнес понимает риски и метрики. И тимлиду надо пройти путь от отрицания до принятия и начать говорить с бизнесом на его языке.

1. Переходим к удовлетворённости пользователя и времени производства Реальная история: в PT у меня была большая морально устаревшая часть системы, но бизнес не сильно хотел что‑то менять. Необходимость переписывания я показал на фактах: - У нас накопилось несколько десятков (возможно, и сотня) багов от пользователей о том, что эта часть просто не работала. - Время внесения любого изменения занимало 2–3 недели, при этом количество проблем значительно не сокращалось.

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

2. Переход к рискам (например, потерянные заказы/деньги) Тут без реальной истории 😉. Но если у вас уже был кейс отказа системы, который привёл к потере денег, - это хороший повод обсудить, что нужно что‑то менять. Можно даже посчитать, сколько денег стоит отказ от технической работы в отличие от её реализации.

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

Итого: говорите на языке бизнеса, и у вас всегда будет квота на технический долг. 🙃

Кстати, а как вы продаёте бизнесу техдолг? И есть ли у вас выделенное capacity на техно?

#mgmt #techno