Skip to content

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

100 реальных вопросов с образцовыми ответами и пояснениями для уровня Senior.

Смотреть пример резюме: Technical Program Manager

Тренировка флешкарточками

Интервальное повторение · Hunter Pass

Вопросы

schedulingdependenciesestimation

Я буду считать обе цепочки определяющими срок, пока фактическое выполнение не создаст существенный запас на 1 из них.

  • За 48 часов я строю направленный граф с результатом, владельцем, диапазоном длительности, условием приёмки и последней безопасной датой каждого узла, затем устраняю циклы до фиксации плана.
  • До недели 6 я резервирую инженерные ресурсы и ревью для обеих цепочек, но ускоряю только работу, продвигающую сквозной checkout.
  • Ворота на неделях 4 и 7 пересчитывают оба пути по завершённой работе и данным тестов; запас менее 5 рабочих дней запускает решение по скоупу.
  • Если к неделе 7 обе цепочки остаются критическими, я убираю edge case программы лояльности стоимостью 2 недели, а не поздно добавляю людей и увеличиваю интеграционную нагрузку.

Зачем это спрашивают: Интервьюер оценивает, умеете ли вы управлять меняющимся критическим путём и принимать количественно обоснованное решение по скоупу для 2 почти критических цепочек.

launchesapi

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

  • К дню 5 команды фиксируют OpenAPI-контракт с семантикой полей, ошибками, идемпотентностью, лимитами и 1 владельцем каждого спорного поведения.
  • Ворота на неделях 3 и 6 требуют, чтобы все 4 потребителя прошли тесты своей заявленной версии против сборки поставщика, а не только против моков.
  • На неделе 9 готовые потребители переходят на v2, а поставщик сохраняет 1 канонический путь бизнес-логики v2 и преобразует v1 на границе.
  • v1 и v2 поддерживаются одновременно минимум 18 недель после запуска v2: полные 16 недель на миграцию, затем 14 последовательных дней с трафиком v1 ниже 1 процента и без одобренных исключений, поэтому самое раннее отключение v1 приходится на конец недели 27.

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

schema

Я выберу expand-and-contract, потому что 30 дней смешанных версий приложений делают одномоментное изменение клиентской схемы небезопасным.

  • На неделе 1 владельцы данных фиксируют инварианты, правила источника истины, поведение nullable-полей и пороги сверки в версионируемом контракте клиентской схемы.
  • На неделе 2 добавляются обратно совместимые поля и readers; двойная запись начинается только после 24 часов теневого сравнения с расхождением ниже 0,01 процента.
  • Backfill идёт с ограничением не более 20 000 записей в секунду, а все 6 команд переводят чтение к неделе 8 по единой матрице совместимости.
  • Старые поля удаляются не раньше недели 12 и только после завершения 30-дневного сосуществования, 7 последовательных дней без старых чтений и успешных ворот отката и сверки.

Зачем это спрашивают: Интервьюер оценивает, умеете ли вы выстроить крупную миграцию клиентской схемы вокруг совместимости, измеримой корректности и конечного окна отката.

schedulingdependencieslaunches

Я выделю срез из 3 признаков для запуска, сохранив прямой путь его переноса в общий feature store.

  • К дню 3 команды источника и потребителя фиксируют определения 3 признаков, предел свежести 5 минут, владельцев, хранение и приёмочные тесты.
  • На неделе 3 появляется принадлежащий поставщику append-only feed с теми же идентификаторами и типами признаков, которые будет принимать итоговое хранилище, поэтому вторая модель вычислений не создаётся.
  • Checkout интегрируется на неделях 4-6; ворота недели 6 требуют доступности feed на уровне 99,9 процента и расхождения значений менее 0,1 процента за 7 дней.
  • Полное хранилище сравнивается с feed 14 дней после поставки на неделе 10, и checkout переключается к неделе 12 только после успешной сверки; иначе временный feed истекает на неделе 14 и требует решения по скоупу или дате.

Зачем это спрашивают: Интервьюер проверяет, умеете ли вы убрать избыточную техническую зависимость с критического пути, не создавая постоянную параллельную платформу.

milestonesdependenciesplanning

Я разорву цикл минимальными контрактами и временным адаптером вместо хрупкой синхронной передачи.

  • Двухдневная сессия по последовательности выделяет минимальные стабильные поверхности: consent event v1, схему чтения profile и интерфейс auth SDK.
  • К дню 3 auth начинает работу по зафиксированной схеме profile, а mobile независимо отправляет consent event v1 до готовности финальной реализации profile.
  • Платформенный адаптер преобразует текущий consent payload до конца недели 6; нативные поставщики должны быть готовы к неделе 5, после чего до удаления нужны 7 дней без обращений к адаптеру.
  • Если сквозные ворота недели 2 не пройдены, я убираю offline enrichment профиля и возвращаю 10 рабочих дней вместо сохранения цикла через синхронный релиз.

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

endpointsmockinglaunches

Я объединю contract-first моки с тонким продакшен-срезом, потому что одни моки создают ложный прогресс по сроку.

  • За 24 часа поставщик и потребители выделяют 3 критичных для запуска эндпоинта, а остальные 8 переносят за границу первого релиза.
  • OpenAPI-контракт и сгенерированный мок появляются к дню 2, но готовность потребителя остаётся предварительной, пока те же тесты не пройдут против сборки поставщика.
  • К неделе 5 поставщик отдаёт проверку токена, поиск пользователя и отзыв доступа, а команды-потребители перестраивают вокруг этих ворот UI и локальную валидацию.
  • Если интеграционные ворота недели 5 сорваны, я убираю account linking и возвращаю 2 недели либо переношу дату, а не добавляю переработки для 7 команд.

Зачем это спрашивают: Интервьюер проверяет, отличаете ли вы полезный параллелизм contract-first от оптимизма на моках и сохраняете ли датированное запасное решение.

schedulingdependencieslaunches

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

  • За 2 дня владельцы домена перечисляют инварианты порядка; любое обязательное правило между аккаунтами сохраняет 12-недельный путь брокера и сдвигает запуск на 3 недели.
  • К дню 4 контракт события включает ID аккаунта, монотонный номер внутри аккаунта, ID события и окно replay 24 часа.
  • Брокер отдаёт партиционированный поток на неделе 3, а все 6 команд интегрируются к неделе 6 по тестам на 2 миллионах событий в минуту и всплесках до 4 миллионов.
  • Replay 100 миллионов событий на неделе 7 должен показать 0 нарушений порядка внутри аккаунта и менее 0,01 процента дублей, каждый из которых сверяется, оставляя 2 недели на подготовку запуска.

Зачем это спрашивают: Интервьюер оценивает, умеете ли вы оспорить лишнюю зависимость от порядка и заменить её явными техническими инвариантами и измеримыми воротами.

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

  • Интегрированный граф включает длительность работы в лаборатории, время настройки, вероятность повторного теста, самую раннюю готовность и последний безопасный слот для всех 3 путей.
  • Каждую неделю я резервирую 12 часов критическому пути, 5 часов почти критическому и 3 часа повторным тестам, затем пересчитываю доли по фактическим результатам.
  • Команды попадают в лабораторию только после прохождения минимум 95 процентов тестов эмулятора, контрактов и fixtures, чтобы не тратить общее узкое место на базовые дефекты.
  • Полные интеграционные ворота на неделях 5 и 8 выбирают между сокращением матрицы самых редких устройств с экономией 4 дней и переносом даты сертификации.

Зачем это спрашивают: Интервьюер проверяет, умеете ли вы включить дефицитный технический ресурс в модель зависимостей и принять количественно обоснованное решение по восстановлению.

pricingconcurrencylaunches

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

  • За 48 часов команды определяют валюту, точность, округление, идемпотентность и поведение replay в схеме v2 с тестами совместимости.
  • Быстрый потребитель проходит ворота на неделе 3; при запуске на неделе 5 поставщик выпускает канонический v2, а транслятор отдаёт v1 медленному потребителю.
  • До недели 4 replay 10 миллионов событий должен показать 0 расхождений цен, выдержать 1 миллион событий в минуту и добавить не более 15 процентов к задержке p99.
  • Медленный потребитель проходит ворота на неделе 7, а транслятор финансируется до 14 последовательных дней с трафиком v1 ниже 1 процента, поэтому самое раннее отключение приходится на неделю 9.

Зачем это спрашивают: Интервьюер оценивает, умеете ли вы провести высоконагруженное изменение семантики контракта через версионирование, данные replay и мост, покрывающий все 7 недель миграции.

schedulingdependenciesauth

Я выберу 2 волны, потому что параллельная миграция всех 8 команд одновременно откроет общую зависимость и потратит весь запас в 4 дня.

  • Адаптер и контракт авторизации завершаются на неделях 1-5, а поведение отката и эквивалентность политик доказываются до перевода продакшен-трафика любого потребителя.
  • Две команды с разными паттернами доступа мигрируют на неделях 6 и 7; волна 2 начинается на неделе 8 только после 5 последовательных дней без нарушений контракта минимум на 100 000 решений авторизации.
  • Остальные 6 команд мигрируют на неделях 8-13, затем идут финальная проверка на неделях 14 и 15 и продакшен-переключение в день 1 недели 16.
  • Задержка ворот до 4 рабочих дней расходует заявленный запас; более долгая задержка переносит 3 команды с самым низким трафиком вместо сокращения 2-недельной финальной проверки.

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

roadmapcapacityroadmapping

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

  • Я свяжу каждую запрошенную возможность с потребителями в Q2-Q4, требуемой датой, доказательством приемки и дефицитными навыками, затем найду цепочки зависимостей, определяющие ценность.
  • Я профинансирую в Q1 стабилизацию контрактов и инструменты миграции, если они разблокируют четыре продуктовые команды, а отдельную работу над панелями без последующих зависимостей отложу.
  • Я зарезервирую 15 процентов из 420 инженерных недель на интеграцию, технический риск и отклонение прогноза вместо распределения всей ёмкости на функциональный скоуп.
  • Опубликованная дорожная карта отделит обязательства Q1 от прогнозов Q2 и назовёт доказательства, которые переведут каждый последующий элемент в обязательство.

Зачем это спрашивают: Интервьюер оценивает, умеет ли кандидат превратить ограниченную ёмкость и последующие зависимости в убедительную многоквартальную последовательность.

milestonestrackingplanning

Я отмечу этап красным, потому что прогресс миграции определяют готовность потребителей и production-доказательства, а не затраченные усилия реализации.

  • Я заменю процент готовности тремя критериями выхода: 12 согласованных контрактов, 12 проходящих наборов контрактных тестов и поэтапный production-трафик с порогами ошибок и задержки.
  • Поставщик и каждый потребитель получат датированные пробелы, владельцев и обязательную волну миграции, начиная с двух репрезентативных потребителей в течение 14 дней.
  • Я остановлю необязательные функции поставщика, пока первая волна не подтвердит совместимость, телеметрию и откат на реальном трафике.
  • Если к следующей месячной проверке тесты пройдут менее 8 потребителей, я перепланирую дату отключения и профинансированный период двойной поддержки, а не сохраню квартальный ярлык.

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

roadmapscalingtokens

Я выстрою identity-работу по жёсткому сроку, общему разблокирующему эффекту и стоимости задержки, затем явно покажу, что команда не может делать параллельно.

  • Сначала я определю, нужна ли модернизация токенов для локализации или SSO; если да, профинансирую минимальный production-ready срез, открывающий оба направления.
  • Локализация в ЕС получит защищённый путь к 30 сентября, включая время на проверки и региональную валидацию, а не только завершение кода.
  • SSO пойдёт следующими вертикальными срезами для самых ценных клиентов, причём воронка на 4 миллиона долларов будет скорректирована на вероятность сделки и требуемые клиентами даты.
  • Я опубликую одну обеспеченную ёмкостью последовательность с вытесненным скоупом, датами решений и запасным планом на случай провала контрольного доказательства модернизации в Q2.

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

scope-managementlaunchestesting

Я сохраню дату только с меньшим безопасным скоупом, который достигает 700 миллисекунд и имеет проверенный путь отката.

  • Я выделю минимальный сквозной путь оформления заказа, убрав необязательные рекомендации и два малонагруженных метода оплаты за выключенные флаги.
  • Ворота запуска потребуют репрезентативную пиковую нагрузку в 1,5 раза выше прогноза, p99 ниже 700 миллисекунд, частоту ошибок ниже 0,5 процента и завершённое учение по откату.
  • Я сравню сокращённый запуск с переносом даты по риску выручки, охвату клиентов, нагрузке на поддержку и стоимости возврата отложенного скоупа.
  • Если порог производительности не пройден к последней обратимой дате, я порекомендую перенос, а не скрытую трату надёжности ради календаря.

Зачем это спрашивают: Интервьюер проверяет, умеет ли кандидат принять измеримое решение по скоупу, дате и надёжности при реальном рыночном сроке.

program-managementlaunchesestimation

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

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

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

releases

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

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

Зачем это спрашивают: Интервьюер проверяет, умеет ли кандидат перестроить release train на основе измеримой пользы координации и стоимости пакетной доставки.

roadmaptech-debtreliability

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

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

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

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

  • Я разделю пробелы продукта, стоимость миграции, надёжность и слабый спрос через интервью с 3 пользователями и репрезентативной выборкой из 17 остальных команд.
  • Перепланирование получит 8 инженерных месяцев на сокращение настройки ниже восьми часов и подключение ещё пяти команд с реальными production-нагрузками за шесть недель.
  • На время проверки я сохраню повторно используемую автоматизацию, но остановлю расширение функций и новые платформенные зависимости.
  • Если любой порог не достигнут, я закрою платформу, проведу три команды через план выхода и верну оставшуюся ёмкость более ценной работе дорожной карты.

Зачем это спрашивают: Интервьюер проверяет, способен ли кандидат преодолеть эффект невозвратных затрат с конкретными ограниченными по времени критериями продолжения и закрытия.

milestonesprocurementplanning

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

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

Зачем это спрашивают: Интервьюер оценивает быстрое перепланирование дорожной карты вокруг существенной зависимости от поставщика с техническими и коммерческими доказательствами.

roadmapcapacityroadmapping

Я уберу целые результаты и параллельность, а не сокращу каждый поток на 20 процентов и сделаю все этапы ненадёжными.

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

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

Закрытые вопросы

  • 21

    60 сервисам нужна единая наблюдаемость за 6 месяцев: поставщик просит $900 000 в год, а инженеры оценивают внутреннюю разработку в 6 специалистов на 2 квартала. Как вы проведёте решение build-versus-buy?

    procurementobservabilityestimation
  • 22

    SaaS-платформа обслуживает 200 корпоративных клиентов в одном развёртывании стоимостью $180 000 в месяц. Выделенный контур добавляет $22 000 на клиента в месяц, но 3 регулируемых потенциальных клиента требуют доказуемой изоляции. Как вы проведёте выбор между общей и выделенной моделью размещения?

    deploymentcloud
  • 23

    Глобальный сервис запасов обрабатывает 20 000 резервирований в секунду в 3 регионах. Продукт допускает не более 0,01% продаж сверх остатка, а строгая согласованность поднимет p99 со 120 до 280 мс. Как вы проведёте решение о согласованности?

    consistencylatency
  • 24

    Checkout должен получить решение fraud-сервиса в пределах 300 мс, но на пике сервис отвечает до 2 секунд и имеет доступность 99,7%. Как вы направите выбор между синхронной и асинхронной интеграцией?

    async
  • 25

    У публичного API есть 80 известных потребителей, 15% трафика не имеет найденного владельца, а несовместимое изменение схемы нужно выпустить за 9 месяцев. Как вы проведёте решение о версионировании?

    versioningschema
  • 26

    7 продуктовых команд создают отдельные сервисы прав доступа. Общая платформа требует 6 инженеров на 2 квартала, а каждая команда может выпустить локальный сервис за 8 недель. Как вы проведёте выбор между общей платформой и владением команд?

    ownership
  • 27

    Аналитика обрабатывает 2 ТБ в день 4-часовым батчем за $18 000 в месяц, а стейкхолдеры требуют свежесть в 5 минут при оценке streaming в $55 000 в месяц. Как вы проведёте выбор между batch и streaming?

    stakeholder-managementestimationcommunication
  • 28

    Сервис для 8 миллионов пользователей выходит в 3 региона. Active-active добавляет $140 000 в месяц и 35 мс к p99 записи, а active-passive имеет проверенную цель восстановления в 20 минут. Как вы сформируете решение об архитектуре rollout?

    releasesarchitecture
  • 29

    Search API обслуживает 12 000 запросов в секунду с p99 в 180 мс и доступностью 99,95%. Достижение 120 мс и 99,99% оценивается ещё в $900 000 в год. Как вы проведёте компромисс стоимости, задержки и надёжности?

    estimationapilatency
  • 30

    Старая платформа заказов обрабатывает 3 миллиона запросов в день и стоит $90 000 в месяц. Big-bang замена требует 6-часовой остановки записи, а strangler rollout добавляет $60 000 в месяц на 6 месяцев. Как вы проведёте выбор rollout?

    releasesmigration
  • 31

    Семь команд добавляют сквозной процесс заказа в пяти сервисах при нагрузке 3 000 заказов в секунду, а повторы могут дублировать списания или терять обновления остатков; как вы снизите риск некорректных записей до запуска через восемь недель?

    risk-managementlaunches
  • 32

    Вам нужно перенести 18 ТБ и 2,4 миллиарда записей за 90-минутное окно переключения с участием пяти команд-владельцев данных; какой риск-план вы потребуете до утверждения даты?

    risk-management
  • 33

    Запрос оформления заказа проходит через шесть сервисов и должен укладываться в 350 мс по p95 и 800 мс по p99 при 4 000 RPS; как вы зададите и будете контролировать бюджеты задержки между командами?

    latency
  • 34

    У нового платёжного потока SLO успешных запросов 99,95% за 28 дней и прогноз 200 миллионов запросов; как вы используете бюджет ошибок для управления риском развёртывания до запуска?

    risk-managementlaunchesreleases
  • 35

    За квартал трафик должен вырасти с 6 000 до 24 000 RPS, а руководство требует 35% запаса ёмкости и p99 ниже 500 мс; как вы построите риск-план по ёмкости для пяти команд?

    risk-managementcapacity-planningcapacity
  • 36

    Восемь команд готовят развёртывание в трёх регионах с целью доступности 99,99%, RTO 15 минут и RPO 60 секунд; как вы выстроите программу до первой клиентской волны?

    program-managementreleases
  • 37

    Платёжная программа на 11 команд запускается через 16 недель в шести юрисдикциях и зависит от доказательств PCI-DSS, проверок передачи данных по GDPR и трёх изменений архитектуры безопасности; как не допустить позднего блокера?

    program-managementlaunchesarchitecture
  • 38

    Развёртывание меняет схемы и API в 14 сервисах, пока 1,2 миллиарда записей переносятся за 21 день; какие доказательства отката и готовности вы потребуете до запуска?

    health-checksrollbackschema
  • 39

    Критичный поставщик идентификации должен поддержать 12 сервисов, три региона и 8 000 входов в секунду через десять недель; какие риски и решения вы проработаете до запуска?

    procurement
  • 40

    Десять команд и 25 сервисов находятся в четырёх неделях от запуска с ожидаемыми двумя миллионами транзакций в день; какой пакет готовности достаточен для решения о запуске или его отмене?

    launchestransactionshealth-checks
  • 41

    VP просит к следующей пятнице ранжировать четыре команды по velocity за последние 6 спринтов: 42, 31, 68 и 27 points; вы опубликуете рейтинг, нормализуете points или замените сравнение?

    agilenormalization
  • 42

    В процессе онбординга разработчиков с участием 3 команд lead time равен 24 дням, но активный cycle time составляет только 8 дней, а цель через 10 недель равна 14 дням; вы добавите 2 инженеров, автоматизируете приём или сократите WIP?

    onboarding
  • 43

    За 6 недель до переключения директора называют программу готовой на 80 процентов, но актуальные доказательства есть только у 21 из 40 критериев, а у 3 из 8 критических gates доказательств нет; вы сообщите 80 процентов, 53 процента или откажетесь от процента?

    program-managementhealth-checks
  • 44

    CTO требует за 8 недель внедрить DORA scorecard для 18 команд и предлагает рейтинг с целью деплоить ежедневно; вы выпустите этот рейтинг или контекстный scorecard во владении команд?

    deployment
  • 45

    Портфель из 12 программ сообщает о выполнении 92 процентов этапов, но принятые результаты есть только у 7 из 12 программ, а 4 из оставшихся 5 опаздывают более чем на 30 дней; какой набор метрик вы вынесете на ежемесячный обзор через 2 недели?

    milestonesprogram-managementplanning
  • 46

    На следующие 6 календарных недель у SRE есть 12 engineer-weeks: запуск A запрашивает 7 engineer-weeks, имеет фиксированную дату через 5 календарных недель и контрактный риск $2 миллиона; запуск B запрашивает 10, нацелен на 7 календарных недель, несёт ожидаемую ценность $500 000, может сдвинуться на 2 календарные недели и требует 5 engineer-weeks до внешней проверки в конце недели 6; запуск C запрашивает 8, нацелен на 9 календарных недель, даёт $100 000 годовой экономии, не имеет внешней зависимости и допускает перенос. Все оценки имеют уровень p80, а квалифицированной замены SRE нет. Как вы расставите приоритеты и распределите 12 engineer-weeks?

    schedulingdependencieslaunches
  • 47

    Шесть backend-инженеров дают 60 engineer-weeks за 10 календарных недель: контрактная миграция платформы требует 32 engineer-weeks, revenue-фича требует 26, а 10 engineer-weeks нужно сохранить для поддержки; вы разделите инженеров 3 на 3, остановите фичу или сократите её скоуп?

    scope-managementmigrations
  • 48

    Четыре data-инженера должны обработать 24 согласования production-моделей за 4 недели, но сертифицированы только 2 reviewer, и каждый после операционной работы может согласовать 2 изменения в неделю. Ещё 1 инженер получит квалификацию после 4 парных согласований к концу недели 2, а затем сможет согласовывать 2 изменения в неделю. Спрос включает 6 compliance-изменений к неделе 2, 10 клиентских обязательств к неделе 4 и 8 гибких внутренних изменений. Какой план ёмкости вы зафиксируете?

    capacity-planningcapacityconcurrency
  • 49

    Восемь инженеров дают 104 gross engineer-weeks за квартал из 13 недель, за последние 4 квартала незапланированная работа занимала 18, 22, 20 и 20 процентов, фиксированные отпуска и governance overhead занимают ещё 15 процентов без пересечения, а roadmap запрашивает 82 engineer-weeks. Какой прогноз доступной ёмкости и потолок обязательств вы опубликуете?

    capacity-planninggovernancecapacity
  • 50

    Четырнадцать команд зашли в тупик по cross-org RFC для 20 000 обновлений биллинга в секунду с freshness SLO 5 минут, а решение нужно за 15 рабочих дней; вы выберете REST fan-out, Kafka events или продолжите оба дизайна?

    kafkadesignfan-out
  • 51

    Восемь команд должны через 7 недель запустить систему управления складом на 12 площадках, но интегрированный план теперь требует 11 недель, а полный перенос ставит под риск сезонную пропускную способность стоимостью $18 миллионов. Вы защищаете исходный скоуп, переносите дату или спасаете меньший запуск?

    risk-managementscope-managementlaunches
  • 52

    Вы принимаете программу движка страховых требований с 10 командами, которая идёт 14 месяцев, пропустила 3 этапа, потратила $9,6 миллиона из бюджета $12 миллионов и совпадает со старой системой только по 82% требований при цели 99,95%. Новое регуляторное правило вступает в силу через 16 недель. Вы перезапускаете, продолжаете или закрываете программу?

    milestonesprogram-managementplanning
  • 53

    Семь команд потратили 2 квартала и 84 инженерных месяца на новый движок видеотранскодирования. До публичного запуска осталось 10 недель, но стоимость равна $0,027 за минуту при цели $0,012, p95 завершения равен 11 минутам при цели 4, а текущая система стоит $0,018. Вы закрываете или продолжаете разработку?

    launches
  • 54

    У шести команд осталось 4 недели до назначенного советом директоров срока удаления статических production-ключей, но мигрировал только 41 из 130 сервисов, программа уже опаздывает на 5 недель, а безопасность нашла 17 раскрытых ключей за последние 30 дней. Вы останавливаетесь, продолжаете без изменений или сужаете работу?

    program-managementestimation
  • 55

    У девяти команд есть 8 недель на выпуск управления корпоративными устройствами для Windows, macOS, Linux, 6 интеграций идентификации и 2 клиентов с годовыми контрактами на $6 миллионов. Интегрированное тестирование прогнозирует 13 недель, а Windows, macOS и 2 интеграции можно подготовить за 7. Вы сокращаете скоуп или переносите дату?

    releasestesting
  • 56

    Семь команд должны через 18 дней направить новую модель модерации контента на 20% трафика. Продукт требует запуска, инжиниринг предлагает канарейку на 5%, а безопасность заявляет право вето, потому что доля пропущенных нарушений равна 2,4% при лимите 1,0%. Как вы разрешите конфликт полномочий в этот срок?

    launchesestimationdeployment-strategies
  • 57

    Шести командам нужен общий API прогноза доставки для запуска у ритейлера через 5 недель, но логистика и коммерция отказываются от владения. Контракт менялся 14 раз за прошлый квартал, p99 равен 900 мс при цели 300 мс, а у 7 инцидентов за 60 дней не было явного ответственного. Какое решение по владению вы проведёте?

    incidentsownershipapi
  • 58

    У двадцати четырёх команд есть 14 недель на открытие автоматизированной багажной системы с 63 межкомандными зависимостями, 19 элементами со статусом критичных и 17 передачами без приёмочных тестов. Перенос даты аэропорта стоит $4 миллиона. Как вы превратите сеть в исполнимое решение о приоритетах?

    acceptancesystem-designdependencies
  • 59

    Двадцать две команды должны уйти с container runtime, для которого через 9 недель прекращаются security-патчи. Перенесено только 58 из 146 сервисов, оставшиеся 88 несут 72% production-трафика, а platform on-call может поддерживать оба runtime только ещё 6 недель. Вы даёте общее продление или принудительно проводите миграцию?

    on-callmigrationscontainers
  • 60

    У пяти команд есть 12 недель на миграцию каталога объёмом 9 ТБ с 18 000 записей в секунду и допустимым расхождением не более 0,01%. Все 11 путей записи приложений нельзя изменить раньше недели 10, а двойная запись добавляет 35 мс к бюджету p99 в 120 мс. Вы выберете двойную запись в приложениях или change-data capture из журнала?

  • 61

    Восемь команд находятся в 10 неделях от запуска в трёх регионах с SLO доступности 99,99%. Юристы утверждают, что данные клиентов ЕС не могут покидать ЕС, а текущий active-active дизайн реплицирует их в США и стоит $240 000 в месяц. CRO настаивает на одновременном запуске всех регионов. Вы сохраните дату, измените топологию или исключите ЕС?

    designsloreplication
  • 62

    Платёжный rollout достиг 25% трафика с участием шести команд без Sev-1, но скорость расхода error budget равна 6x, p99 вырос на 42%, а расхождение реестра составляет 0,08% при лимите 0,01%. Владелец запуска хочет сегодня вечером перейти к 50%, чтобы сохранить дату через три дня. Вы приостановите, откатите или продолжите?

    launchesreleasesrollback
  • 63

    Change gate для 22 команд увеличил медианный lead time с трёх до девяти дней, 35% изменений обходят его, а ручная проверка поймала только один из последних 40 неудачных релизов. До регулируемого запуска осталось 12 недель. Вы отмените gate, усилите контроль или перестроите его без остановки доставки?

    launches
  • 64

    Шестнадцать инженерных команд отказываются от DORA scorecard после того, как VP использовал ранний dashboard для их ранжирования, покрытие данных составляет только 72%, а CTO всё ещё требует сократить lead time на 30% в этом квартале. У вас восемь недель на восстановление внедрения. Вы сделаете отчётность обязательной, откажетесь от метрик или перезапустите программу?

    program-managementcoveragedecision-making
  • 65

    Sev-1 затрагивает 14 сервисов и девять команд, но шесть записей о владении в service catalog устарели, и responders уже потеряли 12 минут на вызов неверных команд. У платформы SLO 99,95% и цель устранения за 30 минут. Вы сначала исправите владение или немедленно измените incident command?

    incidentsownershipslo
  • 66

    Общий сбой checkout затрагивает 11 команд из трёх организаций, использующих метки Sev-1, P0 и Critical с разными правилами командования. Потери выручки равны $120 000 в минуту, p99 вырос с 400 мс до 4,5 секунды, а через восемь минут ни у кого нет полномочий. Вы согласуете фреймворки во время сбоя или вводите одну модель командования?

  • 67

    В 8:00 вы подтверждаете, что флагманский запуск девяти команд через пять дней задержится минимум на шесть недель: пиковые тесты показывают успешность 99,2% при SLO 99,95%, а кампания на $12 миллионов начинается через 48 часов. CEO ждёт обновление через 90 минут. Вы защищаете дату сокращением скоупа или предлагаете CEO перенести её?

    scope-managementlaunchestesting
  • 68

    За четыре дня до enterprise-запуска семи команд с годовой ценностью $8 миллионов CISO блокирует релиз, потому что логи привилегированных администраторов можно изменять и они хранятся только 30 дней вместо обязательных неизменяемых 365 дней. Инженеры считают эксплуатацию теоретической и оценивают исправление в три недели. Вы запросите исключение, сократите скоуп или перенесёте запуск?

    scope-managementlaunchesreleases
  • 69

    Discovery увеличивает стоимость платформенной программы пяти команд с $12 миллионов до $15,6 миллиона, создавая дефицит финансирования 30%, после уже потраченных $6 миллионов. Ожидаемая годовая экономия остаётся $8 миллионов, но одно допущение о масштабе ещё не проверено, а CFO примет решение за 10 рабочих дней. Вы запросите все $3,6 миллиона, сократите скоуп или остановитесь?

    program-management
  • 70

    Два сбоя платформы длительностью 47 и 83 минуты за последние 30 дней снизили доступность примерно до 99,70% при SLO 99,95% и привели к SLA-компенсациям $4,8 миллиона. Одиннадцать команд продолжают работу над roadmap, а заседание совета директоров состоится через 72 часа. Вы запросите широкую заморозку функций, профинансированный план надёжности или оба решения?

    roadmapsloroadmapping
  • 71

    За 6 недель до фиксации платформенного бюджета 3 директора по разработке не могут согласовать стратегию: продлить managed PaaS за 1,7 миллиона долларов, потратить 3,8 миллиона на миграцию 26 сервисов в Kubernetes или профинансировать оба пути за 5,5 миллиона при лимите 4,2 миллиона. Один регулируемый запуск невозможен на PaaS. Какую стратегию вы порекомендуете, если ни один директор вам не подчиняется?

    kubernetescloudlaunches
  • 72

    Принятый RFC по версионированию API даёт 24 командам 16 недель на прекращение выпуска неверсионированных эндпоинтов, но 7 команд настаивают, что им нужны 24 недели, а запуск для партнёров на 3 миллиона долларов зависит от 2 из них. Платформенная команда может поддерживать только 1 временный слой совместимости. Как вы определите план внедрения?

    endpointsversioningdecision-making
  • 73

    Cross-org RFC отклонён после 10 недель работы, потому что 5 из 17 затронутых команд привлекли только на финальном ревью, а до заморозки архитектуры остался 21 день. Вы защищаете текущее предложение, отзываете его или начинаете решение с нуля?

    decision-makingarchitecture
  • 74

    Двум программам нужна одна платформенная команда в следующие 12 недель, но доступно только 32 инженерные недели. Регуляторное исправление требует 20 инженерных недель до фиксированного срока с риском 8 миллионов долларов; growth-запуск требует 24, но меньшая когорта, сохраняющая 2 миллиона из 6 миллионов долларов ARR, требует 12. Какое портфельное решение вы проведёте?

    program-managementlaunchesestimation
  • 75

    Годовое финансирование зафиксировано на уровне 9 миллионов долларов: регуляторное исправление до 30 сентября требует 4 миллиона, reliability-работа после 3 месяцев с расходом error budget в 3 раза выше нормы требует 3 миллиона, а growth-запуск с прогнозом 12 миллионов долларов ARR запрашивает 5 миллионов. Как вы распределите деньги и решите, что выйдет?

    launchesprioritization
  • 76

    Поддержка observability-стека для 55 сервисов заканчивается через 14 недель. Внутренняя замена требует 24 недели и 2,4 миллиона долларов в первый год; vendor может запуститься за 10 недель за 1,6 миллиона в год, но требует 3-летний контракт. Вы строите, покупаете или платите 900 000 долларов за продление старого стека на 6 месяцев?

    build-buyobservabilityprocurement
  • 77

    За 5 недель до клиентского запуска на 4 миллиона долларов закупка identity-vendor отстаёт на 3 недели: privacy требует соглашение о передаче данных, legal отклоняет лимит ответственности, а finance не одобрил 650 000 долларов годовых расходов. Уменьшенный запуск без enterprise SSO всё ещё возможен. Какую последовательность решений вы зададите?

    procurementlaunches
  • 78

    На восьмой неделе 14-недельного развёртывания стратегического поставщика приобретают: доступность падает с 99,98% до 99,4%, время ответа поддержки растёт с 2 до 19 часов, мигрировано 40% нагрузок, а окно расторжения закроется через 30 дней. Второй провайдер сможет принять трафик за 6 недель и 350 000 долларов. Что вы решите?

    procurementreleases
  • 79

    Mid-level TPM просит вас забрать программу developer platform для 9 команд, у которой осталось 12 недель, уже выделено 60 инженерных недель, а 3 спонсора отдельно требуют снижения затрат, ускорения подключения и соответствия политикам. Общей метрики успеха нет. Как вы будете менторить TPM и решите, продолжать ли реализацию?

    mentoringonboardingsponsor
  • 80

    Mid-level TPM выпустил 6 зелёных еженедельных отчётов, но пропустил 3 технических риска, вызвавших задержку на 2 недели; следующая фаза запускается через 7 недель под клиентское обязательство на 5 миллионов долларов и охватывает 12 сервисов. Вы оставите TPM на критическом пути, сократите его скоуп или замените?

    schedulingdependenciesscope-management
  • 81

    За 8 недель вам нужно нанять 12 senior TPM, но в последних 25 циклах каждого региона доля успешных кандидатов составляет 52% в Америке, 24% в Европе и 60% в Азии. Как устранить расхождение, не сорвав срок и не снизив планку?

    estimation
  • 82

    TPM хочет получить повышение до senior в цикле через 10 недель. Он вовремя провёл 4 запуска, но партнёры говорят, что самые сложные межкомандные решения принимал его руководитель, а переиспользуемого рабочего механизма он не создал. Какой план повышения вы зададите?

    launchesfeedbackcross-team
  • 83

    В программе из 25 команд уже 14 регулярных встреч, которые отнимают 220 человеко-часов в неделю, но медиана ожидания межкомандных решений всё равно составляет 9 дней. Как вы перестроите рабочую модель за следующий месяц?

    program-managementcross-team
  • 84

    За 8 недель до глобального запуска 43% передач работы между командами Америки, Европы и Азии открываются повторно, а медиана ожидания заблокированной работы составляет 19 часов. Что вы измените в исполнении?

    launches
  • 85

    Половина команд в миграции платформы из 40 сервисов переходит в новые подразделения, до конца остаётся 12 недель, а оба executive-спонсора заменены. Как вы обновите план, не перезапуская программу?

    program-managementmigrationssponsor
  • 86

    После приобретения компании 90 сервисов должны поддержать единый клиентский опыт за 6 месяцев, но у 37 нет подтверждённого владельца, а компании используют несовместимые согласования релизов; 14 изменений для первого совместного релиза уже ждут с медианой 6 дней, а до релиза осталось 8 недель. С чего вы начнёте?

    releases
  • 87

    За 36 часов до критического запуска начинается Sev-1, ошибки checkout достигают 12%, а 5 из 8 инженеров подготовки к запуску являются единственными квалифицированными участниками устранения. Как вы поведёте оба направления?

    launcheshealth-checks
  • 88

    Все 18 вех на панели запуска зелёные, но внедрение клиентами упало с 38% до 21%, число приоритетных инцидентов выросло с 3 до 7 в месяц, а стоимость транзакции увеличилась на 26%. Какой статус и следующее решение вы зададите?

    milestonesplanningreleases
  • 89

    CEO публично обещает полный глобальный запуск через 9 недель до инженерной оценки. Первая техническая проверка даёт P50 в 13 недель, P80 в 16 и 4 нерешённые критические зависимости. Что вы сделаете за следующие 72 часа?

    launchespromisesestimation
  • 90

    Два principal-архитектора не могут выбрать между централизованным API gateway и sidecar-компонентами service mesh для применения политик в 14 командах при 80 000 запросов в секунду; команды стоят уже 8 дней, допустимая добавка к p99 равна 12 мс, а compliance-запуск назначен через 10 недель. Как вы прекратите тупик?

    launchesapilocking
  • 91

    За 3 недели до переключения 8 сервисов трассировка показывает, что 38 процентов вызовов авторизации всё ещё используют недокументированный запрос к старому профилю. Замена теряет 6 процентов запросов на прогнозном пике 18 000 RPS при SLO 99,95 процента, а продление старого контракта стоит 180 000 долларов. Вы исправляете, строите мост или переносите запуск?

    authslo
  • 92

    Через 10 дней после передачи платформы токенов из 12 сервисов новая команда дважды не ответила на оповещение в течение 22 минут и не смогла выполнить откат; от платформы зависит миграция на 7 миллионов долларов через 6 недель, а её SLO доступности равен 99,99 процента. Вы сохраняете дату организационной передачи или возвращаете общее владение?

    ownershipmigrationstokens
  • 93

    За 5 недель до запуска аналитики в ЕС privacy review блокирует копирование 2,4 миллиарда необработанных событий в день в американское хранилище, потому что 7 из 24 полей позволяют идентифицировать пользователей. Запуск поддерживает годовые контракты на 6 миллионов долларов, а риск по GDPR может достигнуть 20 миллионов евро; как вы перенаправите программу?

    program-managementlaunchesgdpr
  • 94

    За 6 недель до запуска платежей, связанного с контрактами на 8 миллионов долларов, PCI-аудитор обнаруживает, что номера карт проходят через 11 сервисов, и оценивает текущий план контроля ещё в 9 недель. Авторизация должна выдерживать SLO доступности 99,95 процента и p99 задержки 800 миллисекунд; какой срок и скоуп вы зафиксируете?

    scope-managementlaunchesauth
  • 95

    Через 42 минуты после переключения базы при 30 000 записей в секунду сверка показывает, что 0,7 процента записей разделились между старой и новой системами, примерно 529 000 строк. Сервис проводит транзакции на 2,5 миллиона долларов в день и имеет SLO доступности 99,99 процента; вы откатываетесь, исправляете вперёд или продолжаете наращивать трафик?

    databasetransactionssystem-design
  • 96

    За 10 дней до 3 запусков два инцидента Sev-1 забирают 5 из 8 SRE на следующие 14 дней. Платежи уже потратили 60 процентов месячного error budget, у сервиса удаления регуляторный срок через 12 дней, а запуск поиска поддерживает кампанию на 3 миллиона долларов; как распределить оставшиеся 30 инженерных дней SRE?

    incidentsestimationreliability
  • 97

    Через 6 недель и 900 000 долларов работы над программой рекомендаций finance отклоняет платформу событий за 1,8 миллиона долларов; оставшаяся работа над рекомендациями стоит 4,1 миллиона, а без платформы покрытие падает со 100 до 20 процентов трафика и прогноз годовой ценности с 9 до 1 миллиона долларов. Что вы финансируете теперь?

    program-managementcoverage
  • 98

    VP отменяет вашу рекомендацию остановиться на 25 процентах после того, как canary расходует error budget в 3,2 раза быстрее допустимого. Полное развёртывание затем вызывает сбой на 47 минут, 180 000 неудачных checkout и компенсации на 2,1 миллиона долларов; какие решения вы примете во время и после инцидента?

    reliabilitydeployment-strategiesincidents
  • 99

    В портфеле на 18 команд и 35 миллионов долларов 14 технических решений ждут вас, медианный возраст решения достиг 9 дней, а два сервиса с SLO 99,95 процента пропустили релизные ворота на 3 недели. Как перестать быть узким местом без потери контроля?

    trackingreleasesportfolio
  • 100

    Спасение за 6 недель сохраняет контракт на 12 миллионов долларов, но 74 человека работали в среднем по 58 часов в неделю, 31 экстренное решение обошло обычную проверку, а запуск дал 2 инцидента Sev-2 при SLO 99,95 процента. CEO хочет начать фазу 2 через 5 дней; что вы сделаете?

    launchesincidentsslo