Модуль 1. Переход от Senior к Lead

От /

Содержание

Этот модуль — не про повышение должности.
И не про то, что человек “стал важнее”, “стал начальником” или “теперь меньше пишет код”.

Это модуль про смену единицы ответственности.

Senior чаще всего мыслит так:

Есть сложная задача.
Я должен понять её, решить её, написать код, довести свой кусок до качества.

Lead должен начать мыслить иначе:

Есть сложная работа.
Она должна стать понятной, выполнимой, распределённой, проверяемой и доведённой до результата командой.

Вот здесь и происходит настоящий переход.

Не из “кодера” в “начальника”.
А из человека, который держит свою сложность, в человека, который держит сложность системы работы.

Беру за основу исходную рамку программы: первый модуль нужен именно для различения Senior Developer и Tech Lead / Team Lead — Senior отвечает за сложную часть работы, а Lead отвечает за то, чтобы сложная работа стала выполнимой для команды.

1. Главная идея модуля

Senior решает сложность внутри задачи

Senior обычно силён в том, что он может взять неочевидную, мутную, технически тяжёлую часть и протащить её через сопротивление.

Он умеет:

разобраться в legacy;
понять непонятный баг;
спроектировать кусок решения;
написать сложную бизнес-логику;
разобраться с интеграцией;
починить production issue;
дать совет junior / middle;
увидеть плохой код;
предложить технический вариант;
сделать важную часть фичи.

Это большая инженерная зрелость.

Но это ещё не leadership.

Потому что Senior может быть очень сильным, но при этом вся команда вокруг него остаётся зависимой, слепой, медленной или хаотичной.

Команда может жить так:

все ждут, пока Senior посмотрит;
все несут вопросы только к нему;
все сложные задачи автоматически падают на него;
без него никто не понимает архитектуру;
решения принимаются в его голове;
документации нет;
риски не видны;
план держится на героизме;
delivery происходит не через систему, а через личное протаскивание.

И внешне это может выглядеть как “сильный инженер”.

Но с точки зрения команды это может быть скрытая поломка.

Потому что система работает не потому, что она устроена, а потому что один человек постоянно компенсирует её неустроенность.

Lead делает сложность доступной для команды

Lead не обязан быть самым сильным человеком в каждой технической детали.

Но Lead обязан уметь сделать так, чтобы работа не распалась.

Он должен видеть:

что именно нужно сделать;
зачем это нужно сделать;
кто это будет делать;
какой контекст нужен человеку;
где задача слишком большая;
где непонятно требование;
где есть риск;
где есть зависимость;
где архитектурное решение ещё не принято;
где команда спорит не о том;
где человек застрял;
где delivery имитируется активностью;
где качество начинает проседать;
где нужно вмешаться;
где, наоборот, нужно не мешать.

Lead — это не тот, кто делает за всех.

Lead — это тот, кто не даёт работе превратиться в туман.

2. Центральное различение

Senior Developer:
держит сложную задачу.

Lead:
держит систему выполнения сложной работы.

Или ещё жёстче:

Senior отвечает:
“Как мне это сделать?”

Lead отвечает:
“Как сделать так, чтобы это было сделано командой и не развалило систему?”

Это разные режимы сознания.

Senior может быть сосредоточен на локальном решении:

код;
алгоритм;
API;
класс;
модуль;
баг;
performance;
тест;
pull request.

Lead должен держать более широкий контур:

требование;
пользовательский сценарий;
архитектурное последствие;
декомпозиция;
риски;
зависимости;
люди;
коммуникация;
качество;
production;
срок;
delivery;
память решения;
будущее изменение.

То есть Lead не перестаёт быть инженером.
Он расширяет инженерное мышление с кода на систему работы.

3. Ошибка перехода: стать “ещё более Senior”

Самая частая ошибка — думать, что переход к Lead означает:

я теперь должен ещё лучше кодить;
я должен брать самые сложные задачи;
я должен быстрее всех отвечать;
я должен всё знать;
я должен всё проверять;
я должен всё спасать;
я должен быть главным техническим мозгом команды.

Это ловушка.

Так человек становится не Lead, а Super Senior Bottle-neck.

Он вроде бы незаменим, но команда вокруг него слабеет.

Признаки этой ловушки:

без него не принимаются решения;
он перегружен вопросами;
он постоянно переключается;
он сам берёт самые сложные задачи;
он не успевает нормально думать;
он раздражается, что остальные “не видят очевидного”;
он переписывает чужой код вместо того, чтобы передать принцип;
он хранит контекст в голове;
он становится главным узким местом delivery.

И тогда возникает странная ситуация:

Чем сильнее Lead работает руками за всех,
тем слабее становится система вокруг него.

Это не значит, что Lead не должен писать код.

Должен, особенно если это Tech Lead.

Но его кодинг уже не может быть просто личной производительностью.
Его техническое действие должно усиливать команду.

Например:

не просто “я написал сервис”,
а “я показал структуру, по которой команда дальше может делать похожие сервисы”;

не просто “я починил баг”,
а “я нашёл класс причин, из-за которых такие баги возникают”;

не просто “я сделал refactoring”,
а “я снял препятствие, которое замедляло несколько будущих изменений”;

не просто “я ответил junior”,
а “я дал ему способ самому разбирать такие задачи дальше”.

4. Что именно меняется при переходе

4.1. Меняется объект внимания

У Senior объект внимания часто такой:

моя задача;
мой pull request;
мой компонент;
мой deadline;
мой technical solution.

У Lead объект внимания шире:

работа команды;
поток задач;
система решений;
качество delivery;
командная автономность;
архитектурная связность;
видимость рисков;
согласованность ожиданий.

Senior может сказать:

Моя задача готова.

Lead должен спросить:

А feature готова?
А пользовательский сценарий работает?
А QA понимает, что проверять?
А deployment готов?
А rollback есть?
А зависимость закрыта?
А Product понимает ограничения?
А команда знает, что изменилось?
А следующий человек сможет это поддерживать?

То есть Lead не удовлетворяется локальной готовностью.

Он проверяет готовность результата как системы.

4.2. Меняется отношение к задаче

Senior часто получает задачу и решает её.

Lead не может просто взять задачу как данность.

Он должен проверить:

эта задача вообще правильно сформулирована?
понятна ли цель?
не перепутано ли решение с проблемой?
есть ли acceptance criteria?
понятны ли ограничения?
не слишком ли крупный кусок?
можно ли разрезать?
есть ли технические риски?
есть ли зависимость от другой команды?
есть ли скрытая работа?
есть ли влияние на production?
кто должен участвовать?

Для Senior задача часто начинается с Jira ticket.

Для Lead задача начинается раньше — с проверки, что именно вошло в команду под видом задачи.

Потому что в команду часто прилетает не работа, а смесь:

желания бизнеса;
догадки Product Owner;
технической неопределённости;
срока с потолка;
старого долга;
политического давления;
неполного контекста;
фантазии о простоте.

Если Lead это не разрежет, команда потом будет страдать внутри мутной формулировки.

4.3. Меняется способ влияния

Senior влияет через личное качество работы.

Lead влияет через устройство среды, в которой работают другие.

Senior делает сильный кусок.

Lead создаёт условия, в которых сильные куски могут появляться не случайно, а системно.

Это влияние через:

декомпозицию;
архитектурные рамки;
инженерные стандарты;
code review;
согласование решений;
видимость рисков;
ясную коммуникацию;
обучение людей;
защиту фокуса команды;
правильное распределение ответственности;
снятие блокеров;
память решений.

Lead не просто “помогает людям”.

Он настраивает причинность работы.

5. Senior vs Lead: подробная карта различий

Senior:
берёт сложную задачу.

Lead:
делает сложную работу выполнимой для команды.

Senior:
думает, как решить.

Lead:
думает, кто, как, в каком порядке, с какими рисками и каким результатом решает.

Senior:
видит техническую проблему.

Lead:
видит техническую проблему, её влияние на delivery, людей, сроки, качество и будущую поддержку.

Senior:
может быть героем.

Lead:
не должен строить систему на героизме.

Senior:
может держать контекст в голове.

Lead:
должен выносить контекст наружу, чтобы команда могла им пользоваться.

Senior:
чинит конкретный баг.

Lead:
смотрит, почему такие баги вообще проходят в систему.

Senior:
даёт технический совет.

Lead:
формирует инженерный стандарт принятия решений.

Senior:
делает review кода.

Lead:
через review передаёт способ видеть качество, сложность и последствия.

Senior:
может спорить за своё решение.

Lead:
должен организовать принятие решения так, чтобы команда понимала контекст, trade-offs и последствия.

Senior:
отвечает за свой результат.

Lead:
отвечает за то, чтобы результат команды был реальным, а не нарисованным в статусах.

6. Lead — это не “начальник”

Очень важно сразу вытащить эту подмену.

Переход в Lead часто воспринимают через власть:

теперь я главный;
теперь я раздаю задачи;
теперь я контролирую людей;
теперь мои решения важнее;
теперь я могу говорить, как надо.

Это слабое понимание роли.

Lead — это не человек, который получил право командовать.

Lead — это человек, на котором появляется дополнительная обязанность удерживать реальность работы.

Власть без ответственности превращает Lead в локального начальника.
Ответственность без власти превращает Lead в перегруженного спасателя.
Нормальная Lead-позиция требует связки:

ответственность;
влияние;
видимость;
право поднимать риски;
право менять процесс;
право задавать инженерные стандарты;
право не принимать мутную работу внутрь команды без уточнения;
право говорить “так мы сломаем delivery”;
право защищать команду от хаоса;
обязанность защищать результат от самообмана команды.

Lead не должен быть приятным координатором хаоса.

Lead должен быть точкой, через которую хаос становится различённым.

7. Где граница между Tech Lead, Team Lead, Engineering Manager, Architect, Product Owner

Этот блок нужен, потому что люди часто смешивают роли.

И тогда начинается каша:

Tech Lead думает, что он Product Owner.
Team Lead думает, что он Engineering Manager.
Architect рисует схемы, но не отвечает за delivery.
Product Owner протаскивает технические решения.
Engineering Manager лезет в код без контекста.
Команда не понимает, кто за что отвечает.

Нужно не религиозно закреплять роли, а различать зоны ответственности.

Tech Lead

Tech Lead держит техническую состоятельность решения.

Его фокус:

архитектура;
качество кода;
технические решения;
границы компонентов;
интеграции;
технические риски;
review;
технический долг;
production readiness;
инженерные стандарты.

Tech Lead спрашивает:

Это решение выдержит изменения?
Где здесь скрытая сложность?
Как это будет поддерживаться?
Как это будет тестироваться?
Что произойдёт при сбое?
Какой contract между частями системы?
Где мы создаём долг?
Какие решения нужно зафиксировать?

Team Lead

Team Lead держит командную выполнимость работы.

Его фокус:

распределение задач;
delivery;
командная коммуникация;
развитие людей;
блокеры;
координация;
ритм работы;
конфликты;
загрузка;
взаимодействие с другими командами;
состояние команды как производственной системы.

Team Lead спрашивает:

Команда понимает, что делает?
Работа разрезана нормально?
Никто не заблокирован?
Нет ли перегруза на одном человеке?
Кто может взять эту задачу?
Что мешает delivery?
Где команда теряет фокус?
Где нужен разговор?

Engineering Manager

Engineering Manager держит организационный контур.

Его фокус:

найм;
performance review;
карьерный рост;
структура команды;
бюджеты;
процессы;
организационные риски;
долгосрочная способность команды;
согласование с бизнесом;
людские решения.

Engineering Manager спрашивает:

Есть ли у команды нужные люди?
Как растут инженеры?
Где нужен найм?
Кто перегружен?
Кто не соответствует роли?
Как устроить команду на следующие полгода?
Что мешает команде на уровне организации?

Architect

Architect держит системную техническую целостность шире одной команды.

Его фокус:

общая архитектура;
межсервисные границы;
интеграционные принципы;
технологическая стратегия;
стандарты;
масштабирование;
безопасность;
данные;
долгосрочная эволюция системы.

Architect спрашивает:

Как это решение влияет на всю систему?
Не создаём ли мы неправильную границу?
Как это будет жить через год?
Как команды будут взаимодействовать?
Какие технологические решения должны быть едиными?
Где нужна автономность, а где стандартизация?

Product Owner

Product Owner держит ценность продукта и приоритеты.

Его фокус:

пользователь;
бизнес-цель;
ценность;
приоритеты;
backlog;
acceptance criteria;
scope;
ожидаемый результат;
что делать сейчас, а что не делать.

Product Owner спрашивает:

Какую проблему пользователя решаем?
Почему это важно сейчас?
Что является минимально ценным результатом?
Какие сценарии обязательны?
Что можно отложить?
Как поймём, что результат достигнут?

Важное различение

Lead не обязан подменять все роли.

Плохой Lead пытается стать всем сразу:

и архитектором;
и продуктом;
и менеджером;
и scrum master;
и главным разработчиком;
и психологом;
и пожарным;
и секретарём;
и единственным носителем памяти.

Нормальный Lead делает другое:

различает, какой контур сейчас провален;
поднимает это наружу;
подключает нужную роль;
фиксирует решение;
не даёт провалу одной роли разрушить всю команду.

То есть Lead не обязан быть всеми.
Но Lead должен видеть, когда отсутствие какой-то ответственности начинает ломать delivery.

8. Что значит “держать delivery”

“Держать delivery” — это не спрашивать каждый день:

Ну что, когда будет готово?

Это вообще не управление.

Это имитация управления через давление.

Держать delivery — значит видеть путь работы от входа до результата.

Откуда пришла задача?
Что она должна изменить в реальности?
Кто пользователь?
Какой сценарий должен заработать?
Что нужно сделать технически?
Какие части есть?
Что можно поставить раньше?
Где риск?
Где зависимость?
Кто делает?
Кто проверяет?
Как поймём, что готово?
Как попадёт в production?
Что может сломаться?
Кто должен узнать об изменении?

Delivery — это не “мы писали код”.

Delivery — это когда изменение прошло путь:

смысл → требование → техническое решение → реализация → проверка → поставка → работающий сценарий → подтверждённый результат.

Если команда неделю была занята, но пользовательский сценарий не приблизился к работе, это может быть активность без delivery.

Если команда провела много митингов, но не сняла неопределённость, это может быть коммуникация без delivery.

Если команда написала много кода, но не может безопасно выкатить, это может быть разработка без delivery.

Lead должен видеть эту разницу.

9. Основные анти-паттерны перехода

9.1. Lead-герой

Я сам всё сделаю быстрее.

Проблема: команда не растёт, Lead выгорает, знание остаётся в одной голове.

Нормальное действие:

Я могу сделать сам, но должен понять:
это разовая авария или повторяющийся класс работы?
Если это повторяющийся класс работы, нужно передать способ действия команде.

9.2. Lead-диспетчер

Я раздал задачи, значит управляю.

Проблема: раздача задач не равна управлению работой.

Нормальное действие:

Проверить не только кто что делает, но и:
понятна ли задача;
есть ли контекст;
есть ли критерий завершения;
есть ли зависимость;
есть ли риск;
есть ли способ проверить результат.

9.3. Lead-микроменеджер

Я должен контролировать каждый шаг.

Проблема: команда перестаёт думать, всё проходит через Lead, скорость падает.

Нормальное действие:

Контролировать не каждое движение человека,
а точки риска, интерфейсы между частями, критерии готовности и качество решений.

9.4. Lead-переводчик хаоса

Бизнес принёс мутную задачу, я как-нибудь объясню её команде.

Проблема: Lead становится прокладкой между хаосом и командой, но не устраняет хаос.

Нормальное действие:

Не протаскивать мутность внутрь команды,
а возвращать вопрос на уровень смысла:
какую проблему решаем;
для кого;
какой результат нужен;
что является обязательным;
что можно не делать;
какие ограничения реальны.

9.5. Lead-хранитель тайного знания

Я всё помню, спрашивайте меня.

Проблема: команда зависит от памяти одного человека.

Нормальное действие:

Решения, причины, ограничения и договорённости должны быть вынесены в артефакты:
ADR, README, technical brief, decision log, onboarding notes.

10. Структура модуля

Урок 1. Смена единицы ответственности

Цель урока

Показать, что Lead отличается от Senior не “уровнем крутости”, а объектом ответственности.

Основной тезис

Senior отвечает за выполнение сложной задачи.
Lead отвечает за выполнимость сложной работы командой.

Что разобрать

почему сильный Senior не автоматически хороший Lead;
почему личная продуктивность может начать мешать командной продуктивности;
почему “я сам быстрее сделаю” иногда разрушает систему;
почему Lead должен видеть не только код, но и поток работы;
почему Lead отвечает за связь между смыслом, задачами, людьми, архитектурой и результатом.

Практика

Взять 3 задачи из прошлого опыта и разложить:

Что я делал как Senior?
Что должен был бы увидеть Lead?
Какие риски были не в коде, а вокруг задачи?
Что нужно было вынести наружу?
Кто ещё должен был понимать контекст?
Как можно было сделать работу менее зависимой от одного человека?

Урок 2. Карта ответственности Lead

Цель урока

Собрать полную карту зон, которые Lead должен хотя бы видеть, даже если не всеми управляет напрямую.

Зоны ответственности

1. Смысл работы
2. Требования
3. Декомпозиция
4. Архитектурные решения
5. Распределение задач
6. Delivery
7. Code quality
8. Технический долг
9. Риски
10. Коммуникация
11. Люди и рост
12. Production readiness
13. Документация и память решений
14. Взаимодействие со стейкхолдерами

Важная мысль

Lead не обязан всё делать руками.
Но если Lead вообще не видит какой-то контур, этот контур может незаметно сломать результат.

Например:

можно хорошо писать код, но провалить требования;
можно хорошо раздать задачи, но провалить архитектуру;
можно хорошо провести daily, но не увидеть production risk;
можно хорошо договориться с Product, но перегрузить команду;
можно быстро закрыть feature, но создать долг, который убьёт следующие три feature.

Практика

Составить Lead Responsibility Map:

Контур ответственности:
Что должно быть видно?
Какие признаки, что контур ломается?
Какие вопросы Lead должен задавать?
Какие артефакты помогают держать этот контур?
Кто ещё участвует?

Урок 3. От “сделал сам” к “сделал через систему”

Цель урока

Показать, что Lead должен перестать мерить свою ценность только количеством лично закрытых задач.

Главный конфликт

У сильного Senior часто есть внутренняя привычка:

ценность = я сам решил сложную вещь.

У Lead формула меняется:

ценность = команда смогла решить сложную вещь устойчиво, понятно и воспроизводимо.

Это болезненный переход.

Потому что Lead может меньше кодить руками и при этом приносить больше пользы.
Но если у человека внутри ценность привязана только к личному коду, ему будет казаться, что он “ничего не делает”.

На самом деле он может делать более высокий уровень работы:

снял неопределённость;
разрезал feature;
предотвратил архитектурную ошибку;
помог middle взять сложную задачу;
договорился о contract с другой командой;
вытащил риск до релиза;
зафиксировал решение;
убрал bottleneck;
сделал review так, что человек понял принцип;
защитил команду от бессмысочного scope creep.

Это не “меньше инженерии”.
Это инженерия на уровне системы работы.

Практика

Переписать действия из Senior-режима в Lead-режим.

Senior-режим:
“Я сам починил flaky tests”.

Lead-режим:
“Я разобрал причины flaky tests, выделил повторяющийся паттерн, договорился о критерии стабильности, добавил checklist для новых тестов и распределил исправления между двумя разработчиками”.

Senior-режим:
“Я сделал интеграцию с внешним API”.

Lead-режим:
“Я проверил contract внешнего API, выделил риски авторизации и нестабильных статусов, предложил adapter layer, зафиксировал ADR и разрезал работу на spike, happy path и error handling”.

Урок 4. Границы ролей

Цель урока

Убрать кашу между Tech Lead, Team Lead, Engineering Manager, Architect и Product Owner.

Главный тезис

Проблемы начинаются не тогда, когда роли пересекаются.
Проблемы начинаются тогда, когда ответственность исчезает в пересечении ролей.

Например:

Product думает, что Tech Lead сам уточнит смысл.
Tech Lead думает, что Product уже всё понял.
Team Lead думает, что Architect проверил решение.
Architect думает, что команда сама оценит delivery risk.
Engineering Manager думает, что Team Lead держит состояние людей.
Team Lead думает, что Engineering Manager разрулит перегруз.

И в итоге никто не держит реальность целиком.

Lead должен уметь сказать:

Сейчас у нас не техническая проблема, а проблема требования.

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

Сейчас у нас не проблема скорости разработки, а проблема зависимости от внешней команды.

Сейчас у нас не проблема QA, а проблема отсутствия acceptance criteria.

Сейчас у нас не проблема архитектуры, а проблема scope, который пытаются протащить без trade-off.

Практика

Для кейса описать:

какая роль должна принять решение;
какая роль должна дать контекст;
какая роль должна подтвердить приоритет;
какая роль должна оценить технический риск;
что Lead должен сделать, если роль отсутствует или не действует.

Урок 5. Что значит “держать систему целиком”

Цель урока

Научить смотреть на команду и работу не набором отдельных событий, а связанной системой.

Lead-смотрение

Lead должен видеть не только:

Вася делает backend.
Петя делает frontend.
Оля пишет тесты.
Feature должна быть готова в пятницу.

А всю цепочку:

Feature решает такой-то пользовательский сценарий.
Backend зависит от contract.
Frontend ждёт mock.
QA не имеет acceptance criteria.
DevOps нужен feature flag.
Есть риск с миграцией данных.
Middle взял слишком большой кусок.
Senior перегружен review.
Product ещё не решил edge case.
Релиз в пятницу возможен только если contract будет подтверждён во вторник.

Вот это и есть Lead-уровень.

Не магия.
Не харизма.
Не “быть начальником”.

А способность держать причинную карту работы.

Практика

Разобрать feature по схеме:

1. Пользовательский сценарий
2. Бизнес-результат
3. Технические части
4. Зависимости
5. Риски
6. Люди
7. Проверка
8. Deployment
9. Rollback
10. Коммуникация

11. Главная практика модуля

Практика: Team Responsibility Map

Участник должен описать свою текущую или прошлую команду как систему ответственности.

Не “у нас 5 разработчиков и QA”.

А так:

Что команда производит?
Какие задачи входят в команду?
Кто формулирует требования?
Кто режет задачи?
Кто принимает архитектурные решения?
Кто держит code quality?
Кто отвечает за production?
Кто видит технический долг?
Кто общается со стейкхолдерами?
Где принимаются решения?
Где теряется контекст?
Где появляется зависимость от одного человека?
Где команда ждёт внешнего решения?
Где Lead нужен как точка сборки?

Выходной артефакт

Team Responsibility Map

Структура:

1. Название команды / продукта
2. Что команда поставляет
3. Основные типы задач
4. Участники и роли
5. Зоны ответственности
6. Где ответственность ясна
7. Где ответственность размыта
8. Где есть bottleneck
9. Где есть риск потери знания
10. Какие 3 изменения Lead должен внести в систему работы

12. Диагностические вопросы для Lead

Эти вопросы можно дать как отдельный рабочий инструмент.

Что сейчас считается результатом?
Все ли одинаково понимают этот результат?
Какая часть работы самая мутная?
Какая часть работы самая рискованная?
Где задача слишком большая?
Где нет владельца решения?
Где человек делает работу без достаточного контекста?
Где команда ждёт внешнюю зависимость?
Где мы называем активность прогрессом?
Где мы закрываем ticket, но не закрываем пользовательский сценарий?
Где решение существует только в голове одного человека?
Где мы ускоряемся за счёт будущего долга?
Где я как Lead должен вмешаться?
Где я, наоборот, должен не забирать ответственность у человека?

13. Мини-симуляции для модуля

Ситуация 1. Senior всё делает сам

В команде есть сильный Senior.
Все сложные задачи автоматически уходят к нему.
Middle-разработчики делают простые задачи и почти не растут.
Senior перегружен, review копится, релиз задерживается.
Product считает, что проблема в скорости команды.

Задача участника

Разложить:

что здесь видит Senior;
что здесь должен увидеть Lead;
где bottleneck;
какую работу нельзя просто “ускорить”;
как перераспределить задачи;
как передать контекст;
какой риск нужно объяснить Product;
какой артефакт нужен команде.

Ситуация 2. Мутная feature

Product приносит задачу:
“Нужно добавить новый статус заказа, это маленькое изменение”.

Backend понимает, что статус влияет на оплату, уведомления, отчётность и интеграцию с партнёром.
QA не понимает, какие сценарии проверять.
Frontend ждёт enum.
Product говорит, что это нужно срочно.

Задача участника

Разложить:

почему это не “маленькое изменение”;
какие вопросы нужно задать;
какие зоны системы затронуты;
как разрезать работу;
какой spike нужен;
какие риски поднять;
что написать в status update.

Ситуация 3. Lead стал диспетчером

Team Lead каждое утро спрашивает статусы.
Все отвечают, что работают.
Через неделю оказывается, что две задачи заблокированы,
одна сделана не по тому сценарию,
а одна не может быть протестирована.

Задача участника

Разложить:

почему daily не удержал реальность;
какие вопросы Lead должен был задать раньше;
где отсутствовали критерии готовности;
где была невидимая зависимость;
как перестроить контроль delivery без микроменеджмента.

14. Домашнее задание модуля

Задание 1. Senior-to-Lead разбор

Взять одну сложную задачу из своего опыта и описать её в двух режимах.

Режим Senior

Что я сделал?
Какой код написал?
Какое техническое решение принял?
Какую проблему решил?
Что было сложно лично для меня?

Режим Lead

Как эта задача вошла в команду?
Был ли понятен смысл?
Как её можно было разрезать?
Какие были зависимости?
Какие были риски?
Кто ещё должен был понимать контекст?
Какие решения нужно было зафиксировать?
Где команда могла стать автономнее?
Что нужно было сделать, чтобы похожие задачи дальше решались легче?

Задание 2. Карта ответственности команды

Составить Team Responsibility Map.

Обязательные блоки:

что команда поставляет;
какие роли есть;
где принимаются технические решения;
где принимаются продуктовые решения;
где теряется контекст;
где есть bottleneck;
где один человек является скрытой зависимостью;
какие зоны ответственности не закреплены;
что Lead должен сделать в первую очередь внутри системы работы.

Задание 3. Личный переходный план

Составить личный план перехода из Senior-режима в Lead-режим.

Не в формате “стать лучше”.

А конкретно:

Что я должен перестать делать сам за всех?
Какую ответственность я должен начать выносить наружу?
Какие решения нужно фиксировать письменно?
Каких людей нужно начать растить?
Какие вопросы я должен задавать до начала реализации?
Какие риски я должен поднимать раньше?
Какой recurring bottleneck я должен убрать?
Какой один командный артефакт я создам?

15. Артефакты после модуля

После первого модуля у участника должны остаться не впечатления, а рабочие материалы.

1. Senior vs Lead responsibility map
2. Team Responsibility Map
3. Role Boundary Map
4. Lead diagnostic questions
5. Senior-to-Lead case analysis
6. Personal Lead Transition Plan

Это уже можно использовать не только в обучении, но и на собеседовании.

Потому что человек может показать не абстрактное:

я хочу быть лидом;
я умею общаться;
я беру ответственность.

А конкретное:

я понимаю, какие контуры должен держать Lead;
я умею видеть bottleneck;
я различаю роли;
я могу разложить delivery;
я понимаю, где Senior-режим перестаёт работать;
я могу показать, как команда становится автономнее;
я умею превращать личное знание в командный артефакт.

16. Финальное упражнение модуля

Lead Simulation: первая неделя в роли Lead

Вводная

Ты становишься Lead в команде из 6 человек.

Команда поддерживает backend-сервис заказов.
Есть legacy-код.
Есть новая feature по изменению статусов заказа.
Product говорит, что изменение маленькое.
QA жалуется, что требования неполные.
Senior-разработчик всё привык делать сам.
Middle-разработчик боится брать сложные задачи.
Frontend ждёт contract.
Есть внешний партнёрский API.
Релиз хотят через неделю.
Документации почти нет.

Задача участника

Нужно описать:

1. Что ты проверишь в первый день?
2. Какие вопросы задашь Product?
3. Какие технические риски выделишь?
4. Как разрежешь feature?
5. Что отдашь Senior?
6. Что отдашь Middle?
7. Как не превратить Senior в bottleneck?
8. Какой contract нужен Frontend?
9. Что должен проверить QA?
10. Какие решения нужно зафиксировать?
11. Какой status update напишешь стейкхолдерам?
12. Что будет считаться реальным delivery?

Пример ожидаемого мышления

Не так:

Я соберу команду, раздам задачи и буду контролировать выполнение.

А так:

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

После этого выделю spike на проверку contract и влияния на legacy.
Параллельно зафиксирую минимальный сценарий для первого релиза.
Senior не будет единственным исполнителем всей feature:
он возьмёт архитектурную рамку и review критичных частей,
а Middle получит ограниченный кусок с понятным contract и поддержкой.

Для Frontend нужен стабильный enum/status contract.
Для QA нужны acceptance criteria по переходам статусов.
Для Product нужно явно показать:
это не одно поле в базе, а изменение состояния заказа в нескольких сценариях.

Delivery будет считаться не merge backend-кода,
а работающий и проверенный сценарий изменения статуса заказа,
готовый к безопасному релизу.

Вот это уже Lead-уровень.

17. Короткая формула модуля

Переход от Senior к Lead — это переход:

от личного выполнения
к организации выполнимости;

от сложной задачи
к системе сложной работы;

от “я решил”
к “команда смогла решить”;

от знания в голове
к знанию в системе;

от героизма
к воспроизводимости;

от локального кода
к delivery;

от реакции на проблемы
к раннему различению рисков;

от “быть самым сильным”
к “делать команду сильнее”.

И главный итог первого модуля:

Lead — это не Senior с властью.

Lead — это инженер,
который начинает отвечать за то,
чтобы техническая работа,
люди,
решения,
риски,
качество
и delivery
не распались на несвязанные куски.

Вот с этого и должен начинаться курс.

Subscribe
Прокрутить вверх