Индивидуальные встречи 1:1, оценка эффективности, циклы обратной связи, планы улучшения, продвижение, карьерный рост
Время освоения: ~40 минут Цель: Освоить инструменты performance management — от регулярных 1:1 до сложных разговоров о низкой эффективности — для развития сильной команды
| Модель | Структура | Когда использовать |
|---|---|---|
| SBI | Situation → Behavior → Impact | Корректирующая обратная связь, конкретные ситуации |
| STAR | Situation → Task → Action → Result | Похвала и оценка достижений, performance review |
| Сэндвич | Позитив → Критика → Позитив | НЕ рекомендуется: критика теряется, воспринимается неискренне |
| Этап | Действие | Периодичность |
|---|---|---|
| Постановка целей | SMART/OKR, выравнивание с командными и бизнес-целями | Квартально / в начале года |
| Регулярный check-in | 1:1 встречи, обратная связь | Еженедельно / раз в 2 недели |
| Mid-year review | Промежуточная оценка прогресса, коррекция | Раз в полгода |
| Performance review | Итоговая оценка, самооценка, 360°, новые цели | Ежегодно / раз в полгода |
| Уровень | Чем измерять | Чего не делать |
|---|---|---|
| Junior | Скорость обучения, качество задач, самостоятельность | Не сравнивать с senior по количеству задач |
| Middle | Влияние на команду, качество кода, решение проблем | Не оценивать только по velocity |
| Senior | Технический вклад, наставничество, архитектурные решения | Не игнорировать soft skills |
| Staff+ | Бизнес-влияние, кросс-командное взаимодействие, стратегия | Не оценивать только по коду |
Performance management — это не ежегодная формальность. Это система непрерывных инвестиций в людей, которая определяет, растёт ли команда или стагнирует.
Зачем нужен performance management:
Принципиальная ошибка: многие тимлиды думают о performance management только когда есть проблема. Правильный подход — регулярная профилактика.
💡 Помните: Цель performance management не контроль, а рост. Лучший результат — когда разработчик сам хочет становиться лучше и видит, как это происходит.
1:1 — основа отношений тимлида с каждым членом команды. Это пространство для роста, обратной связи и решения проблем, которые не выходят на поверхность в общих обсуждениях.
Что 1:1 — это НЕ:
Что 1:1 — это ДА:
Частота и длительность:
Повестка: разработчик ведёт повестку, тимлид задаёт вопросы
Типичные вопросы тимлида:
- «Что сейчас даётся труднее всего?»
- «Что мешает тебе работать эффективнее?»
- «Что бы ты изменил в наших процессах?»
- «Над чем ты хочешь вырасти в следующем квартале?»
- «Есть ли что-то, что я мог бы делать иначе?»
Шаблон документирования 1:1:
## 1:1 с [Имя] — [Дата]
### Темы разработчика
- [то, что принёс разработчик]
### Обсудили
- [ключевые темы встречи]
### Обратная связь
- [что дал тимлид / что получил от разработчика]
### Action items
- [ ] Разработчик: [задача] до [дата]
- [ ] Тимлид: [задача] до [дата]
### Следующая встреча: [дата]
SBI (Situation — Behavior — Impact) — структура, которая делает обратную связь конкретной и действенной.
Структура:
Situation (Ситуация): «Вчера на встрече по планированию спринта...»
Behavior (Поведение): «...ты несколько раз перебил коллег, не дав им закончить мысль...»
Impact (Влияние): «...из-за чего два предложения по оптимизации не были рассмотрены,
и команда вышла с ощущением, что их мнение не учитывается.»
После SBI: задать вопрос, а не читать лекцию:
«Что ты думаешь об этом? Замечал ли ты эту ситуацию с другой стороны?»
Обратная связь работает только тогда, когда она свежая.
| Временной промежуток | Эффективность обратной связи |
|---|---|
| В тот же день | Очень высокая — ситуация свежа в памяти |
| В течение недели | Высокая — ситуация ещё понятна |
| На ежеквартальном review | Низкая — детали забыты, кажется запоздалой |
| На ежегодном review | Очень низкая — воспринимается как список претензий |
Правило: если хочешь сказать что-то важное, скажи сегодня. Завтра будет сложнее, через месяц — почти бесполезно.
| Признак | Конструктивная | Деструктивная |
|---|---|---|
| Конкретность | «На прошлой неделе задача X заняла вдвое больше из-за...» | «Ты вечно тормозишь» |
| Фокус | Поведение и его влияние | Личность и характер |
| Тон | Нейтральный, уважительный | Обвинительный, эмоциональный |
| Формат | Приватно (для негативной), публично (для позитивной) | Любая критика публично |
| Цель | Рост и изменение | Наказание или разрядка |
Хороший performance review строится на данных, собранных за весь период, а не на памяти последнего месяца.
Что собирать в течение года:
Хорошая самооценка — база для честного разговора. Плохая самооценка — либо самокритика, либо самовосхваление.
Вопросы для самооценки:
1. Каковы твои главные достижения за период? Что ты создал или улучшил?
2. Где ты не дотянул до своих собственных ожиданий? Что помешало?
3. Какие навыки ты развил? Что остаётся зоной роста?
4. Как ты повлиял на команду? (не только технически)
5. Что тебе нужно от меня, чтобы расти быстрее?
360° — оценка от коллег, смежных команд и прямых подчинённых (если есть).
Принципы организации:
Вопросы для 360°:
- Что [имя] делает, что помогает тебе работать лучше?
- Что [имя] мог бы делать иначе, чтобы быть более эффективным?
- Опиши конкретный случай, когда вы успешно сработались.
SMART цели:
S — Specific (конкретная)
M — Measurable (измеримая)
A — Achievable (достижимая)
R — Relevant (релевантная)
T — Time-bound (ограниченная во времени)
Плохо: «Стать лучше в архитектуре»
Хорошо: «Провести 2 архитектурных ревью и написать ADR для системы кэширования до Q2»
OKR (Objectives & Key Results):
Objective: Стать go-to человеком по производительности системы
Key Results:
- KR1: Снизить p99 latency API на 30% к концу квартала
- KR2: Провести 3 performance-аудита с задокументированными результатами
- KR3: Обучить 2 разработчиков профилированию Python-приложений
Игнорирование проблемы производительности — одна из самых дорогих ошибок тимлида. Она влияет на всю команду.
Ранние признаки low performance:
Алгоритм работы с low performer:
1. Прямой разговор — озвучить наблюдения конкретно (SBI)
2. Поиск причины — внешние факторы, личные проблемы, wrong role?
3. Совместный план улучшений — конкретные метрики, сроки
4. Поддержка — тимлид активно помогает, не только наблюдает
5. PIP (если план не работает) — формальный план с прозрачными условиями
6. Расставание — крайняя мера, когда остальное исчерпано
PIP — формальный документ, когда неформальная работа не принесла результата.
Что должен содержать PIP:
Важно: PIP — это не приговор. Цель — дать человеку реальный шанс изменить ситуацию.
Топ-перформеры не просят о признании — они молча уходят, если его нет.
Что удерживает лучших людей:
| Ошибка | Почему это плохо | Как исправить |
|---|---|---|
| Давать обратную связь только на ежегодном review | К этому моменту обратная связь теряет смысл, человек не помнит контекст и воспринимает её как накопленные претензии | Внедрить культуру своевременной обратной связи: в течение 24–48 часов после ситуации |
| Отменять 1:1 встречи при занятости | Сигнализирует человеку, что он не в приоритете, разрушает доверие и связь | Переносить, но не отменять; если совсем нет времени — хотя бы 15 минут |
| Говорить только о задачах на 1:1, не обсуждая рост и карьеру | Разработчик не видит пути вперёд и начинает искать рост вовне | Резервировать минимум 50% времени 1:1 на карьеру, цели и развитие |
| Не документировать обратную связь и договорённости | При следующей встрече теряется контекст, человек чувствует непоследовательность | Вести краткие заметки после каждой 1:1, отправлять action items письмом |
| Ждать performance review для разговора о проблемах | Проблема нарастает, влияет на команду, человек чувствует себя преданным («почему не сказал раньше?») | Говорить о проблемах сразу, как только они стали систематическими |
| Оценивать по видимости, а не по влиянию | Интроверты и «тихие» архитекторы недооцениваются, публичные «звёзды» переоцениваются | Собирать конкретные данные о вкладе каждого, проводить 360° для баланса |
Проанализируйте последние 4 встречи 1:1 с каждым разработчиком:
Вспомните ситуацию из последних 2 недель, когда хотели дать обратную связь, но не дали:
Далее: Конфликты