Вопросы на собеседовании: Technical Program Manager

Управление программой координирует связанные проекты ради результата, который ни один проект не может обеспечить самостоятельно.

• Программа объединяет несколько потоков работ вокруг общих целей, ограничений и критериев успеха.
• Она управляет межкомандными зависимостями и компромиссами, а не оптимизирует каждый проект изолированно.
• Ее дорожная карта меняется по мере появления новых данных в проектах, а целевой результат программы остается ориентиром для решений.
• Управление охватывает общие риски, выгоды и решения, выходящие за границы отдельных проектов.

Полезный устав программы создает общий договор о результатах, границах, ответственности и принятии решений.

• Зафиксируйте проблему, целевые результаты, измеримые критерии успеха и явные нецели.
• Укажите потоки работ, ответственных владельцев, основные зависимости, допущения и ограничения.
• Определите права принятия решений, пути эскалации, ритм управления и стейкхолдеров, утверждающих существенные изменения.
• Зафиксируйте исходный график, предел бюджета или доступной мощности и условия приостановки либо закрытия программы.

Разложите цель на независимо управляемые возможности, сохранив все интерфейсы между потоками работ.

• Начните с пользовательских или бизнес-результатов и определите возможности, необходимые для их достижения.
• Объедините работу так, чтобы одна команда могла отвечать за целостный результат с четкими критериями начала и завершения.
• Определите интерфейсы, общие вехи и точки интеграции между потоками до назначения дат.
• Проверьте, что декомпозиция включает обеспечивающие работы по безопасности, миграции данных, эксплуатации и внедрению.

Интегрированная дорожная карта показывает, как результаты команд складываются в цели программы и где может нарушиться последовательность.

• Отражайте вехи результата и межкомандные точки интеграции, а не каждую задачу команд.
• Показывайте связи с предшественниками, внешние зависимости, даты решений и необходимое время подготовки.
• Отделяйте обязательства по датам от прогнозов и указывайте уверенность или допущения каждого прогноза.
• Сохраняйте ссылки на планы команд, чтобы детали оставались у локальных владельцев, а последствия для программы были видны всем.

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

• Веха поставки подтверждает, что конкретный артефакт или возможность соответствует заданным критериям приемки.
• Веха интеграции доказывает, что компоненты совместно работают через контракт или сквозной сценарий.
• Веха решения фиксирует последний разумный срок выбора, влияющего на объем, архитектуру или график.
• Для каждой вехи нужны владелец, доказательство завершения, зависимости и последствия переноса.

Стройте карту зависимостей на конкретных обязательствах поставщика и потребителя, а не на списке команд.

• Для каждой зависимости укажите поставляемый результат, потребителя, владельцев с обеих сторон и критерии приемки.
• Зафиксируйте требуемую дату, самую раннюю доступность, время подготовки, статус и допущение о сроках.
• Свяжите зависимости в направленную последовательность, чтобы увидеть критический и близкие к нему пути.
• Проверьте карту с обеими сторонами, потому что зависимость согласована только при общем понимании контракта поставщиком и потребителем.

TPM должен классифицировать зависимости по типу ограничения, потому что для разных типов нужны разные меры управления.

• Технические зависимости включают API, схемы, среды, общие сервисы и порядок интеграции.
• Зависимости поставки возникают, когда потоку работ нужен артефакт или решение другой команды для продолжения.
• Ресурсные зависимости появляются, когда редкие специалисты, тестовые среды или окна релиза нужны нескольким потокам.
• Внешние зависимости включают поставщиков, регуляторные согласования, договоры и обязательства по миграции клиентов.

Критический путь представляет собой самую длинную цепочку зависимостей, определяющую самую раннюю дату завершения программы.

• Оцените длительность и связи с предшественниками для работ, ведущих к целевому результату.
• Рассчитайте цепочку с нулевым или минимальным резервом времени и проверьте допущения с владельцами поставки.
• Защитите эту цепочку ранними решениями, явным выделением мощности, частыми проверками интеграции и снижением рисков.
• Пересчитывайте ее при изменении оценок, объема или зависимостей, потому что критический путь не остается постоянным.

Близкие к критическому пути могут стать критическими после небольшой задержки, поэтому резерв времени служит ранним предупреждением.

• Отслеживайте общий и свободный резерв, чтобы понимать, какие работы можно сдвинуть без переноса последующих этапов или программы.
• Сравнивайте не только номинальную длительность, но и неопределенность, поскольку путь с высокой вариативностью может быть рискованнее текущего самого длинного.
• Задайте пороги проверки для путей, остаточный резерв которых стал меньше вероятной задержки.
• Не допускайте незаметного расходования резерва: зафиксируйте, кто может его использовать и какое решение для этого требуется.

Контракт зависимости делает ожидаемый результат, сроки и механизм изменений однозначными для обеих команд.

• Определите артефакт или возможность, спецификацию интерфейса, приемочные тесты и требования к качеству.
• Назовите владельцев со стороны поставщика и потребителя, даты поставки и потребности, а также допущения о последовательности.
• Укажите правила совместимости, версионирования, тестовых данных, сред и координации развертывания.
• Включите сроки уведомления, пути эскалации и процесс утверждения изменений обязательства.

Оцените альтернативы относительно цели программы, прежде чем принимать перенос нижестоящего графика.

• Узнайте, может ли поставщик раньше предоставить сокращенный совместимый срез или заглушку контракта.
• Определите, может ли потребитель изменить порядок работ, использовать моки или продолжить за абстракцией без опасного объема переделок.
• Сопоставьте добавление ресурсов со стоимостью адаптации и координации, не считая, что дополнительные люди автоматически вернут время.
• Представьте варианты изменения объема, порядка и даты вместе с последствиями, владельцами и последним сроком решения.

Представляйте график как диапазон прогноза с явной уверенностью и допущениями, а не с ложной точностью.

• Соберите диапазоны оценок владельцев и найдите коррелирующие риски, способные одновременно сдвинуть несколько потоков.
• Используйте анализ сценариев или вероятностное моделирование, если данных достаточно для расчета дат с заданной уверенностью.
• Сообщайте вероятную дату и дату с более высокой уверенностью, четко отделяя обе от внешнего обязательства.
• Обновляйте прогноз по фактическому прогрессу и новым допущениям, а не выдавайте устаревший базовый план за предсказание.

Категории RAID разделяют неопределенные угрозы, плановые предположения, уже возникшие проблемы и внешние потребности.

• Риск представляет собой неопределенное событие, способное повлиять на цель, поэтому ему нужны вероятность, влияние и ответные меры.
• Допущение принимается за истину при планировании, но должно быть проверено к указанной дате конкретным владельцем.
• Проблема уже возникла и требует решения, оценки влияния и актуального плана действий.
• Зависимость представляет собой входной результат или решение, которое другая сторона должна предоставить по явному обязательству.

Практичный реестр связывает каждое неопределенное событие с уровнем риска, ответственностью, сигналами и подготовленными мерами.

• Сформулируйте причину, событие и влияние и свяжите их с затронутой целью или вехой.
• Зафиксируйте вероятность, влияние, близость, итоговый рейтинг и доказательства, на которых основаны оценки.
• Назначьте одного ответственного владельца риска, а также меры снижения с владельцами и сроками.
• Определите триггеры, резервные действия, остаточный риск, дату пересмотра и текущий статус.

Используйте откалиброванные определения, привязанные к порогам программы, чтобы команды оценивали уровень риска по общей шкале.

• Задайте диапазоны вероятности численно или через наблюдаемую частоту, а не только словами.
• Отдельно определите уровни влияния на график, объем, стоимость, безопасность, надежность и результаты клиентов.
• Используйте самое существенное влияние или согласованный взвешенный метод, сохраняя исходные оценки по каждому измерению.
• Пересматривайте оценки при появлении новых доказательств и фиксируйте причину изменения рейтинга.

Количественная оценка полезна для сравнения неопределенных потерь, но не заменяет суждение о тяжелых последствиях.

• Ожидаемая денежная стоимость умножает вероятность на финансовое влияние и помогает расставлять приоритеты сопоставимых рисков.
• Моделирование графика объединяет диапазоны оценок и зависимости, чтобы показать распределение дат завершения.
• Исходные данные остаются неопределенными, а коррелирующие риски могут сделать простые расчеты вводящими в заблуждение.
• Риски безопасности, права или надежности с низкой вероятностью могут требовать мер независимо от ожидаемой стоимости.

Снижение меняет уровень риска до события, а резервный план определяет действия после сигнала о его наступлении.

• Меры снижения могут уменьшить вероятность, ослабить влияние, передать риск или исключить рискованный подход.
• Резервный план представляет собой заранее утвержденный запасной вариант с владельцем, ресурсами, сроками и критериями запуска.
• Оба плана должны учитывать вторичные риски и остаточный уровень риска после действий.
• Финансирование или мощности для резервного плана должны быть реальными, иначе это лишь намерение.

Хороший триггер наблюдаем, появляется достаточно рано для действий и прямо связан с подготовленным решением.

• Используйте измеримые условия, например пороги задержки, даты согласования, динамику дефектов или оставшийся резерв графика.
• Определите, кто следит за сигналом, как часто и где фиксируются доказательства.
• Разделите порог предупреждения и запуска, если до исполнения резервного плана нужно раннее исследование.
• Избегайте расплывчатых триггеров вроде беспокойства стейкхолдеров, потому что они не ведут к последовательным действиям.

Назначьте одного ответственного владельца риска, а каждой мере снижения дайте отдельного владельца исполнения.

• Владелец риска отслеживает уровень, поддерживает оценку в актуальном состоянии и предлагает изменения ответных мер.
• Владельцы действий исполняют конкретные меры к согласованным датам и предоставляют доказательства завершения.
• TPM обеспечивает видимость между потоками и эскалацию, но не должен автоматически владеть каждым техническим риском.
• Ответственность должна сопровождаться правом решения или явным путем к человеку, у которого оно есть.

Риск снижается, когда доказательства показывают уменьшение его уровня, а не просто завершение задач по снижению.

• Отслеживайте изменения вероятности, влияния, близости и остаточного уровня для главных рисков.
• Проверяйте, изменили ли меры исходное условие, с помощью тестов, согласований или наблюдаемых опережающих индикаторов.
• Используйте график накопления или динамики рисков, который также показывает новые риски и закрытый уровень риска.
• Эскалируйте неизменно высокий уровень, даже если выполнение действий идет по графику.