Вам дают возможность испытать что-то перед заключением договора купли-продажи. Это вы считаете нормальным, потому что автомобиль потом вернуть нельзя. На самом деле можно, просто проблематично.
Работодатель тоже хочет испытать сотрудника перед заключением договора найма. "Вернуть" работника после его заключения тоже проблематично, хотя и возможно.
От выполнения тестового можно отказаться, вас же никто не обязывает его делать. Но, при покупке машины из двух салонов вы наверняка выберете тот, который разрешит вам тестдрайв. И там, и там есть какие-то договорные отношения на этапе до заключения какого-либо письменного соглашения. И они направлены на то, чтобы это соглашение как можно скорее подписать. Отличий тут не особо много.
Испытательный срок никаких гарантий не дает тем более. И чтобы он вообще начался, работодателю необходимо провести просто огромную кучу мероприятий. Вполне понятно, что он хочет этого всего избежать, отсеяв неподходящих по разным параметрам людей как можно на более раннем этапе.
Я сам не сторонник тестовых заданий, но когда мне его дают, я либо его выполняю (ведь это я ищу работу, это в моих интересах прежде всего), либо ищу другого работодателя. А так как никаких договорных отношений еще не наступило юридически, тут уж как договоришься. Кто мешает сказать, вы простите, тут работы на неделю, я не готов. За это нет никакой ответственности, кроме гипотетической потери престижа в глазах работодателя.
Так вы в себе сначала разберитесь, в ваших высказываниях сплошные противоречия.
Например, Я больше не могу класть задачи по компоненту в беклог(только на самое дно). Как у вас получается одновременно и могу, и не могу? И на основании этого вы делаете выводы какие-то, очевидно тоже противоречивые, сдобрив всю историю кликбейтом, в чем сами и признаетесь ) ну, акей.
На хабре с завидной периодичностью появляются такие статьи, от короля и ко(тм).
Помню, был тут недавно разработчик, которого попросили с испытательного срока где-то в Минске, он тоже выдал кучу грязного белья, получил 2к каментов. В каментах правда выяснилось, что он просто курил в кабинете, хотя его просили так не делать.
Правда сейчас статья куда-то пропала, разработчик в стоплисте у всех нанимателей, хайп завял, все как обычно. Подобного рода статей не встретишь на англоязычных тематических ресурсах, вываливать грязное белье нигде не принято. Видимо, речь про это.
Тогда заголовок был бы слегка другой, не находите? Автор делает какое-то громкое заявление, но по факту ничем его не подтверждает, кроме собственных ощущений. Что соответственно вводит в заблуждение читателей, зачем?
Вот все, что вы описали, это не проблемы внедрения SCRUM\Agile. Все, что вы описали - это ваше субъективное восприятие ситуации. Ваша зона комфорта разрушена, адаптироваться не получилось. Я так понимаю, поезд никакой не остановился, он просто поехал без вас, что вас совсем не устроило.
Попробуйте сменить фокус восприятия, он у вас смещен и из-за этого получаюются сплошные противоречия. Например, "Я больше не могу класть задачи по компоненту в беклог(только на самое дно)". превращается в "Я могу класть задачи по компоненту в беклог, но меня не устраивает, что их приоритезируют подобным образом"
"На первый взгляд набор инстументов не изменился команды, дейли, ретро, планирование, беклог, это было до трансформации это никуда не делось после"
превращается в
"Инструменты работают, но применяются неправильно по моему мнению".
По идее хорошо бы прийти к ПМу (любому начальнику) и с ним поговорить для начала, выяснить что происходит. Но, как понимаю, и тут не сложилось, только вы почему-то в этом вините всех вокруг, а должны спросить в первую очередь с себя. Ведь если бы процессы были сломаны и все было так плохо и все не работало, проект был бы нежизнеспособен и закрыт. Чего, очевидно не случилось, просто вы ушли. С таким отношением неважно какую метдологию подставить в заголовок, всегда все будет плохо. Надо менять отношение, вы в меньшинстве так или иначе, с ветряными мельницами бороться такое себе занятие.
Предлагаю не мешать сюда религию. Факт, всем нужен процесс, всем нужен контроль, что он выполняется. Бизнес хочет понимать, на что он тратит деньги. Исполнители должны понимать, что от них хочет бизнес. И это зачастую настолько далекие друг от друга люди, что без посредника они просто не договорятся. И чем сложнее процессы, тем сложнее схемы и тем больше посредников. Плохо, когда это превращается в карго-культ. Но, как правило, бизнес - это не дурак и все такие вещи рано или поздно исчезают. Либо исчезает несмышленый бизнес. Дураков тратить деньги в никуда очень мало )) Как правило, секты очень эффективны, там как раз все за идею. Рабочий коллектив сложнее, там кто-то за идею, кто-то за деньги, кто-то комбинирует. И это нормально!
Задача менеджера - транслировать хотелки бизнеса в понятный всем план действий. У бизнеса хотелки простые - заработать побыстрее, снизив издержки побольше. В этом кроется противоречие, потому что фонд заработной платы - это издержки.
Там везде много разных документов, есть еще Трудовой Кодекс, он вообще всем помогает. OpenSource проекты, это тоже коммерческие проекты. Просто монетизируются они по-другому.
Это все, к сожалению, не отменяет сотен тысяч инженеров, у которых ни с того ни со всего "потерялся контроль над компонентом" (что бы это ни значило). И они сразу отправились "воевать с группой из нескольких десятков человек".
К сожалению (или к счастью), ситуация такова, что люди все разные, подходы к работе тоже широко варьируются. Кто-то выгорел, кто-то устал, кто-то испытывает личную непрязнь, кто-то просто саботирует процесс, плетет интриги, кто-то беспринципный карьерист. Что предлагаете с ними делать?
Там в целом все прекрасно. Даже неглядя на то, что автор просто поленился вычитать статью, показав сразу всем, как он относится к основному инструменту своей работы.
"На место настоящих инструментов пришли суррогаты". Что за инструменты, какие были, какие стали, на основании каких признаков сделан соответствующий вывод.
"Разговоры о скраме выглядят шаблонно, люди используют одинаковые слова и бывает произносят их в одинаковом порядке. Контекст вообще неясен. Зачем об этом разговаривать вообще. Есть спринт, есть задачи, их надо делать, проставлять пометки соответствующие. В каком месте тут появляется разговор и для чего вообще. Необязательно знать, как устроена машина, чтобы на ней ездить. А кондуктору в автобусе необязательно знать устройство ДВС для выполнения своих обязанностей.
" Скрам мастера и коучи не помогают мне решать проблемы". Какого рода проблемы тут могут возникать, это проблемы организации процесса или самого процесса или чего проблемы. От участника процесса ничего не требуют в целом, кроме выполнения задач в спринте, или у вас не так?
"Я не могу воевать с группой из нескольких десятков человек, которая ещё и владеет правилами игры". Почему вообще настала необходимость воевать, а не договариваться? Виноват ли скрам, что вы не хотите или не умеете работать в команде?
"Я потерял контроль над своим компонентом". У вас командная разработка или индивидуальная? Про какой контроль идет речь? Если исходный код компонента лежит в общем доступе, это достаточный контроль или какой еще нужен?
И самое главное, как вы раньше-то работали. Как стало понятно, а как было? Заголовок кликбейт, в статье про это вообще ничего нет, кроме того, что вам кажется. Без конкретики это какой-то клуб джентльменов получается.
Совет, если текст статьи прогнать через спеллчекер, он будет читаться полегче.
Всего рабочая неделя составляет 40 часов. Вы "ожидаете" от стажера 30-35 часов, то есть рабочий день у него будет не 8-и часовой, как у всех, а всего лишь шести\семи? В таких условиях совмещать-то они могут, но что из этого получится, вопрос риторический.
И в ТК РФ нет таких понятий "работать гибко, работать на время, работать на результат". Там оперируют четким и понятными "график работы", "неполный рабочий день", "соглашение сторон", "обязанности работника", "права работника" и прочее.
Да все просто, рабочих часов в неделю всего сорок. И если программист сидит и ковыряется там, где сэкономили на админе, он пишет меньше кода, чем тот, который только пишет код. "Плоские команды" и другой трешачок может и по-другому работают, но сейчас при всей перегретости рынка при выборе секта или вменяемый работодатель, люди выберут таки второй вариант. Мотивация сесть и обняться, а потом всю ночь обняться и дебажить прод, к счастью перестает работать. И все эти разговоры, что же должен уметь сеньор, да все он должен уметь, а еще он прод дебажит на горячую, это все неуклюжие попытки сэкономить на персонале, они обычно заканчиваются весьма плачевно для стейкхолдеров.
Уж не знаю, где вы берете таких сотрудников, сложно судить без каких-либо деталей. Так можно, но зачем, когда за вменяемые деньги сейчас без всяких усилий можно просто найти работу с нормальными процессами, спокойно там работать и спокойно зарабатывать на смузи и красный мотоцикл, без вот этого всего.
Ничего негативного. Ваш прод, честно говоря, больше похож на небольшой стартап на деньги инвестора, которые ему возвращать никто не собирается. В любых серьезных организациях "круговая порука" и другие модные бирюзовые эксперименты быстро заканчиваются после первых факапов, а бизнес тотчас вспоминает про старый добрый ITIL, где все давным давно уже придумали и прописали натурально кровью и потом.
Узкие специалисты в лонгтерме в целом эффективнее, чем ходячая энциклопедия, которая все знает, но ничего не умеет. Поэтому всем по-большему счету все равно, знает ли сетевик про флаги айпитейблс или нет. От него требуется корректно настроенная сеть, если он ее обеспечивает, он хороший специалист. Если при этом директор сэкономил на других инженерах и сетевик сидит крутит правила айпитейблс для докера, то у него и сеть будет средненькая, и докер хреновенько будет работать. Крылов не зря же написал свою басню в 1813 году еще про щуку и кота. Не зря же нейрохихург всю жизнь учится выполнять только одно дело в своей жизни, но выполнять ювелирно и профессионально. И времени у нейрохирурга на детальное изучение и разработку ПО, которое ему помогает, совсем нет. На работе в целом не за кругозор платят, а за выполнение рабочих обязанностей, четко прописанных в соответствующих документах. Человек, сконцентрированный на своих обязанностях выполняет работу лучше, чем абстрактный мастер на все руки. И чем сложнее обязанности, тем их будет меньше и меньше. В целом все методики уже давно выработаны, что подходит командам, что не подходит, это все давно известно и опций там не особо много. Размытая ответственность - это антипаттерн, либо прихоть бизнеса, который может себе это позволить, их немного. Все остальное подчиняется четким законам давным давно известным, противиться этому глупо. Такие дела.
Как-то с областями ответственности у вас не работает, поэтому вместо специалиста сеньора (боюсь спросить, у вас лид тогда кто) у вас какой-то робот, владеющий фундаментальными знаниями о Вселенной, знающий кулинарную энциклопедию наизусть и секвенирующий геном во время перекура, решая в уме сложные задачи из криптографии, пока в мире решения не имеющие.
Доступ у всех = ответственные все = никто ни за что не ответственный.
Почему бы вам просто не назначить ответственных по областям. При этом все будут счастливо заниматься своими делами, применяя свои навыки там где они нужны. Не надо суперчеловека для этого искать, их все равно нет. Загрузку данных в голову пока не придумали, выучить все в мире невозможно. Лучше выучить что-то целенаправлено, но более глубоко, чем овладеть обширными энциклопедическими знаниями, которые никуда толком приложить нельзя.
Может наверное, зависит от того, насколько хорош сотрудник. Ради некоторых организации и не на такое идут.
Вам дают возможность испытать что-то перед заключением договора купли-продажи. Это вы считаете нормальным, потому что автомобиль потом вернуть нельзя. На самом деле можно, просто проблематично.
Работодатель тоже хочет испытать сотрудника перед заключением договора найма. "Вернуть" работника после его заключения тоже проблематично, хотя и возможно.
От выполнения тестового можно отказаться, вас же никто не обязывает его делать. Но, при покупке машины из двух салонов вы наверняка выберете тот, который разрешит вам тестдрайв. И там, и там есть какие-то договорные отношения на этапе до заключения какого-либо письменного соглашения. И они направлены на то, чтобы это соглашение как можно скорее подписать. Отличий тут не особо много.
Испытательный срок никаких гарантий не дает тем более. И чтобы он вообще начался, работодателю необходимо провести просто огромную кучу мероприятий. Вполне понятно, что он хочет этого всего избежать, отсеяв неподходящих по разным параметрам людей как можно на более раннем этапе.
Я сам не сторонник тестовых заданий, но когда мне его дают, я либо его выполняю (ведь это я ищу работу, это в моих интересах прежде всего), либо ищу другого работодателя. А так как никаких договорных отношений еще не наступило юридически, тут уж как договоришься. Кто мешает сказать, вы простите, тут работы на неделю, я не готов. За это нет никакой ответственности, кроме гипотетической потери престижа в глазах работодателя.
Так вы в себе сначала разберитесь, в ваших высказываниях сплошные противоречия.
Например,
Я больше не могу класть задачи по компоненту в беклог(только на самое дно).
Как у вас получается одновременно и могу, и не могу? И на основании этого вы делаете выводы какие-то, очевидно тоже противоречивые, сдобрив всю историю кликбейтом, в чем сами и признаетесь ) ну, акей.
На хабре с завидной периодичностью появляются такие статьи, от короля и ко(тм).
Помню, был тут недавно разработчик, которого попросили с испытательного срока где-то в Минске, он тоже выдал кучу грязного белья, получил 2к каментов. В каментах правда выяснилось, что он просто курил в кабинете, хотя его просили так не делать.
Правда сейчас статья куда-то пропала, разработчик в стоплисте у всех нанимателей, хайп завял, все как обычно. Подобного рода статей не встретишь на англоязычных тематических ресурсах, вываливать грязное белье нигде не принято. Видимо, речь про это.
Тогда заголовок был бы слегка другой, не находите? Автор делает какое-то громкое заявление, но по факту ничем его не подтверждает, кроме собственных ощущений. Что соответственно вводит в заблуждение читателей, зачем?
Вот все, что вы описали, это не проблемы внедрения SCRUM\Agile.
Все, что вы описали - это ваше субъективное восприятие ситуации. Ваша зона комфорта разрушена, адаптироваться не получилось. Я так понимаю, поезд никакой не остановился, он просто поехал без вас, что вас совсем не устроило.
Попробуйте сменить фокус восприятия, он у вас смещен и из-за этого получаюются сплошные противоречия. Например,
"Я больше не могу класть задачи по компоненту в беклог(только на самое дно)".
превращается в
"Я могу класть задачи по компоненту в беклог, но меня не устраивает, что их приоритезируют подобным образом"
"На первый взгляд набор инстументов не изменился команды, дейли, ретро, планирование, беклог, это было до трансформации это никуда не делось после"
превращается в
"Инструменты работают, но применяются неправильно по моему мнению".
По идее хорошо бы прийти к ПМу (любому начальнику) и с ним поговорить для начала, выяснить что происходит. Но, как понимаю, и тут не сложилось, только вы почему-то в этом вините всех вокруг, а должны спросить в первую очередь с себя. Ведь если бы процессы были сломаны и все было так плохо и все не работало, проект был бы нежизнеспособен и закрыт. Чего, очевидно не случилось, просто вы ушли.
С таким отношением неважно какую метдологию подставить в заголовок, всегда все будет плохо.
Надо менять отношение, вы в меньшинстве так или иначе, с ветряными мельницами бороться такое себе занятие.
Но ведь, если в бизнесе есть дураки, почему их не может быть среди инженеров?
Предлагаю не мешать сюда религию.
Факт, всем нужен процесс, всем нужен контроль, что он выполняется. Бизнес хочет понимать, на что он тратит деньги. Исполнители должны понимать, что от них хочет бизнес. И это зачастую настолько далекие друг от друга люди, что без посредника они просто не договорятся. И чем сложнее процессы, тем сложнее схемы и тем больше посредников. Плохо, когда это превращается в карго-культ. Но, как правило, бизнес - это не дурак и все такие вещи рано или поздно исчезают. Либо исчезает несмышленый бизнес. Дураков тратить деньги в никуда очень мало ))
Как правило, секты очень эффективны, там как раз все за идею.
Рабочий коллектив сложнее, там кто-то за идею, кто-то за деньги, кто-то комбинирует. И это нормально!
Задача менеджера - транслировать хотелки бизнеса в понятный всем план действий. У бизнеса хотелки простые - заработать побыстрее, снизив издержки побольше. В этом кроется противоречие, потому что фонд заработной платы - это издержки.
Там везде много разных документов, есть еще Трудовой Кодекс, он вообще всем помогает. OpenSource проекты, это тоже коммерческие проекты. Просто монетизируются они по-другому.
Это все, к сожалению, не отменяет сотен тысяч инженеров, у которых ни с того ни со всего "потерялся контроль над компонентом" (что бы это ни значило). И они сразу отправились "воевать с группой из нескольких десятков человек".
К сожалению (или к счастью), ситуация такова, что люди все разные, подходы к работе тоже широко варьируются. Кто-то выгорел, кто-то устал, кто-то испытывает личную непрязнь, кто-то просто саботирует процесс, плетет интриги, кто-то беспринципный карьерист. Что предлагаете с ними делать?
Почему вы так считаете?
Если вы вдруг будете брать в салоне новый автомобиль и вам сначала предложат тестдрайв, вы разве откажетесь?
Там в целом все прекрасно. Даже неглядя на то, что автор просто поленился вычитать статью, показав сразу всем, как он относится к основному инструменту своей работы.
А ведь он книги пишет и кто-то это покупает ))
Я вообще ничего не понял, он просил деньги у рекрутингового агенства за выполнение тестового задания?) Тогда понятно все, могли бы не оправдываться.
Я даже не поленился и открыл ссылку. Правда сразу и закрыл,
Не такой методологии Agile
Сложно с таким спорить.
Чуть больше конкретики не помешало бы. Например,
"На место настоящих инструментов пришли суррогаты". Что за инструменты, какие были, какие стали, на основании каких признаков сделан соответствующий вывод.
"Разговоры о скраме выглядят шаблонно, люди используют одинаковые слова и бывает произносят их в одинаковом порядке. Контекст вообще неясен. Зачем об этом разговаривать вообще. Есть спринт, есть задачи, их надо делать, проставлять пометки соответствующие. В каком месте тут появляется разговор и для чего вообще. Необязательно знать, как устроена машина, чтобы на ней ездить. А кондуктору в автобусе необязательно знать устройство ДВС для выполнения своих обязанностей.
" Скрам мастера и коучи не помогают мне решать проблемы". Какого рода проблемы тут могут возникать, это проблемы организации процесса или самого процесса или чего проблемы. От участника процесса ничего не требуют в целом, кроме выполнения задач в спринте, или у вас не так?
"Я не могу воевать с группой из нескольких десятков человек, которая ещё и владеет правилами игры". Почему вообще настала необходимость воевать, а не договариваться? Виноват ли скрам, что вы не хотите или не умеете работать в команде?
"Я потерял контроль над своим компонентом". У вас командная разработка или индивидуальная? Про какой контроль идет речь? Если исходный код компонента лежит в общем доступе, это достаточный контроль или какой еще нужен?
И самое главное, как вы раньше-то работали. Как стало понятно, а как было? Заголовок кликбейт, в статье про это вообще ничего нет, кроме того, что вам кажется. Без конкретики это какой-то клуб джентльменов получается.
Совет, если текст статьи прогнать через спеллчекер, он будет читаться полегче.
Всего рабочая неделя составляет 40 часов. Вы "ожидаете" от стажера 30-35 часов, то есть рабочий день у него будет не 8-и часовой, как у всех, а всего лишь шести\семи?
В таких условиях совмещать-то они могут, но что из этого получится, вопрос риторический.
И в ТК РФ нет таких понятий "работать гибко, работать на время, работать на результат". Там оперируют четким и понятными "график работы", "неполный рабочий день", "соглашение сторон", "обязанности работника", "права работника" и прочее.
Да все просто, рабочих часов в неделю всего сорок. И если программист сидит и ковыряется там, где сэкономили на админе, он пишет меньше кода, чем тот, который только пишет код. "Плоские команды" и другой трешачок может и по-другому работают, но сейчас при всей перегретости рынка при выборе секта или вменяемый работодатель, люди выберут таки второй вариант. Мотивация сесть и обняться, а потом всю ночь обняться и дебажить прод, к счастью перестает работать. И все эти разговоры, что же должен уметь сеньор, да все он должен уметь, а еще он прод дебажит на горячую, это все неуклюжие попытки сэкономить на персонале, они обычно заканчиваются весьма плачевно для стейкхолдеров.
Уж не знаю, где вы берете таких сотрудников, сложно судить без каких-либо деталей. Так можно, но зачем, когда за вменяемые деньги сейчас без всяких усилий можно просто найти работу с нормальными процессами, спокойно там работать и спокойно зарабатывать на смузи и красный мотоцикл, без вот этого всего.
Ничего негативного. Ваш прод, честно говоря, больше похож на небольшой стартап на деньги инвестора, которые ему возвращать никто не собирается. В любых серьезных организациях "круговая порука" и другие модные бирюзовые эксперименты быстро заканчиваются после первых факапов, а бизнес тотчас вспоминает про старый добрый ITIL, где все давным давно уже придумали и прописали натурально кровью и потом.
Узкие специалисты в лонгтерме в целом эффективнее, чем ходячая энциклопедия, которая все знает, но ничего не умеет. Поэтому всем по-большему счету все равно, знает ли сетевик про флаги айпитейблс или нет. От него требуется корректно настроенная сеть, если он ее обеспечивает, он хороший специалист. Если при этом директор сэкономил на других инженерах и сетевик сидит крутит правила айпитейблс для докера, то у него и сеть будет средненькая, и докер хреновенько будет работать. Крылов не зря же написал свою басню в 1813 году еще про щуку и кота. Не зря же нейрохихург всю жизнь учится выполнять только одно дело в своей жизни, но выполнять ювелирно и профессионально. И времени у нейрохирурга на детальное изучение и разработку ПО, которое ему помогает, совсем нет.
На работе в целом не за кругозор платят, а за выполнение рабочих обязанностей, четко прописанных в соответствующих документах. Человек, сконцентрированный на своих обязанностях выполняет работу лучше, чем абстрактный мастер на все руки. И чем сложнее обязанности, тем их будет меньше и меньше.
В целом все методики уже давно выработаны, что подходит командам, что не подходит, это все давно известно и опций там не особо много. Размытая ответственность - это антипаттерн, либо прихоть бизнеса, который может себе это позволить, их немного. Все остальное подчиняется четким законам давным давно известным, противиться этому глупо. Такие дела.
Как-то с областями ответственности у вас не работает, поэтому вместо специалиста сеньора (боюсь спросить, у вас лид тогда кто) у вас какой-то робот, владеющий фундаментальными знаниями о Вселенной, знающий кулинарную энциклопедию наизусть и секвенирующий геном во время перекура, решая в уме сложные задачи из криптографии, пока в мире решения не имеющие.
Доступ у всех = ответственные все = никто ни за что не ответственный.
Почему бы вам просто не назначить ответственных по областям. При этом все будут счастливо заниматься своими делами, применяя свои навыки там где они нужны. Не надо суперчеловека для этого искать, их все равно нет. Загрузку данных в голову пока не придумали, выучить все в мире невозможно. Лучше выучить что-то целенаправлено, но более глубоко, чем овладеть обширными энциклопедическими знаниями, которые никуда толком приложить нельзя.