Ключевое
Приоритизация бэклога — зона ПМ (через Комитет Инициатив с входным триажом); постановки готовят аналитики. Тимлид отвечает за приёмку постановок, декомпозицию, инженерную готовность, оценки, зависимости, контроль задач, процесс, качество и людей.
Что предстоит делать
Планирование и поставка
•Организовывать работу команды по канбану: ведение доски, WIP-лимиты, контроль старения задач, pull-принцип взятия задач.
•Фасилитировать оценку задач, согласовывать объём принимаемой в работу и сроки с ПМ, фиксировать договорённости.
•Обеспечивать инженерную готовность задач, декомпозицию, выявление зависимостей и эскалацию рисков.
•Брать задачи из оттриаженной повестки (ПМ/Комитет Инициатив) — без личного участия в первичном триаже инициатив.
Постановка и контроль задач
Вход — готовые постановки от аналитиков (Confluence, пространство «Постановки и архитектура»: бриф, клиентский путь, альтернативные сценарии, межсервисное взаимодействие, контракты). Тимлид:
•Принимает постановку: проверяет полноту и реализуемость (сценарии, контракты, затрагиваемые сервисы), запрашивает у аналитика доп. информацию, возвращает на доработку — до оценки и декомпозиции.
•Декомпозирует постановку на задачи — крупные эпики разбивает на подзадачи по сервисам/слоям.
•Добавляет техническое описание для разработчика: какие сервисы и компоненты затрагиваются, контракты, интеграции, риски, критерии готовности задачи.
•Формулирует и назначает конкретные задачи исполнителям: кто, что, когда.
•Ставит задачи в Jira: создание, назначение, описание, критерии готовности.
•Контролирует исполнение отдельных задач и принимает результат.
•Определяет сроки и дедлайны по конкретным задачам — в канбане нет итераций: прогноз по lead time и приоритетам потока, обязательства по срокам даются по задаче, а не «в следующем спринте».
•Даёт обратную связь по качеству выполнения задач.
Качество и код
•Быть первой линией ревью и merge MR в своём домене — включая работу с большим legacy-монолитом.
•Обеспечивать соблюдение командой DoR/DoD, практик тестирования (PHPUnit, PHPStan) и кодстайла.
•Следить за дефектностью и качеством релизов, инициировать улучшения совместно с QA.
Техдолг
•Выявлять и фиксировать техдолг своего домена в бэклоге команды — не «копить в голове», а вести как задачи с приоритетом и оценкой.
•Резервировать долю пропускной способности команды под техдолг (доля согласовывается с ПМ) и защищать её при пополнении потока.
•Инициировать устранение системных проблем через арх-комитет (RFC), а не локальными заплатками.
•Не является владельцем архитектурных направлений To-Be (ЦАМ, проектирование конвейера) — это зона руководителя группы; тимлид обеспечивает реализацию принятых RFC в своём домене и эскалирует конфликты «техдолг vs фичи» вместо накопления долга.
Люди
•Проводить регулярные 1:1 (еженедельный формат с чек-поинтом «что идёт, что застряло»), ставить цели развития, вести ИПР.
•Участвовать в найме (тех-интервью по матрице), онбординге, техплане испытательного срока.
•Проводить ≥1 технического воркшопа в квартал, обучать старших дежурных.
Инциденты и дежурство (DUTY)
•Команда участвует в дежурстве платформы; лид — точка эскалации (маршрут: дежурный → старший смены → лид домена).
•Доводить унаследованные инциденты домена до исправления (MR), участвовать в post-mortem по значимым инцидентам.
•Соблюдать правило эскалации: наверх — только то, что не решено за 24 часа, в формате «Проблема → Что предпринято → Варианты А/Б → Какой ресурс нужен». Молчаливое затягивание — такой же сбой, как лишняя эскалация.
Архитектура
•Участвовать в архитектурном комитете лидов (4 лида, кворум 3/4, SLA на решение по RFC ≤3 рабочих дней, ротация секретаря) — в рамках управленческой ёмкости, сверх командной нагрузки не добавляется.
Процессы и дисциплина
•Фиксировать работы и время в Jira, вести ежедневный дейли команды.
•При удалёнке — быть на связи в корпоративном мессенджере/почте с 10:00 до 17:00 МСК каждый рабочий день.
Ёмкость (важно донести)
•~30% времени защищено под управленческие функции — с компенсацией за счёт снижения кодинг-нагрузки, а не сверх неё. Это не «менеджмент в свободное время».
•Ручное сопровождение релизов и рутинные хотфиксы — не зона тимлида (релиз-конвейер выделен; у лидов — выпуск по чек-листу).
Что мы ожидаем от кандидата
Обязательно:
•Высшее или незаконченное высшее образование.
•Опыт управления командой разработки от 1 года.
•Уверенный PHP 8.1+, готовность ревьюить и принимать решения в большом legacy-коде (монолит + Symfony-компоненты).
•Понимание инженерных практик, метрик и процессов (ревью, DoR/DoD, PHPUnit/статанализ, WIP, cycle time).
Будет плюсом:
•Понимание управленческих практик, метрик и процессов.
•Опыт организации дежурств/on-call и разбора инцидентов (RCA/post-mortem).
По каким метрикам оценивается работа
•Predictability — план-факт по объёму при контроле качества.
•Cycle time / Ageing WIP — время выполнения задач при стабильном качестве.
•Defect escape / Change failure rate — доля релизов с проблемами.
•Team health — текучка, проведение 1:1, результативность ИПР.
•Самостоятельность — число решений, закрытых без эскалации наверх; соблюдение SLA ревью в домене (нисходящий тренд эскалаций).
Условия
•Оформление c первого рабочего дня в аккредитованную ИТ-компанию в соответствии с нормами ТК РФ, социальные гарантии.
•Гибридный формат работы.
•Очень удобный, просторный офис с дизайнерской отделкой и мощной техникой.
