Устроившись в компанию, в курилке все равно услышите достаточно аргументов в сторону "у нас говно процессы") А так, лучше в сапогах заходить во дворец, чем в белых носочках в грязь
Я старался сделать статью живой и структурной, поэтому местами тон действительно мог показаться категоричным. Скорее, это приём, чтобы акцентировать внимание на часто игнорируемых проблемах. Хотелось подчеркнуть очевидное
Полностью согласен с тем, что темп определяется множеством факторов, и инженерная зрелость — лишь часть картины. Именно поэтому я и старался в статье подсветить один из самых недооценённых аспектов, который часто упускается в малых командах и на ранних этапах проектов — где архитекторов и продвинутого менеджмента просто нет.
Безусловно, зрелое управление, контроль ресурсов, культура постоянного улучшения — всё это критически важно. Но если при этом разработка разворачивается вручную, баги ловятся "на проде", а каждая задача начинается с “а где у нас это вообще лежит”, то даже сильное управление будет буксовать.
Вы правы, что это не только про IT. Но в IT потери из-за инфраструктурной сырости особенно заметны, потому что стоимость итерации часто минимальна — и значит, каждый тормоз бьёт по скорости сразу.
Очень классный комментарий, возможно, стоит сделать об этом отдельный пост: как сочетаются инженерная зрелость и зрелость процессов управления.
В крупных компаниях с выстроенной инженерной культурой и наличием архитекторов/техлидов/сеньоров подобные ошибки происходят реже — именно благодаря сильным процессам и контролю.
Но статья писалась прежде всего для малого и среднего бизнеса, а также для стартапов, где таких ролей может не быть вовсе (слишком дорого).
О дааа, своими глазами точно такое же видел. Тут уже конечно проблема легаси, но замечание правильное. Давненько я диназавров уже в проектах не видел. Последнее помню - система на Делфи, которую поддерживал один разраб.
Когда дошло до того, что разраб решил забрать права на систему себе, вот тогда уже компания начала переписывать на свежий стек
Цель статьи — не разжечь очередной холивар по поводу стека, а подсветить проблему управленческого выбора. Когда новые технологии тянут в прод не потому, что они реально решают задачу, а потому что “хайпово” или “разработчику хочется попробовать”. Поэтому я и старался пример подать максимально абстрактно, без фокуса на конкретную базу данных, язык или фреймворк. Речь не о том, что X — плох, а о том, что без критического мышления даже хороший инструмент может погубить релиз
Устроившись в компанию, в курилке все равно услышите достаточно аргументов в сторону "у нас говно процессы")
А так, лучше в сапогах заходить во дворец, чем в белых носочках в грязь
Да да да
Казалось бы, очень очевидная вещь, но на эту ошибку постоянно продолжают натыкаться проекты.
Я старался сделать статью живой и структурной, поэтому местами тон действительно мог показаться категоричным. Скорее, это приём, чтобы акцентировать внимание на часто игнорируемых проблемах. Хотелось подчеркнуть очевидное
Полностью согласен с тем, что темп определяется множеством факторов, и инженерная зрелость — лишь часть картины. Именно поэтому я и старался в статье подсветить один из самых недооценённых аспектов, который часто упускается в малых командах и на ранних этапах проектов — где архитекторов и продвинутого менеджмента просто нет.
Безусловно, зрелое управление, контроль ресурсов, культура постоянного улучшения — всё это критически важно. Но если при этом разработка разворачивается вручную, баги ловятся "на проде", а каждая задача начинается с “а где у нас это вообще лежит”, то даже сильное управление будет буксовать.
Вы правы, что это не только про IT. Но в IT потери из-за инфраструктурной сырости особенно заметны, потому что стоимость итерации часто минимальна — и значит, каждый тормоз бьёт по скорости сразу.
Очень классный комментарий, возможно, стоит сделать об этом отдельный пост: как сочетаются инженерная зрелость и зрелость процессов управления.
В крупных компаниях с выстроенной инженерной культурой и наличием архитекторов/техлидов/сеньоров подобные ошибки происходят реже — именно благодаря сильным процессам и контролю.
Но статья писалась прежде всего для малого и среднего бизнеса, а также для стартапов, где таких ролей может не быть вовсе (слишком дорого).
Возможно, я действительно не до конца точно интерпретировал проблему — обязательно учту это в следующих материалах.
Я сейчас в начале пути как автор и только ищу оптимальный формат подачи, так что обратная связь особенно ценна. Спасибо!
Я, кстати, такое ни разу даже не встречал) Ни разу ко мне не приходили с рассказом: «Прикинь, что новое появилось… Rabbit!!»
О дааа, своими глазами точно такое же видел. Тут уже конечно проблема легаси, но замечание правильное. Давненько я диназавров уже в проектах не видел. Последнее помню - система на Делфи, которую поддерживал один разраб.
Когда дошло до того, что разраб решил забрать права на систему себе, вот тогда уже компания начала переписывать на свежий стек
Цель статьи — не разжечь очередной холивар по поводу стека, а подсветить проблему управленческого выбора. Когда новые технологии тянут в прод не потому, что они реально решают задачу, а потому что “хайпово” или “разработчику хочется попробовать”. Поэтому я и старался пример подать максимально абстрактно, без фокуса на конкретную базу данных, язык или фреймворк. Речь не о том, что X — плох, а о том, что без критического мышления даже хороший инструмент может погубить релиз