Назад к блогу
Performance review 31 августа 2026 · 8 мин читать

Как подготовиться к performance review в IT и обсудить повышение зарплаты

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

Анастасия Дроздова

Анастасия Дроздова

Карьерный консультант и коуч для IT специалистов

Анастасия Дроздова — карьерный консультант для IT-специалистов

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

Это нормально. Большинство людей приходят к такой встрече с ощущением, что они работали много, но не всегда умеют честно и красиво объяснить, что именно изменилось благодаря их участию.

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

Как говорить о рабочих достижениях

Хорошая структура для performance review — это три блока:

  • Точка А: что было до, какая была проблема и почему она была важна.
  • Действия: что ты сделал, какие решения принял, какие инструменты применил, какие роли выполнял.
  • Точка Б: что изменилось после твоей работы и почему это важно для команды, продукта или бизнеса.

Именно эта логика помогает говорить не просто «я сделал», а «я помог системе работать лучше, быстрее, стабильнее и дешевле».

Вопросы, которые помогают говорить языком цифр и аналитики

Когда ты говоришь о достижениях, не надо перечислять все задачи. Нужно показать, что их результат измерим. Вот вопросы, которые реально помогают:

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

Вот примеры, которые работают в IT:

Слабое формулирование: «Ускорил работу системы»

Сильное формулирование: «Снизил p95 latency с 820 ms до 410 ms, улучшив скорость ответа критичных пользовательских сценариев».

Или:

Слабое формулирование: «Помогал с аналитикой и отчетностью»

Сильное формулирование: «Автоматизировал отчетность по QA-процессу, сократив ручную проверку с 6 до 1 часа в неделю».

Какую именно математику стоит использовать

Подход работает лучше всего, когда ты перед собой задаешь 10 простых вопросов и отвечаешь на них по итогам квартала:

  1. Какое число операций, запросов или секунд изменилось после моего решения?
  2. Сколько дефектов или инцидентов стало меньше?
  3. Какое количество часов теперь экономится в неделю?
  4. Какие пользовательские или бизнес-показатели улучшились?
  5. Как изменился масштаб системы после оптимизации?
  6. На сколько сократилось время на повторяющийся процесс?
  7. Что перестало зависеть от одного человека?
  8. Как уменьшился риск срыва сроков или ошибок?
  9. Что стало быстрее в коммуникации или в принятии решений?
  10. Какие метрики теперь лучше, чем были в начале квартала?

Важно: ты не обязан говорить всё сразу. Но один-два точных числа должны быть в твоем рассказе обязательно.

Как отвечать на вопросы про софт-скиллы без скучного списка

Многие люди на ревью начинают говорить: «Я коммуникабельный, стрессоустойчивый, умею работать в команде». Это, конечно, хорошо, но слишком абстрактно. Важно перевести это в сценарии и факты.

Есть две простые схемы:

1. SBI + Growth

Это классическая схема для международных компаний и зрелых команд:

  • Situation: какая была ситуация?
  • Behavior: что ты делал?
  • Impact: какой был эффект?
  • Growth: чему ты научился и как улучшил себя дальше?

Пример:

«В проекте была проблема с задержками по релизам: команда регулярно сталкивалась с конфликтами по приоритетам. Я предложил более ясную схему согласования и регулярный статус-ревью, после чего время на согласование сократилось с 12 дней до 4, а процесс стал заметно прозрачнее. После этого я стал лучше видеть, где решения нужно принимать быстрее, а где — с участием команды».

2. CARL

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

  • Context: контекст и проблема.
  • Action: что ты сделал.
  • Result: что получилось.
  • Learning: чему ты научился.

Главное преимущество обеих схем — они показывают не «идеального сотрудника», а живого человека, который понимает логику изменений и умеет расти.

Как подготовиться к performance review за 30 минут

Вот короткая цепочка, которая работает.

  1. Собери 3–5 самых сильных задач за квартал.
  2. Для каждой запиши: проблема, решение, результат, цифры.
  3. Выдели 2–3 кейса, где ты реально повлиял на продукт, команду или бизнес.
  4. Подготовь фразу: «В этом квартале я помог добиться X, потому что Y».
  5. Подумай, как это связано с твоими целями на следующий период.

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

Итог

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

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


Шаблон самооценки

Заполните этот шаблон перед встречей:

  • Период и роль: какие цели и зона ответственности были у меня.
  • Результаты: 3–5 задач по схеме «контекст — действие — эффект».
  • Вклад в команду: какие процессы, решения или коллег я поддержал.
  • Развитие: чему научился и что хочу улучшить.
  • Следующий период: какие цели и ресурсы нужны.
  • Запрос: что именно хочу обсудить о роли, уровне или компенсации.

Учебный пример: «За период я автоматизировал отчётность QA, сократил ручную проверку с 6 до 1 часа в неделю и хочу обсудить расширение зоны ответственности и соответствие компенсации новому уровню». Это пример структуры, а не факт о реальном клиенте.