PM / Agile-Kanban коуч (delivery)

Twinby
Москва •Опубликовано 9 июля 2026
Зарплата не указана
Полная занятость3–6 летМенеджер
Зарплата не указана

Описание

О роли

Twinby — один из крупнейших российских дейтинг-сервисов с миллионами пользователей: реалтайм (лента, матчи, чаты), деньги (подписки, покупки), антифрод и модерация. Мы перестраиваем инженерную систему Twinby CIS и собираем команды практически с нуля. Ищем delivery / Agile-Kanban коуча, который отвечает за поток и предсказуемость доставки — не «ведёт джиру и проводит дейли».

Это кросс-командная роль: ты не владеешь продуктом («что» — за продактом) и не отвечаешь за «как» внутри команды (это техлид). Ты отвечаешь за то, чтобы замкнутый цикл «Идея → готовность → разработка → гейты → релиз → выводы» реально работал и не вставал. Качество у нас — свойство процесса, а не героизма: твоя зона — сделать поток видимым, держать его здоровым и предсказуемым.

Чем предстоит заниматься

  • Держать поток как систему: Kanban с явными политиками для текущей работы + Shape Up для крупных фич (фикс времени, переменный объём, «аппетит» вместо оценки, по умолчанию не продлеваем). Не «чистый Scrum» и не «чистый Kanban» — рабочая операционная модель.

  • Резать WIP: WIP-лимиты 1–2 задачи на инженера — главный рычаг предсказуемости. Вскрывать скрытый WIP и очереди (ревью, QA, приёмка), мерить, где задачи реально стоят.

  • Вести классы обслуживания: Standard / Expedite (P0–P1) / Fixed-date — чтобы срочное не сносило плановое, а у каждой работы была понятная политика прохождения.

  • Мерить поток и прогнозировать вероятностно: WIP, cycle time, throughput, work item age; прогноз в духе «с вероятностью 85% к 1–8 июля», а не «будет 1 июля». Строки кода, коммиты и стори-поинты на человека как цели — нет (закон Гудхарта).

  • Лечить здоровье доставки: carryover, зависшие и стареющие задачи, межкомандные зависимости — распутывать и снимать блокеры, а не «напоминать в чате».

  • Делать гейты политиками перехода, а не ритуалом, и вести тяжёлые разговоры данными: что лечит систему, а что нет; защищать команду от перегрузки.

Что мы ждём

  • Опыт, где ты реально вытаскивал команду из завала: хронический carryover, срывающиеся релизы, зависимость от одного человека на критичном модуле — и чинил это руками, а не описывал в презентации.

  • Мышление про поток: cycle time, throughput, WIP, work item age, доля незапланированной работы — и вероятностный прогноз вместо обещаний «к пятнице».

  • WIP-лимиты и классы обслуживания для тебя — рабочий инструмент, а не теория: ты понимаешь, зачем резать незавершёнку и как разводить срочное и плановое.

  • Умеешь диагностировать прежде, чем лечить: сначала смотришь, где встал поток и почему, потом меняешь политики — а не вводишь церемонии в первый день.

  • Trade-offs с оговорками: когда уместен Kanban, когда Scrum, когда гибрид и где работает Shape Up — по природе работы, а не «X современнее Y».

  • Технически грамотен настолько, чтобы понимать, о чём спорят инженеры (техдолг, связность, релизный цикл, надёжность), и не дать процессу подменить результат.

Будет плюсом

  • Релевантный домен: turnaround / спасение проектов, зрелый продуктовый Kanban с WIP-лимитами и метриками потока, release engineering, управление потоком инцидентов и поддержки под нагрузкой.

  • Практика вероятностного прогноза (перцентили, Monte-Carlo) и опыт Shape Up на реальных циклах.

  • Активность в сообществе: выступления на AgileDays, Flow Conf, в Канбан-сообществах; канал или блог про поток и delivery.

Чего НЕ требуем

Артефактов Scrum наизусть и «правильной» длины спринта, иконостаса сертификатов (PSM / PMP / SAFe / ICP), заученных определений церемоний, опыта именно в нашем трекере или в дейтинге. Нам важнее масштаб хаоса, который ты разгребал, и мышление про поток.

Окружение и инструменты

Jira и Confluence для работы и документации, метрики потока и дашборды (Yandex DataLens) как способ видеть, где стоит работа, и принимать решения по данным. Конкретный набор подстроим под тебя — важно, чтобы инструмент служил потоку, а не наоборот.

Что предлагаем

  • Настоящий мандат менять систему доставки, а не косметика на церемониях: ты задаёшь политики потока с нуля, пока нормы ещё не застыли.

  • Настоящая инженерная система, а не лозунги: замкнутый цикл доставки, метрики потока вместо velocity и стори-поинтов, вероятностный прогноз вместо дат «пальцем в небо».

  • Влияние на поток сразу нескольких команд на масштабе миллионов пользователей.

  • Высокая автономия и прямой контакт с CTO: тебя слушают по данным, а не по статусу.

  • Формат: удалёнка, РФ.

Описание

О роли

Twinby — один из крупнейших российских дейтинг-сервисов с миллионами пользователей: реалтайм (лента, матчи, чаты), деньги (подписки, покупки), антифрод и модерация. Мы перестраиваем инженерную систему Twinby CIS и собираем команды практически с нуля. Ищем delivery / Agile-Kanban коуча, который отвечает за поток и предсказуемость доставки — не «ведёт джиру и проводит дейли».

Это кросс-командная роль: ты не владеешь продуктом («что» — за продактом) и не отвечаешь за «как» внутри команды (это техлид). Ты отвечаешь за то, чтобы замкнутый цикл «Идея → готовность → разработка → гейты → релиз → выводы» реально работал и не вставал. Качество у нас — свойство процесса, а не героизма: твоя зона — сделать поток видимым, держать его здоровым и предсказуемым.

Чем предстоит заниматься

  • Держать поток как систему: Kanban с явными политиками для текущей работы + Shape Up для крупных фич (фикс времени, переменный объём, «аппетит» вместо оценки, по умолчанию не продлеваем). Не «чистый Scrum» и не «чистый Kanban» — рабочая операционная модель.

  • Резать WIP: WIP-лимиты 1–2 задачи на инженера — главный рычаг предсказуемости. Вскрывать скрытый WIP и очереди (ревью, QA, приёмка), мерить, где задачи реально стоят.

  • Вести классы обслуживания: Standard / Expedite (P0–P1) / Fixed-date — чтобы срочное не сносило плановое, а у каждой работы была понятная политика прохождения.

  • Мерить поток и прогнозировать вероятностно: WIP, cycle time, throughput, work item age; прогноз в духе «с вероятностью 85% к 1–8 июля», а не «будет 1 июля». Строки кода, коммиты и стори-поинты на человека как цели — нет (закон Гудхарта).

  • Лечить здоровье доставки: carryover, зависшие и стареющие задачи, межкомандные зависимости — распутывать и снимать блокеры, а не «напоминать в чате».

  • Делать гейты политиками перехода, а не ритуалом, и вести тяжёлые разговоры данными: что лечит систему, а что нет; защищать команду от перегрузки.

Что мы ждём

  • Опыт, где ты реально вытаскивал команду из завала: хронический carryover, срывающиеся релизы, зависимость от одного человека на критичном модуле — и чинил это руками, а не описывал в презентации.

  • Мышление про поток: cycle time, throughput, WIP, work item age, доля незапланированной работы — и вероятностный прогноз вместо обещаний «к пятнице».

  • WIP-лимиты и классы обслуживания для тебя — рабочий инструмент, а не теория: ты понимаешь, зачем резать незавершёнку и как разводить срочное и плановое.

  • Умеешь диагностировать прежде, чем лечить: сначала смотришь, где встал поток и почему, потом меняешь политики — а не вводишь церемонии в первый день.

  • Trade-offs с оговорками: когда уместен Kanban, когда Scrum, когда гибрид и где работает Shape Up — по природе работы, а не «X современнее Y».

  • Технически грамотен настолько, чтобы понимать, о чём спорят инженеры (техдолг, связность, релизный цикл, надёжность), и не дать процессу подменить результат.

Будет плюсом

  • Релевантный домен: turnaround / спасение проектов, зрелый продуктовый Kanban с WIP-лимитами и метриками потока, release engineering, управление потоком инцидентов и поддержки под нагрузкой.

  • Практика вероятностного прогноза (перцентили, Monte-Carlo) и опыт Shape Up на реальных циклах.

  • Активность в сообществе: выступления на AgileDays, Flow Conf, в Канбан-сообществах; канал или блог про поток и delivery.

Чего НЕ требуем

Артефактов Scrum наизусть и «правильной» длины спринта, иконостаса сертификатов (PSM / PMP / SAFe / ICP), заученных определений церемоний, опыта именно в нашем трекере или в дейтинге. Нам важнее масштаб хаоса, который ты разгребал, и мышление про поток.

Окружение и инструменты

Jira и Confluence для работы и документации, метрики потока и дашборды (Yandex DataLens) как способ видеть, где стоит работа, и принимать решения по данным. Конкретный набор подстроим под тебя — важно, чтобы инструмент служил потоку, а не наоборот.

Что предлагаем

  • Настоящий мандат менять систему доставки, а не косметика на церемониях: ты задаёшь политики потока с нуля, пока нормы ещё не застыли.

  • Настоящая инженерная система, а не лозунги: замкнутый цикл доставки, метрики потока вместо velocity и стори-поинтов, вероятностный прогноз вместо дат «пальцем в небо».

  • Влияние на поток сразу нескольких команд на масштабе миллионов пользователей.

  • Высокая автономия и прямой контакт с CTO: тебя слушают по данным, а не по статусу.

  • Формат: удалёнка, РФ.

Похожие вакансии

Оператор исходящих B2B-продаж (холодная база)
Т-Банк
от 70000 руб.
Полная занятостьОпыт 1–3 года
Менеджер по продажам кредитных продуктов
Т-Банк
от 82000 руб.
Полная занятостьОпыт 1–3 года
Менеджер дистанционных продаж среднему и крупному бизнесу
Т-Банк
Зарплата не указана
Полная занятостьОпыт 1–3 года
Менеджер по продажам кредитных продуктов
Т-Банк
от 71000 руб.
Полная занятостьОпыт 1–3 года
Сетевой инженер
АО «ОТП Банк» (JSC «OTP Bank»)
Зарплата не указана
Полная занятостьОпыт 1–3 года
Менеджер по продукту (координатор команды)
Оптимакрос
Зарплата не указана
Полная занятостьОпыт 1–3 года