
Организованное программирование
Performance Review в IT: как правильно оценивать разработчиков и сотрудников / Сергей Бережной #91
Sonntag, 6. September 2026 · 1 h 22
Kapitelklicken springt direkt hin
Shownotes
🔹 Присоединяйся к курсу «ИИ для разработчиков» ru.hexlet.io/programs/ai-for-developers?utm_so… /></p><p>Performance Review — одна из самых болезненных управленческих практик в IT. Люди спорят с оценками, менеджеры пытаются объяснить решения, сотрудники учатся «хакать» метрики, а компания тратит огромное количество времени на калибровки. Но зачем вообще нужна вся эта сложная система и почему нельзя просто платить всем хорошо? В этом выпуске мы поговорили с Сергеем Бережным — руководителем, который много лет участвовал в построении Performance Review в Яндексе. Разобрались, зачем компании нужна разница в оценках, почему Performance Review можно рассматривать как способ распространения информации по большой организации и как материальная мотивация превратилась в инструмент управления.</p><p><br /></p><p>Обсудили, как люди оверфитятся под метрики, почему правила Performance Review приходится периодически менять, как Яндекс экспериментировал со шкалой оценок — от букв A–F до C− и цветных плюсов — и зачем вообще учитывать человеческую психологию в, казалось бы, математической системе. Отдельно поговорили о калибровках: почему руководителю нельзя просто доверять собственной оценке сотрудника, как сравнение нескольких «красавчиков» помогает уменьшить менеджерский bias и почему иногда даже плохое Performance Review оказалось лучше, чем полное отсутствие системы.</p><p><br /></p><p>Разобрали и более неприятную сторону: можно ли превратить ревью в инструмент увольнения, насколько легко хачить 360, почему сотрудники обижаются на снижение оценки и почему Performance Review больше напоминает покер, чем шахматы. Нельзя идеально просчитать одну конкретную раздачу — приходится смотреть на long term. Поговорили и о том, где закончился рост разработчика: почему технологическое совершенство не всегда конвертировалось в деньги, как искать точки роста внутри unit-экономики компании и почему настоящий рост на высоких грейдах начинался там, где инженер учился менять экономику бизнеса, а не просто писать больше кода.</p><p><br /></p><p>А ещё обсудили метрики, которые действительно способны резко изменить производительность команды, влияние AI на Performance Review, проблему потери контекста при масштабировании компаний и то, почему удалённая работа не отменяла Performance Review — если менеджмент умел оценивать результаты, а не количество красных глаз в офисе.</p><p><br /></p><p>Полезные ссылки:</p><p>t.me/veged_and_code</p><p><br /></p><p>Подписывайтесь на канал «Организованное программирование» в Telegram: ttttt.me/orgprog</p><p>– Список подкаст-платформ (Apple Podcast, Google Podcast, Spotify, Яндекс.Музыка и другие): podcast.ru/1734325321</p><p>- Смотрите нас на площадке "Вконтакте" - vkvideo.ru/video-224967259_456239353</p>… /></p><p>🔹 Курсы по искусственному интеллекту: ru.hexlet.io/courses_artificial-intelligence?u… Клуб в Telegram t.me/HexletClubBot</p><p><br /></p><p>#IT #управлениеIT #оценкасотрудников #грейды #KPI #360оценка #премии #мотивациясотрудников #ITменеджмент #управлениекомандой #разработка #ITкоманда #ОрганизованноеПрограммирование #КириллМокевнин</p><p><br /></p><p>Performance Review в IT: как правильно оценивать разработчиков и сотрудников / Сергей Бережной #91</p>