Нанять Продакт Оунера: 82 вопроса для собеседования

Все просто. 82 вопроса для собеседования на роль Продакт Оунера от Стефана Уолперса, известного коуча из Age of Product, имеющего 16-летний практический опыт работы с XP и Scrum, в том числе в роли Product Owner и Scrum Master, а также опыт найма продактов и скрам-мастеров в команды.

Вступление

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

Сама по себе роль владельца продукта усложняет процесс найма. Продакт Оунер — наименее четко определенная и одновременно наиболее многоаспектная роль в Scrum.

Владелец продукта является инноватором, а значит создает ценность для клиентов и организаций, если получает возможность работать гибко. Владелец продукта также является наиболее уязвимой ролью Scrum. Сделайте из него «руки», реализующие только идеи стейкхолдеров, лишите Продакта права говорить «нет» – например, защищая бэклог продукта – и владелец продукта скоро станет ахиллесовой пятой любой гибкой организации.

Роль владельца продукта зависит от размера организации, отрасли, в которой она работает, ее культуры и этапа жизненного цикла продуктов этой организации. Наконец, есть определенное совпадение с ролью менеджера продукта. (Спойлер: они не идентичны.)

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

Вопросы для собеседования с владельцем продукта в этом PDF-файле смоделированы на основе целостной модели разработки гибкого продукта для программных продуктов:

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

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

Набор вопросов для собеседования с владельцем продукта №1: Роль Scrum Product Owner

Эта категория касается мета-уровня роли Владельца продукта и процесса Scrum.

• 1. Какова главная цель аджайла?

Как говорится в «Манифесте гибкой разработки программного обеспечения», речь идет главным образом об адаптивности, а не о соблюдении плана. Или, если говорить о Питере Друкере, речь идет больше о том, чтобы делать правильные вещи, и меньше о том, чтобы делать вещи правильно. В вопросах разработки продукта быть гибким означает откладывать решение об инвестировании на самый поздний экономически целесообразный момент. Это достигается путем проверки гипотез как можно быстрее и дешевле, тем самым уменьшая риски и максимизируя эффективность работы команды разработчиков. Это также означает смелость прекратить усилия, если выбранный курс теряет жизнеспособность.

• 2. Как бы вы охарактеризовали свою роль как владельца продукта? Вы фасилитатор, тренер, менеджер, провидец, тактик, координатор или драйвер?

Это открытый вопрос, чтобы лучше увидеть понимание кандидатами своей роли. Владелец продукта – это руководящая роль, не предоставляющая полномочий в традиционном понимании управления. Таким образом, владелец продукта частично представлен всеми лейблами, упомянутыми в вопросе. Роль владельца продукта также называют «ботлнеком» или «ахиллесовой пятой скрама»; любое упоминание об этом, несомненно, будет плюсом. Если кандидат в большинстве своем говорит вещи типа «Я создаю истории пользователей», стоит подробнее расспросить его, что он имеет в виду.

• 3. Как вы бы описали разницу между Продакт Оунером и Продакт Менеджером? Может, обе роли – это просто разные названия для идентичных обязанностей?

Полный комплект «людей продукта», охватывающий роль менеджера и владельца продукта в одном лице, встречается редко. Слишком много времени нужно, чтобы покрыть все обязанности: от коммуникации с командами до работы со стейкхолдерами и клиентами. В зависимости от продукта PO могут работать на слишком низком уровне, чтобы стать значимыми игроками в процессе. Поэтому крупные организации распределяют обязанности между двумя или более людьми. Продакт менеджер чаще отвечает за стратегические аспекты, в то время как владелец продукта выполняет более тактическую роль. Для меньших или менее сложных продуктов владельцы продукта могут выполнять обе роли одновременно.

• 4. Пересекаются ли между собой роли Product Owner и Product Manager?

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

• 5. Когда вы последний раз говорили стейкхолдерам «Нет»? В каких обстоятельствах и каковы ваши выводы из ситуации?

Способность говорить «нет» – это важная квалификация и расширение возможностей для каждого Продакт Оунера. К примеру, нужно защитить команду от любимого, но сомнительно ценного проекта стейкхолдера. Или покончить с уединенным мышлением и локальной оптимизацией внутри организации. Владельцы продуктов создают ценность, доставляя нужный продукт и максимизируя объем намеренно невыполненной работы. Поэтому организация должна уважать их «нет». Иначе они не будут выполнять свою роль: максимизацию ценности продукта для всей организации. Применение Scrum без уполномоченного владельца продукта создает отличный процесс Waterfall 2.0. Таким образом, полномочия владельца продукта в продуктовом беклоге могут служить лакмусовой бумажкой принятия организацией принципов гибкости.

• 6. Беклог продукта контролируется «продуктовым советом». Он регулярно собирается и применяет своеобразный процесс а-ля Stage Gate® для утверждения приоритетов. Можете ли вы действовать как уполномоченный владелец продукта, если вы не контролируете Беклог продукта?

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

• 7. Какие «ярлыки» приходят вам в голову, когда вы думаете о своей роли как владельца продукта?

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

• 8. Как вы сотрудничаете с другими членами скрам-команды?

Рано, часто, с уважением, прозрачно, респонсивно, отвечаю с должной скоростью и вниманием. Как говорится в Скрам Гайде 2020:

• 9. Если бы ваш Scrum Master предложил возможный курс продукта, как бы вы отреагировали?

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

• 10. Если вы клиент, заказывающий фичи, а скрам-мастер – представитель команды, осуществляющей доставку, как вам лучше всего сотрудничать?

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

• 11. Какие роли вы считаете необходимыми для многофункциональной Scrum-команды, поставляющей программное обеспечение?

В идеальном мире члены кроссфункциональной команды овладевают всеми навыками, необходимыми Scrum-команде для самостоятельного придания ценности клиентам. Это может работать на ранней стадии, когда одна команда занимается всем. Когда организации необходимо масштабироваться, работа с взаимозависимостями (другими командами) становится необходимостью. Фактический состав команды сильно зависит от ее задач. Типичными ролями в кроссфункциональных командах являются бизнес-аналитики или дата-аналитики, дизайнеры UX/UI, разработчики (front-end, back-end), QA и AQA, DevOps и т.д.

• 12. В каких скрам-событиях должен участвовать владелец продукта?

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

• 13. Нужно ли иметь визию продукта, чтобы быть успешным в качестве владельца продукта?

Безусловно, да. Или, цитируя Льюиса Кэрролла:

Гибкий пакет продуктов начинается с видения и стратегии компании. Он разбивается на портфолио продуктов и дорожную карту для каждой услуги и продукта и завершается соответствующими бэклогами и бэклогами спринта. Владелец продукта должен знать все уровни гибкого стека продуктов.

• 14. Как владелец продукта становится ботлнеком для скрам-команды?

Замедление работы скрам-команды происходит часто потому, что процесс управления бэклогом продукта несовершенен: элементы Product Backlog создаются незадолго до начала спринта или не соответствуют стандартам качества, поскольку PO не может выделить достаточно времени на их создание и доработку. PO может быть недоступным для вопросов, задаваемых во время спринта. Чтобы уменьшить риск такого влияния владельца продукта на команду, нужно привлекать других членов скрам-команды раньше или вообще поощрять коллективное владение продуктом. Этот подход в значительной степени поддерживается созданием общего понимания целей на уровне команды. (Начните с «Почему мы это делаем?»)

• 15. Как вы знаете, что вы хороший владелец продукта?

Добавление историй пользователей в Product Backlog доказывает, что PO может управлять системой тикетов. Однако измерение реальной ценности для клиентов требует иного подхода. Соответствующие KPI вклада владельца продукта в команду будут сосредоточены на результате продукта, а не на количестве закрытых задач. Примерами таких показателей являются лид-тайм от идеи до реализации фичи, время цикла оценки идей или NPS.

Набор №2: Продакт Дискавери и внешние стейкхолдеры

Эта категория вопросов для собеседования с Продактом Оунером говорит о дискавере (открытии) и управлении продуктом.

• 1. Считаете ли вы, что Scrum правильно управляет процессом открытия продукта?

Lean UX, Lean Startup, Design Thinking или Service Design – это другие гибкие практики, которые гораздо лучше подходят для открытия продукта, чем Scrum. Все, на что ссылается Scrum, это то, что владелец продукта несет ответственность за управление Беклогом продукта. Считается, что Product Owner – человек, знающий, что несет ценность в любой момент времени. Но Scrum не объясняет, как владелец продукта получает эту информацию.

• 2. Как появляются новые идеи и требования к ним?

Здесь кандидаты во владельцы продукта должны объяснить свои идеи о процессе открытия продукта: от идеи до гипотезы, эксперимента и проверки. Есть разные методы получения идей: через анализ потребностей рынка, отраслевых тенденций, ваших данных (аналитика, NPS и т.п.) и конкуренции. Полезны регулярные встречи с заинтересованными сторонами, такими как отделы продаж и обслуживания клиентов, а также Scrum-командами. Мощно работает предоставление членам команды возможности тратить часть своего рабочего времени на новые идеи. Регулярное наблюдение за клиентами через непрерывное тестирование пользователей – эффективный способ получить информацию о новых фичах, продуктах и услугах. Этот подход еще более полезен, когда вся скрам-команда активно участвует в процессе.

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

Кандидат должен назвать несколько ведущих гибких фреймворков, таких как Jobs-to-be-done, Lean UX, Lean Startup, Design Sprints, Service Design, design etnography и lean user testing, NPS, Voice of Customer и другие.

• 4. Как включить исследование пользователей в процесс открытия продукта?

“Исследование пользователей” или лучше “тестирование пользователей” должно быть непрерывным, регулярным занятием в любой организации, управляющей продуктом. Это важная часть гибкого цикла создания-измерения-обучения. На практике это означает, что общение с дизайнерами и UX researchers становится неотъемлемой частью работы PO и команды. (В идеале они принадлежат самой команде.) Кроме того, отзывы клиентов постоянно собираются путем проведения частых интервью и наблюдений пользователей. Эти вещи относятся и к техническим проектам, например, API-сервисам.

• 5. Сколько времени вы уделяете исследованию пользователей и пониманию потребностей клиентов?

Проводить 50% времени с клиентами было бы здорово. Меньше 10%, и если никто другой не занимается дискавери продукта от имени владельца продукта, означает, что процесс нуждается в улучшении. К примеру, необходимо освободить PO от административных задач, таких как написание историй пользователя. (Примечание: владелец продукта не должен быть главным автором user stories.)

• 6. Как бы вы хотели, чтобы выглядел процесс работы с идеями со стороны стейкхолдеров и других членов организации?

Активное вовлечение заинтересованных сторон и членов общей организации в процесс открытия продукта – это правильный подход. Людям нравится иметь цель и быть частью чего-то большего, чем они сами. Предоставление возможности вносить вклад каждому, независимо от его должности в организации, облегчает работу PO. Процесс такого уровня включения не требует хитроумных технологий. Чтобы запустить его, будет достаточно даже обычной общедоступной excel-таблички или формы. Первый шаблон для предложения фич может содержать вопросы типа «почему», «что» и «для кого». Он может соответствовать тактическому или стратегическому характеру предложения, возможным временным рамкам или оценке ожидаемого возврата инвестиций. Самое важное, что разработка процесса должна быть гибкой: начинаем с MVP, а затем совершенствуем его, когда уже получен первый опыт.

• 7. На каком этапе вы привлекаете Scrum-команду в дискавери продукта?

Как можно раньше. Для такой практики существует три главные причины:

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

• 8. Как определить, стоит ли идея инвестиций?

Существуют количественные и качественные категории, такие как увеличение дохода, выгоды от сокращения затрат благодаря совершенствованию внутренних процессов, повышения уровня удовлетворенности клиентов (NPS), подписки клиентов на новые продукты, положительные отзывы клиентов в службе поддержки и т.д. Кандидаты на позицию Продакт Оунера должны продемонстрировать свои знания по поводу того, какой бэклог продукта пригоден к реализации, максимизируя ценность работы разработчиков от имени клиентов. Это позволяет обсуждать результаты продукта, а не результаты работы, избежать роста «фабрики фич» и преодолеть индустриальную парадигму в целом.

• 9. Как избежать неправильного распределения ресурсов на функции или продукты, которые никому не нужны?

Владельцы продукта могут избежать неправильного распределения ресурсов путем принятия твердого решения в момент, когда становится понятно, что продукт или функция не ценны или невозможны. Это означает, что необходимо наладить непрерывный процесс мониторинга, например, измерения показателей или регулярные тесты пользователей. Как только цикл создания-измерения-обучения предоставит доказательство того, что идея или продукт является неудачным решением, распределение ресурсов следует прекратить. Не позволяйте ошибке «безвозвратных издержек» затмить ваше суждение: независимо от того, сколько уже израсходовано, это не оправдывает продолжения работы над продуктом.

• 10. На каких этапах владельцы продуктов принимают участие в планировании?

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

Набор вопросов №3: управление внутренними стейкхолдерами

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

• 1. Недавно ваша организация решила стать гибкой и ориентированной на продукт. Как вы проинформируете стейкхолдеров о последствиях?

Хорошей отправной точкой было бы работать с Манифестом гибкой разработки программного обеспечения, убедившись, что люди понимают, что адаптация к изменениям вместо соблюдения плана имеет первостепенное значение для будущего успеха организации. Заинтересованные стороны также должны понимать, что «требования» (и, следовательно, возможно, усилия по локальной оптимизации) больше не являются действительной формой процесса доставки продукта. Непрерывное открытие продукта, итеративная и постепенная разработка становятся основными принципами, позволяющими совершенствовать эксперименты и учиться на ошибках передовых практик. Стать гибким означает конкурировать с другими, вероятно, более ценными, идеями продукта за дефицитные ресурсы и признать, что PO является вратарем бэклога. Больше нет произвольных дат доставки, а есть интервалы доставки, во время которых знания сегодняшнего дня проектируются в будущее. В конце концов, стейкхолдеры должны осознать масштаб последствий отказа от командно-контрольного стиля управления и предоставления полномочий по доставке продукции автономным и самоорганизованным командам.

• 2. Как вы организуете сотрудничество со стейкхолдерами и совершенствуете его со временем?

Коммуникация и прозрачность имеют решающее значение для эффективного сотрудничества с заинтересованными сторонами. Существуют разные способы формирования и совершенствования этого общения со временем. Например, можно установить регулярные встречи с каждым из стейкхолдеров или попросить их указать на кого-то, кто будет так называемым «послом» продукта, будет выступать в роли «связного». Организовать воркшопы со стейкхолдерами и послами, попросив Scrum-мастера и разработчиков о помощи. Объединиться с UX-специалистами и организовать встречи по user journeys или сторимапингу. Пригласить стейкхолдеров на встречи Product Backlog Refinement, чтобы объяснить ценность историй пользователей Scrum-команде. Также подходят сессии обзора спринта (спринт ревью) и интервью с пользователями.

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

Можно попытаться завоевать их путём демонстрации ценности гибкой разработки продукта. В начале процесса перехода целесообразно обучать их с помощью продуктовых воркшопов. Проверенными примерами являются user story mapping или воркшопы по планированию дорожной карты продукта. (На этом этапе рекомендуем заручиться помощью опытного тренера.) Доказано также, что это помогает установить тесный график общения с заинтересованными сторонами.

Сотрудничество улучшает также и обучение членов команд роли «связных» в организации. Это смягчает чувство потери контроля со стороны стейкхолдеров.

Впоследствии будут неплохо работать и типичные события, как Sprint Reviews, демонстрируя ценность, поставленную скрам-командой в течение спринта. В крайнем случае, если ничего не сработает, PO может попросить о поддержке стейкхолдера C-уровня.

• 4. Новая фича просрочена и оказалась сильно недооцененной из-за неожиданного технического долга. Тем не менее, ваш самый важный стейкхолдер настаивает, что ее нужно доделать, ведь столько усилий уже вложено. Как вы будете поступать?

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

• 5. Как вы относитесь к пет-проектам?

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

• 6. Посреди квартала сейлзы пробуют реализовать вам фичи непонятной ценности. Scrum-команда считает, что эти фичи – дикие гипотезы, единственной целью которых является оправдать получение бонусов сейлзами. Команде не очень-то хочется этим заниматься. Как вы будете разрешать ситуацию?

Эту проблему можно сравнить с проблемой pet project и решать соответственно. Однако отличительным фактором в этом случае является срочность и, вероятно, другой статус стороны, требующей этих фичей. В организации, ориентированной на продажи, команда продаж может заручиться спонсорской поддержкой со стороны C-уровня для таких предложений. Обычно это случается, когда прогнозы продаж не выполняются. В этой ситуации владелец продукта часто может только привлечь поддержку других заинтересованных сторон, чтобы отразить спрос на основе альтернативных затрат. Если вмешательство исполнительной власти перекрывает обычный процесс, владелец продукта должен немедленно решить эту проблему. Вы не можете одновременно и иметь (гибкий) торт, и съесть его.

• 7. Отдел продаж обещает клиентам фичи ради заключения с ними сделок без предварительной договоренности с вами. Как вы с этим справляетесь?

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

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

Хорошей отправной точкой является создание системы управления идеями. Это может быть простой шаблон, охватывающий вопрос о том, что, почему, когда, для кого и рентабельность инвестиций. Оценивая идею, обязательно следует общаться с человеком, который ее предложил. Если идея взята в реализацию, привлеките автора к процессу. К примеру, пригласите его на воркшоп по составлению историй пользователя или тестированию продукта пользователями. Обеспечьте непрерывную обратную связь на протяжении всего цикла разработки и доставки с регулярными контрольными точками по начальным целям. Наконец, через 3–12 месяцев после доставки, сообщите заинтересованной стороне, оправдали ли результаты ожидания (например, рентабельность инвестиций, экономия средств, привлеченность и другие KPI).

Набор №4: Портфолио и планирование дорожной карты продукта

Вопросы в этом наборе касаются одной из самых противоречивых тем в профессии: как сформировать гибкие родмапы продуктов?

• 1. Видение продукта и стратегия в вашей организации сохраняются под грифом «Секретно», чтобы предотвратить похищение идей конкурентами. Помешает ли это вашей работе как владельцу продукта?

Да, это значительно усложнит работу владельца продукта, поскольку для эффективного внедрения инноваций необходима прозрачность. Сегодня инновации – это командный вид спорта. Блестящая личность, самостоятельно создающая большие инновации, — это миф. (Даже господин Джобс не считал себя таким человеком.) Ну, а совместная командная работа начинается с общего понимания видения продукта и его стратегии.

• 2. Разве планирование портфолио и продукта не является анахронизмом в гибкой организации?

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

• 3. Каков ваш подход к созданию дорожных карт продукта?

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

• 4. Как часто следует планировать родмапы продуктов?

Планирование дорожной карты – это непрерывная работа по анализу продуктов на всех этапах: живых, в разработке, на стадии планирования или на грани постепенного отказа. В зависимости от зрелости организации, размера продуктового портфеля, ее продуктов и услуг, отрасли и уровня регулирования это может быть ежеквартальная или даже ежемесячная практика.

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

Рекомендуется активно включить скрам-команду в процесс открытия продукта (product discovery). Если разработчики видят только документацию и BRD, нельзя ожидать от них инициативы по самоорганизации – мы ведь сами ограничиваем их и лишаем понимания процессов, происходящих за рубежом ближайшего релиза. (Это приводит к синдрому винтика в механизме, ослабляющем представление людей об автономии.) Владелец продукта может привлечь разработчиков к процессу открытия продукта разными способами: например, при анализе историй пользователя, планировании дорожной карты продукта, участии в тестировании продукта пользователями и т.д.

• 6. Кто должен участвовать в планировании дорожной карты продукта?

Обычно это внутренние стейкхолдеры, члены Scrum команд или их представители и владельцы продукта. Добавление клиентов – скорее бонус, чем правило.

• 7. Сколько времени вы тратите на общение с клиентами и исследование отраслевых тенденций?

По эмпирическому правилу скрама предполагается, что 50% времени должно выделяться на коммуникацию со стейкхолдерами всех уровней.

• 8. Какое отношение Монте-Карло имеет к запланированным датам доставки?

Моделирование по методу Монте-Карло – это статистический подход на основе алгоритма для получения числовых результатов. Владельцы продуктов могут использовать этот подход для прогнозирования возможных окон доставки выпусков или функций на основе предварительной эффективности команды Scrum. (Этот вопрос открывает дискуссию о том, как иметь дело со сроками, прогнозами и другими законными запросами заинтересованных сторон по доставке продукта.)

Набор №5: Бэклог продукта, уточнение бэклога, рабочие элементы, прогнозы и оценки

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

• 1. Какова цель Product Backlog Refinement?

Уточнение – это непрерывный процесс создания резервных бэклогов, позволяющий Scrum-команде мгновенно планировать спринт.

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

• 2. Сколько времени нужно потратить на доработку бэклога?

Несмотря на то, что Скрам Гайд 2020 отменяет предварительные указания по распределению времени, общепринятое правило – до 10% времени скрам-команды для уточнения бэклога продукта.

• 3. Как вы организовали процесс уточнения элементов бэклога продукта?

В общем, полезно структурировать процесс уточнения вокруг таких вопросов, как:

• Какие задачи уже не актуальны?
• Какие нужно разделить?
• Какие нужно обновить?
• Изменяет ли это уточнение предварительные оценки?
• Изменился ли приоритет отдельных задач?
• Есть ли у нас нерассмотренные и неприоритетные темы или запросы? (Если да, их нужно зафиксировать как новые элементы Product Backlog.)

• 4. Над каким количеством элементов продуктового беклога можно параллельно работать, чтобы обеспечить постоянную доставку ценности для клиентов и компании?

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

• 5. Вы любите использовать Backlog продукта как своего рода хранилище, добавляя идеи, чтобы продолжить работу над ними на более позднем этапе. Со временем вы создали более 500 тикетов на разных этапах. Как думаете: может ли команда Scrum работать эффективно на 500 тикетах?

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

Особенно не стоит успокаивать назойливых стейкхолдеров, просто добавляя их идеи в Product Backlog. Это не решает проблему; это просто откладывает неизбежное обсуждение, поскольку теперь заинтересованные стороны ожидают, что скрам-команда создаст им Инкремент.

• 6. На каком уровне вы привлекаете других членов команды к процессу рефайнмента?

По готовности каркаса задачи.

Готовность нелегко обобщить, поскольку она зависит от характера самого продукта, опыта команды и стиля руководства организации. Для формирования общего понимания рабочего элемента всеми членами команды точный момент привлечения является решающим. Если команда будет привлечена слишком рано, разработчики могут считать это пустой тратой времени. Если скрам-команду привлечь слишком поздно, например, когда все требования уже готовы, разработчики почувствуют нехватку уважения. Если есть сомнения, владелец продукта должен привлечь Scrum Master к процессу.

• 7. Как определить ценность элемента бэклога продукта?

Некоторые проверенные категории для определения ценности: прогнозируемый рост дохода, эффект сокращения расходов, прогнозируемый рост клиентской базы и повышение уровня удовлетворенности клиентов.

Дополнительные характеристики доступны в модели Scrum.org Evidence-based management.

• 8. Как вы объясняете членам команды ценность элемента продуктового бэклога?

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

Желательно, чтобы члены Scrum-команды знали об этом заранее, поскольку они должны участвовать в user testing (тестировании на пользователях).

• 9. Какие хорошие практики заказа элементов Backlog продукта?

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

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

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

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

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

• 11. Почему user story mapping является полезной техникой для владельцев продуктов?

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

• 12. Как лучше создавать элементы беклога продукта?

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

• 13. Как выглядит хорошая история пользователя? Какова ее структура?

Для разработки программного обеспечения атрибутами образцовой истории пользователя являются:

• Наличие описания
• Определенность критериев готовности
• Помещается в спринт
• Содержит все элементы интерфейса
• Выявлены все возможные зависимости и блокеры
• Определены метрики успеваемости
• Оценено командой

Читайте «Три-К» Рона Джеффриса и “Принцип ИНВЕСТИРОВАНИЯ” Билла Уэйка.

• 14. Где вы обсуждаете истории пользователей только во время доработки?

Лучший способ обсудить историю пользователя – сделать это синхронно со всеми вовлеченными членами команды, чтобы обеспечить общее понимание. Этот подход работает как для цельных, так и для распределенных Scrum-команд.

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

Избегайте длительных обсуждений тикетов. Это признак слабости предварительного отбора.

• 15. Каковы типичные подводные камни уточнения бэклога (Product Backlog Refinement)?

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

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

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

В целом, критерии готовности (Acceptance criteria) определяют функциональные и нефункциональные требования к продукту или его фичи. Уровень детализации может отличаться в зависимости от характера задачи. К их созданию целесообразно привлекать команду Scrum, поскольку некоторые из них могут быть уже учтены в определении готового.

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

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

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

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

• 19. Когда бы вы удалили фичу?

Лучше бы и вовсе такую фичу не создавать.

Если, несмотря на все этапы проверки во время Product Discovery, фича с низкой ценностью проскользнет в Product Backlog и будет доставлена, следует ее как можно быстрее удалить. То же касается имеющейся фичи, утратившей полезность.

Набор №6: Планирование Спринта, Спринт, Ревью (Обзор) Спринта, Ретроспектива

Шестая категория вопросов адресуется собственно Спринту.

• 1. Вы проталкиваете критически важную историю в следующий Спринт. Правда, дизайны еще не финализированы, но дизайнеры обещают доставить их максимум до конца второго дня Спринту. И все же Скрам-мастер отвергает идею, говоря, что элемент бэклога не готов к следующему Спринту. Что можно сделать?

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

Вот только это всегда решение Скрам-команды и никогда – Продакта.

• 2. Следует ли Продакт Оунеру асайнить рабочие элементы на конкретных членов Скрам-команды?

Это неприемлемо. Это должны делать сами разработчики.

• 3. Должен ли Продакт Оунер участвовать во всем событии Планирования Спринта?

Давайте посмотрим на Планирование Спринта поподробнее.

Продакт Оунер представляет бизнес-цели следующего Спринта Скрам-команде. В сотрудничестве с ним Скрам-команда создает Цель Спринта. Тогда разработчики выбирают – учитывая обстоятельства, например, доступную капасити, – элементы Беклогу, которые они считают необходимыми, чтобы достичь Цели Спринта. Здесь присутствие Продакт Оунера просто необходимо.

Теперь разработчики могут заняться, например, детализацией элементов Бэклога Спринта – например, разбивкой их на задачи, определением, где требуется больше информации, или распределением задач в команде. Здесь Продакт Оунер не обязательно должен присутствовать, но должен быть на связи, чтобы быстро отвечать на вопросы.

• 4. Должен ли Продакт Оунер посещать Дейли Скрамы?

Обязательно. Это поможет быстро дать ответы разработчикам и избежать задержек.

• 5. Ваша Скрам-команда, по вашим ощущениям, регулярно оценивает элементы по самым высоким возможным рамкам. Похоже, что они пытаются каждый раз «подстелить соломки» в случае, если что-то пойдет не так. Как вы с этим справляетесь?

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

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

Такое поведение заинтересованных сторон неприемлемо. Владелец продукта преследует цель заранее четко понять объем фичи, на которую есть запрос. Проникновение фич через бэкдор – типичный анти-шаблон Scrum, который нужно исследовать и решить.

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

• 7. Имеет ли владелец продукта право вето, когда речь идет о выпуске инкрементов продукта?

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

Этот вопрос открывает дискуссию о встроенных системах сдерживаний и противовесов и о том, как может работать эффективное сотрудничество в скрам-команде.

• 8. Нужно ли релизить каждый продукт продукта, который был завершен во время спринта?

Scrum-команда решает, когда и какой инкремент для клиентов нужно релизить.

• 9. Как вы организовали Sprint Review?

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

• 10. Во время Sprint Review разработчики показывают фичи, которых вы никогда раньше не видели. Как вы реагируете?

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

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

• 11. После окончания спринта вы участвуете в Ретроспективе?

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