Так парадокс ситуации в том, что наше законодательство всё ещё 'профсоюзное'. Проблема именно в людях, которые не видят своего интереса в отстаивании коллективных прав.
А еще с этого года эвалюэйшн производится только по запросу самого сотрудника. То есть, если ты не запрашиваешь — значит, не хочешь идти на диалог с компанией, не работаешь на улучшение, надбавки не заслужил. А если запросил — то еще не факт, что что-то получишь, так как неизвестно, оценят ли результаты твоей работы как «активное улучшение», или же ты просто «хорошо работал».
А это, кстати, интересно, что на официальном уровне можно отказаться от ревью. Что они сделают, если вся команда откажется, интересно?)
Я имел в виду что покорный человек «в системе» мыслит только паттернами покорности системы и игры по правилам которые система (те кто похитрее) навязывает, вместо того чтобы начать мыслить вне рамок
мне не известны другие способы кроме того что бы работать больше. Потому что везение это когда из 100 случаев два выигрышных и я пробовал 99. Если комментарий с точки зрения богатства, именно про деньги, то нужно ставить в приоритет зарабатывание. Например, когда у вам нужно заработать денег, вы можете работать программистом и пытаться растить экспертизу что-бы увеличивать свою зарплату. Можно поступить по другому и можно работать программистом и играть на бирже что бы реально зарабатывать. Можно взять дополнительную работу и клепать приложеньки или сайтики или что угодно, а можно найти человека который сделает это за тебя и ты получишь разницу за счет правильной организации процесса. В первом случае ты не масштабируешся и всегда будешь работать ради работы, а во втором можно экстраполировать подход и зарабатывать. Все зависит от того какой смысл ты вкладываешь. От смысла зависит то какой шаг делать дальше
Очень жаль, что современная пропаганда вдолбила мысль о том, что нужно стараться вытянуть билет в лотерию, вместо командной работы. Ну, это и понятно — сплоченная команда просто перестанет поддаваться на пропаганду, и тогда руководителям придется руководить, а не ждать халявного профита.
сли постараться то можно в процессе текущих задач также настроить CI получше, обновить либу, запилить прототип сервиса, зафиксить проблему рядом с тем местом где вы делали правки (а не забивать на нее), покрыть тестами то что не ложилось в задачу и тд
Ну так помещайте эти работы в ваш Роадмэп, а не надейтесь, что какой то сотрудник принесет вам это на халяву.
Уже не помню в какой книге (что-то про профессионального программиста) приводили пример человека который внимательно слушал проблемы, озвученные своим руководителем и постепенно решал их
Руководитель, в данном случае, манипулятор.
проактивный
Это понятно, что когда у вас в планировании хаос, или вы намеренно не включаете какие то задачи в план, потому что жалко времени, вам нужны проактивные. Вообщем, вы доказываете только мой тезис о том, что pr — инструмент эксплуатации.
Работать по плану это значит отбивать те деньги которые и так тратиться на сотрудника. Если зарплата «по рынку» зачем платить больше если человек не стримится ни к чему и плывет по течению.
Ну так ставьте в план те задачи, которые способствуют повышению для сотрудника, а не ждите «чуда»
Такая модель будет работать до тех пор пока сотрудник создаёт добавочную стоимость своей работой
Если он ее не создает, тогда у меня для вас плохие новости — ваш бизнес скоро обонкротится. Другими словами, работник не может не создавать добавочной стоимости, иначе ваш бизнес не будет прибыльным.
Когда выйдет новый фреймворк или работа упростится так что ее можно будет делать в два раза быстрее и у сотрудника не будет возможности перенять такой опыт он станет нерентабельными
Как профнепригодность связана с мотивацией? Если вы действительно заботитесь о развитии своих сотрудников — ставьте для них такие задачи (если они сами с этим согласны), а не ждите от них роста.
Нужно стараться делать добавочную стоимость своей работой сверх привычного уклада, тогда работодатель будет ценить такой вклад
Ну вот от такого отношения и появляется pr где человек пишуший фреймворк превозносится над человеком, исправляющий баги.
указание трёх компаний с их процессами как личного опыта. В мире миллионы компаний и везде по разному.
Кроме этого я опирался на публичный доклад Сергея Бережного и отзывы на процесс pr в яндексе из интернета.
Собирать оценку за год или полгода мне нужно отмечать моменты когда инженер сделал полезную вещь для команды, проекта, компании, когда от него этого не ожидали
Если видно что инженер делает 150% того что то него требуется, будут сделаны соответствующие выводы
Честно говоря, выглядит как плохо поставленные процессы. Что значит сделать то, что не ожидали? У вас так плохо с планированием, что вы не знаете, что вам нужно? И если это сделал разработчик, почему его стоит наградить, если другие работали по плану и в соответствии с ожиданиями? Такая системя выглядит, как попытка отвести от руководства какую либо ответственность и работать по принципу — давайте соберем вместе нормальных ребят, а они что-нибудь нам сделают.
Многие описанные вещи выглядят как история получившаяся на эффекте «выжившего».
Об этом в статье упоминалось неоднократно, но других способов нет, т.к. процесс закрытый, а там, где это было возможно, я оставлял ссылки на публичные данные. Поэтому стоит уточнить, что именно вам кажется ошибкой выжившего.
Ну тогда у вас этот процесс имеет признаки формального.
В случае Яндекса, на основании доклада Сергея, целью pr является не просто определить качественный рост сотрудника (на следующую должность например), но и сравнить людей. Например, сотрудник X работает лучше сотрудника Y на 20%, поэтому ему стоит дать премию на 20% больше. Судя по вашему описанию, ревью было одним из многих факторов для повышения, поэтому вы не заметили негативного фактора.
А вот когда ваш коллега запилил новый js фреймворк просто потому что у него была такая задача, а вы фиксили баги по этой же причине, но повышение и максимальную премию дают коллеге — вот тогда бы вы заметили.
В далекой перспективе ты получишь мир, где везде плохо. Даже сейчас, найти компанию без этого pr проблематично. Поэтому это проигрышная стратегия в долгосрочной перспективе.
В этом и суть pr — это инструмент эксплуатации и занижения твоей стоимости, а не роста. Именно поэтому он активно распространяется в компаниях не смотря на однозначно негативное отношение к нему большого количества сотрудников компаний.
Так в этом и проблема, что pr появляется во всех компаниях. Их нет только в стартапах, которым реально нужен результат, как было указано тут в одном из комментариев.
Степень нечестности ревью, просто пропорциональна рациональности разработчиков: если люди ведутся на манипуляцию, она будет выгодна компании, а если не ведутся тогда компания сделает себе хуже т.к. вообще потери от ухода разработчика, который проработал год и более довольно большие.
Вот с этим полностью согласен, но мой опыт показывает, что как раз таки разработчики ведутся, т.к. для этого включена очень мощная пропагандистская машина.
Все зависит от воли руководителей — если они не захотят, никакая политика не поможет. В этом и коварство performance review — тебе пытаются объяснить, что этот процесс объективный и справедливый, но по факту ничего не меняется, а вот ты можешь поверить в эту пропаганду.
Реально действующий профсоюз может быть организован только сотрудниками. Иначе, он со временем превращается в т.н. жёлтый профсоюз
Так парадокс ситуации в том, что наше законодательство всё ещё 'профсоюзное'. Проблема именно в людях, которые не видят своего интереса в отстаивании коллективных прав.
Думаю нет. Поэтому, я благодарен компании за тот опыт, который я получил.
Ну это точно не про это статья - компания живёт и по сей день и все у нее хорошо.
А это, кстати, интересно, что на официальном уровне можно отказаться от ревью. Что они сделают, если вся команда откажется, интересно?)
В точку!
medium.com/@olivia.s.biggs30/a-third-of-americans-believe-theyll-become-millionaires-but-80-of-millionaires-have-inherited-562104920f50
Очень жаль, что современная пропаганда вдолбила мысль о том, что нужно стараться вытянуть билет в лотерию, вместо командной работы. Ну, это и понятно — сплоченная команда просто перестанет поддаваться на пропаганду, и тогда руководителям придется руководить, а не ждать халявного профита.
Ну так помещайте эти работы в ваш Роадмэп, а не надейтесь, что какой то сотрудник принесет вам это на халяву.
Руководитель, в данном случае, манипулятор.
Это понятно, что когда у вас в планировании хаос, или вы намеренно не включаете какие то задачи в план, потому что жалко времени, вам нужны проактивные. Вообщем, вы доказываете только мой тезис о том, что pr — инструмент эксплуатации.
Ну так ставьте в план те задачи, которые способствуют повышению для сотрудника, а не ждите «чуда»
Если он ее не создает, тогда у меня для вас плохие новости — ваш бизнес скоро обонкротится. Другими словами, работник не может не создавать добавочной стоимости, иначе ваш бизнес не будет прибыльным.
Как профнепригодность связана с мотивацией? Если вы действительно заботитесь о развитии своих сотрудников — ставьте для них такие задачи (если они сами с этим согласны), а не ждите от них роста.
Ну вот от такого отношения и появляется pr где человек пишуший фреймворк превозносится над человеком, исправляющий баги.
Кроме этого я опирался на публичный доклад Сергея Бережного и отзывы на процесс pr в яндексе из интернета.
Честно говоря, выглядит как плохо поставленные процессы. Что значит сделать то, что не ожидали? У вас так плохо с планированием, что вы не знаете, что вам нужно? И если это сделал разработчик, почему его стоит наградить, если другие работали по плану и в соответствии с ожиданиями? Такая системя выглядит, как попытка отвести от руководства какую либо ответственность и работать по принципу — давайте соберем вместе нормальных ребят, а они что-нибудь нам сделают.
Об этом в статье упоминалось неоднократно, но других способов нет, т.к. процесс закрытый, а там, где это было возможно, я оставлял ссылки на публичные данные. Поэтому стоит уточнить, что именно вам кажется ошибкой выжившего.
В статье он рассматривался в контексте «справедливого распределения благ».
В случае Яндекса, на основании доклада Сергея, целью pr является не просто определить качественный рост сотрудника (на следующую должность например), но и сравнить людей. Например, сотрудник X работает лучше сотрудника Y на 20%, поэтому ему стоит дать премию на 20% больше. Судя по вашему описанию, ревью было одним из многих факторов для повышения, поэтому вы не заметили негативного фактора.
А вот когда ваш коллега запилил новый js фреймворк просто потому что у него была такая задача, а вы фиксили баги по этой же причине, но повышение и максимальную премию дают коллеге — вот тогда бы вы заметили.
Два вопроса по этой системе:
Так в том и суть, что классическая схема при которой ты напрямую добиваешься премии у руководства выглядит честнее и прозрачнее чем pr
Так в этом и проблема, что pr появляется во всех компаниях. Их нет только в стартапах, которым реально нужен результат, как было указано тут в одном из комментариев.
Вот с этим полностью согласен, но мой опыт показывает, что как раз таки разработчики ведутся, т.к. для этого включена очень мощная пропагандистская машина.