Новый тимлид часто выходит в команду с накопленными проблемами: процессы расшатаны, стейкхолдеры не доверяют, роли размыты. Хочется всё исправить сразу — и именно это чаще всего делает первые месяцы катастрофой. Разберём, как войти в команду спокойно и без лишних потерь.
Первый соблазн — вмешаться немедленно
Когда видишь хаос, рука тянется к реформам. Поменять процесс, поговорить с токсичными, отвоевать полномочия у перегруженного продакт-овнера, разобраться с бывшим лидом, которого оставили в команде.
Проблема в том, что в первые недели у тебя нет ни фактов, ни доверия. Команда уже пережила одну встряску — слабого лида или неудачный период. Третья встряска подряд без диагностики только усугубит ситуацию.
Правило первых недель: наблюдай и собирай данные, не ломай то, что ещё работает.
Как читать ситуацию: один клубок, не пять проблем
Типичный набор симптомов при входе в проблемную команду выглядит так:
- команда берёт больше, чем успевает;
- стейкхолдеры не верят её оценкам;
- поток задач от соседних команд вытесняет приоритеты;
- продакт-овнер перегружен и плохо вовлечён;
- в ревью кода конфликты.
Соблазн — завести пять задач и решать по одной. На деле это одна петля:
прошлый лид не держал управление → PO вынужденно забрал планирование → у PO нет времени на контекст → команда берёт всё, что просят (отказывать некому) → обещания не выполняются → стейкхолдеры перестают доверять → каждый давит свои задачи напрямую → поток вытесняет приоритеты → обещания снова не выполняются.
Понимание петли меняет стратегию. Не «починить пять пунктов», а восстановить контур управления обязательствами: кто принимает работу, на каком основании, что обещаем и как держим слово.
Первые 30 дней: узнать команду и договориться о ролях
1:1 со всеми
Проведи короткий разговор с каждым участником команды. Один и тот же формат: что работает, что раздражает, что поменял бы первым, кому доверяешь, что тебя здесь держит.
Из одиннадцати таких разговоров карта команды складывается точнее, чем из любого отчёта. Бывший лид и «конфликтные» участники — те же самые вопросы, без особого статуса встречи.
Контракт с продакт-овнером
Если PO при прошлом лиде взял на себя планирование и внешние коммуникации — он не виноват. Он держал то, что падало. Полномочия не отвоёвывают манифестом, их возвращают постепенно, показывая, что новая рука держит.
Разговор напрямую: «ты тащишь чужую работу, я пришёл её забрать — давай спланируем передачу». Письменно фиксируем: планирование и оценки берёт лид (с PO как источником приоритетов), внешние коммуникации по статусам — лид, приоритеты и продуктовые решения — PO. Передаём по одной зоне за раз: PO должен убедиться, что новая рука держит, прежде чем отпустить следующую.
Если в команде остался прошлый лид
Это деликатная ситуация. Команда привыкла к нему, он знает контекст, и к нему продолжают ходить по привычке. Риск — «теневой лид», который обесценивает твои решения, даже не намеренно.
Если человек хочет экспертную роль — это актив, не угроза. Договорённость явно: его мандат — технические вопросы и кросс-проектная экспертиза; несогласие с решениями — лично тебе, не в общем канале; в ревью он участник на общих правилах, не последняя инстанция. Твоя сторона: реальные задачи под его экспертизу и видимый статус.
Проверяй через месяц. Если работает — у тебя сильнейший союзник с контекстом. Если нет — это разговор с руководством о переводе: два центра власти команда не переживёт.
Маленькая видимая победа
Найди что-то, что болит у команды и чинится за одну неделю: автодеплой одного сервиса, убрать бессмысленную встречу, навести порядок на доске. Сигнал «новый лид — что-то меняется к лучшему» важнее самого изменения.
Дни 30–60: взять под контроль поток задач
Замер перед изменениями
Сначала две-три недели просто считай: сколько задач пришло извне, от кого, сколько своих, сколько закончили. Эта статистика — фундамент всего следующего.
Единая точка входа для чужих задач
Задача от другой команды попадает не разработчику в личку, а в одну очередь с шаблоном (что, зачем, к какому сроку, что будет, если не сделать). Это не бюрократия — это перевод невидимого потока в видимый. Половина «срочного» отваливается уже на этапе заполнения трёх полей.
Квота мощности и дежурный
Фиксированная доля на внешние запросы — например, 20% — и дежурный, который в свою неделю занимается только ими. Остальная команда защищена от переключений; внешние заказчики получают предсказуемый канал вместо лотереи «кого поймаю в чате». Квота публична: «ваша задача взята, очередь такая, будет тогда-то».
Системный вопрос за этим: почему мелкие задачи вообще летят сюда? Если каждой соседней команде нужны правки в одном сервисе — возможно, нет нормального API самообслуживания. Лучший ответ на поток — продукт, который делает задачи ненужными. Это и есть аргумент в разговоре с PO о приоритетах.
Планирование от факта
Берём в итерацию столько, сколько команда фактически закрывала в последние недели, а не сколько «должны успеть». Поначалу это выглядит как мало — и именно тут ломается петля невыполненных обещаний: выполненное скромное обещание ценнее амбициозного невыполненного.
WIP-лимит
«Долгий ящик» в задачах — это незавершёнка, размазанная по доске. Лимит на количество задач в работе одновременно физически не даёт ей образовываться: меньше начатого — быстрее заканчивается.
Нормы ревью
Письменные правила: про код, а не про автора; замечание как предложение, а не требование; блокирующее замечание — только нарушение стандарта или дефект, остальное на усмотрение автора. Вкусовые споры (форматирование, нейминг, любимые конструкции) выносятся в зафиксированный стандарт — спорить со стандартом можно в отдельном месте, а не в каждом ревью.
Если конфликты в ревью носят характер доминирования, а не резкости — разговор один на один с конкретными примерами: не «ты токсичный», а «вот тред, вот формулировка, вот её эффект — джун заблокирован на три дня». Рецидив после двух разговоров — дисциплинарный шаг с участием руководства.
Дни 60–90: сделать команду предсказуемой
Публичный регулярный статус
Короткая еженедельная сводка стейкхолдерам: что взяли, что закончили, что не возьмём и почему, что в очереди и когда. Скучно, повторяемо, без сюрпризов — ровно так выглядит надёжность снаружи.
Обещания только из статистики
«Сделаем к пятнице» произносится, только если это следует из фактической пропускной способности с буфером на непредвиденное. Всё остальное — «в очереди, ориентир такой-то».
Через два месяца выполненных скучных обещаний команда снова получает право на суждение — то самое, которого стейкхолдеры сейчас не дают.
Ретроспективы: одно изменение за раз
Не «улучшим всё», а одно изменение процесса за итерацию с проверкой через две недели: сработало или нет.
Первые инженерные инвестиции
Когда поток управляем, появляется ресурс на причины пожаров: автотесты на критический путь, мониторинг на необслуживаемые сервисы, автоматизация выкатки. По одной инвестиции за итерацию — теперь есть кому её защитить.
Почему это работает: неявное в явное
Все эти приёмы устроены одинаково: они переводят неявное в явное.
Неявные ожидания → письменный контракт ролей. Невидимый поток задач → очередь с шаблоном. Ощущение «мы всё успеем» → статистика закрытых задач. Вкусовые споры → зафиксированный стандарт. Устные договорённости → еженедельный статус.
Команда из такого кейса страдает не от злых людей и не от слабых технологий — от неявности, в которой каждый достраивает картину сам.
Коротко
- В первые недели наблюдай и собирай данные — не реформируй хаотично.
- Проблемы выглядят как пять пунктов, но крутятся в одной петле: нет контура управления обязательствами.
- 1:1 со всеми при входе дают карту команды точнее любого отчёта.
- Полномочия у перегруженного PO возвращают постепенно — по одной зоне, показывая, что рука держит.
- Бывший лид в команде — потенциальный союзник, если зафиксировать мандат явно.
- Квота мощности и дежурный превращают невидимый поток чужих задач в управляемую очередь.
- Планирование от факта (сколько реально закрывали) ломает петлю невыполненных обещаний.
- Доверие стейкхолдеров возвращается скучной регулярностью: еженедельный статус + выполненные скромные обещания.
- Конфликты в ревью делятся на резкость формы (лечится нормами) и доминирование (лечится разговором с конкретными примерами).
Что почитать дальше
- Что делает архитектор — карта владения сервисами, которая закрывает конфликты «чья это задача».
- ADR — журнал решений; работает и для организационных договорённостей.
- Executable engineering standard — как зафиксированный стандарт убирает вкусовые споры из ревью.