На каждом созвоне слышно:
«Надо думать наперёд»
«Давайте писать с запасом на рост»
«Архитектура должна быть зрелой»
И в той же команде — к вечеру релиз на костылях, баги в проде и геройская починка «в ночи».
Но ведь команда не из новичков. Разработчики знают, как «по уму». Почему же всё не так?
Ответ — в среде (не день недели). Даже зрелый инженер не может строить на болоте.
Не «ленивый разработчик», а токсичная среда
Ошибка менеджмента — думать, что хорошее решение рождается просто из опыта.
Нет. Оно рождается из условий, в которых этот опыт может реализоваться.
Человек может знать, как должно быть. Но если у него каждый день:
таски прилетают из лички, без формализации
прод выкатывается руками с рабочего ноута
на любое «давайте подумаем» возвращается: «только не сейчас, у нас дедлайн»
архитектурных решений нет — каждый делает как хочет
…он не будет делать по уму. Он просто не сможет. Всё, что требует вдумчивости и аккуратности — умирает в борьбе за «успеть к четвергу».
Дедлайны как образ жизни
В стартапах, да и в большинстве SMB (Small and Medium Business), спешка — это не инцидент, а режим.
Руководство считает, что ускорение — это просто «сделайте быстрее».
Но ускорение не появляется из давления. Оно появляется из стабильности.
Хорошая команда не ускоряется, когда на неё давят.
Хорошая команда ускоряется, когда её не дёргают и не рушат процессы каждые два дня.
Иначе получается обратный эффект:
Разработчик вырезает тесты, упрощает архитектуру, клепает фичу на авось — и уходит чинить баги следующую неделю.
Зачем думать, если всё равно откатим?
Ситуация хуже, когда в команде даже нет ощущения, что хорошая инженерия нужна.
А зачем писать доку, если всё равно не читают?
Зачем писать чисто, если потом всё переписывают?
Зачем тесты, если фича важна «прямо сейчас»?
Такой настрой выжигает мотивацию у тех, кто мог бы делать качественно.
Они просто адаптируются: делают, как скажут. Работают на выживание. Без смысла и без инициативы.
«Сделай быстро» — почти всегда = «сделай плохо»
Иногда звучит вроде бы логично: «мы сначала сделаем MVP, потом переделаем».
Но ты и сам знаешь — никто потом не переделывает. MVP становится базой, на которую навешивают ещё 5 этажей фич.
В результате: все делают вид, что проект живёт, но на самом деле — просто держат его на плечах.
Как сделать «по уму» возможным
Не нужно ждать прихода «супер‑сеньора», который всё спасёт. Надо создать среду, в которой любой нормальный разработчик может не выживать, а работать.
Уберите бардак из процессов
Дайте хоть немного стабильности
Слушайте инженеров — не в формате «окей», а с действиями
Не подменяйте скорость качеством
А главное — не обесценивайте инициативу.
Если человек хочет улучшить архитектуру, автоматизировать процесс, наладить тесты — поддержите. Даже если сейчас «не время». Потому что другого времени может и не быть.
Вместо вывода
Если в команде делают плохо — это не всегда про людей.
Чаще — про среду, в которой невозможно делать хорошо.
Разработчики знают, как «по уму». Просто вы им не дали такой возможности.
Я пишу о таких штуках в Telegram-канале Техдир на пальцах — без кода и заумных слов. Только реальные кейсы, честные мысли и решения, которые работают.
