На каждом созвоне слышно одни и те же правильные слова: Надо думать наперед, Архитектура должна быть мощной, Давайте писать с запасом на рост.
А к вечеру — очередной релиз на костылях, баги в проде и геройская починка в ночи. И самое забавное, что команда не состоит из новичков. Все прекрасно знают, как делать правильно. Но знание — это не гарантия.
Даже самый лучший инженер не построит небоскреб на болоте.
Среда против людей
Ошибка менеджмента — думать, что хорошие решения рождаются только из опыта. Нет. Опыт работает, когда есть условия, в которых его можно применить.
Разработчик может знать, как правильно. Но если задачи прилетают в личку, выкатывать прод приходится руками с рабочего ноута, а на любое предложение подумать спокойно прилетает в ответ "давай потом, у нас дедлайн" — знание не спасает. Все, что требует вдумчивости и аккуратности, умирает.
В итоге архитектуры как системы нет, каждый тянет в свою сторону, общий уровень падает. Не потому, что люди ленивые или некомпетентные, а потому что сама среда запрещает работать по уму.
Среда сильнее намерений
Даже самые мотивированные разработчики постепенно ломаются, если вокруг хаос. В начале они еще пытаются тащить — заводят тесты, пишут документацию, настаивают на обсуждении архитектуры.
Но в среде, где задачи приходят из лички, релизы выкатываются руками, а любое предложение подумать - встречает стену дедлайнов, это все выглядит бессмысленно.
Со временем человек адаптируется. Не потому что он разленился или разучился думать, а потому что так проще выживать. Смысла спорить нет, сделаешь по уму — получишь конфликт и сорванный срок, сделаешь кое-как и успеешь — все довольны.
Это и есть самая опасная ловушка. Среда медленно, но верно перетягивает даже сильных инженеров на сторону "лишь бы запустилось". И дальше проект уже держится не на экспертизе, а на костылях и энтузиазме тех, кто еще не успел устать.
Дедлайны
В стартапах и большинстве SMB спешка — не исключение, а режим.
Управленцы искренне верят, ускорение = давайте сделаем быстрее. Но скорость не появляется от давления.
Когда команду не дергают каждые два дня, она и правда способна работать быстрее. Но когда весь процесс превращается в погоню за очередным "успеем к четвергу", выходит обратное. Разработчики начинают вырезать тесты, упрощать архитектуру, собирать фичи на авось. На следующий день эти же люди чинят баги.
Небольшой живой пример
К этой теме хорошо подходит типовой случай. Делается проект, работает в Docker. И вот на продакшне внезапно отваливается сервис. Все в панике, пользователи жалуются. Решение? Рестарт контейнера!
Сервис ожил — значит, спасли. Все выдыхают и бегут дальше.
А на вопрос "почему упало?" ответ всегда один: "потом разберёмся, потом перепишем нормально".
Зачем стараться, если все равно перепишем
Со временем в команде закрепляется цинизм. Зачем писать документацию, если ее никто не читает?
Зачем рефачить код, если через месяц все перепишут?
Зачем тратить время на тесты, если фича нужна прямо сейчас?
Так умирает мотивация у тех, кто мог бы делать качественно. Люди приспосабливаются: делают как скажут, работают на выживание.
Иллюзия MVP
Знакомая мантра, Сначала сделаем MVP, потом переделаем. Только "потом" никогда не наступает. На MVP начинают навешивать этажи новых фич, и вскоре оно превращается в хрупкий каркас, который держится исключительно на плечах команды.
По уму - возможно
Хорошая инженерия не появляется благодаря суперсеньору-спасателю. Она появляется там, где среда позволяет любому нормальному разработчику работать спокойно и последовательно.
Когда процессы предсказуемы, когда инициативу не обрубают фразой "сейчас не время", когда стабильность важнее кажущейся скорости.
Да, поддержка инженеров, автоматизация, тесты и улучшение архитектуры кажутся не срочными. Но если их все время откладывать, момент для этого так и не наступит. И тогда команда будет жить в костылях бесконечно.
Можно сколько угодно срезать углы, выкатывать костыли и гордиться ночными подвигами, но такие проекты редко доживают до серьезного уровня.
Скорость появляется не от давления и не от дедлайнов. Она появляется там, где есть стабильность и условия для вдумчивой работы. И если кажется, что команда делает плохо, чаще всего стоит посмотреть не на людей, а на ту среду, в которой они работают.
Потому что даже лучшие инженеры не могут построить небоскреб на болоте)
Оффтоп
Если тебе близки подобные темы — приглашаю в Telegram-канал «Техдир на пальцах».
Строим дружное и общительное коммьюнити.
