Курс на лида — это не “как стать приятным начальником”.
Это программа про то, как инженер перестаёт быть только исполнителем задач и начинает держать контур ответственности за систему, команду, delivery, качество решений, риски и смысл работы.
То есть лид — это не “главный программист” и не “мини-менеджер”. Это человек, который отвечает за то, чтобы техническая реальность не распалась на хаос: задачи, архитектура, люди, сроки, долги, баги, релизы, требования, конфликты, собеседования, онбординг, код, продакшен, заказчики.
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;
- как отличать бизнес-цель от конкретного решения;
- как находить скрытые ограничения;
- как работать с неполными требованиями;
- как говорить “это не влезет” без театра;
- как предлагать альтернативы;
- как фиксировать договорённости;
- как не дать бизнесу протащить хаос внутрь команды.
Scrum Guide разделяет ответственности внутри Scrum Team: Developers, Product Owner и Scrum Master; вся Scrum Team отвечает за создание ценного increment каждый Sprint. (Scrum Guides) Для курса на лида это важно не как религиозное следование Scrum, а как различение: лид не должен становиться ни Product Owner вместо Product Owner, ни Scrum Master вместо Scrum Master, ни единственным человеком, который “всё помнит”.
Отдельный навык:
Перевести "нам нужна кнопка" в:
- какую проблему решаем;
- кто пользователь;
- какой сценарий;
- какой результат считаем успешным;
- какие ограничения;
- что можно не делать сейчас;
- что будет считаться завершением.
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 вообще нужна.
А лид должен собирать это обратно:
Вот пользовательский сценарий.
Вот технический путь.
Вот зоны риска.
Вот что делаем сейчас.
Вот что не делаем.
Вот почему.
Вот какой результат должен появиться.
Если собрать это как полноценную программу
Неделя 1. Роль лида
- Senior vs Lead.
- Ownership.
- Ответственность за систему.
- Карта зон ответственности лида.
Практика: описать свою текущую или прошлую команду как систему ответственности.
Неделя 2. Delivery и поток задач
- Как задача проходит от идеи до production.
- Где возникают блокеры.
- Как видеть flow.
- DORA-метрики.
Практика: нарисовать delivery map своей команды.
Неделя 3. Декомпозиция и планирование
- Slicing.
- MVP.
- Risk-based planning.
- Spike.
- Оценки.
- Commitment без вранья.
Практика: взять большую фичу и разрезать её на поставляемые куски.
Неделя 4. Архитектура для лида
- Границы сервисов.
- Интеграции.
- Данные.
- Очереди.
- Транзакции.
- Консистентность.
- ADR.
Практика: написать ADR по архитектурному решению.
Неделя 5. Code Review и инженерные стандарты
- Review как обучение.
- Review как контроль качества.
- Review как защита архитектуры.
- Конфликты на review.
Практика: разобрать pull request и дать lead-level feedback.
Неделя 6. Production и reliability
- Logs, metrics, tracing.
- SLI / SLO.
- Incident response.
- Postmortem.
- Error budget.
Практика: описать SLO для сервиса и план реакции на инцидент.
Неделя 7. Работа с требованиями
- Stakeholders.
- Product thinking.
- Уточнение смысла задачи.
- Acceptance criteria.
- Как не брать мутные требования внутрь команды.
Практика: превратить мутный запрос бизнеса в нормальный technical brief.
Неделя 8. Люди и менторинг
- Junior / Middle / Senior.
- Feedback.
- Развитие людей.
- Конфликты.
- Один сильный токсичный инженер.
- Один слабый, но перспективный инженер.
Практика: провести разбор ситуации с разработчиком и написать план роста.
Неделя 9. Найм и онбординг
- Interview structure.
- System design interview.
- Behavioral signals.
- Hiring risks.
- Onboarding plan.
Практика: составить собеседование для backend developer / team lead.
Неделя 10. AI-assisted engineering
- ChatGPT / Codex / Copilot.
- AI в coding workflow.
- AI в review.
- AI в тестах.
- AI в документации.
- Риски галлюцинаций.
- Правила команды.
Практика: построить AI-assisted workflow для команды.
Неделя 11. Технический долг и legacy
- Типы долга.
- Приоритизация.
- Refactoring strategy.
- Migration plan.
- Как продавать долг бизнесу.
Практика: составить debt reduction plan.
Неделя 12. Финальный lead simulation
Финальное упражнение должно быть не тестом, а симуляцией:
Есть команда из 6 человек.
Есть legacy-сервис.
Есть срочная feature.
Есть баг в production.
Есть конфликт между backend и QA.
Есть Product, который давит сроками.
Есть middle, который застрял.
Есть senior, который всех раздражает, но много знает.
Есть внешний API, который нестабилен.
Задача участника:
- разложить ситуацию;
- выделить риски;
- определить план;
- распределить работу;
- написать status update;
- принять архитектурное решение;
- дать feedback человеку;
- защитить команду;
- довести delivery до результата.
Вот это был бы настоящий экзамен на лида.
Какие артефакты должны остаться после курса
Не сертификат “я молодец”, а набор рабочих артефактов:
1. Team responsibility map
2. Delivery flow map
3. Risk register
4. Architecture overview
5. ADR template
6. Code review checklist
7. SLO template
8. Incident postmortem template
9. Technical debt register
10. Hiring scorecard
11. Onboarding plan
12. AI usage policy for engineering team
13. Stakeholder update template
14. Personal lead operating system
Вот это уже можно показать работодателю.
Не “я прошёл курс”, а “я умею держать такие-то контуры”.
Самая сильная формула курса
Лид — это человек, который удерживает связь между:
- смыслом продукта;
- архитектурой;
- людьми;
- процессом;
- качеством;
- сроками;
- production;
- рисками;
- решениями.
То есть лид не просто “руководит людьми”.
Он удерживает неразваливание реальности внутри инженерной системы.
активность ≠ результат
занятость ≠ delivery
митинги ≠ управление
архитектурная схема ≠ архитектура
команда ≠ набор людей
оценка ≠ обещание
Agile ≠ хаос с daily
code review ≠ придирки
AI ≠ понимание
лид ≠ начальник
