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

Описания нет

• Организовывать работу команды по канбану: ведение доски, WIP-лимиты, контроль старения задач, pull-принцип взятия задач.
• Фасилитировать оценку задач, согласовывать объём принимаемой в работу и сроки с ПМ, фиксировать договорённости.
• Обеспечивать инженерную готовность задач, декомпозицию, выявление зависимостей и эскалацию рисков.
• Брать задачи из оттриаженной повестки (ПМ/Комитет Инициатив) — без личного участия в первичном триаже инициатив.
• Принимает постановку: проверяет полноту и реализуемость (сценарии, контракты, затрагиваемые сервисы), запрашивает у аналитика доп. информацию, возвращает на доработку — до оценки и декомпозиции.
• Декомпозирует постановку на задачи — крупные эпики разбивает на подзадачи по сервисам/слоям.
• Добавляет техническое описание для разработчика: какие сервисы и компоненты затрагиваются, контракты, интеграции, риски, критерии готовности задачи.
• Формулирует и назначает конкретные задачи исполнителям: кто, что, когда.
• Ставит задачи в Jira: создание, назначение, описание, критерии готовности.
• Контролирует исполнение отдельных задач и принимает результат.
• Определяет сроки и дедлайны по конкретным задачам — в канбане нет итераций: прогноз по lead time и приоритетам потока, обязательства по срокам даются по задаче, а не «в следующем спринте».
• Даёт обратную связь по качеству выполнения задач.
• Быть первой линией ревью и merge MR в своём домене — включая работу с большим legacy-монолитом.
• Обеспечивать соблюдение командой DoR/DoD, практик тестирования (PHPUnit, PHPStan) и кодстайла.
• Следить за дефектностью и качеством релизов, инициировать улучшения совместно с QA.
• Выявлять и фиксировать техдолг своего домена в бэклоге команды — не «копить в голове», а вести как задачи с приоритетом и оценкой.
• Резервировать долю пропускной способности команды под техдолг (доля согласовывается с ПМ) и защищать её при пополнении потока.
• Инициировать устранение системных проблем через арх-комитет (RFC), а не локальными заплатками.
• Тимлид обеспечивает реализацию принятых RFC в своём домене и эскалирует конфликты «техдолг vs фичи» вместо накопления долга.
• Проводить регулярные 1:1 (еженедельный формат с чек-поинтом «что идёт, что застряло»), ставить цели развития, вести ИПР.
• Участвовать в найме (тех-интервью по матрице), онбординге, техплане испытательного срока.
• Проводить ≥1 технического воркшопа в квартал, обучать старших дежурных.
• Доводить унаследованные инциденты домена до исправления (MR), участвовать в post-mortem по значимым инцидентам.
• Соблюдать правило эскалации: наверх — только то, что не решено за 24 часа, в формате «Проблема → Что предпринято → Варианты А/Б → Какой ресурс нужен». Молчаливое затягивание — такой же сбой, как лишняя эскалация.
• Участвовать в архитектурном комитете лидов (4 лида, кворум 3/4, SLA на решение по RFC ≤3 рабочих дней, ротация секретаря) — в рамках управленческой ёмкости, сверх командной нагрузки не добавляется.

• Высшее или незаконченное высшее образование.
• Опыт управления командой разработки от 1 года.
• Уверенный PHP 8.1+, готовность ревьюить и принимать решения в большом legacy-коде (монолит + Symfony-компоненты).
• Понимание инженерных практик, метрик и процессов (ревью, DoR/DoD, PHPUnit/статанализ, WIP, cycle time).
• Будет плюсом: Понимание управленческих практик, метрик и процессов; Опыт организации дежурств/on-call и разбора инцидентов (RCA/post-mortem)

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