Как подготовиться к performance review в IT и обсудить повышение зарплаты
Performance review проходит в разные сроки и по разным правилам. Подготовка помогает спокойно собрать результаты, обсудить развитие и сформулировать запрос о повышении, если он уместен.
Анастасия Дроздова
Карьерный консультант и коуч для IT специалистов
Когда в календаре появляется performance review, легко вспомнить только последние задачи. Лучше заранее собрать факты за весь оцениваемый период и связать их с целями команды.
Это нормально. Большинство людей приходят к такой встрече с ощущением, что они работали много, но не всегда умеют честно и красиво объяснить, что именно изменилось благодаря их участию.
Ниже — простой и рабочий лайфхак, который помогает говорить на языке результата, а не на языке “я просто делал свою работу”.
Как говорить о рабочих достижениях
Хорошая структура для performance review — это три блока:
- Точка А: что было до, какая была проблема и почему она была важна.
- Действия: что ты сделал, какие решения принял, какие инструменты применил, какие роли выполнял.
- Точка Б: что изменилось после твоей работы и почему это важно для команды, продукта или бизнеса.
Именно эта логика помогает говорить не просто «я сделал», а «я помог системе работать лучше, быстрее, стабильнее и дешевле».
Вопросы, которые помогают говорить языком цифр и аналитики
Когда ты говоришь о достижениях, не надо перечислять все задачи. Нужно показать, что их результат измерим. Вот вопросы, которые реально помогают:
- Какое конкретное число изменилось после моего решения?
- Сколько времени или операций теперь экономится?
- Какой показатель качества, скорости или стабильности улучшился?
- Сколько проблем перестало происходить?
- Что стало быстрее, дешевле, масштабируемее?
Вот примеры, которые работают в IT:
Слабое формулирование: «Ускорил работу системы»
Сильное формулирование: «Снизил p95 latency с 820 ms до 410 ms, улучшив скорость ответа критичных пользовательских сценариев».
Или:
Слабое формулирование: «Помогал с аналитикой и отчетностью»
Сильное формулирование: «Автоматизировал отчетность по QA-процессу, сократив ручную проверку с 6 до 1 часа в неделю».
Какую именно математику стоит использовать
Подход работает лучше всего, когда ты перед собой задаешь 10 простых вопросов и отвечаешь на них по итогам квартала:
- Какое число операций, запросов или секунд изменилось после моего решения?
- Сколько дефектов или инцидентов стало меньше?
- Какое количество часов теперь экономится в неделю?
- Какие пользовательские или бизнес-показатели улучшились?
- Как изменился масштаб системы после оптимизации?
- На сколько сократилось время на повторяющийся процесс?
- Что перестало зависеть от одного человека?
- Как уменьшился риск срыва сроков или ошибок?
- Что стало быстрее в коммуникации или в принятии решений?
- Какие метрики теперь лучше, чем были в начале квартала?
Важно: ты не обязан говорить всё сразу. Но один-два точных числа должны быть в твоем рассказе обязательно.
Как отвечать на вопросы про софт-скиллы без скучного списка
Многие люди на ревью начинают говорить: «Я коммуникабельный, стрессоустойчивый, умею работать в команде». Это, конечно, хорошо, но слишком абстрактно. Важно перевести это в сценарии и факты.
Есть две простые схемы:
1. SBI + Growth
Это классическая схема для международных компаний и зрелых команд:
- Situation: какая была ситуация?
- Behavior: что ты делал?
- Impact: какой был эффект?
- Growth: чему ты научился и как улучшил себя дальше?
Пример:
«В проекте была проблема с задержками по релизам: команда регулярно сталкивалась с конфликтами по приоритетам. Я предложил более ясную схему согласования и регулярный статус-ревью, после чего время на согласование сократилось с 12 дней до 4, а процесс стал заметно прозрачнее. После этого я стал лучше видеть, где решения нужно принимать быстрее, а где — с участием команды».
2. CARL
Эта схема особенно удобна, когда речь про коммуникацию, конфликты, лидерство, зрелость и принятие решений:
- Context: контекст и проблема.
- Action: что ты сделал.
- Result: что получилось.
- Learning: чему ты научился.
Главное преимущество обеих схем — они показывают не «идеального сотрудника», а живого человека, который понимает логику изменений и умеет расти.
Как подготовиться к performance review за 30 минут
Вот короткая цепочка, которая работает.
- Собери 3–5 самых сильных задач за квартал.
- Для каждой запиши: проблема, решение, результат, цифры.
- Выдели 2–3 кейса, где ты реально повлиял на продукт, команду или бизнес.
- Подготовь фразу: «В этом квартале я помог добиться X, потому что Y».
- Подумай, как это связано с твоими целями на следующий период.
И главное: если получается говорить о достижениях не абстрактно, а через конкретику, performance review становится командной встречей, а не экзаменом.
Итог
Не надо ждать, пока менеджер сам “додумает”, чем вы были полезны. Лучше говорить о результатах заранее: в понятной структуре, с цифрами и с ясным результатом для команды или бизнеса.
Во многом именно так рождается не только сильная оценка, но и разговор о зарплате, росте и следующем уровне ответственности.
Шаблон самооценки
Заполните этот шаблон перед встречей:
- Период и роль: какие цели и зона ответственности были у меня.
- Результаты: 3–5 задач по схеме «контекст — действие — эффект».
- Вклад в команду: какие процессы, решения или коллег я поддержал.
- Развитие: чему научился и что хочу улучшить.
- Следующий период: какие цели и ресурсы нужны.
- Запрос: что именно хочу обсудить о роли, уровне или компенсации.
Учебный пример: «За период я автоматизировал отчётность QA, сократил ручную проверку с 6 до 1 часа в неделю и хочу обсудить расширение зоны ответственности и соответствие компенсации новому уровню». Это пример структуры, а не факт о реальном клиенте.