Я точно все проблемы не помню уже, Zalando было трудно с управлением данных, наплодились процессы новые(для стандартизации этих микросервисов), и что-то у них там с наймом тяжеловато было(хотя с этим я не уверен) Если интересно, то я откопал вот такую статейку для вас: https://habr.com/ru/articles/322474/ А у Ghostery чуть проще, они просто не были готовы к резкому росту процессов и нехватке ресурсов для развития и поддержания огромной кучи компонентов. Но про них уже не найду источник
Я наоборот "до и после" считаю приманкой цифрами (это уже везде, даже в резюме теперь все кишит этими сухими "ускорил работу API yна 70%")
У разных людей разное восприятие ценности. Эта статья не обещала волшебную таблетку. Я намеренно не стал превращать её в кейс с цифрами, потому что хотел акцентировать внимание на системной проблеме.
Это не решение, это подсветка. Иногда надо остановиться и просто взглянуть на ситуацию со стороны, прежде чем разбирать метрики.
Конкретику можно обсудить — и она будет разной для каждой команды. А универсального "до/после" тут по определению не существует.
Выглядит так, будто любой текст, который не уложен в шаблон глубокого кейса с бордами, метриками и ссылками, автоматически отправляется в корзину с надписью "AI slop".
Формат был намеренно простым и без схем — не каждый пост обязан быть whitepaperом, особенно если цель — обозначить проблему, а не защищать диссертацию.
Аргументы вроде "нет ссылок на Scrum Guide" выглядят как перегрев линейки: мы всё же не в секции peer-review. Да и читать по диагонали, а потом требовать цифры... Такое себе
Про пустой профиль и "птенца" — заезженный выпад, когда по сути сказать уже нечего, а хочется сохранить позу сверху.
Контент можно критиковать по делу, но не по тому, что он недостаточно похож на то, что вы привыкли считать правильным...
Сейчас столько "детекторов" ллм развелось... Что Вам не нравится, нету мата? Или как сейчас любят еще говорить дети, что если есть кавычки - значит ллм. Парадоксально, мы обучаем ллм на человеческих текстах, а потом на человеческий текст говорим "СГЕНЕРИРОВАЛИ! ФУ!". Абсурд...
Совершенно верно, виноват не Agile. Это всего лишь инструмент, которым многие просто не умеют пользоваться, но при этом верят, что делают все правильно.
Это палка о двух концах — безусловно, проблемы бывают и со стороны разработки. Где-то не хватает инициативности, где-то не озвучены риски, а где-то и правда можно было бы просто задать пару вопросов
Но конкретно в этой статье я сознательно фокусировался на управленческой стороне: как формулируются задачи, с каким контекстом они приходят, и почему иногда сами вводные мешают нормальной работе. Про ответственность разработчиков — абсолютно согласен
Устроившись в компанию, в курилке все равно услышите достаточно аргументов в сторону "у нас говно процессы") А так, лучше в сапогах заходить во дворец, чем в белых носочках в грязь
Я старался сделать статью живой и структурной, поэтому местами тон действительно мог показаться категоричным. Скорее, это приём, чтобы акцентировать внимание на часто игнорируемых проблемах. Хотелось подчеркнуть очевидное
Полностью согласен с тем, что темп определяется множеством факторов, и инженерная зрелость — лишь часть картины. Именно поэтому я и старался в статье подсветить один из самых недооценённых аспектов, который часто упускается в малых командах и на ранних этапах проектов — где архитекторов и продвинутого менеджмента просто нет.
Безусловно, зрелое управление, контроль ресурсов, культура постоянного улучшения — всё это критически важно. Но если при этом разработка разворачивается вручную, баги ловятся "на проде", а каждая задача начинается с “а где у нас это вообще лежит”, то даже сильное управление будет буксовать.
Вы правы, что это не только про IT. Но в IT потери из-за инфраструктурной сырости особенно заметны, потому что стоимость итерации часто минимальна — и значит, каждый тормоз бьёт по скорости сразу.
Очень классный комментарий, возможно, стоит сделать об этом отдельный пост: как сочетаются инженерная зрелость и зрелость процессов управления.
В крупных компаниях с выстроенной инженерной культурой и наличием архитекторов/техлидов/сеньоров подобные ошибки происходят реже — именно благодаря сильным процессам и контролю.
Но статья писалась прежде всего для малого и среднего бизнеса, а также для стартапов, где таких ролей может не быть вовсе (слишком дорого).
О дааа, своими глазами точно такое же видел. Тут уже конечно проблема легаси, но замечание правильное. Давненько я диназавров уже в проектах не видел. Последнее помню - система на Делфи, которую поддерживал один разраб.
Когда дошло до того, что разраб решил забрать права на систему себе, вот тогда уже компания начала переписывать на свежий стек
Цель статьи — не разжечь очередной холивар по поводу стека, а подсветить проблему управленческого выбора. Когда новые технологии тянут в прод не потому, что они реально решают задачу, а потому что “хайпово” или “разработчику хочется попробовать”. Поэтому я и старался пример подать максимально абстрактно, без фокуса на конкретную базу данных, язык или фреймворк. Речь не о том, что X — плох, а о том, что без критического мышления даже хороший инструмент может погубить релиз
Я точно все проблемы не помню уже, Zalando было трудно с управлением данных, наплодились процессы новые(для стандартизации этих микросервисов), и что-то у них там с наймом тяжеловато было(хотя с этим я не уверен)
Если интересно, то я откопал вот такую статейку для вас: https://habr.com/ru/articles/322474/
А у Ghostery чуть проще, они просто не были готовы к резкому росту процессов и нехватке ресурсов для развития и поддержания огромной кучи компонентов. Но про них уже не найду источник
Я наоборот "до и после" считаю приманкой цифрами (это уже везде, даже в резюме теперь все кишит этими сухими "ускорил работу API yна 70%")
У разных людей разное восприятие ценности. Эта статья не обещала волшебную таблетку. Я намеренно не стал превращать её в кейс с цифрами, потому что хотел акцентировать внимание на системной проблеме.
Это не решение, это подсветка. Иногда надо остановиться и просто взглянуть на ситуацию со стороны, прежде чем разбирать метрики.
Конкретику можно обсудить — и она будет разной для каждой команды. А универсального "до/после" тут по определению не существует.
Выглядит так, будто любой текст, который не уложен в шаблон глубокого кейса с бордами, метриками и ссылками, автоматически отправляется в корзину с надписью "AI slop".
Формат был намеренно простым и без схем — не каждый пост обязан быть whitepaperом, особенно если цель — обозначить проблему, а не защищать диссертацию.
Аргументы вроде "нет ссылок на Scrum Guide" выглядят как перегрев линейки: мы всё же не в секции peer-review. Да и читать по диагонали, а потом требовать цифры... Такое себе
Про пустой профиль и "птенца" — заезженный выпад, когда по сути сказать уже нечего, а хочется сохранить позу сверху.
Контент можно критиковать по делу, но не по тому, что он недостаточно похож на то, что вы привыкли считать правильным...
Сейчас столько "детекторов" ллм развелось...
Что Вам не нравится, нету мата? Или как сейчас любят еще говорить дети, что если есть кавычки - значит ллм.
Парадоксально, мы обучаем ллм на человеческих текстах, а потом на человеческий текст говорим "СГЕНЕРИРОВАЛИ! ФУ!".
Абсурд...
Совершенно верно, виноват не Agile. Это всего лишь инструмент, которым многие просто не умеют пользоваться, но при этом верят, что делают все правильно.
Согласен. Про отсутствие процессов я уже тоже писал разбор.
А кто вы в прошлом месяце на основе ваших трат?)
Полностью согласен, но таких хороших пользователей очень мало, к сожалению
Все, о чем я пишу - не новинка для сферы. Разумеется, какие-то проблемы поднимались ранее.
Я пытаюсь их снова подсветить своей интерпретацией, ведь эти ошибки в бизнес остаются до сих пор.
Поэтому не стоит, надрываясь, пытаться доказать «подделку», просто проходите мимо молча
Это палка о двух концах — безусловно, проблемы бывают и со стороны разработки. Где-то не хватает инициативности, где-то не озвучены риски, а где-то и правда можно было бы просто задать пару вопросов
Но конкретно в этой статье я сознательно фокусировался на управленческой стороне: как формулируются задачи, с каким контекстом они приходят, и почему иногда сами вводные мешают нормальной работе. Про ответственность разработчиков — абсолютно согласен
И вот это "дешево и позавчера" со временем может стоить в разы дороже для бизнеса, чем "по уму"
Устроившись в компанию, в курилке все равно услышите достаточно аргументов в сторону "у нас говно процессы")
А так, лучше в сапогах заходить во дворец, чем в белых носочках в грязь
Да да да
Казалось бы, очень очевидная вещь, но на эту ошибку постоянно продолжают натыкаться проекты.
Я старался сделать статью живой и структурной, поэтому местами тон действительно мог показаться категоричным. Скорее, это приём, чтобы акцентировать внимание на часто игнорируемых проблемах. Хотелось подчеркнуть очевидное
Полностью согласен с тем, что темп определяется множеством факторов, и инженерная зрелость — лишь часть картины. Именно поэтому я и старался в статье подсветить один из самых недооценённых аспектов, который часто упускается в малых командах и на ранних этапах проектов — где архитекторов и продвинутого менеджмента просто нет.
Безусловно, зрелое управление, контроль ресурсов, культура постоянного улучшения — всё это критически важно. Но если при этом разработка разворачивается вручную, баги ловятся "на проде", а каждая задача начинается с “а где у нас это вообще лежит”, то даже сильное управление будет буксовать.
Вы правы, что это не только про IT. Но в IT потери из-за инфраструктурной сырости особенно заметны, потому что стоимость итерации часто минимальна — и значит, каждый тормоз бьёт по скорости сразу.
Очень классный комментарий, возможно, стоит сделать об этом отдельный пост: как сочетаются инженерная зрелость и зрелость процессов управления.
В крупных компаниях с выстроенной инженерной культурой и наличием архитекторов/техлидов/сеньоров подобные ошибки происходят реже — именно благодаря сильным процессам и контролю.
Но статья писалась прежде всего для малого и среднего бизнеса, а также для стартапов, где таких ролей может не быть вовсе (слишком дорого).
Возможно, я действительно не до конца точно интерпретировал проблему — обязательно учту это в следующих материалах.
Я сейчас в начале пути как автор и только ищу оптимальный формат подачи, так что обратная связь особенно ценна. Спасибо!
Я, кстати, такое ни разу даже не встречал) Ни разу ко мне не приходили с рассказом: «Прикинь, что новое появилось… Rabbit!!»
О дааа, своими глазами точно такое же видел. Тут уже конечно проблема легаси, но замечание правильное. Давненько я диназавров уже в проектах не видел. Последнее помню - система на Делфи, которую поддерживал один разраб.
Когда дошло до того, что разраб решил забрать права на систему себе, вот тогда уже компания начала переписывать на свежий стек
Цель статьи — не разжечь очередной холивар по поводу стека, а подсветить проблему управленческого выбора. Когда новые технологии тянут в прод не потому, что они реально решают задачу, а потому что “хайпово” или “разработчику хочется попробовать”. Поэтому я и старался пример подать максимально абстрактно, без фокуса на конкретную базу данных, язык или фреймворк. Речь не о том, что X — плох, а о том, что без критического мышления даже хороший инструмент может погубить релиз