Перейти к основному содержимому

Первые 90 дней тимлида

Руководителю
Теория данных (раздел 3)

Миграции и оценка объёма данных — Пакетная работа, Основы БД. Проверка на стенде — SQL для тестировщика. Карта — о разделе.

Переход в роль тимлида — это смена режима работы — больше неопределённости, больше горизонтальных связей, меньше предсказуемых "зелёных тестов". Материал — практический маршрут на первые 2–3 месяца. Два сценария: вы пришли в новую команду или стали лидом своей бывшей команды.

Ожидания от роли — в Роль тимлида. Основы проекта — в Основы управления IT-проектами.


Общее правило — без обещаний в первые недели

В первые 2–4 недели не давайте жёстких коммитов по срокам и объёму бизнесу, руководству и команде. У вас ещё нет картины:

  • технического долга и "минных полей" в коде;
  • реальной скорости команды и скрытых отпусков/офферов;
  • процессов согласований и релизного цикла;
  • стиля заказчика (продукт, бизнес-аналитика);
  • того, что уже обещали до вашего прихода.

Обещание "сделаем за три дня" при месячном техдолге на конфиг — типичный источник потери доверия. Лучше: "изучу контекст до пятницы, вернусь с оценкой и рисками".


Сценарий A — новая команда

Неделя 1 — картирование

ДействиеЗачем
Встреча с непосредственным руководителемОжидания, KPI испытательного срока, известные конфликты, эскалации
Встреча с продуктом / владельцем бэклогаЦели квартала, боль пользователей, что "горит"
Регламенты, Confluence, доступыСократить время на "где лежит правда"
Наблюдение за дейли, планированием, ретроКак реально работают церемонии, а не как в презентации
Короткие 1-on-1 с каждымОжидания от вас, мотивация, риски ухода (формат)

С руководителем зафиксируйте письменно:

  • зона ответственности (люди, сроки, качество, найм — что именно);
  • рычаги (бюджет, приоритет бэклога, увольнение);
  • красные флаги по людям, о которых вам уже сказали.

Недели 2–4 — глубина

  • Пройдите путь от идеи до прода — где ломается, кто владелец сред, как устроен мониторинг.
  • Соберите список рисков — интеграции, единственный эксперт, устаревший стек, долги по тестам.
  • Уточните правила релиза и on-call, если есть.
  • Начните еженедельные 1-on-1 по регулярному расписанию.

Месяцы 2–3 — изменения

  • Одно улучшение процесса с измеримым эффектом (например, шаблон задачи, лимит WIP, фикс токсичного дейли — см. стендапы).
  • Прозрачный план по техдолгу согласованный с продуктом.
  • Первые обратные связи команде: что улучшилось, что в работе.

Сценарий B — своя бывшая команда

Вы уже знаете код и людей — это ускоряет старт. Появляются другие риски:

  • коллеги воспринимают вас по-старому ("Вася из соседнего стола");
  • ожидание фаворитизма или, наоборот, жёсткости "теперь начальник";
  • соблазн микроменеджмента, потому что "сам сделаю быстрее".

Рекомендации:

  1. Публичная встреча с командой — новая роль, что изменится в коммуникации, что останется прежним.
  2. Явно разделить дружбу и рабочую обратную связь — критика только на 1-on-1.
  3. Делегировать задачи, которые раньше делали вы сами; не забирать "лучшие" фичи себе.
  4. Те же шаги с руководителем и продуктом — формально, как для внешнего кандидата.

Церемонии — на что смотреть

ЦеремонияВопросы лиду
ДейлиКоманда говорит друг с другом или отчитывается вам? Есть ли углубления в детали?
ПланированиеЗадачи готовы к разработке? Есть ли буфер?
РетроПоявляются ли действия или только жалобы?
Ревью / демоВидит ли стейкхолдер ценность?

Подробнее про дейли — Ежедневные стендапы; про оценки — Оценка трудозатрат.


Анализ команды (лёгкая матрица)

Для каждого человека (только для себя, без ярлыков в HR):

ОсьНаблюдение
РезультатСтабильность поставки, качество
РостКуда хочет развиваться
РискВыгорание, оффер, конфликт
ВзаимодействиеКому помогает / кого блокирует

Цель — распределить внимание и менторство, а не "рейтинговать".


Типовые ошибки первых месяцев

ОшибкаАльтернатива
Сразу менять весь процессОдно изменение, измерить эффект
Брать критичные задачи в кодРазблокировать того, кто учится
Игнорировать продуктЕженедельный слот 30 мин с владельцем бэклога
Публичная критика на дейлиХвалить при всех — разбирать наедине
Токсичный оптимизм ("всё успеем")Именованные риски в плане

Чек-лист к концу 90 дней

  • Ожидания руководителя и ваша зона ответственности зафиксированы
  • С каждым в команде был регулярный 1-on-1 минимум 6 раз
  • Вы можете нарисовать поток от задачи до прода
  • Есть список топ-5 рисков и план по одному из них
  • Команда понимает приоритеты на квартал
  • Вы не выгорели: есть блоки без встреч в календаре

Куда дальше


План коммуникации на первые 90 дней

Сильный старт тимлида зависит от ясных договорённостей с ключевыми сторонами.


Кого синхронизировать регулярно

  • Руководитель — цели, риски, формат эскалаций.
  • Продукт или владелец бэклога — приоритеты, scope, изменения.
  • Смежные команды — зависимости, SLA, зона ответственности.
  • Команда разработки: контекст решений и прозрачность приоритетов.

Мини-чек-лист зрелого старта

  • У каждого участника команды есть понятные ожидания на квартал.
  • У вас есть список операционных и кадровых рисков.
  • Топ-риски имеют план действий и владельца.
  • В календаре закреплены регулярные 1-on-1 и слоты без встреч.

Этот минимум снижает хаос и формирует доверие к новой роли.


В подборках

Статья входит в тематические подборки и блок "С чего начать?" на главной. Соседние шаги того же маршрута:

ТимлидРоль тимлида — ожидания, риски и выбор траектории, Ежедневные стендапы и коммуникация, Эффективное управление разработчиками, Scrum — о разделе, Команда и управление — о разделе, Культура кода — о разделе.