На каждом созвоне слышно:
«Надо думать наперёд»
«Давайте писать с запасом на рост»
«Архитектура должна быть зрелой»
И в той же команде — к вечеру релиз на костылях, баги в проде и геройская починка «в ночи».
Но ведь команда не из новичков. Разработчики знают, как «по уму». Почему же всё не так?
Ответ — в среде (не день недели). Даже зрелый инженер не может строить на болоте.
Не «ленивый разработчик», а токсичная среда
Ошибка менеджмента — думать, что хорошее решение рождается просто из опыта.
Нет. Оно рождается из условий, в которых этот опыт может реализоваться.
Человек может знать, как должно быть. Но если у него каждый день:
таски прилетают из лички, без формализации
прод выкатывается руками с рабочего ноута
на любое «давайте подумаем» возвращается: «только не сейчас, у нас дедлайн»
архитектурных решений нет — каждый делает как хочет
…он не будет делать по уму. Он просто не сможет. Всё, что требует вдумчивости и аккуратности — умирает в борьбе за «успеть к четвергу».
Дедлайны как образ жизни
В стартапах, да и в большинстве SMB (Small and Medium Business), спешка — это не инцидент, а режим.
Руководство считает, что ускорение — это просто «сделайте быстрее».
Но ускорение не появляется из давления. Оно появляется из стабильности.
Хорошая команда не ускоряется, когда на неё давят.
Хорошая команда ускоряется, когда её не дёргают и не рушат процессы каждые два дня.
Иначе получается обратный эффект:
Разработчик вырезает тесты, упрощает архитектуру, клепает фичу на авось — и уходит чинить баги следующую неделю.
Зачем думать, если всё равно откатим?
Ситуация хуже, когда в команде даже нет ощущения, что хорошая инженерия нужна.
А зачем писать доку, если всё равно не читают?
Зачем писать чисто, если потом всё переписывают?
Зачем тесты, если фича важна «прямо сейчас»?
Такой настрой выжигает мотивацию у тех, кто мог бы делать качественно.
Они просто адаптируются: делают, как скажут. Работают на выживание. Без смысла и без инициативы.
«Сделай быстро» — почти всегда = «сделай плохо»
Иногда звучит вроде бы логично: «мы сначала сделаем MVP, потом переделаем».
Но ты и сам знаешь — никто потом не переделывает. MVP становится базой, на которую навешивают ещё 5 этажей фич.
В результате: все делают вид, что проект живёт, но на самом деле — просто держат его на плечах.
Как сделать «по уму» возможным
Не нужно ждать прихода «супер‑сеньора», который всё спасёт. Надо создать среду, в которой любой нормальный разработчик может не выживать, а работать.
Уберите бардак из процессов
Дайте хоть немного стабильности
Слушайте инженеров — не в формате «окей», а с действиями
Не подменяйте скорость качеством
А главное — не обесценивайте инициативу.
Если человек хочет улучшить архитектуру, автоматизировать процесс, наладить тесты — поддержите. Даже если сейчас «не время». Потому что другого времени может и не быть.
Вместо вывода
Если в команде делают плохо — это не всегда про людей.
Чаще — про среду, в которой невозможно делать хорошо.
Разработчики знают, как «по уму». Просто вы им не дали такой возможности.
Я пишу о таких штуках в Telegram-канале Техдир на пальцах — без кода и заумных слов. Только реальные кейсы, честные мысли и решения, которые работают.
Комментарии (19)
akakoychenko
07.07.2025 11:23Как-то написал комментарий https://habr.com/ru/articles/902662/comments/#comment_28216466 вообще на другую тему, но, кажется, он сюда даже лучше зайдет)
Closius
07.07.2025 11:23Хорошая структура — это способ, которым ИИ заменит вас. Так что лучше сделать это не лучшим образом
akakoychenko
07.07.2025 11:23Почему обязательно ИИ? За десятки лет до ИИ подобным способом защищали свою вотчину белковые программисты от того, чтобы босс не заменил на белкового собрата, но подешевле/посговорчивее
DjUmnik
07.07.2025 11:23Как устроиться в компанию, где нормальные процессы, если есть только опыт работы в компаниях, где ненормальные процессы?
Techdir_hub Автор
07.07.2025 11:23Устроившись в компанию, в курилке все равно услышите достаточно аргументов в сторону "у нас говно процессы")
А так, лучше в сапогах заходить во дворец, чем в белых носочках в грязь
pnmv
07.07.2025 11:23"по уму" - дорого и послезавтра, а бизнесу надо "дёшево и позавчера".
всякую дурь, вне зависимости от сложности, отдают сотрудникам, которых не жалко. то есть, работающим по нижней планке зарплатной вилки.
Techdir_hub Автор
07.07.2025 11:23И вот это "дешево и позавчера" со временем может стоить в разы дороже для бизнеса, чем "по уму"
pnmv
07.07.2025 11:23они смотрят на это под другим углом. под каким именно, я не знаю, но очень сильно под другим.
возможно, даже, под таким, что: "техдолг побоку, ведь это не наш техдолг, так что пусть растет, главное запустить поскорее. а разработчика всегда заменить можно".
можно долго и упорно рассуждать о том, что умеющий сделает хорошо "всегда", но ситуации разные бывают. есть компании, где тебе просто не дадут сделать хорошо. ты, или сделаешь, как все, и побыстрее, или пойдешь на мороз. а допиливать можешь в свободное от работы время - офис открыт круглые сутки, но нет гарантии, что твое крутое решение примут.
gluck59
07.07.2025 11:23Когда в среднем звене сплошные временщики, горизонт планирования съеживается до пары месяцов.
astypalaia
07.07.2025 11:23За 25+ лет работы разработчиком убедился не один раз: если человек знает и умеет делать хорошо - он делает хорошо. Всегда. Если человек не знает и не умеет делать хорошо и ему дать неограниченное количество времени на разработку - он будет думать, что делает хорошо, но делать при этом как умеет, т.е. "нехорошо". И это в любом ремесле. Если мастер клеит обои хорошо - он всегда их клеит хорошо, мастер просто не может себе позволить клеить обои плохо, для мастера это оскорбительно. Если кто-то клеит обои плохо - значит он так делает всегда, независимо от количества отведенного времени.
Viacheslav01
07.07.2025 11:23Если мастеру надо на поклейку обоев хорошо 2 дня, а ему дают только 2 часа, если не устраивает просим на выход. То как бы он не умел клеить хорошо, все равно сделает говно. Ну или уволится с очередной работы.
stan1901
07.07.2025 11:23Допускаю, что так, наверное, бывает. Но поделюсь своим опытом. Я примерно 15 лет проработал в заказной разработке - ни разу заказчик не требовал кардинально снизить оценку. Торговля всегда идёт, но не "за 2 часа вместо 2 дней", а процентов за 20 стоимости. Все понимают, что снижение срока всегда означает как минимум повышение стоимости и риска, снижение качества. Если вдруг не понимают - что ж, бывает, расходимся.
Сейчас работаю в продуктовой разработке с жёсткими дедлайнами и постоянными "влётами" - то же самое. Практически все известные мне большие косяки связаны не с требованием сделать быстро, а с банальной ленью и отсутствием опыта. Вместо того, чтобы подумать день и сделать за неделю, разработчик сделал за три дня, а потом переделывает по чуть-чуть годами. Ну да, формально он сэкономил на первом этапе, но заказчику такая экономия не видна на фоне остальных этапов разработки.
bogolt
07.07.2025 11:23Поддерживаю. Много раз замечал что хорошие решения часто даже стоят по времени не то чтобы больше чем плохие. Просто люди
привязываются к своим идеям, и редко готовы их пересмотреть. Потом они реализуют плохую идею, а потом всей команде приходится ее поддерживать, потому что оно уже на проде и так просто не изменить теперь.
не обладают достаточным опытом
упертые ослы ( смотри пункт один )
Когда попадется упертый человек без опыта или с опытом как делать плохо зато быстро, вот тут начинается бесконечная гонка переделываний говнокода.
Ну еще бывает начальство неправильно ставит задачу, или просто "хочет странного". Например не понимают полноценного решения и топят за какое-то но понятное им. Такие понятные и мегапростые решения тоже регулярно выходят боком.
tsapkov_tem
Ооо, это мое любимое. Сколько я на себе волос вырвал в начале карьеры, когда спотыкался об это. Особенно забавно, когда тебе говорят «Сделай быстренько, посмотрим как будет выглядеть, дальше решим». А потом, спустя пару месяцев, тебе же это приходит, уже пятиэтажное чудо, про которое ты уже забыл, и говорят накинуть еще этаж)
Techdir_hub Автор
Да да да
Казалось бы, очень очевидная вещь, но на эту ошибку постоянно продолжают натыкаться проекты.
ReaderReader
У меня был случай, когда MVP был настолько востребован, что его сразу пустили в боевой прод. Потом, разумеется, всегда не было времени на нормальный дизайн, а количество требуемых фич постоянно росло. Кончилось тем, что в этом кодовом аду не смогли пофиксить ошибку после недели поисков, после чего все-таки было принято решение сделать все по уму. Но не тут-то было... За это время MVP успел обрасти фичами, которые делались по принципу "запили вот это к позавчера", и без какого-либо контроля, насколько эти фичи дополняют друг друга, перекрывают друг друга, или даже вообще друг другу противоречат. При этом заказчики уже во всю пользовались всем спектром функционала. В результате при перезагрузке проекта получилось нечто, что внутри имело хороший дизайн, было поддерживаемо и т.д., и при этом эмулировало наружу весь тот ад, который успел появиться за годы жизни проекта.