---
title: База знаний к секции про управленческий опыт — канон people-менеджмента
source: подготовлено 2026-10-07, TASK-50; по materials/ (официальная страница Яндекса, банки вопросов, Практикум), канону менеджмента и подтверждённому опыту пользователя
---

# База знаний: управление людьми и командами

Десять разделов — по одному на типовой блок вопросов. Формат: что это → как звучит сильный ответ → инструменты → твоя фактура.

## §1. Целеполагание

**Суть:** перевести бизнес-цель в цели команды так, чтобы каждая была измеримой, имела владельца и каденцию проверки.

- Иерархия: бизнес-цель → цель команды/квартала → результат (outcome, не output) → задачи.
- **SMART**: конкретная, измеримая, достижимая, релевантная, ограниченная сроком. **OKR**: Objective + 3–4 Key Results, амбициозность; KR — измеримый результат, не список задач.
- **Outcome vs output**: «сделать миграцию» — output; «сократить время синхронизации остатков в 10 раз» — outcome.
- Каденция: квартальные цели → ревью раз в 2 недели → корректировка (менять цель или ресурсы, а не «терпеть»).
- **Технические цели** (для лида): техроудмап, техдолг как отдельная цель с бюджетом, надёжность (SLO), скорость поставки.
- Инструменты: техроудмап, PBR (Product Backlog Refinement), квартальное планирование, матрица приоритетов.

**Фразы:** «цель без метрики и владельца — пожелание»; «если цель нельзя увидеть в бизнес-результате — это задача, а не цель»; «плана нет, есть гипотеза, которую проверяем каждые две недели».

**Твоя фактура:** единый техроудмап трёх команд (Райф), техдолг-процесс (Райф, Самокат), PBR и дежурства (Баланс), планирование трёх запусков (Самокат).

## §2. 1:1 (главный инструмент)

**Суть:** регулярная встреча, где повестку задаёт сотрудник, а не статус задач.

- Цели: доверие, раннее выявление проблем, карьера и мотивация, честная обратная связь в обе стороны.
- Что обсуждать: как дела (человек, не только проект), препятствия, рост и цели, отношения в команде, обратная связь мне как руководителю.
- Частота: раз в 1–2 недели, 30–45 минут, не переносить; документировать договорённости и возвращаться к ним.
- Anti-patterns: превращать в статус-репорт; отменять при загрузке; вести монолог; обсуждать только текущие задачи.
- Признак зрелости: «что менялось по итогам 1:1» (росли задачи, уходили блокеры, менялись планы развития).

**Твоя фактура:** выстроил регулярный процесс 1:1 (Райф); ~20 выросших инженеров за 9 лет — прямой результат работы через 1:1 и делегирование.

## §3. Обратная связь

**Суть:** конкретная, своевременная, приватная, с планом — иначе не работает.

- **SBI**: Situation (когда/где) → Behaviour (что конкретно сделал/не сделал) → Impact (какое влияние). Без обобщений («ты всегда…»).
- **Radical candor**: забота лично + честный вызов напрямую (не «рутинная неискренность» и не «обструктивная агрессия»).
- Позитивная обратная связь тоже нужна и тоже конкретна; публично — хвалить, приватно — критиковать.
- Feedforward: не только «что было не так», но «как сделать в следующий раз».
- Разговор о несоответствии: факты → влияние → ожидания → план с точками контроля → последствия.

**Фразы:** «негативный фидбек не должен быть сюрпризом на перформанс-ревью — он звучит в момент события».

## §4. Конфликты

**Суть:** конфликт — норма; задача лида — превратить его в решение, а не погасить.

- **Томас-Килманн** (5 стилей): соперничество (важно и срочно), сотрудничество (важно и долгосрочно), компромисс, избегание, приспособление. Выбор зависит от важности цели и отношений.
- Техника: разделить **людей и проблему**; выслушать обе стороны отдельно; свести спор **к критериям и данным** (не «кто прав», а «какой критерий»); назначить владельца решения; договориться о «disagree and commit».
- Эскалация — нормальный инструмент, если конфликт блокирует или пересекает зоны; не «провал лида».
- Типы: технический спор, личностный конфликт, конфликт ролей/зон, конфликт с бизнесом (сроки vs качество), с руководителем.
- **Формулировка через KPI, а не личность:** «недопонимание в приоритетах: продакту важен T2M, мне — стабильность платформы» вместо «продакт неадекватный». Любая критика бывших коллег — моментальный No Hire.

**Фразы:** «я не искал виноватого — свёл спор к критерию и данным»; «решение приняли одно, а недовольных выслушали всех»; «затяжной конфликт дороже любого технического спора».

**Твоя фактура:** архитектурные споры (DDD, миграции БД, ClickHouse↔PostgreSQL) — решались критериями, POC и владельцем решения; конфликты сроки↔качество с бизнесом.

## §5. Найм

**Суть:** предсказуемый процесс вместо «понравился/не понравился».

- Профиль: hard skills обязательные vs изучаемые, поведенческие требования, **culture add** (что человек привнесёт), а не «culture fit».
- Структурное интервью: одинаковые вопросы к кандидатам, оценка по шкале, ситуационные вопросы («расскажи про…»), участие команды, отдельный сборщик решения.
- Оценка: техническая часть + мотивация + зона роста; проверять, как человек учится и реагирует на неизвестное.
- Онбординг: план первого месяца (buddy, доступы, окружение, первая задача, критерии успеха) — часть найма, а не «после».
- Метрики: time-to-hire, доля прошедших испытательный, retention 6 мес, качество найма (по оценке команды).

**Фразы:** «ошиблись в найме — дороже, чем в архитектуре: переделывать долго, расставаться больно»; «сначала критерии, потом знакомство».

**Твоя фактура:** комплексная система оценки кандидатов (Баланс); формирование команд с нуля и найм (Самокат); DevContainers/скрипты для быстрого онбординга (Дикси).

## §6. Развитие и повышения

**Суть:** развитие — управляемый процесс с измеримыми признаками, а не «повезло с сотрудником».

- Матрица компетенций / грейды: что отличает уровни (самостоятельность, зона ответственности, влияние).
- ИПР: цель развития → действия (70-20-10: практика/окружение/обучение) → точки контроля → измеримый результат.
- Признаки готовности к повышению: **консистентность** результата, расширение зоны ответственности, влияние на команду, самостоятельность — не «старался год».
- Делегирование как инструмент роста: давать зону, а не задачу; точки синхронизации вместо микроменеджмента; приёмка по результату.
- Менторство/коучинг: наводящие вопросы вместо готовых ответов; парное программирование; постепенное усложнение.
- **Преемники**: подготовка того, кто может занять твою роль, — критерий зрелости лидера и условие его роста.
- **Bus-factor**: если знание живёт в одном человеке — это риск команды; лечится кросс-ревью, парной работой, документацией, ротацией зон. «Внедрил кросс-ревью, чтобы не было bus-фактора» — сильный системный ответ на ошибку одного человека.

**Фразы:** «растить не за счёт своих задач, а раздавая зоны ответственности»; «если подготовил преемника — ты готов к следующей ступени»; «3 тимлида из своей команды — мой лучший результат».

**Твоя фактура:** матрица компетенций + 10+ семинаров (Баланс); 5 повышений и преемник (Самокат); 3 разработчика → тимлиды (Телематика); преемник (Баланс); инициированное повышение (Райф).

## §7. Сложные решения по людям (расставания)

**Суть:** решение о расставании — результат процесса, а не настроения; готовность принять его вовремя — часть работы лида.

- Этапы: зафиксировать ожидания → план улучшения с точками контроля → честная обратная связь на каждом шаге → решение → человечное проведение расставания → работа с командой.
- Ключевое правило: **расставание не должно быть сюрпризом** — если человек удивлён, значит, обратная связь раньше не звучала.
- Особые случаи: несоответствие на испытательном; **токсичный топ-перформер** (здоровье команды важнее личной производительности — рецидив = расставание); отказ в повышении (тоже сложный разговор).
- Эффект на команду: объяснить решение в допустимых рамках (без деталей), снять неопределённость, перераспределить зоны.

**Фразы:** «дали все шансы, зафиксировали ожидания — решение было честным»; «я отвечаю за команду, а не только за результат одного человека».

## §8. Ресурсы и техстратегия

**Суть:** лид умеет переводить технические потребности на язык ресурсов и бизнеса.

- **Техдолг продаётся бизнесу только в его единицах — скорость, деньги, риск.** Провальный диалог: «нужно 2 спринта на рефакторинг» — «зачем?» — «код плохой» — «он работает? работайте». Сильный: «выкатка фичи в модуле выросла с 3 дней до 2 недель; здесь 40% прод-инцидентов; онбординг — месяц; вот план на 2 спринта и что станет с этими цифрами».

- Планирование мощностей: сколько людей/времени нужно, где узкое место, что не делаем (явные не-цели).
- Техдолг: реестр, приоритизация по влиянию на бизнес и риск, доля спринта, аргументация перед продуктом.
- Надёжность: SLO/SLA, дежурства, инцидент-процесс, постмортемы без поиска виноватых.
- Миграции/архитектурные изменения: этапность, пилот, метрики готовности, план отката.
- Бюджет и найм: обоснование перед руководством в цифрах (ёмкость, риск, стоимость бездействия).

**Фраза:** «прихожу не с "нам нужен рефакторинг", а с двумя вариантами и ценой каждого».

**Твоя фактура:** миграция на новую инфраструктуру (готовность 80%, Райф), единый техдолг-процесс, C4-схемы, CI-параллелизация (Дикси), RPC-протокол и Core-библиотека (Баланс).

## §9. Коммуникации и стейкхолдеры

**Суть:** влиять без власти, держать три направления: вверх, вниз, в стороны.

- Стейкхолдеры: бизнес/заказчик, смежные команды, руководитель, команда.
- Влияние: аргументы данными и ценой вариантов, early alignment (не ставить перед фактом), прозрачность статусов и рисков.
- Защита команды: взять удар на себя, снять шум, но не скрывать проблемы (скрытые проблемы — дороже).
- Конфликт с руководителем: не «победить», а «выяснить стоящую задачу и показать цену выбора».
- Синхронизация команд: Scrum of Scrums-жанр, единые ритуалы, общие цели.

**Фраза:** «вверх — с фактами и вариантами; вниз — с контекстом; в стороны — с договорённостями».

**Твоя фактура:** синхронизация трёх команд в единый юнит (Райф), единые процессы для новых команд (Самокат), доклады и семинары как внешняя коммуникация экспертизы.

## §10. Команда, культура, метрики

- Размер команды: 5–9 человек — оптимум для прямой коммуникации; больше → делиться или появляется иерархия.
- **Психологическая безопасность** (Google Project Aristotle): можно ошибаться, задавать вопросы, признавать незнание — основа обучения.
- Инженерные метрики (DORA): частота деплоя, lead time, MTTR, доля неуспешных изменений — «здоровье» команды, а не KPI людей.
- Ритуалы: ежедневные синки, ретро, планирование, демо, постмортемы.
- Текучка vs удержание: считать причины уходов; растить людей важнее, чем бояться, что уйдут («если ушёл сильнее — ты инвестор в репутацию»).

**Фраза:** «метрики команды — для улучшения процессов, а не для оценки людей».

---

## §11. Выгорание и благополучие

**Суть:** выгорание — не «слабость», а риск команды; лид замечает ранние сигналы и действует до срыва.

- Ранние сигналы: падение темпа без причины, цинизм, отказ от сложных задач, отдаление от команды, рост ошибок, «тихий» сотрудник.
- Что делать: честный разговор на 1:1 (без обвинений), понять причину (перегрузка, однообразные задачи, конфликт, потеря смысла), пересмотреть нагрузку и задачи, защитить границы времени, при необходимости — отпуск/пауза, вовлечь в новое.
- Что не делать: игнорировать («само пройдёт»), давить, превращать в публичное обсуждение, обещать то, что не в твоей власти.
- Профилактика: понятные цели, разнообразие задач, признание результата, адекватные сроки, ротация, возможность роста.

**Фразы:** «выгорание я вижу раньше, чем падение метрик»; «сначала разговор, потом решение — часто причина не в работе».

## §12. Инциденты и Blameless Postmortem

**Суть:** цель разбора — изменить систему, а не найти виновного; страх наказания убивает информацию.

- Blameless: разбираем не «кто виноват», а «какие условия позволили ошибке произойти» (процесс, автоматизация, обзор, документация).
- Структура постмортема: хронология → влияние (пользователи, минуты недоступности, деньги) → корневые причины (5 why) → что сделаем, чтобы не повторилось → владельцы и сроки.
- Инцидент-процесс: роли (кто координирует, кто коммуницирует), статус-обновления, эскалация, откат, разбор в течение недели.
- Метрики: MTTD/MTTR, доля повторных инцидентов, доля действий из постмортемов, выполненных в срок.
- Связь с секцией: «расскажите о самом крупном факапе» — сильный ответ: моя роль в моменте → как тушили → системные выводы → что изменилось (процесс/автотесты/алерты) → как изменилась практика.

**Фразы:** «мы разбираем систему, а не людей: если ошибся человек, значит, процесс позволил это сделать»; «после факапа появился X — вот что именно изменилось».

## Как этим пользоваться на секции

Не рассказывать теорию. Инструменты (SBI, Томас-Килманн, SMART) называть **один раз и в связке с историей**: «применяли SBI: сначала факт, потом влияние — вот что поменялось». Теория показывает, что ты знаешь рамку; история — что ты её жил.

## Связанные документы
- [`methodology.md`](methodology.md) — скелеты ответов и план подготовки
- [`experience-map.md`](experience-map.md) — твои истории под каждый раздел
- [`materials/03-practicum-managing-team.md`](materials/03-practicum-managing-team.md) — чек-лист «что значит управлять командой»
- [`materials/04-external-digest-4-kita.md`](materials/04-external-digest-4-kita.md) — 4 кита вопросов, кейсы, пропорции STAR, типовые ошибки (реконструкция)
- [`materials/05-habr-12952-interviews.md`](materials/05-habr-12952-interviews.md) — эмпирика реальных интервью: что спрашивают и как читают ответы