Руководитель команды разработки

Ключевое: приоритизация бэклога — зона ПМ (через Комитет Инициатив с входным триажом); постановки готовят аналитики. Тимлид отвечает за приёмку постановок, декомпозицию, инженерную готовность, оценки, зависимости, контроль задач, процесс, качество и людей.

Что предстоит делать

Планирование и поставка

• Организовывать работу команды по канбану: ведение доски, 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 первого рабочего дня в аккредитованную ИТ-компанию в соответствии с нормами ТК РФ, социальные гарантии;
• Гибридный формат работы.
• Очень удобный, просторный офис с дизайнерской отделкой и мощной техникой.