См. также
Performance Review: основы
Как калибровать ожидания, давать обратную связь и превращать рост в понятные критерии.
См. также
Performance Review: основы
Как калибровать ожидания, давать обратную связь и превращать рост в понятные критерии.
Наставничество — это не «воспитывать джунов» и не «проводить 1-на-1». Это способ сделать команду сильнее как систему: выравнивать ожидания, ускорять обучение, расширять автономию и снижать зависимость от отдельных героев. Лидер здесь не главный эксперт, а катализатор роста: он создает условия, в которых люди быстрее становятся самостоятельнее.
TL;DR
- Рост — это система из возможностей, обратной связи и безопасных экспериментов, а не разовые советы.
- 1-на-1 — главный интерфейс наставничества: доверие, контекст, цели, блокеры и план развития.
- Лучшее обучение происходит в потоке delivery: code review, парная работа, дизайн‑ревью, постмортемы, oncall‑дежурства.
- «Stretch‑задачи» растят быстро, если есть guardrails: понятный результат, точки контроля, возможность отката и поддержка.
- Лидер отвечает за справедливость: доступ к интересным задачам, прозрачные ожидания и калибровку уровня.
Наставничество: что это (и что это не)
В командах часто смешивают разные вещи: наставничество, коучинг, обучение и даже «менеджмент». Полезно разделять их по задаче — так вы выбираете правильный инструмент.
| Формат | Когда нужен | Роль лидера |
|---|---|---|
| Наставничество | Когда важно передать опыт и помочь «собрать картину мира». | Делится паттернами, показывает trade‑offs, помогает строить мышление. |
| Коучинг | Когда человеку нужно найти собственное решение и взять ответственность. | Задает вопросы, фокусирует, помогает увидеть варианты и последствия. |
| Обучение | Когда есть конкретный skill‑gap: инструмент, подход, практика. | Дает структуру, упражнения, примеры; проверяет понимание. |
| Спонсорство | Когда для роста нужна видимость и «право на задачу». | Дает возможность: инициативу, роль, публичность, контакт со стейкхолдерами. |
Частая ошибка
Делать наставничество «советами по запросу». Советы важны, но рост начинается, когда появляются регулярность, возможности и обратная связь.
Лидер как катализатор: 4 рычага роста
Катализатор ускоряет реакцию и сам не «сгорает» в процессе. В лидерстве это означает: вы не обязаны тащить все на себе, но обязаны выстроить среду, где команда учится и становится автономнее.
Куда мы идем, что значит «хорошо», какие стандарты качества и как принимаем решения.
Рост появляется, когда есть задачи нужного масштаба: ownership, дизайн, коммуникация, ответственность за прод.
Регулярная, конкретная и своевременная. Не только «что не так», но и «что делать дальше».
Можно ошибаться и учиться, потому что есть canary/rollback, ревью, чек‑листы и помощь коллег.
Диагностика: откуда растем
Перед тем как «запускать наставничество», полезно за 1–2 недели собрать картину: какие навыки уже есть, где риски, где команда зависит от отдельных людей и где тормозит поток разработки.
Про людей
- У кого какой уровень автономии? Кто просит «разрешение», а кто берет ownership?
- Кто кого учит? Есть ли «узкие горлышки» знаний и bus factor?
- Какие сильные стороны у каждого и где человек хочет расти?
Про систему
- Что чаще всего ломает сроки: зависимости, качество, коммуникация, неопределенность?
- Где нет guardrails: тесты, observability, релиз‑процесс, oncall?
- Какие решения повторяются и почему? Есть ли шаблоны/гайды/ADR?
1-на-1: главный инструмент наставничества
Хороший 1-на-1 — не статус‑апдейт. Это место, где вы соединяете три слоя: человека, работу и рост. Именно здесь появляется доверие, которое потом превращается в скорость.
Структура 1-на-1 (30–45 минут)
- Check‑in: как дела, что занимает голову?
- Работа: что идет хорошо, что мешает, где нужен мой вклад?
- Рост: чему учимся сейчас, какая «следующая ступень», какая практика поможет?
- Договоренности: 1–2 конкретных действия до следующей встречи.
Вопросы, которые реально двигают
- Какая часть работы дает тебе энергию, а какая забирает?
- Что бы ты сделал(а) по‑другому, если бы начал(а) задачу заново?
- Какая следующая «взрослая» ответственность тебе интересна?
- Как я могу помочь тебе стать автономнее в этой зоне?
- Где я мешаю (контролем, неопределенностью, приоритетами)?
Практическое правило
Если 1-на-1 превращается в статус‑апдейт — перенесите статус в таск‑трекер, а в 1-на-1 оставьте блокеры, решения, эмоции и рост.
План развития: рост как гипотеза
План развития (IDP) полезен, когда он короткий, измеримый и привязан к реальным задачам. Он должен отвечать на вопрос: какой следующий уровень автономии мы растим и через что.
Шаблон IDP на 6–10 недель
Цель
Конкретное поведение или ответственность (например: «самостоятельно вести дизайн‑док и провести решение через ревью»).
Критерий успеха
Что увидим в артефактах: PR/ADR, метрика, демо, отзыв от стейкхолдера, снижение количества уточнений.
Возможности
- Конкретная задача/инициатива с ownership.
- Шэдоуинг (наблюдение) + совместное выполнение.
- Мини‑проект на улучшение SDLC/качества.
Поддержка
- Кто ментор/ревьюер, как часто синхронимся.
- Какие guardrails: чек‑лист, шаблон документа, точки контроля.
Практики, которые растят в потоке delivery
Самый устойчивый способ развивать людей — встроить обучение в обычную работу. Тогда рост не конкурирует со сроками, а усиливает их.
Code review как наставничество
- Комментируйте принцип (почему), а не только «как сделать».
- Разделяйте must‑fix и nice‑to‑have, чтобы не убивать скорость.
- Давайте примеры и ссылки на гайды/шаблоны (делайте знание переносимым).
Парная работа и шэдоуинг
- Первые 1–2 недели в команде: шэдоуинг на PR, релизах, oncall.
- Сложные участки: парная сессия 60–90 минут вместо бесконечных переписок.
- Ротации ownership: люди учатся системе, а не «своему кусочку».
Дизайн‑доки и ревью решений
Документ заставляет думать, делает предположения явными и ускоряет согласование. Это естественная среда для наставничества: видно качество аргументации и trade‑offs.
Постмортемы как учебный цикл
Хороший постмортем не ищет виноватых, а улучшает систему: guardrails, мониторинг, runbooks, процессы релиза. Это «класс» по надежности прямо на ваших данных.
Stretch‑задачи и делегирование: рост без поломки
Если человек всегда делает задачи «своего уровня», он не растет. Но если вы кидаете его в задачу на два уровня выше без опоры — вы растите стресс, а не компетенцию. Нужен мост: постепенная делегация и безопасные эксперименты.
Лестница делегирования (упрощенно)
- 1Сделай так: четкая инструкция, цель — научиться выполнять по стандарту.
- 2Разберись и предложи варианты: цель — тренировать мышление и компромиссы.
- 3Реши со мной: цель — научиться принимать решения в неопределенности.
- 4Реши и проинформируй: цель — автономия и ответственность за результат.
- 5Полный ownership: цель — масштабировать лидерство и снять зависимость от вас.
Guardrails для stretch‑задачи
- Ясный результат и критерии успеха.
- Точки контроля (например, дизайн‑ревью, mid‑review, pre‑release).
- План отката/rollback и «что делаем, если не успеваем».
- Ревью и поддержка, но без микроменеджмента.
Обратная связь: ускоритель, а не «разбор полетов»
Наставничество ломается, если обратная связь появляется только на performance review. Дайте команде короткий цикл: наблюдение → сигнал → корректировка → закрепление. Подробнее про калибровку и критерии — в главе Performance Review: основы.
Шаблон SBI (конкретно)
Situation — где и когда,
Behavior — что было сделано,
Impact — какой эффект на людей/систему.
Плюс: «в следующий раз попробуй …» — это превращает feedback в действие.
Feedforward (про будущее)
Вместо «почему ты так сделал» спросите: «как мы сделаем лучше в следующий раз». Это снижает защитную реакцию и оставляет человека в режиме обучения.
Как растить разные уровни: короткая шпаргалка
«Одинаковое наставничество для всех» не работает. Джунам нужна структура и частая обратная связь, сеньорам — сложный контекст и пространство для решений.
| Уровень | Что развиваем | Как помогаем |
|---|---|---|
| Junior | Базовые практики и уверенность | Чек‑листы, парная работа, маленькие задачи, быстрый feedback, безопасный oncall‑онбординг. |
| Middle | Ownership и решения | Свой компонент/сервис, дизайн‑доки, ответственность за релиз, работа с качеством и долгом. |
| Senior | Сложность и влияние | Неопределенные задачи, кросс‑командные зависимости, стандарты, наставничество другим. |
| Staff+ | Масштаб и системные улучшения | Архитектура, SDLC, выравнивание стратегии и execution. См. Staff+ инженеры. |
Антипаттерны, которые ломают рост
- Микроменеджмент под видом помощи: вы «спасаете» задачу, но забираете автономию.
- 1-на-1 как отчет: человек не приносит сложные темы, потому что «это не про работу».
- Рост без возможностей: ожидаете нового уровня, но не даете задач и контекста.
- Непрозрачные ожидания: «будь проактивнее» без примеров поведения и критериев.
- Фаворитизм: интересные задачи уходят одним и тем же людям.
- Обратная связь раз в полгода: слишком поздно, чтобы учиться на ней в реальной работе.
- Стыд и наказание за ошибки: команда прячет проблемы, скорость падает.
30–60–90: простой план для техлида
Если вы хотите запустить развитие команды без бюрократии, начните с маленького, но регулярного цикла.
30 дней
Понять и выровнять
- Провести 1-на-1 со всеми, собрать цели и боли.
- Описать ожидания к качеству и «definition of done».
- Наметить 2–3 зоны роста команды (guardrails, ownership, коммуникация).
60 дней
Запустить практики
- Ввести ритм: регулярные 1-на-1 и короткий рост‑чек.
- Запустить 1–2 IDP‑цикла на 6–10 недель.
- Нормализовать дизайн‑ревью и постмортемы.
90 дней
Сделать масштабируемым
- Раздать ownership и «лестницу делегирования» по ключевым зонам.
- Зафиксировать гайды/шаблоны (вики, ADR, чек‑листы).
- Калибровать ожидания и прогресс (связка с performance review).
Итоги
- Рост команды начинается с системы: ожидания → возможности → feedback → guardrails.
- 1-на-1 — главный «канал управления ростом», если там есть доверие и конкретика.
- Делегирование и stretch‑задачи работают, когда есть безопасная рамка и поддержка.
- Наставничество не заменяет мотивацию и оценку — оно усиливает их. См. мотивацию и performance review.