Материал Эйч · Опубликовано 6 августа 2026
Гайд по подготовке к собеседованию на позицию руководителя проектов в цифровой экосистеме МТС: управление длительными проектами, работа со стейкхолдерами, планирование и контроль в гибридном формате
Фишка: Акцент на сочетании проектного, продуктового и операционного подходов в масштабной экосистеме — кандидата оценивают по способности балансировать требования множества стейкхолдеров и управлять длительными кросс-функциональными проектами
| Этап | Длительность | Что проверяют |
|---|---|---|
| HR-скрининг | 30–45 мин | Мотивация, соответствие вакансии, опыт управления проектами от 1 года, готовность к гибридному формату в Москве, зарплатные ожидания |
| Интервью с нанимающим менеджером | 60 мин | Опыт ведения длительных проектов, работа со стейкхолдерами, примеры проектных артефактов, сочетание проектного и продуктового подходов |
| Компетентностное интервью | 60–90 мин | Методологии, планирование, управление рисками и отклонениями, приоритизация, кейсы по конфликтам и простоям команды |
| Финальное интервью | 30–60 мин | Культурное соответствие, системное мышление, мотивация команды, видение развития в экосистеме МТС |
Обязательный минимум
Плюсом будет
Какие знаешь методологии управления проектами?
Waterfall (последовательные фазы), Agile (итерации, гибкость), Scrum (спринты, роли, артефакты), Kanban (поток, WIP-лимиты). Укажи, когда какую применяешь: предсказуемость vs неопределённость.
Что такое Kanban?
Метод визуализации потока работ: доска, колонки, WIP-лимиты, pull-система, непрерывное улучшение (Kaizen). Подходит для поддержки и потоковой работы.
Какое главное ограничение в Kanban?
WIP-лимиты — ограничение незавершённой работы. Без них Kanban превращается в простую доску задач. Также: нет фиксированных итераций, сложнее планировать дедлайны.
Как сочетать проектный, продуктовый и операционный подходы?
Проектный — чёткие цели, сроки, бюджет. Продуктовый — ценность для пользователя, итерации. Операционный — стабильные процессы. В МТС важно уметь переключаться между ними в зависимости от контекста.
Совет: В МТС ценят гибкость: не заучивай одну методологию, покажи, как выбираешь подход под тип проекта и зрелость команды.
Ловушка: Не говори «мы всегда работаем по Scrum» — в экосистеме проекты разной природы, нужна адаптивность.
Как задаются вопросы и уточняются требования у стейкхолдеров?
Интервью, воркшопы, MoSCoW-приоритизация, прототипы. Техника «5 почему», переформулирование, фиксация в матрице требований. Важно: различать wants vs needs.
Что включает техническое задание?
Цели, scope, функциональные/нефункциональные требования, ограничения, критерии приёмки, роли, сроки, риски. ТЗ — договор между бизнесом и командой.
Что включает в себя техническое задание для разработчиков?
User stories / use cases, acceptance criteria, API-контракты, диаграммы, зависимости, NFR (производительность, безопасность). Достаточно детализации для оценки и реализации.
Как описывать юз кейсы и юзер стори для разработчиков?
User story: «Как [роль], я хочу [действие], чтобы [ценность]» + acceptance criteria. Use case: актор, предусловия, основной/альтернативный сценарий, постусловия. User story — для Agile, use case — для детальной проработки.
Что включает разбиение эпиков и что должно быть в их описании?
Эпик → фичи → user stories → задачи. В описании эпика: бизнес-цель, scope, критерии готовности, зависимости, оценка. Декомпозиция по INVEST-критериям.
Фишка: В вакансии МТС прямо указана работа с матрицей требований и согласование со стейкхолдерами — подготовь пример артефакта.
Ловушка: Не путай сбор требований с их написанием за заказчика — роль РП в фасилитации, а не в подмене бизнеса.
Какая длительность проектов была?
Опиши 2–3 проекта разной длительности. Укажи фазы: инициация, планирование, исполнение, контроль, закрытие. Покажи, как адаптировал подход под сроки.
Как управлять приоритетами задач, чтобы разработчики не простаивали и ожидания стейкхолдеров были управляемы?
Прозрачный бэклог, регулярная приоритизация (MoSCoW, WSJF), буфер готовых задач, daily sync, управление WIP. Коммуникация: статус-репорты, демо, управление ожиданиями.
Как коммуницировать с бизнесом при простаивании разработчиков из-за незавершённой проработки требований?
Прозрачность: показать impact (стоимость простоя). Совместный план: кто, что, когда дорабатывает. Эскалация с вариантами. Профилактика: Definition of Ready, регулярные grooming-сессии.
Как контролировать реализацию работ и анализировать влияние отклонений?
EVM (план/факт), отслеживание вех, burn-down/burn-up. При отклонении: root cause analysis, варианты коррекции (crashing, fast-tracking, scope change), пересогласование с стейкхолдерами.
Совет: Подготовь кейс: проект отставал на 2 недели — как выявил, что сделал, какой результат.
Фишка: Вакансия требует MS Project — будь готов показать умение строить Gantt, критический путь, baseline.
Как ставили задачи на проекте?
Процесс: от бэклога → декомпозиция → оценка → назначение → Definition of Done. Инструменты: Jira, Confluence. Прозрачность статусов, регулярные синки.
Как руководитель относится к уходу сотрудника и текущей ситуации проекта?
Оценка рисков (bus factor), план передачи знаний, перераспределение задач, коммуникация со стейкхолдерами. Фокус на минимизации impact, а не на обвинениях.
Какие были бизнес-цели на проекте?
SMART-цели: конкретные метрики (выручка, конверсия, time-to-market). Связь задач команды с бизнес-результатом. Покажи, что понимаешь «зачем», а не только «что».
Есть ли бэклог задач?
Опиши структуру бэклога, процесс пополнения и приоритизации, связь с roadmap. Инструмент: Jira backlog, refinement-сессии.
Совет: МТС ценит умение формировать ощущение причастности к результату — приведи пример, как мотивировал команду в сложный период.
Какие приложения используются в системе, включая системные?
Для РП: Jira (задачи, спринты), Confluence (документация), MS Project (планирование), Miro (воркшопы), PowerPoint (презентации стейкхолдерам). Покажи практический опыт, а не перечисление.
Фишка: В вакансии перечислены MS Project, PowerPoint, Jira, Confluence, Miro — подготовь примеры использования каждого.
Кейс: проект отстаёт от графика
Вы руководите IT-проектом внедрения нового сервиса. Через 3 месяца из 6 проект отстаёт на 4 недели. Ключевой разработчик ушёл в отпуск на 2 недели, заказчик добавил 15 новых требований. Стейкхолдеры требуют сохранить исходный дедлайн. Опишите ваши действия.
1) Анализ: пересчитать критический путь, оценить impact новых требований (change request). 2) Варианты: перенос scope (MoSCoW — отложить Should/Could), ускорение (доп. ресурсы), пересмотр дедлайна. 3) Коммуникация: подготовить 2–3 сценария для стейкхолдеров с trade-offs (срок/scope/бюджет). 4) План восстановления: перераспределение задач, knowledge transfer, буфер. 5) Профилактика: усилить change management, Definition of Ready.
Сложность: N/A
Кейс: конфликт приоритетов между командами
Две команды (разработка и инфраструктура) блокируют друг друга: разработка ждёт среду, инфраструктура занята другим проектом. Сроки обоих проектов под угрозой. Ваши действия как РП?
1) Карта зависимостей: что именно блокирует, критичность, сроки. 2) Эскалация к руководителям обоих направлений с фактами (не эмоциями). 3) Варианты: приоритизация на уровне портфеля, временное решение (mock-среда, container), пересмотр сроков менее критичного проекта. 4) Процесс: внедрить dependency tracking в Jira, регулярные sync между командами.
Сложность: N/A
Кейс: декомпозиция эпика
Бизнес ставит эпик: «Запустить программу лояльности для абонентов». Опишите, как вы декомпозируете его для команды разработки.
1) Уточнить цель: KPI (retention, ARPU), scope (MVP vs full). 2) Выделить фичи: регистрация, начисление баллов, каталог наград, интеграция с биллингом, админ-панель. 3) User stories с acceptance criteria. 4) Зависимости: биллинг → начисление → каталог. 5) Приоритизация MVP: регистрация + начисление + 3 награды. 6) Оценка, планирование спринтов.
Сложность: N/A
3 дня
7 дней
14 дней
| Блок | Готов, если... |
|---|---|
| Методологии | можешь объяснить разницу Waterfall/Agile/Scrum/Kanban и выбрать подход под проект |
| Стейкхолдеры | можешь описать процесс сбора и согласования требований с примером артефакта |
| Планирование | можешь построить план с вехами и объяснить реакцию на отклонение от графика |
| Декомпозиция | можешь разбить эпик на user stories с acceptance criteria |
| Кейсы | 3 готовых STAR-истории: успех, конфликт, провал/урок |
| Инструменты | можешь показать практический опыт Jira, Confluence, MS Project, Miro |
| МТС | понимаешь специфику экосистемы и можешь объяснить мотивацию работать здесь |
В день собеседования
