Практики управления командами, лидерства, найма, оценки эффективности и построения здоровой инженерной культуры.
Переход в тимлиды — не следующий грейд, а смена профессии. Инструменты, которые сделали вас хорошим разработчиком, перестают работать: результат теперь производят не ваши руки, а измерять свою полезность закрытыми задачами больше нельзя. Курс о том, чем занят тимлид в те часы, когда не пишет код, и как принимать решения, у которых нет правильного варианта.
Шестнадцать тем, разбитых по видам работы.
Люди. Найм и технические интервью — от критериев оценки до предвзятости, которая незаметно управляет решением. Регулярные 1:1 и что делать, если они превратились в статус-митинг. Оценка эффективности, обратная связь, планы улучшения, продвижение. Конфликты: медиация, сложные разговоры, момент для эскалации. Карьерные треки, менторство и разница между менторством и спонсорством.
Техника и процесс. Техническая стратегия и дорожная карта, управление техдолгом, RFC и ADR как способ не пересматривать одно и то же решение каждые полгода. Метрики DORA и здоровье команды. Планирование, оценка сроков, риски. Код-ревью как процесс, а не как перепалка в комментариях.
Организация. Коммуникация со стейкхолдерами и отдельно — с руководством: принцип BLUF, перевод технического в бизнесовое, разговор с C-level во время инцидента. Управление изменениями по Коттеру и ADKAR, работа со скептиками. Масштабирование: закон Конвея, Team Topologies, что из модели Spotify работает вне Spotify.
Материал про инженерное управление в продуктовых командах — не про проектное управление по PMBOK и не про менеджмент вообще. Уровень — middle и senior: предполагается, что вы либо уже ведёте команду, либо вам это предложили и вы решаете, соглашаться ли.
Роль тимлида: технические решения, наставничество, код-ревью, баланс кодинга и управления
Технические интервью, критерии оценки, обратная связь, адаптация новых сотрудников, избежание предвзятости
Индивидуальные встречи 1:1, оценка эффективности, циклы обратной связи, планы улучшения, продвижение, карьерный рост
Межличностные конфликты, медиация, сложные разговоры, эскалация проблем
Техническая стратегия, дорожная карта, архитектурные решения, управление техническим долгом
Метрики DORA, скорость команды, время цикла, пропускная способность, оценка здоровья команды
Найм, адаптация сотрудников, построение культуры команды, удалённая и гибридная работа
Коммуникация с заинтересованными сторонами, документация, прозрачность, асинхронная коммуникация
Планирование, оценка сроков, управление рисками, приоритизация задач
Карьерные пути, наставничество, спонсорство, фреймворк роста
Scrum, Kanban, спринты, планирование, ретроспективы, ежедневные стендапы
Принятие технических решений, процесс RFC, документирование архитектурных решений
Модели Коттера и ADKAR, работа со скептиками, постепенное vs радикальное изменение, измерение принятия
Культура код-ревью, процесс ревью, обратная связь
BLUF принцип, перевод техническое→бизнес, форматы апдейтов, сложные разговоры с C-level, инцидент-коммуникация
Conway's Law, Team Topologies, Spotify model, найм EM, сохранение культуры при масштабировании
Доступен после всех тем (0 из 16)
Доступен после зачёта
Специалист, создающий ценность через личную экспертизу, а не через управление людьми. В инженерии — разработчик, который пишет код, проектирует системы, решает технические задачи. Карьера IC: Junior → Middle → Senior → Staff → Principal → Distinguished Engineer.
Пример
Иван — Senior Engineer (IC): его ценность в том, что он пишет код, делает code review, проектирует архитектуру. После перехода в тимлиды он стал управлять 5 людьми — и перестал быть IC.Связанные термины
Менеджер инженерной команды, фокус которого — люди, процессы и организация. Отвечает за найм, карьерный рост сотрудников, производительность команды и доставку результатов. В отличие от Tech Lead, EM меньше вовлечён в технические решения и больше — в организационные вопросы.
Пример
Мария — Engineering Manager: она проводит 1:1 с каждым из 8 разработчиков, ведёт Performance Review, нанимает новых людей, согласовывает дорожную карту с продуктом. Код она пишет редко — в основном как учебные примеры.Связанные термины
Технический лидер команды — роль, совмещающая разработку с техническим руководством. Отвечает за архитектурные решения, качество кода, технические стандарты и наставничество разработчиков. Как правило, продолжает писать код (20–50% времени). Может совмещаться с ролью Engineering Manager или существовать отдельно.
Пример
Алексей — Tech Lead команды backend: он пишет код 40% времени, ведёт архитектурные ревью, разрабатывает RFC для новых систем, проводит технические 1:1 и помогает джунам расти. HR-вопросами занимается отдельный EM.Связанные термины
Модель лидерства, при которой лидер ставит нужды команды выше своих. Задача лидера — устранять препятствия, обеспечивать ресурсы, развивать людей, а не командовать и контролировать. Ввёл Роберт Гринлиф в 1970 году. Основа большинства современных подходов к инженерному лидерству.
Пример
Тимлид замечает, что команда тратит 3 часа в день на ручное развёртывание. Вместо того чтобы поручить это кому-то, он сам пишет скрипт автоматизации, устраняя препятствие — это и есть servant leadership.Связанные термины
Передача ответственности за задачи и решения членам команды с необходимыми полномочиями и контекстом. Эффективное делегирование — не просто «поручить задачу», а передать ownership: человек понимает цель, имеет полномочия и знает, когда обращаться за помощью. Матрица делегирования: от «скажи» до «делегируй полностью».
Пример
Тимлид хочет делегировать проведение технических ревью. Он не просто говорит «теперь ты делаешь ревью», а объясняет критерии качества, проводит первые два ревью вместе, потом наблюдает, потом отпускает. Это полный цикл делегирования.Связанные термины
Убеждённость членов команды в том, что они не будут наказаны за высказывание идей, вопросов, сомнений или признание ошибок. Исследование Google (Project Aristotle, 2016) показало, что психологическая безопасность — ключевой фактор эффективности команды, важнее состава и компетентности людей.
Пример
Разработчик выпустил критический баг в продакшн. В команде с высокой психологической безопасностью он сам сообщает об этом, команда проводит blameless postmortem и улучшает процесс. В команде без неё — он скрывает баг до последнего.Связанные термины
Количество людей в прямом подчинении у менеджера. Оптимальный span: 5–8 человек для Engineering Manager (достаточно для глубоких 1:1), 3–5 для новых менеджеров, 10–15 для опытных EM с зрелой командой. При большем span качество управления падает.
Пример
У Дарьи в подчинении 12 разработчиков. На 1:1 раз в две недели с каждым она тратит 6 часов в месяц только на встречи. В итоге встречи стали формальными — span too wide, нужно нанимать тимлида.Связанные термины
Менеджер, у которого в прямом подчинении находятся другие менеджеры (а не IC-сотрудники). Типичная позиция: Director of Engineering, VP of Engineering. Задачи: выстраивание организационной структуры, найм и развитие менеджеров, координация нескольких команд.
Пример
Виктор — Director of Engineering: у него в подчинении три Engineering Manager, каждый из которых управляет командой из 6–8 человек. Виктор не управляет разработчиками напрямую — только через менеджеров.Связанные термины
Старший IC-специалист без формальной управленческой функции. Работает над системными проблемами, влияющими на несколько команд или всю организацию. Архетипы (по Will Larson): Tech Lead, Architect, Solver, Right Hand. Эквивалентен по грейду Engineering Manager.
Пример
Анна — Staff Engineer: она не управляет людьми, но её RFC по новой архитектуре данных затрагивает 5 команд. Она ведёт технические ревью на уровне организации, консультирует тимлидов и влияет на техническую стратегию через экспертизу.Связанные термины
IC-специалист уровня выше Staff Engineer. Влияет на техническое направление всей компании. Работает с горизонтом 3–5 лет, определяет технические стандарты и принципы для всей инженерной организации. Как правило, участвует в собеседованиях для Senior+ позиций.
Пример
Кирилл — Principal Engineer: он разработал концепцию перехода компании на event-driven architecture, провёл 6 месяцев на proof-of-concept, написал RFC, который стал основой для 3-летней технической стратегии.Связанные термины
Регулярные приватные встречи менеджера/тимлида с каждым членом команды. Цель — поддержка, обратная связь, карьерный рост, выявление проблем. Важно: это встреча сотрудника, а не менеджера. Формат: 30–60 минут еженедельно или раз в две недели. Менеджер слушает 70%, говорит 30%.
Пример
Каждый понедельник Игорь проводит 1:1 с каждым из 5 разработчиков. Он заранее просит заполнить шаблон: «Что идёт хорошо? Что мешает? Над чем хочешь расти?». 1:1 начинается с этих ответов, а не с обновлений по задачам.Связанные термины
Структура для конструктивной обратной связи: Situation (конкретная ситуация — когда и где), Behavior (наблюдаемое поведение — что именно сделал человек), Impact (влияние этого поведения — на команду, продукт, процесс). Устраняет обобщения, субъективность и личные оценки.
Пример
Вместо «ты всегда срываешь сроки»: «На вчерашнем стендапе (S) ты не сказал, что задача заблокирована уже два дня (B), из-за чего мы потеряли день на ожидание и не успели сдать фичу в срок (I)».Связанные термины
Формальный процесс оценки работы сотрудника за период (квартал, полгода, год). Включает самооценку, оценку менеджера, пир-ревью, 360° обратную связь. Результат: оценка по шкале (meets/exceeds/below expectations), решение о повышении/грейде, цели на следующий период.
Пример
В конце квартала Мария заполняет self-review, её 3 коллеги дают пир-ревью, менеджер собирает всё в оценку. Итог: «Exceeds Expectations» — Мария получает промоушн на Senior.Связанные термины
Система сбора обратной связи о сотруднике от всех, с кем он взаимодействует: менеджер сверху, коллеги на одном уровне (peers), подчинённые снизу, иногда внутренние заказчики. Даёт многогранную картину поведения человека в организации.
Пример
Перед Performance Review Дмитрий получает обратную связь от: своего EM (сверху), трёх коллег-разработчиков (peers) и двух джунов, которым он менторит (снизу). Это и есть 360°.Связанные термины
Формальный план улучшения производительности для сотрудника, чья работа не соответствует ожиданиям. Содержит: конкретные измеримые цели, срок (обычно 30–90 дней), еженедельный мониторинг. PIP — последний шаг перед расставанием. Хороший менеджер не доводит до PIP внезапно.
Пример
После трёх кварталов «Below Expectations» Илья получает PIP: «За 60 дней: завершить модуль оплаты, провести два технических ревью, не допустить критических багов в production». Промежуточная проверка через 30 дней.Связанные термины
Фреймворк постановки целей: Objective — амбициозная качественная цель («что хотим достичь»), Key Results — 3–5 измеримых результатов, подтверждающих достижение цели («как поймём, что достигли»). Цикл: квартал или год. Правило: выполнение OKR на 70% — норма, 100% — цель слишком лёгкая.
Пример
O: Стать лучшей командой по надёжности сервиса. KR1: Uptime > 99.9%. KR2: MTTR < 15 минут. KR3: Deployment Frequency ≥ 10 в неделю. KR4: Zero P0 инцидентов из-за недостатков процесса.Связанные термины
Ключевые показатели эффективности — метрики, отражающие прогресс к стратегическим целям. В отличие от OKR, KPI обычно стабильны во времени и измеряют «здоровье» системы. В инженерии: Deployment Frequency, MTTR, Code Coverage, Bug Rate.
Пример
KPI команды backend: Deployment Frequency (не реже 5 раз в неделю), P95 Latency (< 200ms), Error Rate (< 0.1%), Test Coverage (> 80%). Эти метрики команда мониторит постоянно, а не только в конце квартала.Связанные термины
Метрика лояльности и удовлетворённости сотрудников. Вопрос: «С какой вероятностью (0–10) вы порекомендуете эту компанию как место работы?». Promoters (9–10) − Detractors (0–6) = eNPS. Значение: >20 хорошо, >50 отлично, <0 тревожный сигнал.
Пример
В команде из 10 человек: 6 поставили 9–10 (Promoters), 2 поставили 7–8 (Passives, не учитываются), 2 поставили 0–6 (Detractors). eNPS = 60% − 20% = 40. Хороший результат.Связанные термины
Сотрудник, стабильно превосходящий ожидания по результатам и влиянию. Создаёт непропорционально большую ценность для команды. Задача менеджера: сохранить, развивать и дать достаточно сложные задачи, иначе уйдут. Противопоставление: Brilliant Jerk — высокоэффективный, но токсичный.
Пример
Наташа закрывает в два раза больше задач, чем остальные, менторит джунов и принесла идею, сэкономившую 200 часов в квартал. Её менеджер дал ей отдельный сложный проект и договорился о повышении грейда, чтобы удержать.Связанные термины
Метод проведения собеседования с заранее определёнными вопросами, критериями оценки и шкалой для каждого кандидата. Все кандидаты оцениваются по одним и тем же критериям. Снижает влияние когнитивных предвзятостей. Доказано увеличивает прогностическую валидность найма.
Пример
Для роли Senior Backend перед интервью команда договорилась: 3 вопроса на System Design, 2 — на поведение по STAR, оценка по шкале 1–4 по 5 критериям. Все 4 интервьюера используют одинаковые вопросы и рубрику.Связанные термины
Документ, определяющий критерии успеха для конкретной роли: необходимые навыки, компетенции, миссия позиции. Используется для оценки кандидатов и onboarding. Позволяет объективно сравнивать кандидатов и избегать решений на основе «ощущений».
Пример
Scorecard для Frontend Lead: 1) Знает React + TypeScript (must have), 2) Опыт наставничества (must have), 3) Опыт code review процессов (strong plus), 4) Знакомство с micro-frontends (nice to have). Каждый пункт оценивается по шкале 1–4.Связанные термины
Систематические ошибки в оценке кандидатов, влияющие на решение о найме. Основные: Halo Effect (одна сильная черта перекрывает слабости), Affinity Bias (предпочтение похожих на себя), Confirmation Bias (поиск подтверждения первого впечатления), Attribution Error.
Пример
Кандидат работал в Google — интервьюер автоматически ставит высокие оценки (Halo Effect). Структурированное интервью с рубрикой заставляет оценивать конкретные ответы, а не «бренд» кандидата.Связанные термины
Структурированный процесс введения нового сотрудника в роль, команду и компанию. Включает: техническую подготовку (доступы, инструменты), контекст продукта и бизнеса, знакомство с командой, первые задачи. Хороший онбординг длится 3–6 месяцев, не 2 дня.
Пример
Первая неделя нового разработчика: понедельник — оргвопросы и доступы, вторник — обзор архитектуры с тимлидом, среда — первый PR (маленькая задача), четверг-пятница — парное программирование с ментором. Всё это часть онбординг-плана.Связанные термины
Структурированный план для нового сотрудника или менеджера: 30 дней — обучение и наблюдение (слушать, читать, задавать вопросы), 60 дней — участие и вклад (малые победы, понять культуру), 90 дней — ownership (самостоятельное ведение задач и инициативы).
Пример
Новый тимлид в первые 30 дней: провёл 1:1 со всеми, прочитал всю документацию, не принимал решений без контекста. На 60-й день предложил улучшение в процессе code review. На 90-й — взял ownership над roadmap квартала.Связанные термины
Culture Fit — найм людей, похожих на существующую команду (риск: однородность, echo chamber). Culture Add — найм людей, добавляющих что-то новое к культуре (разнообразие точек зрения, опыта, подходов). Современная практика отдаёт предпочтение Culture Add.
Пример
Команда из 6 backend-разработчиков нанимает седьмого. Culture Fit — ещё один Python-разработчик с таким же стеком. Culture Add — разработчик с опытом в Go и distributed systems, который расширит кругозор команды.Связанные термины
Документ, описывающий предлагаемое техническое изменение и открывающий его для обсуждения перед реализацией. Структура: проблема, предлагаемое решение, альтернативы, компромиссы. Позволяет получить экспертизу команды до начала кодинга.
Пример
Разработчик предлагает перейти с REST на GraphQL. Он пишет RFC: описывает текущие проблемы REST, плюсы и минусы GraphQL, план миграции, риски. Команда комментирует 5 дней, затем принимается решение.Связанные термины
Лёгкий документ, фиксирующий архитектурное решение, принятое в конкретный момент: контекст (почему стояла задача), решение (что выбрали), статус (proposed/accepted/deprecated), последствия (что изменилось). ADR — это история решений команды.
Пример
ADR-0042: «Выбор очереди сообщений». Контекст: нужна асинхронная обработка платежей. Рассматривали: RabbitMQ, Kafka, SQS. Решение: SQS — проще в эксплуатации для нашего масштаба. Последствия: нет replay, но нет и операционной сложности Kafka.Связанные термины
Фреймворк распределения ролей при принятии решений. Driver — тот, кто ведёт процесс принятия решения. Approver — тот, кто принимает финальное решение (один человек). Contributors — эксперты, дающие входные данные. Informed — те, кого нужно уведомить о решении.
Пример
Решение о выборе облачного провайдера: Driver — тимлид инфраструктуры (ведёт исследование), Approver — CTO (финальное «да»), Contributors — Backend Lead и Security Engineer (дают требования), Informed — все команды (получат уведомление).Связанные термины
Ретроспектива после инцидента, сфокусированная на системных причинах, а не на поиске виновных. Принцип: люди не делают ошибок намеренно; ошибки указывают на несовершенство системы, процесса или инструментов. Результат: конкретные действия по предотвращению повторения.
Пример
После 2-часового даунтайма команда провела постмортем. Вместо «Иван сделал неверный деплой» — «Процесс деплоя не требовал подтверждения для production, что позволило ошибке проникнуть в prod. Решение: добавить обязательный этап ревью в CI/CD пайплайн».Связанные термины
Практика проверки кода перед мерджем в основную ветку. Цели: нахождение багов, обмен знаниями, поддержание стандартов кода, наставничество. Эффективный ревью: конкретные замечания с обоснованием, различие между must fix и nice to have, уважительный тон.
Пример
Принципы ревью в команде: комментарий типа «nit:» = необязательное улучшение, «blocking:» = нужно исправить, «question:» = хочу понять. Цель — завершить ревью в течение 24 часов после запроса.Связанные термины
Согласованный командой перечень критериев, при выполнении которых задача считается завершённой. Примеры критериев: код написан и прошёл ревью, тесты написаны и проходят, документация обновлена, задеплоено на staging, прошло QA. Применяется ко всем задачам одинаково.
Пример
DoD команды: 1) Code review от двух разработчиков, 2) Unit tests coverage ≥ 80%, 3) E2E test для critical path, 4) Deployed on staging, 5) QA sign-off, 6) CHANGELOG обновлён. Без всего этого задача не Done.Связанные термины
Накопленная стоимость компромиссных технических решений: плохо структурированный код, устаревшие зависимости, отсутствие тестов, архитектурные ограничения. Как финансовый долг: можно взять умышленно (sprint debt) или накопить случайно. Нужно регулярно «выплачивать».
Пример
Команда полгода добавляла фичи без рефакторинга. Теперь каждая новая задача занимает в 3 раза дольше. Тимлид договорился с PM: 20% каждого спринта идёт на технический долг, пока не восстановим скорость.Связанные термины
Документ с пошаговыми инструкциями для выполнения операционных задач или реагирования на инциденты. Цель: любой дежурный инженер (не только автор) может выполнить задачу по инструкции. Снижает Bus Factor в операционных процессах.
Пример
Runbook «Database failover»: 1) Проверь репликацию (команды в секции 1), 2) Уведоми команду в #ops-channel, 3) Переключи connection string (секция 2), 4) Верифицируй (тест в секции 3), 5) Закрой инцидент и обнови постмортем.Связанные термины
Документ, описывающий техническое направление развития на 6–18 месяцев: планируемые улучшения инфраструктуры, погашение технического долга, миграции, платформенные инициативы. Согласуется с бизнес-приоритетами и обновляется ежеквартально.
Пример
Technical Roadmap Q1-Q3: Q1 — миграция на Kubernetes (снижение cost), Q2 — внедрение service mesh для безопасности, Q3 — переход на event-driven architecture для масштабируемости. Каждый пункт имеет бизнес-обоснование.Связанные термины
Долгосрочное (2–5 лет) описание желаемого состояния технической системы. Отвечает на вопрос «Куда мы хотим прийти?». Служит ориентиром для тактических решений: каждое архитектурное решение должно приближать к видению или не противоречить ему.
Пример
Technical Vision команды платформы: «Через 3 года разработчики смогут деплоить новый сервис за 30 минут без участия DevOps, с автоматической настройкой мониторинга, логирования и security». Это видение, а не план.Связанные термины
Фреймворк для принятия решения о разработке компонента: Build (разрабатываем сами — дорого, но максимальный контроль), Buy (покупаем готовое решение — быстро, но зависимость от вендора), Reuse (используем существующее внутри компании или open source). Выбор зависит от стратегической важности и зрелости рынка.
Пример
Нужна система аутентификации. Анализ: Auth — не дифференциатор бизнеса, зрелые решения существуют. Решение: Buy (Auth0) — экономия 3 месяцев разработки. Платёжная логика — дифференциатор: Build.Связанные термины
Документ, перечисляющий потенциальные риски проекта или системы с оценкой вероятности и влияния, планом митигации и ответственным. Позволяет управлять рисками проактивно, а не реагировать на проблемы постфактум.
Пример
Risk Register проекта: Риск «Внешний API станет недоступен» — вероятность: средняя, влияние: критическое, митигация: кэширование + fallback на cached data, ответственный: Игорь. Пересматривается каждые 2 недели.Связанные термины
Единственная метрика, которая лучше всего отражает ценность продукта для пользователей и коррелирует с долгосрочным ростом бизнеса. Служит ориентиром для принятия решений: «Эта фича улучшит North Star?». Примеры: Airbnb — ночи забронированы, Spotify — время прослушивания.
Пример
North Star Metric платформы разработчиков: «Количество деплоев в production в неделю». Каждая инициатива оценивается: «Это увеличит количество деплоев?». Если нет — переосмысляем приоритет.Связанные термины
Коммуникация, не требующая немедленного ответа: email, документы, записанные видео, комментарии в задачах. Противоположность — синхронная коммуникация (встречи, звонки). В распределённых и удалённых командах async-first подход увеличивает продуктивность и уменьшает количество встреч.
Пример
Команда перешла на async-first: обновления по задачам — в Jira-комментариях, технические обсуждения — в Google Docs, срочные вопросы — в Slack с SLA ответа 4 часа. Количество встреч сократилось с 15 до 5 в неделю.Связанные термины
Выявление всех заинтересованных сторон проекта, понимание их интересов и ожиданий, выстраивание коммуникации с каждой группой. Матрица: High Power + High Interest = manage closely, Low Power + High Interest = keep informed. Тимлид тратит 20–30% времени на это.
Пример
Перед запуском нового API тимлид составил карту стейкхолдеров: CTO (High/High — еженедельный статус), команды-потребители API (Low/High — changelog рассылка), юридический отдел (High/Low — разовое согласование данных).Связанные термины
Систематическая запись технических решений, процессов, архитектуры и знаний команды. Типы: ADR (решения), Runbook (операции), Architecture Diagrams (структура), Onboarding Guide (введение). Принцип: документация — часть Definition of Done, не опциональная добавка.
Пример
Правило команды: каждый новый сервис должен иметь README с: описанием, как запустить локально, как задеплоить, ссылкой на ADR о причинах создания. Без этого PR не мерджится.Связанные термины
Четыре ключевых метрики эффективности инженерных команд, разработанные DevOps Research and Assessment (DORA). Измеряют скорость и стабильность доставки программного обеспечения. Коррелируют с бизнес-результатами и удовлетворённостью команды.
Пример
Elite команда по DORA: деплоит несколько раз в день, Lead Time < 1 часа, MTTR < 1 часа, Change Failure Rate < 5%. Это реальные цели, достигнутые командами в книге 'Accelerate'.Связанные термины
Первая метрика DORA: как часто команда успешно деплоит код в production. Уровни: Elite — несколько раз в день, High — раз в день/неделю, Medium — раз в месяц, Low — реже месяца. Высокая частота = меньший размер изменений = меньший риск.
Пример
Команда перешла с monthly релизов на daily деплои через feature flags. Deployment Frequency выросла с 1 до 20 в месяц. Размер каждого деплоя уменьшился в 20 раз, количество инцидентов сократилось вдвое.Связанные термины
Вторая метрика DORA: время от первого коммита до развёртывания в production. Включает: время ревью, прохождения CI, QA, staging. Уровни: Elite < 1 часа, High < 1 дня, Medium 1 неделя – 1 месяц, Low > месяца.
Пример
В команде Lead Time = 3 дня: 4 часа на code review + 2 часа CI/CD + 2 дня ожидания QA (узкое место). Решение: добавить QA-автоматизацию → Lead Time сократился до 6 часов.Связанные термины
Третья метрика DORA: среднее время восстановления сервиса после инцидента. Уровни: Elite < 1 часа, High < 1 дня, Medium < 1 недели, Low > недели. Зависит от: качества мониторинга, наличия runbooks, автоматического rollback.
Пример
Инцидент: база данных недоступна. При MTTR = 4 часа команда тратила: 30 мин на обнаружение (плохой алертинг), 3 часа на диагностику (нет runbook), 30 мин на восстановление. После добавления алертов и runbook — MTTR = 25 минут.Связанные термины
Четвёртая метрика DORA: процент деплоев, вызвавших инцидент или потребовавших rollback. Уровни: Elite < 5%, High 5–10%, Medium 10–15%, Low > 15%. Высокий CFR указывает на проблемы с тестированием или процессом деплоя.
Пример
Из 50 деплоев за месяц 8 потребовали hotfix или rollback: Change Failure Rate = 16% — уровень Medium. Команда добавила end-to-end тесты для critical paths → CFR снизился до 4%.Связанные термины
Классификация DORA для высокоэффективных инженерных команд. Характеристики: Deployment Frequency — несколько раз в день, Lead Time for Changes < 1 часа, MTTR < 1 часа, Change Failure Rate < 5%. Исследование DORA показало, что elite-команды показывают лучшие бизнес-результаты.
Пример
Google, Netflix и Amazon — примеры организаций с elite-метриками DORA. Они деплоят тысячи раз в день, восстанавливаются после инцидентов за минуты. Это достижимо и для небольших команд при правильных практиках.Связанные термины
Анти-паттерн управления: избыточный контроль над деталями работы сотрудников, неспособность делегировать, постоянные проверки прогресса. Признаки: менеджер участвует в каждом решении, разработчики спрашивают разрешения на мелкие действия, нет автономии. Убивает мотивацию и рост.
Пример
Тимлид читает каждый коммит, правит чужой код без объяснений, требует отчёт о каждом часе работы. Разработчики перестают принимать инициативу — зачем, если всё равно переделают. Текучесть в команде растёт.Связанные термины
Анти-паттерн: один разработчик, знающий критически важные части системы и регулярно «спасающий» ситуацию в кризис. Краткосрочно выглядит как ценность. Долгосрочно: Bus Factor = 1, выгорание героя, отсутствие документации и обмена знаниями.
Пример
Только Денис знает, как перезапустить систему очередей в production. Каждый раз при сбое все ждут именно его. Денис работает ночами и в выходные. В итоге — выгорание и увольнение, следом — хаос.Связанные термины
Анти-паттерн: архитектор, принимающий технические решения изолированно от команды, не понимающий реальных операционных и разработческих ограничений. Создаёт «идеальные» архитектуры, которые невозможно реализовать на практике. Противоположность — embedded architect.
Пример
Главный архитектор спроектировал микросервисную архитектуру с 50 сервисами для команды из 5 разработчиков. Команда потратила год на инфраструктуру и ничего не доставила пользователям.Связанные термины
Анти-паттерн: менеджер, который долго не появляется, затем неожиданно «прилетает», «шумит», раздаёт команды и критику, и снова исчезает — оставив команду разбираться с последствиями. Деморализует команду и разрушает доверие.
Пример
CTO раз в месяц заходит на дейли, критикует технические решения, принятые без его ведома, требует немедленно всё переделать, и исчезает. Команда боится принимать решения самостоятельно.Связанные термины
Минимальное количество людей, которых нужно потерять (внезапно заболели, уволились, попали под автобус), чтобы проект оказался в критическом состоянии. Bus Factor = 1 — критический риск. Цель: повысить до 3+ через документацию, ротацию задач и парное программирование.
Пример
Bus Factor = 1: только Наташа понимает систему биллинга. Если она уйдёт — никто не сможет поддерживать критический сервис. Решение: Наташа написала документацию + провела knowledge sharing с двумя коллегами.Связанные термины
Анти-паттерн: высококвалифицированный специалист с деструктивным поведением: грубит коллегам, не уважает чужое мнение, создаёт токсичную атмосферу. Исследования показывают: один Brilliant Jerk снижает производительность команды на 30–40% из-за психологической небезопасности.
Пример
Максим — лучший разработчик по метрикам, но на ревью пишет унижающие комментарии, перебивает на встречах, открыто насмехается над идеями джунов. Трое разработчиков уволились. Потеря превысила его вклад.Связанные термины
Формальный документ, описывающий грейды и ожидания для каждого уровня в инженерной организации. Содержит: технические компетенции, scope влияния, поведенческие ожидания. Примеры уровней: Junior → Middle → Senior → Staff → Principal. Инструмент для прозрачного карьерного роста.
Пример
Career Ladder для Senior Engineer: технически — проектирует системы уровня команды, самостоятельно выполняет амбициозные задачи; по impact — влияние на 1 команду; по поведению — наставляет Junior, участвует в найме.Связанные термины
Mentoring — развитие сотрудника через советы, обучение, обмен опытом. Sponsoring — активное продвижение человека: рекомендации на повышение, включение в видимые проекты, защита перед руководством. Sponsorship действует от человека с влиянием и более напрямую ведёт к росту.
Пример
Ментор говорит: «Вот что тебе нужно улучшить для Senior». Спонсор говорит: «Я предлагаю Машу на роль Tech Lead в новом проекте — она готова». Спонсор рискует своей репутацией, рекомендуя человека.Связанные термины
Состав курса, уровни, практика и способы проверки знаний.
Курс включает 16 тем и 168 вопросов с разбором ответа. Начать можно с первой темы курса.
Маршрут охватывает уровни Middle, Senior. Темы расположены от основы к более сложным инженерным задачам, поэтому можно начать с подходящего места и не пропускать важные зависимости.
После прохождения тем доступен зачёт по курсу «Управление и лидерство» — 20 случайных вопросов с порогом 80%. После зачёта открывается экзамен с развёрнутыми ответами и автоматической оценкой, приближённый к техническому собеседованию.
Да, курс полностью бесплатный: все 16 тем доступны без оплаты.