Я сейчас живу в режиме прилётов. И это тот случай, когда хочется сказать: да какогож х*я-то?!

Фичедрайвинг выглядит как работа над продуктом только первые пару недель. Дальше это начинает напоминать старую городскую систему пожарных команд: пока у тебя редкие пожары — ты держишь бочки с водой, пару лестниц, и всё вроде нормально. Но если у тебя каждый день тревога, то город перестаёт развиваться. Он просто учится быстрее бегать с ведром.

Точно так же ведёт себя команда, когда каждая новая фича срочная, а план меняется быстрее, чем успевают закрывать начатое. В этот момент инженерка перестаёт строить систему и начинает жить реактивно: тушит, затыкает, обходит, “временно решает”. Причём это не про кривые руки. Это про то, что при постоянной тревоге ты физически не можешь делать работу “на вырост”.

И вот что важно: режим постоянных прилётов почти всегда продаётся как гибкость и клиент-ориентированность. Но по факту это обычно один из двух сценариев:

либо бизнес не понимает цену переключений и думает, что “пара правок” не ломает план либо техчасть не умеет держать границы и переводит любой шум в backlog как будто это стратегия

Я как CTO вижу это по симптомам. Они банальные:

команда начинает “бояться трогать” ядро обсуждения архитектуры исчезают, потому что “не до этого” сроки больше зависят от удачи, чем от оценки качество становится тем, что “проверим потом”, а потом превращается в инциденты

И самое смешное: через некоторое время все начинают воспринимать этот хаос как норму. Типа так и должно быть. Хотя это просто город, где сирена орёт постоянно.

Вопрос, который я себе сейчас задаю (и вам задам): мы правда делаем продукт — или мы наладили идеальную систему реагирования на прилёты и называем это скоростью?

#CTO #CEO #featuredriving