Как подготовиться к performance review в IT: пошаговое руководство
апр, 23 2026
Представьте: вы весь год пахали, закрывали сложные тикеты и даже пару раз спасали релиз в выходные. Но на встрече по оценке результатов менеджер говорит, что «в целом всё неплохо», и предлагает оставить текущий грейд без изменений. Знакомо? Проблема в том, что в IT-компаниях результат работы не всегда виден «сам по себе». Если вы не подсветили свои достижения, значит, их не существует в глазах системы.
Когда речь заходит о performance review is систематический процесс оценки эффективности сотрудника, который помогает компании и специалисту понять, где есть рост, а где нужно подтянуться, многие начинают нервничать. На самом деле это ваш главный инструмент для легального повышения зарплаты и перехода на новый уровень. Секрет успеха прост: подготовка начинается не за неделю до встречи, а с первого рабочего дня года.
Главные тезисы для подготовки
- Собирайте доказательства своих успехов в реальном времени (brag-document).
- Оперируйте цифрами и фактами, а не ощущениями.
- Проанализируйте свои soft skills так же детально, как и технические задачи.
- Сформулируйте конкретные цели на следующий период по методике SMART.
- Будьте готовы к конструктивной критике без защитной реакции.
Сбор доказательств: создаем «документ достижений»
Самая большая ошибка - пытаться вспомнить всё, что вы сделали за полгода, сидя в пустом текстовом файле за два дня до ревью. Память нас подводит, и мелкие, но важные победы стираются.
Начните вести так называемый brag-document. Это простой список, куда вы записываете всё, чем гордитесь. Но записывайте не «делал задачу по API», а конкретный результат. Например: «Оптимизировал запрос к базе данных, что сократило время отклика страницы с 2 секунд до 400 мс, что привело к росту конверсии на 2%».
Ваши аргументы должны отвечать на три вопроса: что было сделано, какой измеримый эффект это принесло и кто это заметил? Если коллега из соседнего отдела прислал вам в Slack «спасибо, ты спас проект», заскриньте это. В IT-среде такие свидетельства работают лучше, чем ваши собственные слова.
Работа с самооценкой и Self-Review
В большинстве компаний перед встречей с лидом нужно заполнить Self-Review is формализованный процесс самоанализа, в котором сотрудник самостоятельно оценивает свои компетенции и достижения за отчетный период. Это не просто бюрократия, а ваш шанс задать вектор беседе.
При заполнении не скромничайте, но и не приписывайте себе лишнего. Используйте структуру: «Задача → Мое действие → Результат». Если вы внедрили новую библиотеку, которая ускорила сборку проекта, напишите об этом. Если вы помогли онбордить трех джунов, которые вышли на автономность за месяц вместо двух - это огромный плюс к вашему влиянию на команду.
Не забудьте про Soft Skills is гибкие навыки, такие как коммуникация, умение работать в команде, решение конфликтов и адаптивность, которые определяют эффективность взаимодействия в коллективе. В IT-индустрии технический стек (hard skills) важен, но грейд часто зависит от того, насколько вы помогаете другим расти. Опишите, как вы улучшили процессы в команде или помогли коллеге разобраться в сложном куске кода.
Метод 360 градусов: взгляд со стороны
Многие современные компании используют Feedback 360 is метод комплексной оценки, при которой обратную связь о сотруднике собирают от его руководителя, коллег, подчиненных и иногда даже клиентов. Это значит, что ваше мнение - лишь часть пазла.
Чтобы этот процесс работал на вас, не ждите ревью. Запрашивайте фидбек в течение всего года. Спрашивайте коллег после завершения крупного эпика: «Что я мог бы сделать лучше в этом проекте?» или «В чем моя сильная сторона в нашей работе?». Когда придет время официального ревью, ваши коллеги уже будут знать, за что вас хвалить, и их отзывы будут более детальными и позитивными.
| Плохо (Размыто) | Хорошо (Конкретно) | Эффект для ревью |
|---|---|---|
| «Много писал кода для фронтенда» | «Реализовал 5 новых модулей админки, сократив время ручного ввода данных в 3 раза» | Показывает бизнес-ценность |
| «Помогал коллегам с ревью» | «Провел более 100 код-ревью, выявил критические баги на этапе разработки, что снизило кол-во багов в проде на 15%» | Демонстрирует влияние на качество |
| «Изучал новые технологии» | «Внедрил TypeScript в проект X, что сократило количество runtime-ошибок на 20%» | Связывает обучение с профитом компании |
Постановка целей и SMART-подход
Итогом любого ревью должен стать IDP is Индивидуальный план развития (Individual Development Plan), документ, в котором прописаны конкретные шаги, сроки и ресурсы для профессионального роста сотрудника до следующего грейда. Не позволяйте менеджеру просто сказать «развивайся дальше».
Требуйте конкретики. Если вам говорят «подтянуть архитектурные навыки», предложите свою версию цели по системе SMART (Specific, Measurable, Achievable, Relevant, Time-bound). Вместо размытого «стать лучше в архитектуре», договоритесь о следующем: «К концу второго квартала спроектировать и внедрить паттерн CQRS в сервис уведомлений, пройдя внутреннее ревью от архитектора компании».
Оптимально ставить 3-4 цели. Если их будет десять, вы перегорите или распылите внимание. Разделите их по сложности: одна «быстрая победа» (чтобы почувствовать успех), две основные задачи по грейду и одна амбициозная цель на вырост.
Как реагировать на критику и «неожиданности»
Ревью - это не только похвала. Вы можете услышать, что ваша коммуникация с тестировщиками оставляет желать лучшего или что вы слишком часто срываете сроки по мелким задачам. В этот момент включается режим защиты: хочется начать оправдываться («но тестировщики сами не так поставили задачу!»).
Стоп. Оправдания на ревью воспринимаются как незрелость. Лучшая стратегия - любопытство. Задавайте уточняющие вопросы: «Можешь привести пример ситуации, когда моя коммуникация помешала процессу?», «Что именно в моем подходе кажется тебе неэффективным?».
Когда вы переводите разговор из плоскости «кто виноват» в плоскость «как исправить», вы демонстрируете лидерские качества. Менеджеры ценят людей, которые умеют принимать фидбек и использовать его для роста. Это часто важнее, чем умение писать идеальный код.
После встречи: что делать дальше?
Самое опасное - закрыть документ с целями и забыть о нем до следующего полугодия. Ревью - это не событие, а цикл. Зафиксируйте все договоренности в письменном виде (в Jira, Confluence или просто в почте). Если вам пообещали пересмотр зарплаты через три месяца при условии изучения определенной технологии - задокументируйте это.
Проводите короткие синхронизации с лидом раз в месяц. Спрашивайте: «Я иду по нашему плану развития? Всё ли ок или мне нужно что-то подправить сейчас, чтобы на следующем ревью не было сюрпризов?». Такая проактивность снимает стресс и делает следующее ревью предсказуемым и приятным процессом.
Что делать, если я не согласен с оценкой менеджера?
Не вступайте в эмоциональный спор во время встречи. Попросите менеджера обосновать оценку конкретными примерами. Если аргументы кажутся вам слабыми, предложите пересмотреть оценку через неделю, предоставив дополнительные доказательства своих достижений (те самые скрины и цифры из brag-document). Если консенсус не достигнут, можно обратиться к HR-департаменту для проведения дополнительного посредничества.
Как просить повышение зарплаты на performance review?
Привязывайте запрос к ценности, которую вы приносите бизнесу, а не к личному комфорту. Вместо «мне нужно больше денег, потому что выросла аренда», говорите: «За последние полгода я взял на себя ответственность за модуль X, сократил время разработки фич на 20% и стал ментором для двух коллег. Мой текущий уровень ответственности соответствует грейду Senior, поэтому я предлагаю пересмотреть мой оклад до суммы Y».
Что делать, если я вообще ничего не записывал в течение года?
Начните с анализа истории своих merge-реквестов в Git, задач в Jira и переписки в Slack. Выпишите все крупные фичи, которые вы довели до продакшена. Найдите коллег, с которыми работали в тесных связках, и спросите их, что они считают вашим главным вкладом в проект. Это поможет восстановить хронологию ваших успехов, хотя в будущем лучше вести brag-document в реальном времени.
Влияет ли performance review на увольнение?
В здоровых компаниях ревью - это инструмент развития, а не карательный орган. Однако систематически низкие оценки при отсутствии прогресса в IDP могут стать сигналом для компании о том, что сотрудник не справляется. Именно поэтому важно фиксировать шаги по исправлению ситуации и запрашивать помощь (обучение, менторство), если вы чувствуете, что «плаваете» в каких-то компетенциях.
Как давать фидбек коллегам, чтобы не испортить отношения?
Используйте метод «критика действия, а не личности». Вместо «он медленный и ленивый» напишите «задачи по этому модулю часто задерживаются, что тормозит работу всей команды. Было бы полезно обсудить, как оптимизировать процесс декомпозиции задач для этого коллеги». Фокусируйтесь на фактах и предлагайте решение, а не просто констатируйте проблему.
Что делать дальше: план действий
- Для тех, у кого ревью через месяц: Создайте документ и выпишите все закрытые задачи за период. Найдите 2-3 цифры, которыми можно измерить успех.
- Для тех, кто только вступил в должность: Заведите привычку каждую пятницу записывать в отдельный файл одно главное достижение за неделю.
- Для лидов: Проведите серию коротких 1:1 встреч с командой, чтобы синхронизировать ожидания до основного цикла ревью.