Comments 67
Таким образом этот механизм может быть использован (а значит рано или поздно будет), для объяснения недоплатны сотруднику относительно его рыночной стоимости. Обычно пока компания растет всё ок, но когда у неё кризис, тогда неожиданные результаты ревью и прилетают. То есть конечно это всё манипуляция, но относиться к ней надо спокойно и просто ходить на другие интервью получать оферы, не забывать сколько ты на самом деле стоишь и не вестись на газлайтинг.
Мне кажется, у этой системы есть очень большой недостаток — элементы демократии будут только если этого захочет руководство, для которых оценки составляются, потому что система не прозрачная, а административный и/или юридический вес твоя оценка не имеет
Каждому работнику свой блокчейн токен!
Но разработчика это всё не должно интересовать так как тут речь идёт не о государстве, а о рынке: сменить компанию проще простого. Ты можешь получать столько денег и других благ, сколько тебе готовы заплатить. Соответственно при твоем личном рациональном поведении ты получаешь всегда более менее адекватную зарплату, независимо от того, как устроена процедура ревью в отдельно взятой компании.
Степень нечестности ревью, просто пропорциональна рациональности разработчиков: если люди ведутся на манипуляцию, она будет выгодна компании, а если не ведутся тогда компания сделает себе хуже т.к. вообще потери от ухода разработчика, который проработал год и более довольно большие.
«Делать нормально» — это совсем другая история. Компанию интересует прибыль и это нормально. Вас, наверное, интересует не только прибыль, и это тоже нормально. Этот конфликт интересов нормален и неустраним. Поэтому важно иметь пет-проджект для души. Не надо просто связывать свою жизнь и, скажем так, стремление к искусству с работой на компанию. Дело в том, что вы человек, а компания это общее дело объединяющая людей на тему подзаработать денег. Любой отдельно взятый человек всегда хочет большего чем денег, но для каждого человека в компании это «большее» разное.
сменить компанию проще простого
Так в этом и проблема, что pr появляется во всех компаниях. Их нет только в стартапах, которым реально нужен результат, как было указано тут в одном из комментариев.
Степень нечестности ревью, просто пропорциональна рациональности разработчиков: если люди ведутся на манипуляцию, она будет выгодна компании, а если не ведутся тогда компания сделает себе хуже т.к. вообще потери от ухода разработчика, который проработал год и более довольно большие.
Вот с этим полностью согласен, но мой опыт показывает, что как раз таки разработчики ведутся, т.к. для этого включена очень мощная пропагандистская машина.
— зависит от ПМ-а НЕТЕХНАРЯ, который твою работу никак оценить не может т.к. просто не понимает в ней ничего -> решают софт скиллы
Я даже сталкивался с вариантом типа
— А у нас тут ревью, на вас вон тот ПМ жаловался, что плохо работаете.
— а ниче что это было полгода назад, если не год, и я с ним никогда не разговаривал даже?
Кроме того тебе объясняют, что всё зависит исключительно от тебя, не от системы. В учебниках по HR так и пишут в наставлениях по ведению perf.review: "First say some icebreakers… loads of b*llshit… at the end an employee should feel everything is revolving around him."
"Fundamentals of Human Resource Management" by Diane Arthur.
Вот ещё характерная цитата оттуда:
"The existence of unions within a company automatically means added responsibilities for those in the human resources arena. For example, labor relations experts skilled in the art of contract negotiations and preventing further unionization are essential."
Тут как бы подразумевается, что сотрудники HR — не часть labor, а нечто протовостоящее ему. Хотя ведь тоже наёмные работники.
Тут как бы подразумевается, что сотрудники HR — не часть labor, а нечто протовостоящее ему. Хотя ведь тоже наёмные работники.
Так оно и есть. Ведь есть те, кто делает работу без которой не будет продукта или услуги, а hr это по сути часть руководства. Причём что с ними, что без них уже имеющиеся сотрудники работают абсолютно так же. Т е отдел hr нужен руководству компании для взаимоотношений с сотрудниками, о чём собственно и название отдела, но не самим непосредственным исполнителям... В принципе исполнители вполне могут договорится делать работу не только без hr, но и вообще без директора (обычно он и так не участвует непосредственно. Крамольная мысль то какая, за такое точно уволят...))
Пару дней назад на HN была соответствующая дискуссия на похожую тему (время подошло, у всех сейчас эта хрень в календаре). Позволю себе скопировать сюда лучший комментарий на мой взгляд:
A good friend of mine once told me, "I often feel like my purpose as an engineer is to give business dudes a reason to have meetings."
That statement always rings true to me during performance review and goal setting seasons. This stuff is mostly bullsh*t. "Goals" — as described by OP — don't exist at small startups. It's clear what the goal is: build a product, get customers, grow revenue, etc. The goals of a FAANG company aren't different. If "goals" were actually important, they'd exist ate startups too. Because they don't, it's pretty clear that the pessimistic comments in this thread are correct: they give HR a concrete way to avoid legal liability when it comes to raises/bonuses/promotions/terminations.
It's totally frustrating. I understand OPs sentiment. Unfortunately, the only way to avoid this red-tape nonsense is to join a startup.
Я могу понять, почему performance review нужны в американских компаниях — и потому я в US ни ногой. Но в российских реалиях (да и в европейских тоже) они просто карго-культ. Пока ещё.
Вообще, вегед очень хорошо умеет в политику, но не очень в код. Впечатления от работы с ним у меня так-себе…
Верстальщики (раньше так в яндексе называли фронтендеров), они как коты, от безделья
С тех пор всё меньше обращаю внимание на премии, и всё больше на фиксированный оклад.
Как мне говорили некоторые руководители из Я, "если я у вас Чудак, то от меня ни одна система ревью не спасёт". Это была смешная часть.
А часть серьёзная в том, что я не очень помню свои ощущения от ревью в Я. Но вот в текущей немецкой компании есть процесс ревью и роста. И весь этот процесс построен, как кажется мне и многим уходящим из компании, только ради того, чтобы люди росли медленнее. Вернее, чтобы они делали всё, чтобы вырасти, но поощрять их за это было не обязательно. "Ведь у тебя с хард-скиллами и так всё было нормально очень давно. Мы ждём от тебя последней звёздочки вот в этой графе, а без этого тебе не получить следующий грейд".
Формальная процедура, никакой ламповости и нейронной сети распределенной в мозгах менеджеров.
Участники: HR в роли секретаря/модератора, ПМ, лид, разработчик. Для лида — HR собирает фидбек от членов команды и анонимизирует его. Перед процедурой все участники заполняют таблицу оценок активностей. HR сводит все в один документ и во время процедуры обсуждаются оценки. Результирующая оценка идет в итоговую колонку. Так что обсуждаются в основном расходящиеся оценки. В колонку итоговых комментов вписываются договоренности достигнутые на митинге.
На выходе все участники получают копию заполненной таблицы. Так что сам по себе процесс — просто возможность привести оценки руководителя и подчиненного к общему знаменателю и зафиксировать при участии независимой третьей стороны.
Если я правильно помню, таблицы активностей для профилей не менялись много лет или менялись минимально. Активности были усредненные — типа кодинг, код ревью, участие в митингах с заказчиками и т.п. При повышении грейда добавлялись детали — джуну было достаточно сидеть на митинге пассив листенером, мидлу уже надо было активно участвовать, синьору неплохо было бы подготовить агенду, модерировать митинг и выслать митинг минетс вдобавок к активному участию для получения высшей оценки.
Насколько я понимаю, присутствие HR и создание в процессе артефакта — выступало сдерживающим фактором для всяких нехороших вещей.
Готовые таблицы для следующего грейда — позволяли подготовиться к промоушину, показывая, что надо будет делать на регулярной основе после повышения.
Два вопроса по этой системе:
- Таблица была видна всем? То есть каждый мог посмотреть результат коллеги?
- Кроме повышения принимались ли другие решения на основании ревью?
Аппрайзал — не был единственным фактором для повышения. Там еще были требования по уровню английского, knowledge evaluation и что-то там еще.
В случае Яндекса, на основании доклада Сергея, целью pr является не просто определить качественный рост сотрудника (на следующую должность например), но и сравнить людей. Например, сотрудник X работает лучше сотрудника Y на 20%, поэтому ему стоит дать премию на 20% больше. Судя по вашему описанию, ревью было одним из многих факторов для повышения, поэтому вы не заметили негативного фактора.
А вот когда ваш коллега запилил новый js фреймворк просто потому что у него была такая задача, а вы фиксили баги по этой же причине, но повышение и максимальную премию дают коллеге — вот тогда бы вы заметили.
У нас все гораздо хуже: ты должен сам себе поставить некие цели на отчетный период и их достичь.
Что это за цели такие никто не знает. От «верхнего уровня» менеджмента есть конечно общие указания как сделать чтобы все было хорошо, но в реальности на уровне разработчиков это все ни о чем и сводится к тому что «с потолка» нарисовал и согласовал с непосредственным руководителем — с тем и живем.
Особенно весело получилось в первый раз после введения этой системы. Все такие радостные и «накаченные» HR-ом после презентации всего этого наствили там себе всяких адекватных целей и задач, по типу «сдать фичу XXX в срок YYY», «пофиксть ZZZ багов» ну и что-то в таком-же духе. Все так нормально и вполне со всех сторон хорошо. А потом вдруг случился «упс», когда внезапно заказчик решил отказаться от услуг нашей конторы и все эти цели дружно вылетили в трубу. С тех пор я ставлю только какие-нибудь формальные планы, которые с бюрократического на человечекский примерно переводтся в двух словах как: «хорошо делать свою работу».
Приколы и там были — ну типа новый менеджер где-то повыше хочет внедрить риск менеджмент и собирает со всех вплоть до джунов возможные риски. Думаю самый популярный вариант был попасть под автобус. Или хочет получать на почту ежедневные отчеты от каждого работника. В аутсорсере. Ему наверно через пару месяцев рассказали, как формируются счета для киентов и где можно посмотреть дейлики.
В статье он рассматривался в контексте «справедливого распределения благ».
Во-вторых, заставлять программистов делать что-либо нет возможности — уйдут в другую команду/компанию. Зато предолжение поучаствовать в проведение демки чтобы прокачать активность «проведение презентаций» в аппрайзале — вполне себе аргумент для джуна, чтобы преодолеть первоначальную неуверенность.
В-третьих, это и для руководителя метод контроля — когда находится такой себе синьер-помидор формирующий из зеленого джуна узкого исполнителя самых нелюбимых активностей. И забивающего болт на дальнейшее развитие этого джуна. А на аппрайзале джуна — это прекрасно видно.
Наверняка есть и другие варианты.
Как я понимаю процесс — HR не должен выносить оценку. Только модерировать общение, помогая сторонам договориться и фиксировать достигнутые договоренности. Ну а при реальном конфликте решать его будут именно HR — двигая людей между командами или рекомендуя увольнение.
Интересная статья. Было приятно читать. Спасибо.
По поводу непрозрачности и отсутствия пользы (вреда) не соглашусь:
- мне как разработчику важно знать и понимать как и что мне делать что бы расти профессионально и материально. Если в компании нет процессов которые бы четко эти моменты описывали я это учитываю в плане своего развития и смотрю в перспективу нескольких лет, что придется искать новую компанию. Если процессы есть, но модель не описана или имеет неявные результаты, то стоит заявить о своих желаниях. В плане профессионального роста, каждый инженер может найти почти все необходимые материалы чтобы составить карту компетенций, определить свой реальный трейд и найти себя на пути развития джун-мидл-сеньер-лид-сто и тд. Далее при понимании несоответствия своего уровня и текущего грейда, идём на рынок и находим правильную компанию которая также вас оценивает. С деньгами тоже самое. Если на рынке есть предложения лучше, почему бы ими не воспользоваться? Другое дело как инженеру вам хочется получить признание за заслуги и усилия, результаты труда. Тогда никакие перформанс ревью не помогут. Можно делать опенсурс и зарабатывать звёзды от других разработчиков, производя реальную пользу, которую на текущем месте никто не может оценить или такую пользу не придумать если ты не в мейнстриме.
- мне как руководителю нужны инструменты которые бы помогали разделять материальную часть на людей действительно заслуживающих этого, что бы подогреть интерес, чтобы не ушли, чтобы был пример и тд. Собирать оценку за год или полгода мне нужно отмечать моменты когда инженер сделал полезную вещь для команды, проекта, компании, когда от него этого не ожидали. Собирать оценку удовлетворенности от заказчика. Собирать оценку соответставия заявленным умениям в том числе выполнению целей карты развития самого инженера и тд. Далее можно делать своднную статистику что у инженера получается, а что нет. Все эти аспекты обсуждаются на ревью. Они достаточно прозрачные. Что бы не ошибиться с решением я могу попросить оценить инженера по сводным данным другого руководителя. Если инженер хромает или не мотивирован, или страдает синдромом студента и пытается за неделю до ревью наверстать что-то, значит будут соответствующие выводы. Если видно что инженер делает 150% того что то него требуется, будут сделаны соответствующие выводы.
Многие описанные вещи выглядят как история получившаяся на эффекте "выжившего". Не обязательно во всех компаниях происходит так как это происходило у вас. Где то бывают перекосы и перегибы. Как практика сама по себе, перформанс ревью не несёт вреда. Любой инструмент можно испортить если не понимать как правильно его готовить.
Потом вы сами принимаете условия игры, также как и можете предложить свои.
Собирать оценку за год или полгода мне нужно отмечать моменты когда инженер сделал полезную вещь для команды, проекта, компании, когда от него этого не ожидали
Если видно что инженер делает 150% того что то него требуется, будут сделаны соответствующие выводы
Честно говоря, выглядит как плохо поставленные процессы. Что значит сделать то, что не ожидали? У вас так плохо с планированием, что вы не знаете, что вам нужно? И если это сделал разработчик, почему его стоит наградить, если другие работали по плану и в соответствии с ожиданиями? Такая системя выглядит, как попытка отвести от руководства какую либо ответственность и работать по принципу — давайте соберем вместе нормальных ребят, а они что-нибудь нам сделают.
Многие описанные вещи выглядят как история получившаяся на эффекте «выжившего».
Об этом в статье упоминалось неоднократно, но других способов нет, т.к. процесс закрытый, а там, где это было возможно, я оставлял ссылки на публичные данные. Поэтому стоит уточнить, что именно вам кажется ошибкой выжившего.
Что значит сделать то, что не ожидали? У вас так плохо с планированием, что вы не знаете, что вам нужно?
Если Вам интересно то есть роадмап и майлстоуны, есть цели краткосрочной и долгосрочной перспектвы. Есть спринта. Есть цель спринта. В рамках ежедневной работы вы можете делать задачи и делать их в срок. Быть не больше и не меньше середнячком. Если постараться то можно в процессе текущих задач также настроить CI получше, обновить либу, запилить прототип сервиса, зафиксить проблему рядом с тем местом где вы делали правки (а не забивать на нее), покрыть тестами то что не ложилось в задачу и тд
Уже не помню в какой книге (что-то про профессионального программиста) приводили пример человека который внимательно слушал проблемы, озвученные своим руководителем и постепенно решал их. Таким образом когда о таких проблемах заговаривали снова, выяснялось что они уже были решены. Это и есть быть проактивный. Не быть посредственностью, середнячком.
И если это сделал разработчик, почему его стоит наградить, если другие работали по плану и в соответствии с ожиданиями?
Работать по плану это значит отбивать те деньги которые и так тратиться на сотрудника. Если зарплата «по рынку» зачем платить больше если человек не стримится ни к чему и плывет по течению. Все пытаются экономить. Такая модель будет работать до тех пор пока сотрудник создаёт добавочную стоимость своей работой. Когда выйдет новый фреймворк или работа упростится так что ее можно будет делать в два раза быстрее и у сотрудника не будет возможности перенять такой опыт он станет нерентабельными. Нужно стараться делать добавочную стоимость своей работой сверх привычного уклада, тогда работодатель будет ценить такой вклад
что именно вам кажется ошибкой выжившего
указание трёх компаний с их процессами как личного опыта. В мире миллионы компаний и везде по разному.
сли постараться то можно в процессе текущих задач также настроить CI получше, обновить либу, запилить прототип сервиса, зафиксить проблему рядом с тем местом где вы делали правки (а не забивать на нее), покрыть тестами то что не ложилось в задачу и тд
Ну так помещайте эти работы в ваш Роадмэп, а не надейтесь, что какой то сотрудник принесет вам это на халяву.
Уже не помню в какой книге (что-то про профессионального программиста) приводили пример человека который внимательно слушал проблемы, озвученные своим руководителем и постепенно решал их
Руководитель, в данном случае, манипулятор.
проактивный
Это понятно, что когда у вас в планировании хаос, или вы намеренно не включаете какие то задачи в план, потому что жалко времени, вам нужны проактивные. Вообщем, вы доказываете только мой тезис о том, что pr — инструмент эксплуатации.
Работать по плану это значит отбивать те деньги которые и так тратиться на сотрудника. Если зарплата «по рынку» зачем платить больше если человек не стримится ни к чему и плывет по течению.
Ну так ставьте в план те задачи, которые способствуют повышению для сотрудника, а не ждите «чуда»
Такая модель будет работать до тех пор пока сотрудник создаёт добавочную стоимость своей работой
Если он ее не создает, тогда у меня для вас плохие новости — ваш бизнес скоро обонкротится. Другими словами, работник не может не создавать добавочной стоимости, иначе ваш бизнес не будет прибыльным.
Когда выйдет новый фреймворк или работа упростится так что ее можно будет делать в два раза быстрее и у сотрудника не будет возможности перенять такой опыт он станет нерентабельными
Как профнепригодность связана с мотивацией? Если вы действительно заботитесь о развитии своих сотрудников — ставьте для них такие задачи (если они сами с этим согласны), а не ждите от них роста.
Нужно стараться делать добавочную стоимость своей работой сверх привычного уклада, тогда работодатель будет ценить такой вклад
Ну вот от такого отношения и появляется pr где человек пишуший фреймворк превозносится над человеком, исправляющий баги.
указание трёх компаний с их процессами как личного опыта. В мире миллионы компаний и везде по разному.
Кроме этого я опирался на публичный доклад Сергея Бережного и отзывы на процесс pr в яндексе из интернета.
мне как разработчику важно знать и понимать как и что мне делать что бы расти профессионально и материально
мне как руководителю нужны инструменты которые бы помогали разделять материальную часть на людей действительно заслуживающих этого, что бы подогреть интерес, чтобы не ушли, чтобы был пример и тд.
так вы разработчик или руководитель? Думаю что имеет смысл высказываться от лица кого-то одного, а второй стороне предоставить самим решать что для них лучше.
так вы разработчик или руководитель?
я был разработчиком и прошел всю эту кухню. Сейчас я становлюсь как руководитель
Если видно что инженер делает 150% того что то него требуется, будут сделаны соответствующие выводы.
Нужно стараться делать добавочную стоимость своей работой сверх привычного уклада, тогда работодатель будет ценить такой вклад
это компании выгодно чтобы все так думали. Можно сменить место работы и получить даже больше бенефитов. Вот эти «ты главное херач а мы потом оценим» это ерунда. Я лично видел людей которые херачили, и сам таким был, а повышали других, и прямо на одном и том же проекте работали люди один из которых херачил, а второй делал в 2 раза меньше, а получал в 2 раза больше. Да и вообще, в мире много людей которые много и усердно работают, и что, они все стали богатыми?
Может раньше так и было, человек приходил в компанию молодым после вуза, и работал там пока аж не сдавал бэйджик уже пенсионером. Компания давала рост, зп, и тд. Сейчас парадигма поменялась. Сейчас отношения компаний и сотрудников стали кратковременными, и ни сотрудники ни компании не хотят вкладываться в друг друга.
Когда раб становится рабовладельцем
отличная аллегория!
Все же вопрос рождается сам собой: откуда берутся руководители? откуда появляются лиды? почему разработчики становятся синьорами? Как Рокфеллер становится Рокфеллер? Как Тинькоф становится Тинькофф? Федор Овчинников становится Додо Пиццей?
много людей которые много и усердно работают, и что, они все стали богатыми?
мне не известны другие способы кроме того что бы работать больше. Потому что везение это когда из 100 случаев два выигрышных и я пробовал 99. Если комментарий с точки зрения богатства, именно про деньги, то нужно ставить в приоритет зарабатывание. Например, когда у вам нужно заработать денег, вы можете работать программистом и пытаться растить экспертизу что-бы увеличивать свою зарплату. Можно поступить по другому и можно работать программистом и играть на бирже что бы реально зарабатывать. Можно взять дополнительную работу и клепать приложеньки или сайтики или что угодно, а можно найти человека который сделает это за тебя и ты получишь разницу за счет правильной организации процесса. В первом случае ты не масштабируешся и всегда будешь работать ради работы, а во втором можно экстраполировать подход и зарабатывать. Все зависит от того какой смысл ты вкладываешь. От смысла зависит то какой шаг делать дальше
видел людей которые херачили, и сам таким был, а повышали других
пробовали проанализировать почему так происходило?
мне не известны другие способы кроме того что бы работать больше. Потому что везение это когда из 100 случаев два выигрышных и я пробовал 99. Если комментарий с точки зрения богатства, именно про деньги, то нужно ставить в приоритет зарабатывание. Например, когда у вам нужно заработать денег, вы можете работать программистом и пытаться растить экспертизу что-бы увеличивать свою зарплату. Можно поступить по другому и можно работать программистом и играть на бирже что бы реально зарабатывать. Можно взять дополнительную работу и клепать приложеньки или сайтики или что угодно, а можно найти человека который сделает это за тебя и ты получишь разницу за счет правильной организации процесса. В первом случае ты не масштабируешся и всегда будешь работать ради работы, а во втором можно экстраполировать подход и зарабатывать. Все зависит от того какой смысл ты вкладываешь. От смысла зависит то какой шаг делать дальше
medium.com/@olivia.s.biggs30/a-third-of-americans-believe-theyll-become-millionaires-but-80-of-millionaires-have-inherited-562104920f50
Очень жаль, что современная пропаганда вдолбила мысль о том, что нужно стараться вытянуть билет в лотерию, вместо командной работы. Ну, это и понятно — сплоченная команда просто перестанет поддаваться на пропаганду, и тогда руководителям придется руководить, а не ждать халявного профита.
Согласен со статьей и в ходе комментариев поймал мысль с везением, которая потом проскачила в ютубчике https://youtu.be/iqgNOcfBSTY на Дарт Вайдер канале. Все же не имея наследства есть шанс. Также от обратного если сидеть и перестать стараться точно не получится ничего
отличная аллегория!
не хотел как-то оскорбить, потому вытер ) Извините. Я имел в виду что покорный человек «в системе» мыслит только паттернами покорности системы и игры по правилам которые система (те кто похитрее) навязывает, вместо того чтобы начать мыслить вне рамок
Все же вопрос рождается сам собой: откуда берутся руководители? откуда появляются лиды? почему разработчики становятся синьорами? Как Рокфеллер становится Рокфеллер? Как Тинькоф становится Тинькофф? Федор Овчинников становится Додо Пиццей?
ну вы сами и ответили ниже, вот
Можно взять дополнительную работу и клепать приложеньки или сайтики или что угодно, а можно найти человека который сделает это за тебя и ты получишь разницу за счет правильной организации процесса
вы же сами это и сказали: нужно менять парадигму, а не просто «заваливать мясом» и работать больше. Я думаю что те кто пробиваются наверх, думают не о том как работать больше, а наоборот — думают о том как не работать.
Потом, допустим вы начинаете пахать больше, но то же делают и другие. Пусть не все, конечно, но вы всё равно ввязываетесь в гонку.
пробовали проанализировать почему так происходило?
готов послушать ваш вариант
Я имел в виду что покорный человек «в системе» мыслит только паттернами покорности системы и игры по правилам которые система (те кто похитрее) навязывает, вместо того чтобы начать мыслить вне рамок
В точку!
Наткнулся на видос про везение и отношение везунчиков к остальным. Про то как везунчики после везения принижают заслуги и упорство других которым не повезло https://youtu.be/iqgNOcfBSTY видос около 10 минут, рекомендую. И все же если перестать стараться то точно никуда не вырвешься в системе ты или нет
на пути развития джун-мидл-сеньер-лид-сто и тд.
Немного не в тему, но у вас тут случился «перескок» с технической ветки развития на управленческую.
Не спорю, что многие управленцы именно так и «рождаются», и возможно многие разработчики именно к этому и стремятся, но это скорей от недостатка нормальных управленцев, чем от хорошей жизни. Я лично всегда сичтал что это порорчная практика, т.к. чаще всего при таком перескоке получается яма: мы теряем хорошего технаря (а плохого не «повысили» бы) и приобретаем херового руководителя (т.к. опыта не так чтобы и много).
Обычно техническая ветка идет в архитекторов и т.п.
Я лично всегда сичтал что это порорчная практика, т.к. чаще всего при таком перескоке получается яма: мы теряем хорошего технаря (а плохого не «повысили» бы) и приобретаем херового руководителя (т.к. опыта не так чтобы и много).
а кого тогда брать в управленцы? Выпускника факультета психологии или общепита?
да, бывает так что хороший технарь не становится хорошим руководителем, может и нередко. Но кто сказал что из нетехнарей хорошие руководители?
я видел немало примеров руководства менеджеров-нетехнарей. Ничего хорошего. Решения принимают люди которые не понимают последствий этих решений, ориентируясь на то похвалил клиент на митинге, или не похвалил, если у него нет настроения.
тех лид :) ну и до сто может быть архитектор
Спасибо, статья огонь.
Я не совсем по технической специальности, работаю геймдизайнером в крупной международной компании последние пять лет, но с процессом performance review знаком не понаслышке и описанные Вами проблемы мне очень хорошо знакомы. Постараюсь здесь вкратце обрисовать то, с чем довелось столкнуться на собственном опыте.
Во-первых, это, конечно, полная непрозрачность и субъективность оценивания. Сами по себе параметры, по которым оценивается сотрудник, доступны для обозрения, но сформулированы предельно абстрактно. Оценки выставляются лидом и продом проекта, на котором работаешь. Насколько мне известно, никто не выделяет им под это специальных часов, а поскольку они обычно и так по уши загружены задачами, то оценки могут выставлять в последний момент. Объективность их оценивания никем не проверяется и не контролируется, результаты оценивания недоступны для других членов команды.
Во-вторых, система оценивания базируется на использовании унифицированных параметров и никак не учитывает специфику проекта и обязанности испытуемого. Например, на прошлом проекте я работал нарративным дизайнером (возился со сценарием, текстами диалогов, постановкой кинематографичных сценок и т.д.). Но одним из параметров, по которым выставляется оценка, были навыки дизайна уровней. Понятное дело, что на этом проекте у меня просто не было возможности проявить своих навыков в этом деле — тем не менее, мой лид оценил их на "тройку". Когда я спросил, что именно он оценивал, он не смог выадать сколько нибудь внятного ответа. Последний год я работаю на проекте, где в основном занимаюсь технической работой по перенесению данных из одной таблицы в другую. Уже предвкушаю, как мои руководители будут оценивать мои профессиональные навыки на основании результатов этой деятельности ))))
В-третьих, когда дело доходит до самого собеседования, на котором тебе зачитывают результаты, тебя ожидает систематический газлайтинг со стороны HR. Недоволен условиями труда на проекте — а ты уверен, что ТЫ сделал все от себя зависящее, чтобы этих проблем не было? Не созданы реальные условия для саморазвития (например, не выделяется время на обучение начинающих дизайнеров) — мы тебе не школа, ты сам должен расставлять приоритеты и уметь правильно распоряжаться своим временем. И так далее. В результате любая критика объективных условий труда с твоей стороны представляется как твоя личная недоработка.
Наконец, в-четвертых, непонятно как вообще результаты pr влияют на размер зарплаты и влияют ли вообще. В официальных заявлениях HRы студии повторяют, что результаты pr не являются решающим фактором в определении размера заработной платы. Ок, но как-то же они влияют на него? Как-то влияют, но как именно — мы вам не скажем, это определяет сам мэнеджер, когда обращается с рекомендацией о повышении зарплаты к руководству ("объективность" зашкаливает). Но зато скажем, что цель pr (который у нас называется эвалюэйшн) — это "диалог" и "улучшение", и что претендовать на повышение зарплаты по его итогам могут только те, кто не просто "хорошо выполнял свою работу", а "активно улучшал" работу своей команды (что бы это не значило).
А еще с этого года эвалюэйшн производится только по запросу самого сотрудника. То есть, если ты не запрашиваешь — значит, не хочешь идти на диалог с компанией, не работаешь на улучшение, надбавки не заслужил. А если запросил — то еще не факт, что что-то получишь, так как неизвестно, оценят ли результаты твоей работы как "активное улучшение", или же ты просто "хорошо работал".
Такие дела. Еще раз спасибо за статью, она вдохновила меня выписаться наконец )
А еще с этого года эвалюэйшн производится только по запросу самого сотрудника. То есть, если ты не запрашиваешь — значит, не хочешь идти на диалог с компанией, не работаешь на улучшение, надбавки не заслужил. А если запросил — то еще не факт, что что-то получишь, так как неизвестно, оценят ли результаты твоей работы как «активное улучшение», или же ты просто «хорошо работал».
А это, кстати, интересно, что на официальном уровне можно отказаться от ревью. Что они сделают, если вся команда откажется, интересно?)
Не два человека в компании, а шесть!
ну в остальном все верно
@sky2high0 отвечу тебе здесь.
Альтернатива pr следующая:
Классическая схема, когда сам поднимаешь тему о своих вознаграждениях, для сотрудника выглядит более справедливой и выигрышной, чем pr
Если же руководству хочется сделать какое то справедливое вознаграждение, то стоит распределять его:
Для всей команды, индивидуальное вознаграждение соразмерно текущей зарплате
За выполненные задачи согласно плану, а не за результат (требует профессионализма и от руководства компании)
Спасибо.
1. Этот пункт как раз одна из причин появления PR. До PR во многих компаниях (скажем так без открытия NDA) была статистически значимая разница в компенсации как для конкретных людей в рамках одного отдела, так и целых отделов.
Люди все разные, бывают активные "продаваны себя", а есть просто ребята, которые хорошо делают свою работу и сильно себя не пропихивают. Последних довольно просто переманить повышением, и тогда компания теряет отличного кадра из-за недосмотра конкретного руководителя. Ну и есть еще ряд причин почему плохо повышать только тех, кто просит. Можно вспомнить также стат. значимую разницу в компенсации между мужчинами и женщинами. Про это просто тысячи исследований.
Также (говоря про диспропорции между отделами) одни руководители просто чаще и выше поднимали своих подчиненных, чем другие, и объяснить это чем-то кроме индивидуальных особенностей руководителей было сложно.
PR все вышеописанные ситуации сглаживает. Есть и минусы, конечно, но много где решили, что плюсы перевешивают.
2.1. Много где (в т.ч. в упомянутых в статьей компаниях) есть процентные бонусы от текущей зп. по итогам квартала-полугодия.
2.2. Это хорошо звучит на бумаге, но по факту современный крупный проект — это очень сложная система, с кучей неявных зависимостей, а продукт надо пилить прямо сейчас. Часто жертвуют предварительным планированием, в пользу раннего старта работ. Сокращение планирования до разумных пределов я считаю абсолютно нормальным, т.к., как я уже говорил, продукт постоянно меняется, есть куча бегущих в разные стороны команд и поэтому сделать предсказание вида "ну 3 этап будет длиннее предыдущего, т.к. скорей всего нам не успеют вовремя выделить ML-разработчика, также другие команды нафигачат фич и команда тестирования все не будет успевать, а еще в это время команда инфраструктуры может переводить нас на новые балансеры, что увеличит цикл разработки".
Если аппелировать же к "профессионализму руководства", то это тупиковый путь. Искать виноватых в сложных проектах — это просто тратить кучу времени в пустоту. Куда эффективнее пытаться улучшить процессы на простых и понятных участках, типа "скорость выкатки новой фичи с т.з. разработки" или "среднее время зависания задач в статусах "готово к тестированию" и "тестируется".
По сути вы сейчас высказываете позицию Сергея Бережного, которую я разобрал. Короткий ответ - pr не сглаживают ситуацию, потому что:
Решение о премировании все равно остается за руководством, поэтому решения о любимчиках все так же актуальны
pr усугубляет положение разработчиков "на поддержке" или тех, кто занимается рутинной, постоянной работой
Решили применять pr потому что это выгодно компании и позволяет выжимать максимум - и Яндексе это прям просто очень хорошо демонстрирует, с его ниже рынка зарплатами и постоянными обещалками на каждом ревью, все таки зп привести к рыночной.
Ответ
Вообще не понял, причем тут процентный бонус
Ну вы сейчас подтверждаете только тезис о том, что руководству проще и выгоднее не планировать и выжимать из сотрудников результат путем введения pr
Вообще вся ваша аргументация строится на проблемах руководства. В статье основная мысль в том, что для руководства этот инструмент конечно выгоден, а вот сотрудникам, особенно если им не повезло попасть в рутинные проекты, выгоды от pr нет никакой.
Да, вы правы, я во многом транслирую позицию Сережи, т.к. долго работал в Я и все это прочувствовал с обоих сторон (разработчик и руководитель).
Решение о премировании все равно остается за руководством, поэтому решения о любимчиках все так же актуальны.
Это как раз решается на этапе калибровки. Решения всегда принимаются коллективно. То есть минимизируется фактор "любимчика" одного конкретного руководителя.
pr усугубляет положение разработчиков "на поддержке" или тех, кто занимается рутинной, постоянной работой"
Абсолютно в любом проекте есть место для улучшений. Ни разу не видел обратного. Было бы желание. По крайней мере за 7+ лет в Яндексе не видел обратных ситуаций.
Решили применять pr потому что это выгодно компании и позволяет выжимать максимум...
Вопрос компенсации, конечно, важен и это много обсуждали. Вкратце, Яндекс дает большую компенсацию в горизонте 4-5 лет за счет акций и их постепенного вестинга. Также в Я понятно как расти, что очень важно.
Вообще не понял, причем тут процентный бонус
Вы пишите, что надо "Для всей команды, индивидуальное вознаграждение соразмерно текущей зарплате". Процентный бонус — это бонус, который дается как процент от зп. То есть если ты молодец — вот тебе 15% от твоей зп, это покрывает аругмент "соразмерно текуще плате".
Ну вы сейчас подтверждаете только тезис о том, что руководству проще и выгоднее не планировать и выжимать из сотрудников результат путем введения pr
Нет :) Я объяснил, почему это не работает (дотошное планирование) и что делается вместо.
Возможно, мы имеем в виду разный контекст. Я говорю про большие проекты с 150+ разработчиками и 1000+ внешних коллег.
Решения всегда принимаются коллективно
Коллективно руководством. И какой смысл одному руководители вмешиваться в дела другого руководителя и следить за его объективностью? Более того, другой руководитель вообще понятия не имеет о нюансах разработки в другом отделе, поэтому решение все равно, по факту, выносится руководителем.
Абсолютно в любом проекте есть место для улучшений. Ни разу не видел обратного. Было бы желание. По крайней мере за 7+ лет в Яндексе не видел обратных ситуаций.
Опять подтверждаете мой тезис, что как руководитель вам проще ждать, что кто-то из работников принесет вам улучшение, а вы потом посмотрите, заслуживает это премирования или нет. При этом текущие задачи никто не отменял, и естественно человек будет перерабатывать, чтобы привнести вам улучшение. В итоге, pr отличный инструмент выжимать максимум из своих сотрудников.
Вопрос компенсации, конечно, важен и это много обсуждали. Вкратце, Яндекс дает большую компенсацию в горизонте 4-5 лет за счет акций и их постепенного вестинга. Также в Я понятно как расти, что очень важно.
Это при условии, что человек с вашими задачами, во первых, не выгорит, а во вторых, дорастет до ваших ожиданий. Но по факту с такой системой вам выгоднее, чтобы он через года 3 уволился, потому что в этом случае вам удалось выжать из него максимум, платя при этом минимум.
Вы пишите, что надо "Для всей команды, индивидуальное вознаграждение соразмерно текущей зарплате". Процентный бонус — это бонус, который дается как процент от зп. То есть если ты молодец — вот тебе 15% от твоей зп, это покрывает аругмент "соразмерно текуще плате".
Не ты молодец, а команда молодец - в этом качественное отличие от того, что я предлагаю.
Нет :) Я объяснил, почему это не работает (дотошное планирование) и что делается вместо.
Все правильно, дотошное планирование не нужно, потому что выгоднее занести плетку в виде pr над каждым сотрудником и собирать плоды их работы раз в полгода. Действительно, это выгодно руководству, собственникам компании, но не ее сотрудникам.
При этом текущие задачи никто не отменял, и естественно человек будет перерабатывать, чтобы привнести вам улучшение.
Не надо перерабатывать. Надо так: видишь возможность сделать лучше в проекте, собираешь данные (а это, правда, немного минут в день, но можно долго ждать ответов), что измениться, если это поправить. Готовишь предложение вида "если сделать это, будет вот так вот". Если все правильно понял и команда "купила", то тебе выделят какое-то количество рабочего времени на твоей проект. Вообще хорошо, если работы там, например, на пару человек и это так важно, что тебе part-time дают других коллег.
Дальше это делаешь, и под конец будет тебе плюшка за инициативность, вклад, кооперацию и пр.
Все правильно, дотошное планирование не нужно, потому что выгоднее занести плетку в виде pr над каждым сотрудником и собирать плоды их работы раз в полгода. Действительно, это выгодно руководству, собственникам компании, но не ее сотрудникам.
Экий вы фантазер :) Я же говорю, вы хотите не то чтобы невозможного, а просто откровенно вредного для всех. Или у вас есть живые примеры того, что вы описываете? Был бы рад ознакомиться. Допускаю, что я просто за 13+ лет в ИТ не все еще видел :)
Не надо перерабатывать. Надо так: видишь возможность сделать лучше в проекте, собираешь данные (а это, правда, немного минут в день, но можно долго ждать ответов), что измениться, если это поправить. Готовишь предложение вида "если сделать это, будет вот так вот". Если все правильно понял и команда "купила", то тебе выделят какое-то количество рабочего времени на твоей проект. Вообще хорошо, если работы там, например, на пару человек и это так важно, что тебе part-time дают других коллег.Дальше это делаешь, и под конец будет тебе плюшка за инициативность, вклад, кооперацию и пр.
Да, обычно эти предложения заканчиваются - отличная идея, вот когда сделаете ВСЕООО, можем вам выделить рабочее время. Это просто утопия, что вы описываете, именно поэтому каждый второй комментарий на отзывах о работе в яндексе - о несправедливом pr и переработках
Экий вы фантазер :) Я же говорю, вы хотите не то чтобы невозможного, а просто откровенно вредного для всех. Или у вас есть живые примеры того, что вы описываете? Был бы рад ознакомиться. Допускаю, что я просто за 13+ лет в ИТ не все еще видел :)
Вредного для всех? Вы так и не сказали, чем классическая схема плоха для сотрудника, а на аргумент с планированием сказали, что это сложно для руководства.
Планирование встречается в компаниях, я несколько раз встречал и там проблема с переработками не стоит так остро, как в том же яндексе.
Да, обычно эти предложения заканчиваются - отличная идея, вот когда сделаете ВСЕООО, можем вам выделить рабочее время. Это просто утопия
Я описал свой опыт. Да, не всегда мои предложения проходили, и мне не выделяли ресурсов, но иногда проходили и помогали мне расти как в компании, так и личностно. Жаль, что у вас иной опыт Но вас же никто не держит на вашем месте, правда?
Вы так и не сказали, чем классическая схема плоха для сотрудника, а на аргумент с планированием сказали, что это сложно дляруководства.
Я бы уходил бы от этого противопоставления "дворяне и холопы", это непродуктивно на мой взгляд. Любая дихотомия в целом вредна.
Agile схема (в противовес классической) хороша в первую очередь для бизнеса. Уменьшает time to market. Тут жешь, кто первый того и тапки, тот собрал основную массу сливок. А если бизнесу хорошо, то и сотрудникам хорошо во всех планах. Если в вашей компании иначе, опять-таки, никто вас там насильно не держит :) Поверьте, есть нормальные в этом плане места.
я несколько раз встречал
Расскажите, пожалуйста, подробнее. Как это выглядит? О чем проект, какой размер, сколько людей задействовано, какие артефакты на выходе проектирования, сколько это занимало, кто привлекался? Я допускаю, что так бывает, но уверен, что это не тот подход, который подходит для всех проектов. Интересно послушать про такой опыт.
Перенес комментарий
Почему ты не будешь доволен результатами твоего performance review