Обязанности:
Ключевое: приоритизация бэклога — зона ПМ (через Комитет Инициатив с входным триажом); постановки готовят аналитики. Тимлид отвечает за приёмку постановок, декомпозицию, инженерную готовность, оценки, зависимости, контроль задач, процесс, качество и людей. Что предстоит делать Планирование и поставка Организовывать работу команды по канбану: ведение доски, 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 первого рабочего дня в аккредитованную ИТ-компанию в соответствии с нормами ТК РФ, социальные гарантии; Гибридный формат работы. Очень удобный, просторный офис с дизайнерской отделкой и мощной техникой.Похожие вакансии
Руководитель команды разработки
Договорная
Москва. Станции метро: Авиамоторная
Защищенные Телекоммуникации
Руководитель команды разработки (Go)
От 450 000 до 600 000 руб.
Москва. Станции метро: Авиамоторная
Клируэй Текнолоджис