Собес в МТС · Руководитель проектов

Какие знаешь методологии управления проектами?

Waterfall (последовательные фазы), Agile (итерации, гибкость), Scrum (спринты, роли, артефакты), Kanban (поток, WIP-лимиты). Укажи, когда какую применяешь: предсказуемость vs неопределённость.

Что такое Kanban?

Метод визуализации потока работ: доска, колонки, WIP-лимиты, pull-система, непрерывное улучшение (Kaizen). Подходит для поддержки и потоковой работы.

Какое главное ограничение в Kanban?

WIP-лимиты — ограничение незавершённой работы. Без них Kanban превращается в простую доску задач. Также: нет фиксированных итераций, сложнее планировать дедлайны.

Как сочетать проектный, продуктовый и операционный подходы?

Проектный — чёткие цели, сроки, бюджет. Продуктовый — ценность для пользователя, итерации. Операционный — стабильные процессы. В МТС важно уметь переключаться между ними в зависимости от контекста.

Как задаются вопросы и уточняются требования у стейкхолдеров?

Интервью, воркшопы, 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), пересогласование с стейкхолдерами.

Как ставили задачи на проекте?

Процесс: от бэклога → декомпозиция → оценка → назначение → Definition of Done. Инструменты: Jira, Confluence. Прозрачность статусов, регулярные синки.

Как руководитель относится к уходу сотрудника и текущей ситуации проекта?

Оценка рисков (bus factor), план передачи знаний, перераспределение задач, коммуникация со стейкхолдерами. Фокус на минимизации impact, а не на обвинениях.

Какие были бизнес-цели на проекте?

SMART-цели: конкретные метрики (выручка, конверсия, time-to-market). Связь задач команды с бизнес-результатом. Покажи, что понимаешь «зачем», а не только «что».

Есть ли бэклог задач?

Опиши структуру бэклога, процесс пополнения и приоритизации, связь с roadmap. Инструмент: Jira backlog, refinement-сессии.

Какие приложения используются в системе, включая системные?

Для РП: Jira (задачи, спринты), Confluence (документация), MS Project (планирование), Miro (воркшопы), PowerPoint (презентации стейкхолдерам). Покажи практический опыт, а не перечисление.