Ну, когда ты вступил на менеджерский путь - у тебя есть возможность расти совсем выше, даже если ты пока ещё участвуешь тут в обсуждениях. А у разработчика этой возможности нет. А совсем выше разница в зарплатах будет очень даже ощутимая
Помню, в рамках такого же эксперимента, за две недели вайбкодинга мне удалось сделать не просто напоминалку в телеге, а целую экосистему личного помощника, с календарем, мобильными приложением для iOS и Android, UI для всех браузеров, интеграцией с госуслугами и Гуглом, сбором впечатлений о прошедших мероприятиях и даже прогнозированием ваших дальнейших действий и рекомендацией предстоящих планов, исходя из ваших прошлых напоминаний. При этом, покрытие кода тестами было 100%е а архитектура позволяла расширяться в бизнес логике с полной обратной совместимостью и масштабироваться горизонтально для обеспечения полной отказоустойчивости при любых нагрузках. И вся дальнейшая разработка сводилась к написанию промпта, а CI/CD уже доставляло код на прод, что позволяло измерять ttm буквально в минутах, такая вот система.
Никто не даст вам сходу титул царька. Очень редко, когда у менеджера среднего звена есть свой бюджет и возможность менять корпоративные правила. Да, у него есть свой небольшой пулл ответственности где он может и должен принимать решения, но часто он ограничен сверху.
Я бы сказал, что тут действует та же самая идея с мягкой силой, только в обратном направлении, когда мы задаем вопросы и предлагаем изменения наверх, а не вниз под служебной иерархии.
Но, чтобы к этому придти надо, как правило, заслужить доверие, т.е. пожить по существующим процессам и показать результат. А потом уже взрывать существующие процессы.
Ну, вообще-то, если Марина сказала так сделать, то с Марины и спрос. И вообще, в абсолютно любом случае, спросить "почему ты так сделал" или вообще предъявить за что угодно может только Марина. В народе это называется субординация и это абсолютно нормально. Это не даёт подчинённому возможности "получить" и "растрепать всему отделу, что Марина накосячила, а он получил". В основном, потому что "получить" он может только от Марины.
Для того чтобы сделать "ментальную оценку" не нужно 3 технических этапа, достаточно одного. А формальный отказ можно вообще не обосновывать или придумать обоснование за 7 секунд. Если для этого нужно 10 этапов собеседований, значит вы тратите деньги на то, что можно легко получить бесплатно.
Чтобы нанять кого-то, надо понимать, кто вам нужен и уметь проводить собеседования. И делать это должен нанимающий менеджер или его доверенное лицо, а не какой-то корнеплод, живущий на горе, который вообще никакого отношения к предстоящей работе не имеет.
Я и не предлагал не оценивать задачи и не иметь плана (зато не оценивать задачи предлагал создатель стори пойнтов).
Везде уже научились их оценивать. Поезда вон ходят минута в минуту по расписанию.Многие в ИТ уже тоже научились их оценивать. Мне кажется, что проблемы со сроками только у тех, кто воспринимает фразу "попасть в оценку очень сложно" как аксиому и не пытается сроками управлять. Или у тех, кто пытается использовать бесполезные инструменты, например сторипойнты.
Вот почему-то всех тянет измерять сложный интеллектуальный труд количеством изготовленных на заводе деталей, которые потом конвертируются во время, оправдывая это тем, что сразу во времени оценить очень сложно. Хотя, это кажется очевидным бредом.
Открою страшную тайну, проблема не нова и уже много лет существует практически в любой отрасли и даже в повседневной жизни. Когда мы измеряем любой процесс в точных единицах времени, мы почти всегда ошибаемся. Но только в ИТ решили придумать защекоины, которые потом все равно приходится переводить во время, вместо того, чтобы использовать готовые решения.
Вы говорите о вреде карго-культа, но сама идея сторипойнтов родилась как решение совершенно другой проблемы. А уже потом карго-культисты под агиле лозунгами использовали эту идею для увеличения собственной значимости.
Это всего лишь магия худу, она работает только когда вы в нее верите. Ничего плохого в ней нет, но ничего хорошего она тоже не приносит, кроме иллюзий. Но, если они вам помогают, почему бы и нет?!
Судя по статье, навыки системного аналитика - это очень много воды. Причем, воды из разных бочек, смешанных в одной. К примеру, на основе CAP теоремы строится весь трейд офф между микросервисами и монолитами, т.е. она применяется для системы в целом, а не конкретно в базах данных.
А вообще, мне казалось, что главные навыки системного аналитика - это умение четко выражать свои мысли, посредством написания текста, и умение классифицировать и структурировать информацию, т.е. то самое системное мышление. И развиваются они только практикой.
И снова повестка "скрам и агиле работают, вы просто не умеете их готовить, очень надо нанять того, кто умеет".
Может дело в том, что "карго культ" в этом случае не метафора?! Помимо того, что в самой статье полно противоречий, так она ещё и опирается на 2 "принципа", которые сами по себе являются бредом.
Не бывает никаких самоорганизованных команд. Если ваша команда "самоорганизована" - значит у нее есть неформальный лидер, который координирует ее действия.
А кроссфункциональные команды не существуют, потому что ваш "инкремент" требует участия большого количества людей с разными компетенциями, которые не могут работать одновременно и одинаковое количество времени.
Эх, и снова у нас тут эффективноменеджерский инструмент, который работает, только если вы зовете специально обученного человека его внедрять и рассказывать, какой это полезный инструмент.
Агиле умер, потому что люди начали наконец догадываться, что это просто хорошо проданный карго-культ, о котором и упоминалось в статье. И продан он был хорошо именно потому, что 99% его адептов 99% своего времени объясняли, чем же они занимаются, как же это важно, и как же будет зашибись, если они будут дальше этим заниматься, а незашибись не будет.
И вот мы опять получаем статью про то, как важно уметь в агиле, ведь иначе он не работает. И опять это просто океан воды из рубрики "очевидное и невероятное" и никакой конкретики. "Вот это важно, если не делать будет плохо", "если нарушать правила - будет плохо", "если соблюдать правила - будет хорошо".
Менеджмент - это не про правила, которые надо соблюдать, потому что так написали в известной книжонке. Это про умение обрабатывать конкретные события, в конкретных ситуациях, анализировать их, и на основе этого анализа делать выводы, которые помогают вам выстраивать эти самые правила, чтобы достигать ваших целей.
Не знаю, где вы работали по 20 часов в день, но в крупных компаниях, как правило, работать нужно меньше чем в мелких, а самодурства больше в мелких компаниях, потому что какой-нибудь CEO там царь и бог. В бигтехе больше бесполезного административного состава, но его влияние на разработчика сильно ограничено, из-за размытия ответственности и кучи бестолковых слов типа "агиле", перформанс ревью, и прочей шелухи
Все, конечно, очень сильно зависит от проекта, но, в целом, процессы российского бигтеха скорее позволяют разработчикам потеряться и не работать, чем выжимают из них соки.
У тех, кто после курсов и хотят найти первую работу может и есть конкуренция, есть она и у менеджерского состава, но у разрабов от мидла и выше ее просто нет. Они просто публикуют резюме и ждут, даже откликаться не надо.
Ну, когда ты вступил на менеджерский путь - у тебя есть возможность расти совсем выше, даже если ты пока ещё участвуешь тут в обсуждениях. А у разработчика этой возможности нет. А совсем выше разница в зарплатах будет очень даже ощутимая
Похоже, когда говорили, что внедрение ИИ лишит людей работы, имелось ввиду, что он будет за HR'а фильтровать все отклики и отбрасывать ваши резюме.
Неплохо, конечно, но как-то слабовато.
Помню, в рамках такого же эксперимента, за две недели вайбкодинга мне удалось сделать не просто напоминалку в телеге, а целую экосистему личного помощника, с календарем, мобильными приложением для iOS и Android, UI для всех браузеров, интеграцией с госуслугами и Гуглом, сбором впечатлений о прошедших мероприятиях и даже прогнозированием ваших дальнейших действий и рекомендацией предстоящих планов, исходя из ваших прошлых напоминаний. При этом, покрытие кода тестами было 100%е а архитектура позволяла расширяться в бизнес логике с полной обратной совместимостью и масштабироваться горизонтально для обеспечения полной отказоустойчивости при любых нагрузках. И вся дальнейшая разработка сводилась к написанию промпта, а CI/CD уже доставляло код на прод, что позволяло измерять ttm буквально в минутах, такая вот система.
Только я вам ее не покажу.
Хорошая статья. Все по делу и без воды, как это обычно бывает.
Ну я бы поспорил.
Никто не даст вам сходу титул царька. Очень редко, когда у менеджера среднего звена есть свой бюджет и возможность менять корпоративные правила. Да, у него есть свой небольшой пулл ответственности где он может и должен принимать решения, но часто он ограничен сверху.
Я бы сказал, что тут действует та же самая идея с мягкой силой, только в обратном направлении, когда мы задаем вопросы и предлагаем изменения наверх, а не вниз под служебной иерархии.
Но, чтобы к этому придти надо, как правило, заслужить доверие, т.е. пожить по существующим процессам и показать результат. А потом уже взрывать существующие процессы.
Ну, вообще-то, если Марина сказала так сделать, то с Марины и спрос. И вообще, в абсолютно любом случае, спросить "почему ты так сделал" или вообще предъявить за что угодно может только Марина. В народе это называется субординация и это абсолютно нормально. Это не даёт подчинённому возможности "получить" и "растрепать всему отделу, что Марина накосячила, а он получил". В основном, потому что "получить" он может только от Марины.
Спасибо, не надо.
5 альбомов нейросетевого мусора. Для чего?! Для кого?! Это же все равно что иметь 3 миллиарда себяшек из клубных туалетов и назвать себя фотографом.
Ждём статью о том, как стать талантливым живописцем со своим стилем в разных жанрах, используя Midjorney.
Зачем вообще переводить какую-то ахинею?!
Просто поток воды, цитат не к месту и сомнительных фактов о карго культе, который насколько человек успешно продали, воспользовавшись моментом.
Так-то, эта статья тоже весьма и весьма поверхностна. Просто список терминов и ваше короткое мнение., без реальных примеров или обоснования.
Это не ddd хайпует, а вы хайпуете на ddd)
Все эти этапы для этого не нужны.
Для того чтобы сделать "ментальную оценку" не нужно 3 технических этапа, достаточно одного. А формальный отказ можно вообще не обосновывать или придумать обоснование за 7 секунд. Если для этого нужно 10 этапов собеседований, значит вы тратите деньги на то, что можно легко получить бесплатно.
Чтобы нанять кого-то, надо понимать, кто вам нужен и уметь проводить собеседования. И делать это должен нанимающий менеджер или его доверенное лицо, а не какой-то корнеплод, живущий на горе, который вообще никакого отношения к предстоящей работе не имеет.
Во взрослых бизнесах сторипойнты. Это статья от МТС, куда уж взрослее.
Я и не предлагал не оценивать задачи и не иметь плана (зато не оценивать задачи предлагал создатель стори пойнтов).
Везде уже научились их оценивать. Поезда вон ходят минута в минуту по расписанию.Многие в ИТ уже тоже научились их оценивать. Мне кажется, что проблемы со сроками только у тех, кто воспринимает фразу "попасть в оценку очень сложно" как аксиому и не пытается сроками управлять. Или у тех, кто пытается использовать бесполезные инструменты, например сторипойнты.
Вот почему-то всех тянет измерять сложный интеллектуальный труд количеством изготовленных на заводе деталей, которые потом конвертируются во время, оправдывая это тем, что сразу во времени оценить очень сложно. Хотя, это кажется очевидным бредом.
Открою страшную тайну, проблема не нова и уже много лет существует практически в любой отрасли и даже в повседневной жизни. Когда мы измеряем любой процесс в точных единицах времени, мы почти всегда ошибаемся. Но только в ИТ решили придумать защекоины, которые потом все равно приходится переводить во время, вместо того, чтобы использовать готовые решения.
Вы говорите о вреде карго-культа, но сама идея сторипойнтов родилась как решение совершенно другой проблемы. А уже потом карго-культисты под агиле лозунгами использовали эту идею для увеличения собственной значимости.
Это всего лишь магия худу, она работает только когда вы в нее верите. Ничего плохого в ней нет, но ничего хорошего она тоже не приносит, кроме иллюзий. Но, если они вам помогают, почему бы и нет?!
Судя по статье, навыки системного аналитика - это очень много воды. Причем, воды из разных бочек, смешанных в одной. К примеру, на основе CAP теоремы строится весь трейд офф между микросервисами и монолитами, т.е. она применяется для системы в целом, а не конкретно в базах данных.
А вообще, мне казалось, что главные навыки системного аналитика - это умение четко выражать свои мысли, посредством написания текста, и умение классифицировать и структурировать информацию, т.е. то самое системное мышление. И развиваются они только практикой.
И снова повестка "скрам и агиле работают, вы просто не умеете их готовить, очень надо нанять того, кто умеет".
Может дело в том, что "карго культ" в этом случае не метафора?! Помимо того, что в самой статье полно противоречий, так она ещё и опирается на 2 "принципа", которые сами по себе являются бредом.
Не бывает никаких самоорганизованных команд. Если ваша команда "самоорганизована" - значит у нее есть неформальный лидер, который координирует ее действия.
А кроссфункциональные команды не существуют, потому что ваш "инкремент" требует участия большого количества людей с разными компетенциями, которые не могут работать одновременно и одинаковое количество времени.
Эх, и снова у нас тут эффективноменеджерский инструмент, который работает, только если вы зовете специально обученного человека его внедрять и рассказывать, какой это полезный инструмент.
Очень уж знакомая история.
Агиле умер, потому что люди начали наконец догадываться, что это просто хорошо проданный карго-культ, о котором и упоминалось в статье. И продан он был хорошо именно потому, что 99% его адептов 99% своего времени объясняли, чем же они занимаются, как же это важно, и как же будет зашибись, если они будут дальше этим заниматься, а незашибись не будет.
И вот мы опять получаем статью про то, как важно уметь в агиле, ведь иначе он не работает. И опять это просто океан воды из рубрики "очевидное и невероятное" и никакой конкретики. "Вот это важно, если не делать будет плохо", "если нарушать правила - будет плохо", "если соблюдать правила - будет хорошо".
Менеджмент - это не про правила, которые надо соблюдать, потому что так написали в известной книжонке. Это про умение обрабатывать конкретные события, в конкретных ситуациях, анализировать их, и на основе этого анализа делать выводы, которые помогают вам выстраивать эти самые правила, чтобы достигать ваших целей.
Не знаю, где вы работали по 20 часов в день, но в крупных компаниях, как правило, работать нужно меньше чем в мелких, а самодурства больше в мелких компаниях, потому что какой-нибудь CEO там царь и бог. В бигтехе больше бесполезного административного состава, но его влияние на разработчика сильно ограничено, из-за размытия ответственности и кучи бестолковых слов типа "агиле", перформанс ревью, и прочей шелухи
Все, конечно, очень сильно зависит от проекта, но, в целом, процессы российского бигтеха скорее позволяют разработчикам потеряться и не работать, чем выжимают из них соки.
Вы в каком-то странном мире живёте.
У тех, кто после курсов и хотят найти первую работу может и есть конкуренция, есть она и у менеджерского состава, но у разрабов от мидла и выше ее просто нет. Они просто публикуют резюме и ждут, даже откликаться не надо.