Курс на лида — это не “как стать приятным начальником”.
Это программа про то, как инженер перестаёт быть только исполнителем задач и начинает держать контур ответственности за систему, команду, delivery, качество решений, риски и смысл работы.
То есть лид — это не “главный программист” и не “мини-менеджер”. Это человек, который отвечает за то, чтобы техническая реальность не распалась на хаос: задачи, архитектура, люди, сроки, долги, баги, релизы, требования, конфликты, собеседования, онбординг, код, продакшен, заказчики.
Чтобы говорить о границах ответственности лида, необходимо обозначить соседнюю ответственность — за продуктовую сторону решений: цель, ценность, приоритет и продуктовый scope. В этом курсе субъекта, который её удерживает, будем называть Product Owner. Название пришло из Scrum, но сегодня используется и за его пределами. Конкретное название роли и распределение полномочий зависят от организации.
1. Переход от Senior к Lead
Не “ты теперь лучше кодишь”, а:
- как меняется зона ответственности;
- почему лид отвечает не только за свои задачи;
- чем отличается “сделал сам” от “сделал так, чтобы команда могла сделать”;
- почему лид должен видеть систему целиком;
- где граница между Tech Lead, Team Lead, Engineering Manager, Architect, Product Owner;
- что значит “держать delivery”, а не просто “участвовать в разработке”.
Здесь важное различение:
Senior Developer:
отвечает за сложную часть работы.
Tech Lead / Team Lead:
отвечает за то, чтобы сложная работа стала выполнимой для команды.
И это огромная разница.
2. Команда как инженерная система
Команда — это не “набор людей”.
Команда — это производственная система, у которой есть:
- входящие требования;
- очередь задач;
- ограничения;
- узкие места;
- зависимости;
- скорость принятия решений;
- качество коммуникации;
- уровень технического долга;
- уровень автономности;
- способность восстанавливаться после сбоев.
Вот тут можно давать разбор:
Что команда умеет?
Где команда зависает?
Где теряется смысл?
Где задачи превращаются в болото?
Где один сильный инженер тащит всё на себе?
Где команда симулирует Agile, но фактически живёт в ручном управлении?
Сюда хорошо ложится Team Topologies: там команда рассматривается не абстрактно, а через типы команд, границы ответственности, cognitive load и режимы взаимодействия между командами. В их модели есть четыре фундаментальных типа команд и три основных режима взаимодействия: Collaboration, X-as-a-Service и Facilitation. (teamtopologies.com)
3. Delivery: как доводить работу до результата
Это прям ядро курса.
Потому что лид без delivery — это философствующий старший разработчик.
А лид с delivery — это человек, который умеет превращать мутное требование в поставленный результат.
Модуль должен включать:
- декомпозицию задач;
- slicing больших фич;
- определение MVP;
- Definition of Ready;
- Definition of Done;
- управление зависимостями;
- оценку рисков;
- работу с блокерами;
- daily / planning / refinement / review / retro;
- контроль прогресса без микроменеджмента;
- отличие активности от продвижения;
- отличие “мы что-то делали” от “мы приблизились к результату”.
DORA для измерения software delivery использует метрики, связанные со скоростью и стабильностью поставки: deployment frequency, lead time for changes, change failure rate и failed deployment recovery time. Там же delivery performance описывается не как “люди были заняты”, а как способность команды безопасно, быстро и эффективно поставлять изменения. (dora.dev)
И это очень правильный разворот:
лида надо учить не “пинать людей”, а видеть поток работы.
Где задача вошла?
Где зависла?
Почему зависла?
Кто ждёт кого?
Где недостаточно решения?
Где недостаточно контекста?
Где архитектура мешает delivery?
Где процесс имитирует движение?
4. Архитектура для лида
Не “архитектура как красивые схемы”.
А архитектура как способ не дать системе сдохнуть под изменениями.
Темы:
- модульность;
- границы сервисов;
- bounded contexts;
- API contracts;
- интеграции;
- синхронное и асинхронное взаимодействие;
- очереди;
- транзакционность;
- консистентность;
- observability;
- масштабирование;
- технический долг;
- миграции;
- legacy;
- архитектурные компромиссы;
- когда не надо строить микросервисы;
- как объяснять архитектурное решение команде и бизнесу.
Отдельный блок — Architecture Decision Records. ADR — это короткий документ, который фиксирует одно архитектурное решение, его контекст и последствия; Martin Fowler отдельно подчёркивает, что ADR должен сохранять не только “что решили”, но и почему это решение появилось. (martinfowler.com)
Для лида это критично, потому что команда постоянно страдает не от отсутствия кода, а от отсутствия памяти решений.
Почему мы выбрали Kafka?
Почему не RabbitMQ?
Почему этот сервис отдельный?
Почему эта таблица такая?
Почему авторизация вынесена отдельно?
Почему нельзя просто переписать всё?
Без фиксации решений команда живёт в вечном “а кто это придумал?”.
5. Code Review: проверка инженерных решений и развитие команды
Очень важный модуль.
Code review — это не поиск запятых.
Это место, где лид формирует стандарт инженерного мышления.
Темы:
- что проверять в pull request;
- как отличать вкусовщину от реальной проблемы;
- как не превращать review в унижение;
- как защищать качество без токсичности;
- как объяснять trade-offs;
- как видеть архитектурный запах;
- как находить скрытую сложность;
- как не пропускать “работает, но потом нас убьёт”;
- как учить младших через review;
- как самому не становиться bottle-neck.
Пример различения:
Плохой review:
"переделай, так некрасиво".
Нормальный lead-review:
"здесь смешаны три ответственности: валидация, бизнес-правило и вызов внешнего сервиса. Сейчас это работает, но при следующем изменении мы получим хрупкость. Давай разрежем это на такие-то части".
Вот это уже leadership, потому что ты не просто указываешь на ошибку, а передаёшь способ видеть систему.
6. Работа с требованиями и стейкхолдерами
Лид должен уметь не только отвечать на задачу, но и вскрывать задачу.
Темы:
- как разговаривать с Product Owner;
- как уточнять requirement;
- как отличать бизнес-цель от конкретного решения;
- как находить скрытые ограничения;
- как работать с неполными требованиями;
- как говорить “это не влезет” без театра;
- как предлагать альтернативы;
- как фиксировать договорённости;
- как не дать бизнесу протащить хаос внутрь команды.
Для курса важно различать эти ответственности: лид не должен забирать у Product Owner продуктовые решения, принимать за команду решения о реализации или оставаться единственным человеком, который “всё помнит”.
Отдельный навык:
Перевести "нам нужна кнопка" в:
- какую проблему решаем;
- кто пользователь;
- какой сценарий;
- какой результат считаем успешным;
- какие ограничения;
- что можно не делать сейчас;
- что будет считаться завершением.
7. Планирование, оценки и управление неопределённостью
Тут надо честно объяснять: оценки — это не гадание и не клятва кровью.
Оценка — это способ показать форму неизвестности.
Темы:
- estimation vs commitment;
- story points;
- ideal days;
- t-shirt sizing;
- confidence level;
- risk buffer;
- spike;
- discovery task;
- delivery forecast;
- почему “точно скажи дату” часто является насилием над неизвестностью;
- как не врать бизнесу;
- как не ломать команду сроками;
- как делать видимой реальную сложность.
Пример:
Плохая оценка:
"сделаем за 3 дня".
Осмысленная оценка:
"если API внешнего сервиса соответствует документации — 3 дня.
Если понадобится обходить ограничения авторизации — 5–7 дней.
Если выяснится, что нет стабильного sandbox — сначала нужен spike на 1 день".
Вот это уже язык лида.
8. Инциденты, продакшен и ответственность за живую систему
Лид должен понимать, что код не заканчивается на merge.
Темы:
- logging;
- metrics;
- tracing;
- alerts;
- on-call;
- incident response;
- rollback;
- feature flags;
- postmortem;
- root cause analysis;
- blameless culture без превращения в безответственность;
- SLI / SLO / SLA;
- error budget;
- operational readiness.
Google SRE формулирует SLI как количественный показатель уровня сервиса, SLO как целевое значение для такого показателя, а SLA как отдельный слой договорённости; там же подчёркивается, что метрики должны отражать то, что важно пользователю, а не просто то, что легко измерить. (Google SRE)
Для лида это мощнейший принцип:
Не "у нас CPU нормальный".
А "пользователь может выполнить действие?"
Не "сервер жив".
А "сценарий работает?"
Не "алерт зелёный".
А "сервис выполняет свою функцию?"
9. Люди: менторинг, рост, конфликты
Здесь главное не скатиться в “будь эмпатичным зайчиком”.
Лид работает с людьми не потому, что “надо быть хорошим”, а потому что команда состоит из сознаний, у каждого из которых есть:
- уровень опыта;
- страхи;
- амбиции;
- слепые зоны;
- скорость обучения;
- стиль коммуникации;
- границы;
- усталость;
- сильные стороны;
- способы ошибаться.
Темы:
- как менторить junior / middle / senior;
- как давать feedback;
- как не унижать человека через правку кода;
- как разруливать конфликт;
- как отличать конфликт людей от конфликта ролей;
- как отличать лень от непонимания;
- как отличать саботаж от перегруза;
- как разговаривать с сильным, но разрушительным инженером;
- как не позволять одному человеку захватывать команду;
- как защищать команду от внешнего давления;
- как защищать реальность от команды, если команда реально ошибается.
Очень важное различение:
Менеджерская подмена:
"будь добрее к людям".
Лидерское различение:
"понимай, какая именно причина мешает человеку действовать:
не знает, не умеет, боится, не согласен, перегружен, не видит смысла, саботирует или упёрся в плохую систему".
10. Найм и собеседования
Для лида это отдельная компетенция.
Темы:
- как читать резюме;
- как проводить technical screening;
- как отличать реальный опыт от пересказа;
- как задавать system design вопросы;
- как проверять reasoning;
- как проверять ownership;
- как не нанять токсичного “звёздного” разработчика;
- как оценивать seniority;
- как давать hiring feedback;
- как онбордить нового человека;
- как строить probation plan.
Пример хорошего вопроса:
Не:
"Что такое Kafka?"
А:
"У вас есть сервис заказов, платёжный сервис и сервис уведомлений. Где вы будете использовать синхронный вызов, где событие, где очередь, где нужна идемпотентность, и что сломается при повторной доставке сообщения?"
Потому что лид проверяет не словарь, а способность человека видеть причинность.
11. AI / ML / LLM для лида
Сейчас это уже надо включать обязательно.
Но не в формате “ChatGPT ускоряет разработку в 10 раз”, а нормально:
- как использовать ChatGPT / Codex / Copilot в разработке;
- как давать задачу AI-инструменту;
- как проверять сгенерированный код;
- как не тащить hallucination в production;
- как использовать AI для refactoring, тестов, документации, анализа логов;
- как строить AI-assisted workflow в команде;
- как фиксировать правила использования AI;
- где AI помогает;
- где AI создаёт иллюзию понимания;
- где AI ускоряет junior, а где делает его опаснее;
- как лид должен контролировать качество при AI-assisted development.
DORA в своём research-разделе уже отдельно выделяет AI как фактор, который меняет software delivery и organizational performance; при этом формулировка важная: AI усиливает существующую социотехническую систему, а не магически заменяет её. (dora.dev)
То есть для курса на лида сильная формулировка такая:
AI не заменяет leadership.
AI увеличивает последствия существующего leadership.
Если в команде есть мышление, контекст, review, тесты и архитектурная дисциплина — AI ускоряет.
Если в команде хаос — AI ускоряет производство хаоса.
12. Управление техническим долгом
Технический долг надо разбирать не как “грязный код”, а как отложенную цену решений.
Темы:
- intentional debt;
- accidental debt;
- legacy;
- refactoring strategy;
- strangler pattern;
- migration plan;
- debt register;
- как объяснять долг бизнесу;
- как не превращать refactoring в бесконечное “давайте всё перепишем”;
- как выбирать, какой долг платить первым;
- как связывать долг с delivery risk.
Пример:
Плохая формулировка:
"код плохой, надо переписать".
Лидерская формулировка:
"из-за текущей структуры изменение тарифов занимает 5 дней вместо 1 дня, потому что бизнес-правила размазаны по трём сервисам. Предлагаю выделить pricing module в течение двух спринтов, чтобы следующие изменения тарифов проходили быстрее и безопаснее".
Вот это язык, который понимает и инженер, и бизнес.
13. Документация, знания и память команды
Нормальный лид должен строить не “культ себя”, а систему, которая живёт без постоянного героизма.
Темы:
- README;
- runbooks;
- onboarding docs;
- architecture overview;
- ADR;
- API contracts;
- diagrams;
- knowledge sharing;
- bus factor;
- внутренние tech talks;
- как писать документацию, которую реально читают;
- как не превращать Confluence в кладбище текстов.
Главный принцип:
Если знание существует только в голове лида — это не знание команды.
Это скрытая зависимость.
14. Коммуникация лида
Не “soft skills”, а точная инженерная речь.
Темы:
- как формулировать проблему;
- как различать факт, оценку, интерпретацию и риск;
- как говорить с разработчиком;
- как говорить с QA;
- как говорить с Product;
- как говорить с менеджером;
- как говорить с заказчиком;
- как эскалировать;
- как писать status update;
- как писать risk update;
- как не прятать проблему до последнего.
Пример:
Плохо:
"У нас всё сложно, команда разбирается".
Нормально:
"Интеграция заблокирована, потому что внешний API не возвращает стабильный contract для статусов платежа. Сейчас проверяем два варианта: адаптер на нашей стороне или изменение contract со стороны партнёра. Риск: задержка релиза на 2–3 дня, если партнёр не подтвердит contract сегодня".
Это не корпоративное сглаживание. Это точная передача реальности.
15. Лид как точка сборки смысла
Вот это я бы добавил как отдельный сильный модуль, потому что без него курс будет мёртвым.
Лид должен отвечать на вопросы:
Что мы вообще делаем?
Зачем мы это делаем?
Как это связано с пользователем?
Как это связано с бизнесом?
Как это связано с архитектурой?
Как это связано с задачей конкретного разработчика?
Где здесь результат?
Где здесь имитация результата?
Потому что команда очень легко распадается на локальные действия:
- один пишет endpoint;
- другой чинит тест;
- третий обновляет pipeline;
- четвёртый спорит про naming;
- пятый не понимает, зачем эта feature вообще нужна.
А лид должен собирать это обратно:
Вот пользовательский сценарий.
Вот технический путь.
Вот зоны риска.
Вот что делаем сейчас.
Вот что не делаем.
Вот почему.
Вот какой результат должен появиться.
