Для того чтобы сделать "ментальную оценку" не нужно 3 технических этапа, достаточно одного. А формальный отказ можно вообще не обосновывать или придумать обоснование за 7 секунд. Если для этого нужно 10 этапов собеседований, значит вы тратите деньги на то, что можно легко получить бесплатно.
Чтобы нанять кого-то, надо понимать, кто вам нужен и уметь проводить собеседования. И делать это должен нанимающий менеджер или его доверенное лицо, а не какой-то корнеплод, живущий на горе, который вообще никакого отношения к предстоящей работе не имеет.
Я и не предлагал не оценивать задачи и не иметь плана (зато не оценивать задачи предлагал создатель стори пойнтов).
Везде уже научились их оценивать. Поезда вон ходят минута в минуту по расписанию.Многие в ИТ уже тоже научились их оценивать. Мне кажется, что проблемы со сроками только у тех, кто воспринимает фразу "попасть в оценку очень сложно" как аксиому и не пытается сроками управлять. Или у тех, кто пытается использовать бесполезные инструменты, например сторипойнты.
Вот почему-то всех тянет измерять сложный интеллектуальный труд количеством изготовленных на заводе деталей, которые потом конвертируются во время, оправдывая это тем, что сразу во времени оценить очень сложно. Хотя, это кажется очевидным бредом.
Открою страшную тайну, проблема не нова и уже много лет существует практически в любой отрасли и даже в повседневной жизни. Когда мы измеряем любой процесс в точных единицах времени, мы почти всегда ошибаемся. Но только в ИТ решили придумать защекоины, которые потом все равно приходится переводить во время, вместо того, чтобы использовать готовые решения.
Вы говорите о вреде карго-культа, но сама идея сторипойнтов родилась как решение совершенно другой проблемы. А уже потом карго-культисты под агиле лозунгами использовали эту идею для увеличения собственной значимости.
Это всего лишь магия худу, она работает только когда вы в нее верите. Ничего плохого в ней нет, но ничего хорошего она тоже не приносит, кроме иллюзий. Но, если они вам помогают, почему бы и нет?!
Судя по статье, навыки системного аналитика - это очень много воды. Причем, воды из разных бочек, смешанных в одной. К примеру, на основе CAP теоремы строится весь трейд офф между микросервисами и монолитами, т.е. она применяется для системы в целом, а не конкретно в базах данных.
А вообще, мне казалось, что главные навыки системного аналитика - это умение четко выражать свои мысли, посредством написания текста, и умение классифицировать и структурировать информацию, т.е. то самое системное мышление. И развиваются они только практикой.
И снова повестка "скрам и агиле работают, вы просто не умеете их готовить, очень надо нанять того, кто умеет".
Может дело в том, что "карго культ" в этом случае не метафора?! Помимо того, что в самой статье полно противоречий, так она ещё и опирается на 2 "принципа", которые сами по себе являются бредом.
Не бывает никаких самоорганизованных команд. Если ваша команда "самоорганизована" - значит у нее есть неформальный лидер, который координирует ее действия.
А кроссфункциональные команды не существуют, потому что ваш "инкремент" требует участия большого количества людей с разными компетенциями, которые не могут работать одновременно и одинаковое количество времени.
Эх, и снова у нас тут эффективноменеджерский инструмент, который работает, только если вы зовете специально обученного человека его внедрять и рассказывать, какой это полезный инструмент.
Агиле умер, потому что люди начали наконец догадываться, что это просто хорошо проданный карго-культ, о котором и упоминалось в статье. И продан он был хорошо именно потому, что 99% его адептов 99% своего времени объясняли, чем же они занимаются, как же это важно, и как же будет зашибись, если они будут дальше этим заниматься, а незашибись не будет.
И вот мы опять получаем статью про то, как важно уметь в агиле, ведь иначе он не работает. И опять это просто океан воды из рубрики "очевидное и невероятное" и никакой конкретики. "Вот это важно, если не делать будет плохо", "если нарушать правила - будет плохо", "если соблюдать правила - будет хорошо".
Менеджмент - это не про правила, которые надо соблюдать, потому что так написали в известной книжонке. Это про умение обрабатывать конкретные события, в конкретных ситуациях, анализировать их, и на основе этого анализа делать выводы, которые помогают вам выстраивать эти самые правила, чтобы достигать ваших целей.
Не знаю, где вы работали по 20 часов в день, но в крупных компаниях, как правило, работать нужно меньше чем в мелких, а самодурства больше в мелких компаниях, потому что какой-нибудь CEO там царь и бог. В бигтехе больше бесполезного административного состава, но его влияние на разработчика сильно ограничено, из-за размытия ответственности и кучи бестолковых слов типа "агиле", перформанс ревью, и прочей шелухи
Все, конечно, очень сильно зависит от проекта, но, в целом, процессы российского бигтеха скорее позволяют разработчикам потеряться и не работать, чем выжимают из них соки.
У тех, кто после курсов и хотят найти первую работу может и есть конкуренция, есть она и у менеджерского состава, но у разрабов от мидла и выше ее просто нет. Они просто публикуют резюме и ждут, даже откликаться не надо.
Основные тренды на 2025 год и ещё лет на 10 вперёд:
Специалистов начального уровня много, а продвинутого и среднего меньше, но всем нужны продвинутые по цене начального, поэтому у нас кадровый голод.
Повышать зарплаты никому не хочется, но приходится из-за конкуренции, кадрового голода и инфляции.
Вакансий много.
Эффективные менеджеры продолжают топить за эффективность, делать красивые презентации, придумывать бестолковые правила и звания и ищут другие популярные нынче способы себя занять с красивыми названиями.
Самые популярные языки программирования те же, что были в прошлом году, но есть и другие популярные.
Но это все субъективное мнение на основе личного опыта, просто решил поделиться.
Статья, видимо, написана для того, чтобы HR'ы ее кандидатам скидывали. Чтобы кандидаты просто учили бесполезные термины и тут же забывали их после собеседования.
По факту, единственное, что нужно от продукта в 99% случаев - умение выражать свои мысли и строить конечный образ продукта для достижения поставленных целей, все остальное - частности. Быть мастером спорта по джире, скраму и прочему ему не обязательно, по той простой причине, что команда может не пользоваться ни DoD'ами, ни DoR'ами, ни WBS'ом, ни английским, а может и вообще ничем из того, что тут написано.
Выглядит как очередная попытка стандартизировать нестандартизируемое. С тем же успехом можно написать кто такие джуны, мидлы и сеньоры.
Нормальным руководителям не нужно разбираться в сортах эффективноменеджерских отходов и придумывать очередной бредовый термин. Достаточно уметь замечать существующие проблемы и находить решения.
Ну, вообще, убеждение, что вот именно в ИТ надо постоянно учиться или будет все очень плохо - это миф.
В реальности, бизнесу не нужны хорошие инженеры. Да, сейчас любому бизнесу нужен сайт, или сервис, или мобильное приложение, но 90% процентов задач в ИТ - это гонять туда-сюда json'ы за три строчки кода на языке высокого уровня, а для этого много ума не надо.
Добавьте сюда историю с дефицитом кадров и вот мы уже в реальности, в которой есть разработчики мобильных приложений, которые получают 400+к и не знают, как работает банальный HTTP (случай из жизни). Просто потому что кандидатов очень мало.
Единственная причина, по которой говорят, что в ИТ надо много учиться - это собеседования. Потому что, на самом деле, в сфере очень высокий порог вхождения и быстро меняющиеся тенденции, которые надо класть в голову непосредственно перед поиском работы.
После чего, можно найти себе работу в каком-нибудь бигтехе, где никто не будет много требовать, но и никогда не уволят, платить будут сносно и можете там сидеть до самой пенсии.
В итоге, если иметь хорошую базу и, более-менее, следить за современностью, ты уже будешь на несколько порядков выше сеньеров-помидоров с 3 годами опыта работы после курсов Яндекса, банально потому, что, в отличии от них, ты знаешь как работает компьютер а не конкретный язык, фрэймворк или технология, и все это для тебя лишь инструмент для решения задачи, которым ты можешь при необходимости воспользоваться.
Да, если вы хотите стать хорошим специалистом - нужно учиться. Но не сильно больше чем в другой сфере. Хороший юрист, экономист, музыкант, повар, врач или плотник учатся столько же. У нас слишком маленькие головы, чтобы положить туда все знания из какой-либо сферы деятельности. Вопрос лишь в том, насколько глубокие знания вам нужны.
Так что, скорее, вы любите ИТ, потому что вам делать то, что вы делаете)
А ещё вам нравится изучать новые технологии в области ИТ)
Когда-нибудь, мы все оглянемся назад, вспомним как все эти, паразитирующие на лояльности отрасли, деятели успешных успехов и эффективных процессов доказывали с пеной у рта, какой же полезной деятельностью они занимаются, тихо усмехнемся и пойдем дальше писать свой код.
Но не сегодня. Сегодня мы все ещё видим кучу бестолковых менеджеров, которые списывают свою бестолковость на отсутствие коучей, мастеров или методологов. А все коучи, мастера и методологи списывают бестолковость менеджера на отсутствие ритуалов, незрелость команд, метрик и ещё какой-нибудь бесполезной чепухи.
И все эти проблемы решаются наймом одного человека, который умеет управлять людьми. Умеет защищать интересы сотрудников, чтобы они защищали интересы компании. Но мы пока не поняли, зачем нужны менеджеры. Поэтому, не сегодня.
Раньше был тренд нанимать и распихивать везде агиле коучей и скрум мастеров, а теперь методологов.
И все это делается наиболее эффективным менеджерами и наиболее крутыми АйТи директорами вместо того, чтобы немного поработать и заставить работать начальников подчиненных им отделов, чтобы они наконец поняли, зачем нужны эти самые отделы и что нужно сделать, чтобы решать свои задачи в нужные сроки.
В результате мы имеем кучу административного персонала с максимально размытой зоной ответственности и полное отсутствие управления непосредственными исполнителями.
Зачем вообще переводить какую-то ахинею?!
Просто поток воды, цитат не к месту и сомнительных фактов о карго культе, который насколько человек успешно продали, воспользовавшись моментом.
Так-то, эта статья тоже весьма и весьма поверхностна. Просто список терминов и ваше короткое мнение., без реальных примеров или обоснования.
Это не ddd хайпует, а вы хайпуете на ddd)
Все эти этапы для этого не нужны.
Для того чтобы сделать "ментальную оценку" не нужно 3 технических этапа, достаточно одного. А формальный отказ можно вообще не обосновывать или придумать обоснование за 7 секунд. Если для этого нужно 10 этапов собеседований, значит вы тратите деньги на то, что можно легко получить бесплатно.
Чтобы нанять кого-то, надо понимать, кто вам нужен и уметь проводить собеседования. И делать это должен нанимающий менеджер или его доверенное лицо, а не какой-то корнеплод, живущий на горе, который вообще никакого отношения к предстоящей работе не имеет.
Во взрослых бизнесах сторипойнты. Это статья от МТС, куда уж взрослее.
Я и не предлагал не оценивать задачи и не иметь плана (зато не оценивать задачи предлагал создатель стори пойнтов).
Везде уже научились их оценивать. Поезда вон ходят минута в минуту по расписанию.Многие в ИТ уже тоже научились их оценивать. Мне кажется, что проблемы со сроками только у тех, кто воспринимает фразу "попасть в оценку очень сложно" как аксиому и не пытается сроками управлять. Или у тех, кто пытается использовать бесполезные инструменты, например сторипойнты.
Вот почему-то всех тянет измерять сложный интеллектуальный труд количеством изготовленных на заводе деталей, которые потом конвертируются во время, оправдывая это тем, что сразу во времени оценить очень сложно. Хотя, это кажется очевидным бредом.
Открою страшную тайну, проблема не нова и уже много лет существует практически в любой отрасли и даже в повседневной жизни. Когда мы измеряем любой процесс в точных единицах времени, мы почти всегда ошибаемся. Но только в ИТ решили придумать защекоины, которые потом все равно приходится переводить во время, вместо того, чтобы использовать готовые решения.
Вы говорите о вреде карго-культа, но сама идея сторипойнтов родилась как решение совершенно другой проблемы. А уже потом карго-культисты под агиле лозунгами использовали эту идею для увеличения собственной значимости.
Это всего лишь магия худу, она работает только когда вы в нее верите. Ничего плохого в ней нет, но ничего хорошего она тоже не приносит, кроме иллюзий. Но, если они вам помогают, почему бы и нет?!
Судя по статье, навыки системного аналитика - это очень много воды. Причем, воды из разных бочек, смешанных в одной. К примеру, на основе CAP теоремы строится весь трейд офф между микросервисами и монолитами, т.е. она применяется для системы в целом, а не конкретно в базах данных.
А вообще, мне казалось, что главные навыки системного аналитика - это умение четко выражать свои мысли, посредством написания текста, и умение классифицировать и структурировать информацию, т.е. то самое системное мышление. И развиваются они только практикой.
И снова повестка "скрам и агиле работают, вы просто не умеете их готовить, очень надо нанять того, кто умеет".
Может дело в том, что "карго культ" в этом случае не метафора?! Помимо того, что в самой статье полно противоречий, так она ещё и опирается на 2 "принципа", которые сами по себе являются бредом.
Не бывает никаких самоорганизованных команд. Если ваша команда "самоорганизована" - значит у нее есть неформальный лидер, который координирует ее действия.
А кроссфункциональные команды не существуют, потому что ваш "инкремент" требует участия большого количества людей с разными компетенциями, которые не могут работать одновременно и одинаковое количество времени.
Эх, и снова у нас тут эффективноменеджерский инструмент, который работает, только если вы зовете специально обученного человека его внедрять и рассказывать, какой это полезный инструмент.
Очень уж знакомая история.
Агиле умер, потому что люди начали наконец догадываться, что это просто хорошо проданный карго-культ, о котором и упоминалось в статье. И продан он был хорошо именно потому, что 99% его адептов 99% своего времени объясняли, чем же они занимаются, как же это важно, и как же будет зашибись, если они будут дальше этим заниматься, а незашибись не будет.
И вот мы опять получаем статью про то, как важно уметь в агиле, ведь иначе он не работает. И опять это просто океан воды из рубрики "очевидное и невероятное" и никакой конкретики. "Вот это важно, если не делать будет плохо", "если нарушать правила - будет плохо", "если соблюдать правила - будет хорошо".
Менеджмент - это не про правила, которые надо соблюдать, потому что так написали в известной книжонке. Это про умение обрабатывать конкретные события, в конкретных ситуациях, анализировать их, и на основе этого анализа делать выводы, которые помогают вам выстраивать эти самые правила, чтобы достигать ваших целей.
Не знаю, где вы работали по 20 часов в день, но в крупных компаниях, как правило, работать нужно меньше чем в мелких, а самодурства больше в мелких компаниях, потому что какой-нибудь CEO там царь и бог. В бигтехе больше бесполезного административного состава, но его влияние на разработчика сильно ограничено, из-за размытия ответственности и кучи бестолковых слов типа "агиле", перформанс ревью, и прочей шелухи
Все, конечно, очень сильно зависит от проекта, но, в целом, процессы российского бигтеха скорее позволяют разработчикам потеряться и не работать, чем выжимают из них соки.
Вы в каком-то странном мире живёте.
У тех, кто после курсов и хотят найти первую работу может и есть конкуренция, есть она и у менеджерского состава, но у разрабов от мидла и выше ее просто нет. Они просто публикуют резюме и ждут, даже откликаться не надо.
О, я тоже так могу.
Основные тренды на 2025 год и ещё лет на 10 вперёд:
Специалистов начального уровня много, а продвинутого и среднего меньше, но всем нужны продвинутые по цене начального, поэтому у нас кадровый голод.
Повышать зарплаты никому не хочется, но приходится из-за конкуренции, кадрового голода и инфляции.
Вакансий много.
Эффективные менеджеры продолжают топить за эффективность, делать красивые презентации, придумывать бестолковые правила и звания и ищут другие популярные нынче способы себя занять с красивыми названиями.
Самые популярные языки программирования те же, что были в прошлом году, но есть и другие популярные.
Но это все субъективное мнение на основе личного опыта, просто решил поделиться.
Статья, видимо, написана для того, чтобы HR'ы ее кандидатам скидывали. Чтобы кандидаты просто учили бесполезные термины и тут же забывали их после собеседования.
По факту, единственное, что нужно от продукта в 99% случаев - умение выражать свои мысли и строить конечный образ продукта для достижения поставленных целей, все остальное - частности. Быть мастером спорта по джире, скраму и прочему ему не обязательно, по той простой причине, что команда может не пользоваться ни DoD'ами, ни DoR'ами, ни WBS'ом, ни английским, а может и вообще ничем из того, что тут написано.
Выглядит как очередная попытка стандартизировать нестандартизируемое. С тем же успехом можно написать кто такие джуны, мидлы и сеньоры.
Нормальным руководителям не нужно разбираться в сортах эффективноменеджерских отходов и придумывать очередной бредовый термин. Достаточно уметь замечать существующие проблемы и находить решения.
Коммента, разумеется)
Ну, вообще, убеждение, что вот именно в ИТ надо постоянно учиться или будет все очень плохо - это миф.
В реальности, бизнесу не нужны хорошие инженеры. Да, сейчас любому бизнесу нужен сайт, или сервис, или мобильное приложение, но 90% процентов задач в ИТ - это гонять туда-сюда json'ы за три строчки кода на языке высокого уровня, а для этого много ума не надо.
Добавьте сюда историю с дефицитом кадров и вот мы уже в реальности, в которой есть разработчики мобильных приложений, которые получают 400+к и не знают, как работает банальный HTTP (случай из жизни). Просто потому что кандидатов очень мало.
Единственная причина, по которой говорят, что в ИТ надо много учиться - это собеседования. Потому что, на самом деле, в сфере очень высокий порог вхождения и быстро меняющиеся тенденции, которые надо класть в голову непосредственно перед поиском работы.
После чего, можно найти себе работу в каком-нибудь бигтехе, где никто не будет много требовать, но и никогда не уволят, платить будут сносно и можете там сидеть до самой пенсии.
В итоге, если иметь хорошую базу и, более-менее, следить за современностью, ты уже будешь на несколько порядков выше сеньеров-помидоров с 3 годами опыта работы после курсов Яндекса, банально потому, что, в отличии от них, ты знаешь как работает компьютер а не конкретный язык, фрэймворк или технология, и все это для тебя лишь инструмент для решения задачи, которым ты можешь при необходимости воспользоваться.
Да, если вы хотите стать хорошим специалистом - нужно учиться. Но не сильно больше чем в другой сфере. Хороший юрист, экономист, музыкант, повар, врач или плотник учатся столько же. У нас слишком маленькие головы, чтобы положить туда все знания из какой-либо сферы деятельности. Вопрос лишь в том, насколько глубокие знания вам нужны.
Так что, скорее, вы любите ИТ, потому что вам делать то, что вы делаете)
А ещё вам нравится изучать новые технологии в области ИТ)
Кажется, два этих клиента интереснее чем статья)
Когда-нибудь, мы все оглянемся назад, вспомним как все эти, паразитирующие на лояльности отрасли, деятели успешных успехов и эффективных процессов доказывали с пеной у рта, какой же полезной деятельностью они занимаются, тихо усмехнемся и пойдем дальше писать свой код.
Но не сегодня. Сегодня мы все ещё видим кучу бестолковых менеджеров, которые списывают свою бестолковость на отсутствие коучей, мастеров или методологов. А все коучи, мастера и методологи списывают бестолковость менеджера на отсутствие ритуалов, незрелость команд, метрик и ещё какой-нибудь бесполезной чепухи.
И все эти проблемы решаются наймом одного человека, который умеет управлять людьми. Умеет защищать интересы сотрудников, чтобы они защищали интересы компании. Но мы пока не поняли, зачем нужны менеджеры. Поэтому, не сегодня.
Раньше был тренд нанимать и распихивать везде агиле коучей и скрум мастеров, а теперь методологов.
И все это делается наиболее эффективным менеджерами и наиболее крутыми АйТи директорами вместо того, чтобы немного поработать и заставить работать начальников подчиненных им отделов, чтобы они наконец поняли, зачем нужны эти самые отделы и что нужно сделать, чтобы решать свои задачи в нужные сроки.
В результате мы имеем кучу административного персонала с максимально размытой зоной ответственности и полное отсутствие управления непосредственными исполнителями.