"Просто мелкий фикс" — а на деле полгода рефакторинга

На меме всё как в жизни:
PM видит небольшую задачу, обещающую быстрое улучшение производительности.
А внутри — шесть месяцев архитектурного рефакторинга, болезненных обсуждений и переносов сроков.
Никто не соврал. Просто взгляды разные.

И это повторяется чаще, чем кажется.

1️⃣ Разработчику больно смотреть на старый код.

Он хочет переписать «как надо». Это нормально — каждый инженер внутри себя борется за чистоту.
Но если фича только проверяется, и шансы на её выживание — 20%, такой рефакторинг превращается в роскошь.
Важно уметь задавать себе вопрос: это инвестиция или попытка почувствовать контроль?

2️⃣ PM видит задачу как точку в таймлайне.

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

3️⃣ CTO — тот, кто держит рамку принятия решений.

Он не просто даёт ответ "да" или "нет". Он строит культуру, в которой:
— понятно, когда можно закостылить,
— когда стоит чуть переработать, чтобы код остался гибким,
— и когда пора закладывать архитектуру, потому что бизнес-модель почти доказана, и на этом фреймворке поедет весь следующий квартал.

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