Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Как происходит performance review в инженерной команде

Я Software Engineer и Tech Lead в компании Railsware уже 8 лет. Последние несколько лет в список моих обязанностей входит найм, аллокации, а также поддержка и проведение performance review процесса для инженерной команды.

Каждой инженерной команде нужен способ оценивания ее участников. Он необходим для поддержки карьерного роста, прозрачности зон развития и справедливой компенсации.

В моей статье речь пойдет о том, как мы строили и продолжаем совершенствовать модель оценки инженеров в Railsware — продуктовой студии с командой в 100+ человек. Нашему подходу уже более 7 лет. Он менялся вместе с развитием компании, усовершенствованием процессов и появлением новых ролей.

Значительная часть дохода компании распределяется на инвестиции в команду и в продукты. Существует связь между доходами бизнеса и компенсацией: чем больше доход, тем выше уровень компенсации. И наоборот, рост экспертизы инженерной команды напрямую влияет на успех и доход всей компании. С годами мы выработали свою модель ежегодного performance review, в основе которой лежит эта взаимосвязь.

Несмотря на сложность процесса и немалые затраты ресурсов, правильно построенная система оценки — это весомый вклад в развитие команды и бизнеса в целом. В Railsware инженеры остаются в компании в среднем 5 лет, а для поддержания этого показателя нужны прозрачные возможности роста.

Процесс

В инженерных компаниях бывает несколько видов performance review процесса. Основные отличия в том, кем проводится review (менеджером или командой), как часто и по какой шкале проходит оценка.

В Railsware мы давно осознали, что оценивание инженеров одним менеджером достаточно субъективно. Один человек может быть предвзятым, не видеть всей картины, не знать фидбэка других членов команды. Исходя из этого решили остановиться на модели peer review, при которой оценка каждого инженера основывается на отзыве других инженеров. Engineering Management команда выступает в этом процессе модератором.

Мы выстроили матрицу основных навыков, компетенций и зон ответственности в Product Engineering командах. Это инженерные команды, работающие без Project Manager’ов и отвечающие самостоятельно за процесс разработки, планирование, скоупинг и архитектуру продукта.

Согласно этой матрице, инженеры оценивают коллег, с которыми вместе работали в прошедший период, указывая насколько каждый навык выше или ниже ожидаемого уровня. Оценка всегда должна подкрепляться фидбэком с описанием конкретных ситуаций: что превосходило ожидания или было ниже, как можно было сделать лучше и почему. Таким образом, любое проявление инициативы в командах не остается незамеченным. Ситуации, когда один из инженеров проактивно настроил CI Pipeline, ускорил test suite или же разобрал все узкие места планируемой фичи и помог разбить ее на детальные задачи отражаются в performance review.

Показатели peer review помогают определить, на каком отрезке шкалы роста находится каждый инженер, соответствующий уровень компенсации и на чем стоит сконцентрироваться в дальнейшем.

Результатом performance review процесса является пересмотр компенсации и регулярный фидбэк по карьерному росту каждому инженеру. Компенсация основана не на субъективном мнении одного-двух менеджеров, а на общеизвестной шкале роста в компании и целостной обратной связи.

Матрица навыков

Система оценки инженеров в Railsware представляет собой матрицу навыков. При ее разработке мы преследовали две цели:

  1. Показать пути дальнейшего развития и на что стоит обратить внимание для достижения цели;
  2. Оказать поддержку в карьерном продвижении и создать модель повышения компенсации.

Исходя из потребностей Product Engineering команд и бизнеса, мы пришли к оценке по четырем основным навыкам, каждый из которых включает три категории.

1. Technical Skill — основной инженерный навык, который определяет как широту, так и глубину понимания используемого стека. Сюда входит:

  • Основы программирования — понимание и использование структур данных, паттерны проектирования, рефакторинг, тестирование, Test Driven Development, умение работать с техническим долгом.
  • Глубина знаний — навык работы с основным стеком, сложность и уникальность решаемых задач, опыт улучшения производительности приложений.
  • Широта знаний — знание других подходов, архитектур, баз данных, языков программирования, а также умение их предложить и внедрить в подходящем месте. Одной подписки на Ruby/DBweekly недостаточно, нужно понимать плюсы и минусы каждой предлагаемой технологии, видеть, как она впишется в текущий проект.

2. Productivity. Здесь оценивается продуктивность работы в продукте; как индивидуальная, так и влияние на продуктивность других инженеров в команде. Продуктивность — это далеко не число написанных строк кода в час. Она скорее заключается в качестве и стабильности реализованных решений, следованию принятых в команде практик и ревью кода:

  • Скорость деливери решений, попадание в запланированные сроки или реализация быстрее запланированного. Здесь также оценивается навык разбивать задачу на мелкие и атомарные изменения.
  • Стабильность решений, количество внесенных изменений после ревью, а также умение разблокировать себя и остальных.
  • Скорость входа в новый домен или контекст. Время необходимое, чтобы разобраться с новым стеком или проектом, интерес к новым подходам. Здесь учитывается и помощь другим в изучении нового контекста — написание документации, проактивная работа в паре.

3. Product Contribution. Здесь оцениваются все активности в команде, кроме непосредственно написания кода. В большинстве наших команд нет роли Project Manager. Инженеры, работая напрямую с Product Owner’ом, выстраивают требования задач, проводят планирование и принимают решения о том что, как и когда реализовывать. Инженеры также выстраивают процесс разработки, отвечают за архитектуру приложения, менторинг и онбординг в командах.

Такая структура требует хорошего понимания продукта, пользователей, приоритетов бизнеса и умения управлять техническим долгом. Чем больше инженер берет на себя ответственности и вовлеченности в подобные задачи, тем выше его уровень Product Contribution.

Подробно этот подход описан в статье Product Engineering.

4. Soft skills. Софт скилы — это часто недооцененная или неполноценно понимаемая часть разработки в команде. Многие воспринимают софт скил только как умение договариваться и находить общий язык с другими членами команды. Мы решили разделить его на три равноценные категории:

  • Проактивность и проявления лидерства, которые включают в себя принятие решений, владение задачей от уровня требований до релиза, фидбэк по улучшению процессов разработки и так далее.
  • Коммуникационные навыки и работа в команде.
  • Общий подход к работе, который мы назвали Work Ethic. Здесь оценивается самостоятельность, направленность на результат, надежность, прозрачность в работе. Эта часть софт скила не связана с коммуникационными навыками, но она показывает, насколько инженеру можно доверить самостоятельное решение задачи.

Шкала должна быть понятна всем членам команды с первых дней и отвечать на вопросы: что важно для продукта, для бизнеса, как расти в компании. Поэтому набор скилов и метод проведения performance review детально описываются для всех инженеров в компании, особенно для новичков.

Предвзятость при оценке и фидбэке

В основе объективного review-процесса должна лежать обратная связь, а конструктивная обратная связь требует времени на подготовку.

Фидбэк в процессе performance review должен быть конкретным и детальным. Только в этом случае он будет полезен и пригоден для дальнейшей работы. Поэтому мы выделили две обязательные секции: Goods — что удалось хорошо, To-improves — примеры ситуаций или решений, которые можно было сделать по-другому, с объяснением причин, аргументацией и альтернативным результатом.

При составлении обратной связи и тем более оценке часто возникают предвзятости (Biases), которые мешают объективности. Так проявляется или недостаток информации, или излишняя концентрация на недавних событиях. Дальше я опишу проблемы, которые часто встречаются, и то, как мы их избегаем.

Time Bias

Мы проводим performance review каждые 12 месяцев. Это значит, что принимаются во внимание все результаты, достижения и уровень навыков за прошедший календарный год. Тем не менее часто наблюдается ситуация, когда фидбэк составляется незадолго до самого performance review и в памяти остаются только недавние события последних 1–2 месяцев.

Случается и наоборот — peer-фидбэк составляется на основе ситуации, которая произошла раньше, но явно отложилась в памяти. Один неправильный выбор технологии/паттерна или случай спасения дедлайна одним человеком сильно откладываются в памяти и начинают влиять на все оценки скилов и производительности в будущем. В результате оценка выстраивается на основе уровня и навыков 2—3-летней давности.

Излишняя строгость или снисходительность

Некоторые относятся излишне требовательно к остальным участникам своей команды, критически воспринимая менее приоритетные ошибки. Например, если ваш коллега забыл исправить warning-и линтера перед созданием пулл-реквеста, это еще не повод низко оценивать технический скил в целом.

Другие могут, наоборот, быть слишком снисходительными к недоработкам в команде и пропускать критичные вещи, такие как отсутствие тестов или очевидные performance-проблемы, тем самым завышая оценки всей своей команде.

Важно понимать, к какой группе скилов относится тот или иной contribution, и избегать оценки всех навыков одновременно.

Усреднение всей команды

В любой шкале, когда есть оценка со значением average, часто появляется тенденция усреднять показатели. Это случается, когда у ревьювера недостаточно фидбэка для детальной оценки либо нет желания собирать отзывы.

Здесь проблема не столько в усредненных оценках, сколько в недостатке аргументации и фидбэка. Такие оценки не несут пользы конечным пользователям performance review — инженерам. Оценка average должна подкрепляться списком goods/to-improves, а также иметь обоснование, почему этот навык не above/below average.

Кроме примеров и конкретных рабочих ситуаций, избежать усреднения помогает детально описанная шкала навыков и уровней ожиданий от роли инженера в команде.

Как мы избегаем биасов оценивания

Выстраивание шкалы навыков и сам процесс performance review у нас проводится engineering management командой. Эта команда выступает модераторами во время peer review, помогая другим и самим себе избежать предвзятости оценки.

Review происходит в нескольких группах инженеров по 4–5 человек. Каждый участник выставляет оценку за навык и категорию коллегам, подкрепляя ее фидбэком. После чего в группе выводится финальная оценка методом planning poker, похожим образом как проходит в команде оценка задач в спринт.

Таким образом, все участники review дополнительно модерируют друг друга, уменьшая предвзятость и улучшая общее понимание шкалы навыков.

В итоге оценка от группы людей по общей шкале становится объективней.

Наводящие вопросы помогают прояснить детали описываемых ситуаций, а фидбэк от нескольких участников команды — рассмотреть ситуацию с разных сторон. К каждому пункту матрицы скилов прилагается список вопросов, помогающий детально оценить уровень этого скила. К примеру, если один член команды предложил провести рефакторинг основного участка кода, надо также понимать, как этот рефакторинг объяснили Product Owner’у, как он был спланирован, кто им в итоге занимался и как его реализовали.

Важно детально описать каждый конкретный случай, понять, к какой категории навыков он относится, когда это произошло и исправилась ли ситуация после.

Вывод

Система оценки помогает определить вовлеченность инженера не только в свои проекты и прямые обязанности, но и в жизнь компании. Например, онбординг новичков, участие в сайд-проектах и в развитии команды. Все это влияет на компенсацию.

Что также важно — каждый инженер видит прямую зависимость своей компенсации от проделанной работы.

Подход Railsware — лишь один из примеров, который можно взять на заметку для построения собственной модели. Каждая компания выбирает то, что работает для нее, исходя из целей и потребностей бизнеса. При этом у каждой системы есть свои плюсы и минусы.

Как бы мы не стремились к совершенству, доля субъективности будет всегда. Тем не менее ее величину можно контролировать. Мы находим плюсы описанной модели в том, что она построена на данных и учитывает мнение кросс-функциональных команд, а также делает весь процесс прозрачным.

В результате растет вовлеченность команды в свои непосредственные задачи и в бизнес в целом. Инженеры ощущают себя полноценными участниками создания продуктов, видят результаты своей работы и личные зоны роста, а также мотивированы развиваться внутри компании.

👍ПодобаєтьсяСподобалось7
До обраногоВ обраному8
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

І ще одне питання.
На що власне впливає результати performance review (крім як на надбавку до зп)?

Часть регулярного фидбек процесса. Понимание зон роста, навыков, на которые стоит обратить внимание, дополнительные ответственности/инициативы, которые на себя можно взять.

дополнительные ответственности/инициативы, которые на себя можно взять.

На кой мне это, чем это отличается от надбавки к зп или инициативничать предлагается за бесплатно? Так я себе лучше 2й проектик найду.

Наприклад, є Senior developer, який хоче стати TeamLead або PM

в конторе через дорогу на +500? ))

Productivity. Здесь оценивается продуктивность работы в продукте; как индивидуальная, так и влияние на продуктивность других инженеров в команде. Продуктивность — это далеко не число написанных строк кода в час. Она скорее заключается в качестве и стабильности реализованных решений,

Все-таки незрозуміло, як це оцінюється? У балах (за 10-бальною або 100-бальною школі)?
Як оцінити стабільність і якість всієї роботи, виконаної за рік? Це можуть бути десятки і навіть сотні завдань на проекті.Як це все запам’ятати?

Читай «определённые персонажи в группе могут сдвинуть оценку группы, используя убеждение/положение, или просто факт того, что кто-то голосует солидарно с персонажем, в сторону своей собственной предубежденности».

Такой риск всегда есть, собственно я поэтому и описывал отдельно возможную предвзятость.
Чтобы избежать этого, голосование в каждой группе модерируется engineering management командой. Предубежденность, как и развитый навык убеждения обычно сразу заметны.

Будут ли более сложные системы работать «лучше» и как это «лучше» вообще можно оценить?

Можно сравнить время, затраченное на весь процесс ревью, проанализировать результаты за несколько лет для одних и тех же людей, собрать фидбек команды о процессе ревью и их согласие с результатами.
Мы так и эволюционировали в течении 7 лет в сторону упрощения с сохранением качества/справедливости.
Фидбек должен быть полезен инженеру, для которого проводится ревью, это не процесс ради процесса.

Все-таки незрозуміло, як це оцінюється? У балах (за 10-бальною або 100-бальною школі)?
Як оцінити стабільність і якість всієї роботи, виконаної за рік? Це можуть бути десятки і навіть сотні завдань на проекті.Як це все запам’ятати?

Субъективная общая оценка за весь период по шкале средняя/выше/ниже среднего или сильно выше/ниже среднего. Под оценкой понимается значение с достаточным уровнем аргументации и описанием произошедших ситуаций.
Ревью оценки в группе, фидбек, подкрепляющий оценку и общая шкала минимизируют субъективность.

Само понятие «Продуктивность» включает в себя несколько категорий, о которых выше писал.

Як оцінити стабільність і якість всієї роботи, виконаної за рік?

Вы можете пару раз уронить продакшн или забыть уточнить корнер кейсы своей задачи, в следствии чего несколько раз недооценить работу. Это могут быть единичные случаи, а может происходить регулярно.
Также и наоборот, вы можете заметно быть тем человеком, который регулярно помогает другим в команде быть продуктивным.
Также как и уровень технической экспертизы, на фоне всей инженерной команды можно понять уровень продуктивности каждого отдельного инженера.

Субъективная общая оценка за весь период по шкале средняя/выше/ниже среднего или сильно выше/ниже среднего

А як зрозуміти, що у вашому випадку «середнє»? Хто і як це визначає?

На скільки зазвичай підвищують зп після проходження таких рев’ю? Чи можна розраховувати хоча б на +500/600$?
Якщо ні, який сенс до них готовитись і проходити, якщо можна пройти інтерв’ю в іншу компанію і отримати цей бенефіт?

Думаю, що максимум на який можна розраховувати — 5-7% приросту в рік.
Але якщо це аутсорсинг, то і його можна не отримати, тому що потрібно ще клієнта умовити на підвищення.

100%. Просто перейти через дорогу на проект, где дадут желаемую суму +30%, 50%, а ради даже 15% морочить голову с ревью не стоит того как по мне, та я и сам чудесно понимаю без ревью, чего я не знаю, а что знаю. Тем более , что объективного все равно ты не получишь, а с выводами , что мол плаваешь в никому не нужной фигне или что можно разобрать за недельку, лишь бы сбить ценник

Да, конечно, регулярно происходят повышения и выше.
Если по результатам review видно, что человек оказался underpaid относительно текущего уровня навыков и общего рэнжа компании — его компенсация поднимется на соответствующий уровень.

Якщо ні, який сенс до них готовитись і проходити

Это не тот процесс, к которому нужно «готовиться и проходить», это ведь не экзамен.
Суть в том, чтобы фокусироваться на развитии своих навыков и успешности продукта, над которым работаешь — при этом быть уверенным, что компенсация будет справедливо и соответственно развиваться.
При такой модели пропадает смысл менять компанию только ради $500 прибавки.

При такой модели пропадает смысл менять компанию только ради $500 прибавки.

І часто у вас буває рiчна прибавка «500$» (без зміни рівня девелопера)?

да, каждый performace review process часть команды может получить 500-1000+ прибавку к компенсации.
после ревью у всех компенсация соответствует текущему уровню навыков и дополнительной ответсвенности. при пересмотре мы больше ориентируемся на то, что каждый человек должен получать на текущий момент, а не на разницу в прибавке.

(без зміни рівня девелопера)

мы не используем отдельно прописанные уровни или тайтлы. нет разбиения команды на junior-mid-senior, etc. рост внутри компании осуществляется за счет экспертизы, опыта, или фактического лидерства в отдельной команде.

пример — вы решили лидить часть проекта или разработку отдельной большой фичи, взять ответственность за планирование и релиз. Помимо прямого написания кода, вы больше остальных участвует в организации планирования, помогаете другим разбить фичу на подзадачи и приоритизировать, координирует несколько команд, выстраиваете архитектуру проекта и тд.

в итоге вы занимаете роль Lead Engineer (или техлид) в команде по факту и по уровню своей экспертизы, а не по тайтлу. после performance review это напрямую отражается на компенсации.

его компенсация поднимется на соответствующий уровень.

за чей счёт?

Суть в том, чтобы фокусироваться на (развитии?) ... и успешности продукта, над которым работаешь

это вообще как? здесь в русском то ли «сфокусироваться на развитии успешности» то ли просто «сфокусироваться на успешности» продукта но сильно сути не меняет итого как обычному среднему гребцу «сфокусироваться на успешности продукта над которым работаешь»?

ну как? взять на себя обязанности ба, по, а по вечерам немножко заниматься доменным тестированием;)

я вижу только один смысл во всех этих ревью — дать фидбек человеку в не навязчивой форме, типа — прокачал бы ты немного свой английский или 11ю джаву, а то были непонятки. В остальных случаях ревью это боль.

Чому біль? Отримати фідбек про свою роботу, про те, що можна поліпшити або змінити — це я вважаю дуже сильно допомагає тим, що хоче розвиватися.

дуже сильно допомагає тим, що хоче розвиватися.

а хто не хоче? ))

Хто не хоче, просто відмовтеся від performance review. Скажіть, що вас і так влаштовує ваша зарплата.

просто відмовтеся від performance review.

а якщо нізя відмовитися? )) і чи взагалі є контори де можна відмовитися від?

ну хотябы потому что те кто дает ревью не проходят никакой подготовки как это ревью давать и ревью никак не взвешенно относительно дающих. Если тебе сеньйор с соседнего отдела написал — всегда отличный код, а недавно пришедший джуниор написал — очень запутанный код, то оба отзыва будут рассмотренны твоим менеджером без всяких весовых коофициентов. Я видел ревью где мид пишет ревью сеньйору — неплохо было бы уменьшить количество ошибок в коде, при том что человек ревьювил код только однажны и большинство комментов было про наименование переменных. И таких примеров много, а потом читай все это с менеджером и единсвенный коммент — wow, this was bold, и это то что я называю боль.

Можна ще навести десятки прикладів таких «страждань» — code review, демо з замовником, retrospective і т.д.
Але це ж все окупається високими і стабільними зарплатами в ІТ. Якщо комусь хочеться більш комфортного і безтурботного життя, завжди можна піти з ІТ в іншу сферу.

Детальный фидбек — одна из основных целей проведения ревью процесса. С описанием навыков, на которых стоит сконцентрироваться, примерами ситуаций или технических решений, которые можно было сделать по другому.

но зачем разработчику играть в єти ваши странные игры? разве что вы платите выше рынка, и тогда этот милый каприз идёт в качестве компенсации за повышенный доход. во всех остальных случаях — через дорогу всё то же самое, только без мозголюбства.

мерой продуктивности специалиста (в любой сцк отрасли, хоть в разработке, хоть в вязке веников) является решение задач заказчика в условленный срок, со стабильным оговорённым качеством и с минимальными издержками. всё. любое остальное корпоративное говно не имеет никакого значения.

Люто и бешенно плюсую, народ какаим инфантилизмом или онанизмом страдает вместо того чтобы сделать команде условия комфортными, а клиенту деливери стабильным и спать спокойно.

Решение задач в условленный срок, уровень качества решений, а также умение эти задачи организовывать, планировать, приоритизировать и коммуницировать входят в матрицу навыков, которую описал выше.
По ней проходит оценивание и дается фидбек, как эти навыки улучшить.

разробник безпосередньо ні в які «ігри» не грає, а просто працює собі як завжди, потім дивиться, що йому нарев’ювали. Як вже було вказано вище, це не екзамен і до нього неможливо і не потрібно якось особливо готуватись. Якщо є сумніви в чесності, процес відкритий, фідбек після нього також. Ну і загалом в компанії все добре з оплатою, тому є можливість взагалі не знати ні про які рев’ю і не паритись за зп.

На практиці, до речі, це як раз набагато більш комфортний процес, аніж стандартне рев’ю з менеджером і принизливими (як на мене) торгами за гроші.

PR — это то что нечем заняться бездельникам и галерным манагерам в рабочее время, если год нет движений по з/п, то в соседней шлюпке через улицу заплатят больше, а вы можете упарываться дальше и медитировать своими ревьювами

PR помогает:
1. определить справедливый уровень компенсации
2. выйти на общее понимание зоны роста
можно конечно рандомно зарплаты выставлять, но как то не честно.

справедливый уровень компенсации

Справедливість — це не той термін, який має сенс у питаннях грошей.
Ревью не додає справедливості в ЗП, воно просто виступає виправданням (джастіфікейшн) для рішення менеджера.

выйти на общее понимание зоны роста

Знову ж не зрозуміло, яким чином.
Є цілі працівника. Є цілі (задачі, проблеми) роботодавця.
Зони росту залежать від 2-х попередніх параметрів. Де тут ревью? До чого тут оцінка колег?

performance review — это театр, как и корпоративная культура.
театром занимаются до тех пор пока нет настоящего занятия

Прикольная статья, все в принципе правильно, но веселит немного. Потому что все «красивые» схемы пересмотра рано или поздно упираются в одну тупую реальность — инженер получает более интересное предложение с рынка. И тогда становится понятно — зарплата — это ценность инженера для компании (которая в свою очередь связана со стоимостью на рынке) помноженная на «коэффициент сволочности» инженера. А все performance review — с одной стороны — часть процесса определения этой ценности для компании а с другой стороны — попытки «управления ожиданиями» с элементами peer-прессинга, вкрученными пропорционально брутальности работодателя. Последнее работает все меньше и меньше :-).

Началась статья за здравие, было интересно. В конце вообще стало непонятно с оценками, которые все друг другу ставят и впечатление смазалось.

схему объясняем каждому новому инженеру в компании.
инженеры — основные участники процесса, т.к. peer review.
после каждого review проводим ретроспективу с теми же инженерами, чтобы обсудить потенциальные улучшения.
отдел маркетинга в проведении performance review не участвует :)

А дизлайк можно поставить?

И наоборот, рост экспертизы инженерной команды напрямую влияет на успех и доход всей компании.

а как вы это измеряете? что конкретно результат работы вот этой инженерной команды прямо влияет на бизнес-показатели и доход в частности?

рост revenue бизнеса влияет на рост общего ренжа компенсации. но мы не привязываем напрямую результаты отдельных команд к отдельным показателям бизнеса.
при этом, конечно, отдельные продуктовые метрики, в том числе зависят от сроков и стабильности релизов инженерной команды.

каждая компания строит тот процесс, который работает для неё в данный момент времени.
мы не руководствовались опытом компании Deloitte при выборе своего процесса.

Ремарка без прив’язки до конкретної статті

каждая компания строит тот процесс, который работает для неё в данный момент времени.

Дуже ризикована позиція, оскільки чи працює процес ви дізнаєтесь не «в даний момент», а через Х років, коли помітите тенденцію і зможете її прив’язати саме до процесу рев’ю, а не до інших чинників.

Наприклад, в епамі є процес асесмента (при отриманні наступного тайтла) і я знаю людей які лівнули з компанії або стали менш лояльнішими через цей процес, хоча теоретично там не має бути нічого страшного.
Проблема в тому, що ця ситуація помітна на 10К працівників. В Рейлсвер менше 200, на таких об’ємах можна роками не помічати незадоволення.

мы проводим регулярные one-on-ones с каждым инженером, система performance review прозрачна для всех и по окончанию performance review процесса проводим со всеми отдельные feedback сессии. это помогает в том числе видеть недовольство.
мне кажется, эти процессы легче проводить в компании с меньшим кол-вом сотрудников (<200).

мы проводим регулярные one-on-ones с каждым инженером, система performance review прозрачна для всех и по окончанию performance review процесса проводим со всеми отдельные feedback сессии. это помогает в том числе видеть недовольство.

Ось в тому то й проблема, що «незадоволеність» це не (завжди) покаже. Я бачив кеси, коли людина після рев’ю 2-3 місяці працює, а потім змініє місце роботи, бо «просто там дали краще умови». А ще через 2-3 місяці в приватній розмові розповідає «які там були мудаки і як добре, що він лівнув». Менеджмент звісно не вкурсі цих розмов.

Ваш підхід сильно зав’язаний на «довіру» між працівниками і компанією. Для невеликих компаній (до 200) це й справді може працювати.

да вы и не знали кто придумал этот ревью )))

Мораль: надо сразу распространять религию, а уже потом на других смотреть, как прошло, и только потом внедрять у себя. Я надеюсь, с фреймворками подобная практика не случится. А то выгодно же.

Как происходит performance review в НОРМАЛЬНОЙ инженерной команде

недавно рассказывал чел из нетфликса.

ІМО це все хоч якось працює в топових компаніях, після яких особливо нема куди рости.
А в загальному, для чого запарюватись з бюрократією в ноунейм компанії, шоб отримати пару відсотків підвищення, якшо з часом простіше просто перейти в компанію «через дорогу» і отримати більш суттєве підвищення.

Сокращу до смысла: попадание в запланированные сроки. То есть тот же субъективизм, но с кучей бюрократии в довесок. Соответственно, те кто не умеют в бюркоратию или им банально некогда ею заниматься — проигрывают раза в 2-3 на ровном месте. Те кто умеют — проигрывают по реальным способностям.

Мораль: пусть вам сделает ревью контора через дорогу, если вы не тянете бюрократизм. А останутся только те, кто умеет хорошо пропетлять от планов.

Ну и для тех, кто вдруг не читал: Нулевой потенциал

А механизм бюрократии — таки да. Равно как и механизм подавления в стае у коллективных животных.

«дякуючи» еволюції, найуспішніші на нашій планеті це віруси, грибки та бактерії (а зовсім не хомо сапієнс, як ви можливо чомусь подумали). не поспішайте, дайте цій думці як слід настоятися.

я ж просив не поспішати: ти знову напустив бульок в H²O

тобі б зрозуміти для початку шо ти сам пишеш і навіщо, а вже потім висловлювання інших людей.

класику американської фантастики потрібно вивчати в школі на уроках іноземної літератури, оскільки вона чудово формує уяву і розширює світогляд, я вважаю. головне не перестаратися, бо не лишиться місця для стереотипів мислення та шаблонів проектування.

Я обожнюю фантастику і тому боюсь, що якщо її почнуть заставляти читати в школах, то народ її возненавидить.

Підписатись на коментарі