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

Technical Program Manager координирует техническую работу нескольких команд, чтобы общий результат был достигнут при прозрачных объёме работ, зависимостях, рисках и решениях.

• TPM связывает инженерные планы с работой продукта, дизайна, эксплуатации, безопасности и других функций.
• Роль создаёт ясность с помощью таких артефактов, как дорожная карта, карта зависимостей, RAID log и отчёт о статусе.
• Техническая грамотность позволяет TPM задавать полезные вопросы и выявлять риски поставки, не подменяя инженеров.

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

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

Базовый жизненный цикл технической программы проходит от инициации через планирование и выполнение к контролю, поставке и закрытию.

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

Устав программы является кратким утверждённым документом, который объясняет цель программы и общий порядок управления ею.

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

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

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

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

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

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

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

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

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

Jira или Linear отслеживают исполняемую работу, а Confluence или Notion сохраняют контекст программы и решения вокруг неё.

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

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

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

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

• До расчёта маршрутов перечисляют каждую работу и её предшественников.
• По самым ранним и поздним датам начала или окончания определяют работы с нулевым временным запасом.
• Результат проверяют с инженерными ответственными, потому что пропущенные зависимости или нереалистичные оценки делают расчёт неверным.

Обычные типы зависимостей: окончание-начало, начало-начало, окончание-окончание и начало-окончание.

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

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

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

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

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

RAID log является общим реестром рисков, предположений, проблем и зависимостей, требующих активного внимания в программе.

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

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

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

Вероятность оценивает шанс наступления риска, а влияние оценивает последствия его наступления.

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

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

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

Заинтересованная сторона является человеком или группой, которые влияют на программу, зависят от неё либо имеют полномочия по её решениям или ресурсам.

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

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

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