Когда я пришёл в последнюю компанию тимлидом, первое время ушло на знакомство с командой, ближайшими планами, запуском проекта и задачами адаптации. Через пару недель стало понятно, что пора организовывать работу команды вокруг развития продукта и людей. Я опирался на предыдущий опыт и составил для себя чек‑лист, который разложился на три блока: спринт, команда и продукт.
В этой статье я делюсь этим списком с комментариями - возможно, он окажется полезен тем, кто тоже заходит в новую команду в роли тимлида или хочет навести порядок в своей команде. Здесь нет разбора софт‑скиллов, нет обсуждения, чем тимлид отличается от продакт‑ или проджект‑менеджера, и нет универсальной модели роли. Это набор конкретных действий, которые я для себя определил как важные.
Итак, чек-лист получился таким:
Спринт:
установить все Scrum/Kanban/whatever мероприятия, позвать команду
обеспечить бесперебойную удобную систему перехода из одного спринта в другой
договориться с руководителем, что считается успешным спринтом
Команда:
по календарю распределить периодические 1:1 встречи с каждым участником команды
обсудить с техлидами текущий уровень участников, понять, какие уже договорённости по росту, если есть
обсудить с техлидами и тимлидами других команд процесс ИПР, performance review, матрицы компетенций
Продукт:
обсудить с руководителем и командой, какие компоненты системы относятся к нашей команде
вместе с командой и техлидами провести ревизию, какой сейчас уровень мониторинга каждого компонента
договориться с руководителем, что считается достаточным качеством каждого компонента, и какой процесс работы с багами по каждому
проставить в календарь актуализацию техдолгов по всем направлениям команды: backend, frontend, QA, DevOps, позвать туда соответствующих участников, а также техлидов
Спринт
В этом ��локе тимлид отвечает за то, чтобы у команды был предсказуемый ритм работы: задачи не выпадали между спринтами, люди понимали, что от них ждут, а сам спринт можно было оценить не только «на ощущениях».
1. Настроить мероприятия и позвать команду
Первый шаг - определиться, по какому процессу живёт команда: чистый Scrum, Kanban, Scrumban или своя смесь. Важно не название, а то, чтобы были понятные точки синхронизации, где команда договаривается «что делаем», «как идём» и «что нужно поменять».
Для выбранного процесса тимлид:
Определяет набор регулярных встреч: планирование, груминг/refinement, ежедневные синки, ретро - или их аналоги в Kanban.
Договаривается с командой, зачем нужна каждая встреча: какую информацию там ждут, какие решения принимают, от кого что требуется, формат встречи, а также какие встречи обязательны для всех, а какие можно пропустить.
Важно понимать, что эти встречи нужны не лично лиду. Если он в отпуске или не может присутствовать, это не повод отменять мероприятие для всей команды. Встречи из данного блока нужны, чтобы:
выполнить текущий спринт
подготовиться к следующим Если встречи проводятся, но понимаете, что они не отвечают этим вопросам, то и смысла в них нет.
2. Обеспечить мягкий переход между спринтами
Вторая часть - сделать так, чтобы команда не оказывалась в первый день нового спринта с пулом сырых задач.
Тимлид вместе с командой рисует схему потока работы на несколько спринтов: где делаются фичи, где готовятся будущие задачи (аналитика, декомпозиция, оценка), где чинятся хвосты из прошлых релизов.
Часть времени текущего спринта осознанно резервируется под подготовку следующего: обсуждение задач, продумывание архитектуры, оценка, подготовка тест‑кейсов.
На планировании нового спринта команда выбирает только те задачи, которые уже прошли этот подготовительный цикл, так снижается риск «оценили на глаз, потом внезапно не влезло».
Идея в том, чтобы войти в устойчивый ритм: к концу спринта команда не только доделывает текущие задачи, но и уже готова к следующему, потому что там лежит не хаос, а подготовленный backlog.
3. Договориться с руководителем, что такое «успешный спринт»
Третья ответственность тимлида - вытащить критерии «успеха спринта» из головы руководства и согласовать их в явном виде.
Сюда можно придумать сложные схемы: считать velocity в story points, анализировать загрузку по часам, вводить пороги «не менее 90% задач должны закрываться». На практике только поддержание такой системы занимает много времени и почти гарантированно рождает споры. Гораздо полезнее договориться о коротком и понятном наборе признаков, которые команда может оценить без сложной аналитики.
Например, критерии успешного спринта могут выглядеть так:
закрыто не менее N багов (значение выберете под свою реальность);
главная фича спринта продвинулась на следующий этап (разработка завершена, передано в тестирование или ушло в прод - в зависимости от договорённостей);
команда подготовила задачи на следующий спринт: разобраны, оценены, есть базовое понимание архитектуры и рисков.
Важно именно согласовать эти критерии с руководителем, зафиксировать их и обсудить с командой. Это снижает тревожность и добавляет прозрачности: вместо ситуации, когда каждый по‑разному отвечает на вопрос об успехе спринта, у команды появляется единое понимание, что считать нормой, а что - поводом для изменений.
Команда
В блоке «Команда» тимлид настраивает регулярное взаимодействие с людьми и встраивается в существующие процессы оценки и развития, вместо того чтобы придумывать всё с нуля.
1. Распределить 1:1 по календарю
Первый практический шаг - завести регулярные 1:1 встречи с каждым участником команды и забронировать их в календаре.
Для каждого человека выбирается разумная периодичность: например, раз в 1–2 недели для новых сотрудников и раз в месяц для старичков.
Слоты ставятся сразу на несколько месяцев вперёд, с фиксированной длительностью.
На этих встречах обсуждаются не только задачи, но и мотивация, нагрузка, планы развития, конфликты - всё, что сложно поднять в общем чатике или на созвоне.
Цель тимлида здесь - выстроить личный канал связи с каждым, а не вспоминать о людях только когда что‑то уже горит.
2. Синхронизироваться с техлидами по уровню и росту
Дальше тимлид собирает картину по текущему уровню каждого участника и уже существующим договорённостям.
На встречах с техлидами обсуждается, кто на каком уровне сейчас, какие зоны силы и слабости видят технические лиды по каждому человеку, кто «растёт сам», а кто буксует.
Выясняется, есть ли уже устные или записанные договорённости по росту: что кому обещали, какие цели ставили, какие задачи под развитие уже давались.
По итогам этой калибровки тимлид понимает, с чем входит в личные 1:1: где нужно проговорить ожидания, где поддержать уже начатый план роста, а где честно обсудить стагнацию.
Это помогает не придумывать развитие людей в одиночку, а опираться на взгляд техлидов и существующую историю взаимодействия.
3. Разобраться в процессах ИПР, performance review и матрицах
Третий шаг - понять, как в компании устроены развитие и оценка, и встроить команду в эту систему.
Тимлид общается с техлидами и другими тимлидами, чтобы разобраться, как в компании принято делать индивидуальные планы развития (ИПР): кто инициирует, как часто пересматривают, где их фиксируют и как потом используют.
Отдельно стоит понять процесс performance review: периодичность, источники фидбэка, критерии оценки, формат self‑review, роль тимлида в этой процедуре.
Наконец, важно увидеть, какие матрицы компетенций уже существуют в компании: по каким шкалам оценивают инженеров, какие уровни приняты, как эти матрицы связаны с грейдами и зарплатой.
Задача тимлида - не изобретать свои параллельные правила, а опираться на уже существующие процессы и дополнять их регулярными 1:1 и договорённостями о росте. Важно выстроить с каждым участником команды устойчивую долгосрочную связь независимо от того, хочет ли человек активно расти по ИПРам или ему комфортно на текущем уровне и он предпочитает на нём оставаться.
Продукт
В блоке «Продукт» тимлид отвечает за границы ответственности команды, качество её компонентов и управляемый техдолг. Здесь важно не только «писать фичи», но и понимать, за что именно вы отвечаете в проде и по каким правилам.
1. Определить границы продукта команды
Сначала нужно договориться, что именно входит в вашу зону ответственности.
Тимлид вместе с руководителем и ключевыми участниками команды фиксирует список компонентов: сервисы, модули, скрипты, интеграции, которыми команда владеет.
Для каждого компонента желательно описать кратко: что он делает, кто его основная аудитория (другие сервисы, внутренние пользователи, внешние клиенты), какие зависимости от других команд.
Этот список должен быть доступен всем: в Confluence, репозитории или любом другом общем источнике, чтобы не было ситуации «а это вообще наш кусок или соседей?».
Понятные границы помогают и в дежурствах, и в инцидентах, и при планировании техдолга.
2. Провести ревизию мониторинга
Следующий шаг - понять, насколько хорошо команда вообще видит состояние своих компонентов.
Вместе с командой и техлидами тимлид проходит по каждому компоненту и фиксирует, что уже есть: логирование, метрики, алёрты, дашборды, трассировки, мониторинг ошибок (Sentry и аналоги).
Для каждого элемента отмечается уровень зрелости: есть ли базовые метрики (ошибки, задержки, нагрузка), есть ли алёрты по критичным сценариям, кто получает уведомления и где их смотрит.
По итогам ревизии формируется список дыр: компоненты без мониторинга, без алёртов, без понятных дашбордов, а также минимальный план, как эти дырки закрывать.
Цель первого шага - честно увидеть текущее состояние мониторинга. Дальше задачей команды можно считать постепенное доведение его до уровня, при котором она в большинстве случаев первой узнаёт о проблемах своих сервисов, а не из тикетов техподдержки.
3. Договориться о «достаточном качестве» и процессе по багам
Дальше тимлид согласует с руководителем и командой, что считается нормальным качеством для каждого компонента и как компания или команда работает с дефектами.
Обговариваются целевые уровни качества: допустимый уровень ошибок, время реакции на инциденты, требования к покрытию тестами, частота регрессов и т.п.
Определяется процесс работы с багами: как они попадают в трекер, как приоритизируются, в какие сроки команда обязуется разбирать разные уровни серьёзности, что попадает в ближайший спринт, а что уходит в отдельный backlog.
Важно договориться, что качество - это не только «не падать», но и, например, стабильное время отклика, адекватное поведение под нагрузкой.
Фиксированные критерии качества снимают много споров «почему вы это не починили сразу» и помогают аргументировать приоритизацию.
4. Регулярно актуализировать техдолг
Наконец, техдолг по продукту нужно не просто «где‑то хранить», а регулярно поднимать, пересматривать и брать в спринт.
Тимлид проставляет в календарь встречи по ревизии техдолгов по всем направлениям: backend, frontend, QA, DevOps. Периодичность может быть разной (например, ежемесячно для кода и поквартально для инфраструктуры), но слоты должны быть регулярными.
На эти встречи приглашаются соответствующие участники и техлиды: те, кто лучше всего знает проблемы своих зон и может оценить, во что выльется то или иное улучшение.
По итогам ревизий список техдолга обновляется: часть задач умирает как неактуальные, часть поднимается в приоритет, часть объединяется в более крупные инициативы, которые можно планировать только на уровне всей компании.
Так техдолг становится частью управляемого продукта, а не бесконечным списком «боли», о которой вспоминают только после очередного падения.
Отдельно хочется упомянуть фичёвый roadmap продукта. Формально это зона ответственности продакта и руководства, а не тимлида и команды разработки, и нередко его просто нет: компания годами живёт в режиме «стартапа», ограничиваясь ближайшим спринтом. В такой ситуации я для себя считаю достаточным минимумом понятные планы хотя бы на следующий спринт: этого уже хватает, чтобы команда работала спокойно. Если когда‑нибудь появится прогноз хотя бы на квартал - это станет приятным бонусом, но чек‑лист в этой статье не зависит от наличия большого roadmap’а.
Заключение
Всё выше - это не универсальный стандарт, а рабочая карта, которая помогла мне быстро сориентироваться в новой компании и разложить работу на три понятные блока: спринт, команда и продукт. Где‑то будут другие артефакты и процессы, но базовые вопросы останутся теми же: понятен ли ритм работы, есть ли системная работа с людьми и ясно ли, за какой кусок продукта команда отвечает.
