Идти против течения как продуктовый владелец
Роль product owner-а родилась из гибкой методологии. Итак, как заказчик, я никогда не задумывался дважды о настройке scrum и Kanban и проведении Agile-ритуалов для команд. Но когда мне предложили присоединиться к Xero в качестве старшего PO, я присоединился к молодой команде специалистов по данным и инженеров машинного обучения (ML), которые раньше не использовали гибкую структуру.
И это заставило меня задуматься: действительно ли нам нужно было следовать гибкой структуре, чтобы получить наилучшие результаты для наших пользователей?
Ставлю под сомнение мой подход
Моя новая команда выполняла технологический проект по созданию сервисов искусственного интеллекта (ИИ) для других команд Xero. Другими словами: действительно захватывающий материал. Все яростно работали над бета-версией, которую мы выделили на несколько месяцев, и я был готов погрузиться в свои любимые Agile-ритуалы. Следующие несколько недель я провел, наблюдая за командой, ища доказательства того, что отсутствие у них традиционных гибких методов было каким-то образом разрушительным. Но то, что я обнаружил, когда посмотрел на результаты, меня очень удивило.
Это была команда, которая последовательно уложилась в сроки и, казалось, имела коллективное понимание ценности для клиента и того, что нужно для ее реализации. Они охраняли друг друга от кроличьих нор и были одной из самых продуктивных команд, с которыми мне приходилось работать. Эта команда не использовала никакого подобия Agile, но когда я смотрел на результаты, они были сокрушительны. Как это было возможно? И как я мог оправдать внедрение гибкого подхода, если для этого не было никаких оснований?
Выбор моих гибких сражений
Вот тогда я попал в интроспективную яму. Что такое Agile? Почему схватка? Каких результатов я хотел достичь? Почему я хотел познакомить эту команду с agile, кроме моего мнения, что это было ново и круто, и что это основная часть моей роли как PO? Вместо того, чтобы предлагать команде новые гибкие методологии, я сосредоточился на ответах на несколько важных вопросов:
- Было ли четкое направление?
- Решали ли мы реальные проблемы клиентов?
- Была ли четкая связь между каждой работой и общим направлением?
Я вооружился всеми доступными мне исследованиями пользователей, чтобы понять, что важно для пользователей и как наш сервис соответствует их потребностям. К счастью, у Xero есть фантастическое централизованное хранилище пользовательских исследований, доступное для всех сотрудников, поэтому информация была легко доступна. Помня об исследовании, я определил показатели, которые лучше всего представляют нашу ценность для пользователя. Так получилось, что они отразили метрики, которыми команда уже была одержима:
- Задержка: нашему сервису требовалось ответить в течение X секунд в 95% случаев
- Охват: нам нужно было быть уверенным в Y% наших прогнозов.
- Точность: нам нужно было поддерживать точность Z% для всех надежных прогнозов.
Затем я приступил к приведению каждой новой работы в соответствие с этими показателями. В качестве оружия в своем крестовом походе я выбрал Product Kata *, и первой жертвой стала бы наша произвольная бета-версия.
* В качестве примечания: если вы раньше не использовали Product Kata, ознакомьтесь с ним. Это действительно отличный способ отслеживать ваши успехи на этапе экспериментирования, который в противном случае может оказаться нечетким и неструктурированным. Артефакт, созданный в конце, действительно великолепен для сообщения о вашем прогрессе и путешествии.
Переход к результатам, ориентированным на пользователя
Видя, что крайний срок бета-тестирования был установлен самим собой, команда собралась и решила изменить его с момента времени, когда мы хотели создать набор функций, на время, когда мы достигли набора ориентированных на пользователя результатов . В частности: задержка, охват и точность. Мы начали с того, что сосредоточились на задержке. Чтобы измерить нашу сквозную задержку, мы побежали к API, который вообще что-то возвращал, и обнаружили, что мы уже вдвое быстрее, чем наша цель. Однако после преждевременного празднования мы также обнаружили, что измерить простые показатели, такие как задержка, не всегда просто.
Мы измеряли пропускную способность, и проблема заключалась в том, что эта мера менялась в зависимости от того, насколько мы масштабировали наш конвейер. Когда мы начали записывать различные классы входных данных и их комбинации с параметрами инфраструктуры, это быстро превратилось в огромную головную боль. Итак, что мы измерили? Пропускная способность или задержка? Оба? После недолгих разговоров мы решили проконсультироваться с высшим органом власти - заказчиком. Ориентируясь на клиента, мы выбрали следующие экспериментальные условия для достижения целевой задержки:
- время непрерывного ответа
- при объемах загрузки производства
- и с таким же разнообразием ресурсов, как и при производстве
Соединяем точки
В течение нескольких недель у нас был работающий сервис с приемлемой задержкой. Следующими вехами будут наши амбициозные цели в области точности и охвата. Мы подошли к ним так же, как и к нашей метрике задержки, с Product Kata. Мы безжалостно расставляли приоритеты по заявкам, которые увеличивали эти показатели, снижали приоритеты тем, которые этого не делали, и останавливались, как только достигли поставленных целей.
Вскоре наш сервис достиг результатов, определенных для нашей бета-версии, за две недели до произвольного крайнего срока. Честное ретро показало, что команде действительно нравится направление и структура, хотя мы отметили, что было немного сложно согласовать условия эксперимента. Вопрос был в том, уложились бы мы в срок без «модного подхода» (слова моего менеджера)? Сказать было невозможно.
Поразмыслив, мы решили, что все дело в риске. Мы могли бы уложиться в произвольный крайний срок без Product Kata, но, напрямую связывая наши результаты с ожидаемыми результатами, было гораздо больше шансов, что наше решение решит проблемы наших пользователей. Когда вы работаете над списком функций, существует риск того, что вы можете делать то, что не вносит прямого вклада в ценность. И если вы не будете оценивать свои результаты, вы можете начать с фальстарта.
Возвращаясь к основам
Изначально меня пригласили в команду из-за моего опыта работы с Agile, но в итоге я понял, что иногда лучшее, что вы можете сделать, - это не погружаться в гибкую структуру. Я научился осознанно относиться к изменениям, потому что изменения - это сложно, а менять вещи ради них глупо.
Если это означает, что я заказчик, который не практикуется в гибкой среде, такой как scrum или Kanban, тогда ничего страшного, потому что моя работа - помочь команде принести как можно больше пользы пользователям. Все остальное - это инструмент, который поможет нам достичь этого.
Сосредоточение внимания на результатах - фундаментальный принцип в управлении продуктом, но мне потребовалась новая работа и отличная команда, чтобы научить меня тому, что этот принцип выходит за рамки гибких рамок. В результате мы добились огромных успехов и теперь расставляем приоритеты в работе, исходя из ценности для клиентов. У нас есть краткосрочные, осязаемые цели, к которым нужно стремиться, и действительно крутой процесс (Ката) для управления нашими рабочими экспериментами.
Конечно, моя работа еще не закончена, и это только начало моего пути к продукту в Xero. Фактически, я уже начинаю думать о следующем большом шаге. Но это сообщение на другой день. А пока я хотел бы знать, как бы вы отнеслись к этой ситуации. У вас есть какие-нибудь уроки, которыми можно поделиться? Я хотел бы извлечь уроки из вашего опыта.
