Материал Эйч · Опубликовано 21 июля 2026
Руководитель проектов и портфеля в команде эквайринга: крупные технологические программы, PMO-практики, синхронизация с бизнесом и регуляторикой
Фишка: «Секции до команд»: кандидат проходит стандартизированные блоки (менеджмент, кейсы), и только после успешного прохождения его профиль рассылают командам на выбор — это снижает нагрузку на hiring manager, но удлиняет процесс.
| Этап | Длительность | Что проверяют |
|---|---|---|
| HR-скрининг | 25–30 мин | Опыт в финтехе и управлении программами, мотивация, грейд, зарплатные ожидания, готовность к гибриду в Санкт-Петербурге (офис 2–3 раза в неделю) |
| Секция по менеджменту / PM-компетенциям | 60 мин | Кейсы по срокам, техдолгу, простоям команды, эскалациям; взаимодействие с разработкой и бизнесом; опыт построения PMO |
| Портфель и проектное управление | 60 мин | Приоритизация портфеля, ресурсное планирование PM, дорожные карты, метрики эффективности, прозрачность для стейкхолдеров |
| Домен и контекст эквайринга | 45–60 мин | Понимание платёжных систем, регуляторных требований, импортозамещения; запуск продуктов и пилотирование |
| Знакомство с командой / hiring manager | 40–60 мин | Fit с командой эквайринга, мотивация, вопросы о портфеле и ожиданиях от роли |
| Оффер-встреча | 30–45 мин | Условия, бонусы, перфоманс-ревью, согласование деталей с HR и руководителем |
Обязательный минимум
Плюсом будет
Какие знаешь методологии управления проектами?
Waterfall для регуляторных/инфраструктурных программ; Agile/Scrum/Kanban для продуктовых потоков; гибрид в финтехе. Упомяни выбор под тип проекта, а не «одна методология на всё».
Что такое Kanban и какое главное ограничение в Kanban?
Визуализация потока, WIP-лимиты, pull-система, непрерывное улучшение. Главное ограничение — WIP: без него Kanban превращается в доску задач без управления потоком.
Как участвовал в развитии проектного офиса и методологии?
Единые шаблоны (план, риски, статус), ритуалы (portfolio review, steering), метрики (on-time, scope, budget), обучение PM, пилот → масштабирование практик.
Фишка: В вакансии явно ждут не только delivery PM, но и вклад в развитие PMO: метрики, автоматизация рутины, внедрение практик в подразделении.
Совет: На секции менеджмента в Т-Банке ценят реальный опыт планирования и руководства командами больше, чем теорию из книг по DevOps.
Что включает техническое задание / перечень работ по проекту?
Цели, scope, out-of-scope, требования, ограничения, зависимости, критерии приёмки, роли, риски, план-график. Для IT-проекта — интеграции, NFR, регуляторные требования.
Какая длительность проектов была и как строился план?
Кратко: тип проекта → горизонт (3–6 мес / 1–2 года) → этапы (discovery, build, pilot, rollout) → контрольные точки и буферы на неопределённость.
Как ставили задачи на проекте?
Декомпозиция от целей → эпики/фичи → оценка → приоритизация → постановка в трекере (Jira/YouTrack) с DoR/DoD, owner и сроками.
Что включает разбиение эпиков и что должно быть в их описании?
User story map или WBS; в описании: бизнес-цель, acceptance criteria, зависимости, риски, оценка, связь с метриками.
Ловушка: Не перечисляй только шаблон документа — покажи, как ТЗ/план помогали снять неопределённость и зафиксировать коммиты перед заказчиком.
Как управлять приоритетами задач, чтобы разработчики не простаивали и ожидания стейкхолдеров были управляемы?
Единый бэклог портфеля, WIP-лимиты, прозрачная capacity-модель, регулярная re-prioritization с бизнесом, буфер на срочные регуляторные задачи.
Как работать с приоритетами проектов портфеля и синхронизировать их со стратегией бизнеса?
Критерии: ROI, регуляторный дедлайн, стратегические инициatives, зависимости, риск простоя. Формат: portfolio board + steering committee, фиксация trade-offs.
Есть ли бэклог задач и как вы его ведёте?
Единый источник правды, приоритизация (WSJF/RICE/матрица impact-effort), регулярный grooming, связь с capacity команды.
Фишка: Роль совмещает delivery и portfolio management: нужно уметь и вести крупный проект, и обеспечивать прозрачность всего портфеля для заказчиков.
Как задаются вопросы и уточняются требования у стейкхолдеров?
Подготовка, правильные вопросы (что/зачем/критерии успеха), протоколирование, validation через прототип/MVP, RACI.
Как коммуницировать с бизнесом при простаивании разработчиков из-за незавершённой проработки требован?
Прозрачность: показать cost of delay, предложить plan B (техдолг, другой поток), совместный backlog refinement, эскалация блокера с вариантами решения.
Какие были бизнес-цели на проекте?
Формулируй через метрики: time-to-market нового продукта, снижение отказов транзакций, соответствие регулятору, экономия на инфраструктуре.
Какие у вас заказчики кроме вас самого?
Покажи матрицу стейкхолдеров: бизнес-линия, IT, compliance, операционный блок; как балансировал конфликтующие интересы.
Совет: В Т-Банке ценят умение формулировать развилки и выносить решения на нужный уровень — не «ждать указаний», а приносить options с последствиями.
Как руководитель относится к уходу ключевого специалиста и текущей ситуации проекта?
STAR: оценка impact → bus factor → plan (передача знаний, замена, пересмотр scope/сроков) → коммуникация со стейкхолдерами.
Как контролировать открытые вопросы и формулировать развилки?
Issue log с owner и deadline; для развилки — 2–3 варианта, плюсы/минусы, рекомендация, эскалация на steering при блокере > N дней.
Как обеспечивать контроль коммитов по срокам перед заказчиками?
Baseline + регулярный статус, early warning при отклонении >10%, change control, пересмотр scope только через формальное согласование.
Ловушка: На секции менеджмента часто дают кейсы: сорванный релиз, техдолг, «продукт не работает» — нужен структурированный алгоритм, а не паника.
В каких доменах вы работали и что знаете об эквайринге?
Цепочка: merchant → PSP/acquirer → карточные сети → issuer. Темы: авторизация/клиринг, chargeback, PCI DSS, 54-ФЗ, онлайн/офлайн эквайринг.
Как организовать пилотирование и промышленное развёртывание платёжного решения?
Pilot scope → критерии go/no-go → поэтапный rollout (canary/regions) → мониторинг SLA → rollback plan → hypercare после запуска.
Как адаптировать функционал под новые требования регулятора или импортозамещения?
Impact analysis → gap → программа работ с жёстким дедлайном → параллельный контур → миграция данных → audit trail.
Фишка: Проекты в эквайринге Т-Банка связаны с запуском новых продуктов, адаптацией под платёжные системы и регуляторику — покажи опыт технологических программ в финтехе.
Как обеспечивать проекты ресурсами PM и контролировать целесообразность их выделения?
Capacity planning по навыкам/домену, правило «1 PM на программу / N проектов», регулярный review загрузки, критерии когда PM нужен full-time.
Как работать с low-performers среди PM?
Факты (метрики проектов, feedback стейкхолдеров) → 1:1 с конкретным планом → ментoring/обучение → контрольная точка → решение о ротации.
Как собирать обратную связь стейкхолдеров о работе PM в портфеле?
Регулярные опросы после milestone, ретро с заказчиком, NPS по коммуникации, использование feedback в performance review.
Совет: Роль C-level PM: ожидают опыт управления командой руководителей проектов, а не только личного delivery.
Приоритизация портфеля при конфликте дедлайнов
В портфеле 4 проекта: (A) регуляторный дедлайн через 8 недель — обязательная доработка эквайринга; (B) запуск нового продукта для крупного мерчанта — коммит CEO; (C) оптимизация инфраструктуры — экономия 15% cost; (D) техдолг платёжного шлюза — риск инцидентов. Доступно 3 PM и 2 команды разработки. Как расставите приоритеты и что скажете стейкхолдерам проекта B?
1) A — безусловный приоритет (регуляторный риск). 2) Оценить risk/cost of delay по D — если высокий, выделить часть capacity параллельно с A. 3) B — пересмотреть scope/MVP или сдвинуть дату с письменным trade-off для CEO (partial launch). 4) C — отложить или минимальный quick win. Ресурсы: PM1+PM2 на A, PM3 на B+D coordination. Коммуникация: steering с options для B, не «нет», а «что получим при сценариях».
Сложность: O(n) по числу проектов в оценке приоритетов
Ресурсный план PM на квартал
Бэклог: 2 крупные программы (each 0.5 FTE PM), 5 средних проектов (0.2 FTE each), 3 инициативы «на будущее». В штате 4 PM, один уходит на 6 недель в другую программу. Постройте ресурсный план на квартал.
Capacity: 4 PM × 3 мес = 12 PM-months минус 1.5 PM-months (отпуск/перевод) = 10.5. Demand: программы 3 + средние 3 + инициативы 0 = 6 PM-months core + buffer. Распределение: старший PM на программу 1, PM2 на программу 2, PM3+PM4 на средние (по 2-3 каждый). Инициативы — discovery без FTE или 10% времени старшего PM. Риски: перегруз → defer 2 средних проекта или hire contractor PM.
Сложность: O(n·m) — n проектов, m PM
Эскалация развилки по scope
За 3 недели до релиза бизнес требует добавить интеграцию с новым платёжным методом. Команда оценивает +4 недели. Регуляторный релиз базового функционала обязателен в срок. Ваши действия?
1) Зафиксировать развилку: (1) релиз в срок без интеграции + phase 2; (2) сдвиг на 4 недели — риски штрафов/репутации; (3) MVP интеграции + техдолг. 2) Impact analysis по каждому. 3) Steering в течение 48ч с рекомендацией: сценарий 1 + commitment на phase 2 с датой. 4) Change request в план, обновление comms. 5) Post-mortem по позднему change request.
Сложность: O(1) — фиксированное число options
Каркас ответа
3 дня
7 дней
14 дней
| Блок | Готов, если... |
|---|---|
| Методологии и PMO | можешь объяснить, когда Waterfall, когда Kanban, и как внедрял практики PMO |
| Портфель | можешь за 10 мин разложить приоритеты 4 проектов с trade-offs |
| Стейкхолдеры | есть 2 STAR-кейса по эскалации и управлению ожиданиями |
| Эквайринг | можешь описать цепочку платежа и этапы pilot → prod rollout |
| Команда PM | есть пример развития PM и работы с underperformer |
| Behavioral | pitch на 3 мин и 5 STAR-историй отрепетированы вслух |
В день собеседования