Менеджеры по продукту отвечают за активизацию всех остальных отделов и за то, чтобы заставить их работать сообща. Это делается для того, чтобы продукт продвигался слаженной командой лошадей, а не разрывался на части лошадьми, разбегающимися в разные стороны.
— Дональд С. Пассман
Представляем: Лицо, принимающее решения
Одним из многих преимуществ наличия отличного владельца продукта является повышение скорости и качества принятия решений. Особенно в сложных ситуациях, когда многие вещи, такие как требования, люди и технологии, часто меняются, скорость принятия решений может иметь огромное значение для достижения успеха и постоянной игры в догонялки с конкурентами. Вероятно, не зря мы были свидетелями того, как некоторые корпоративные организации создавали стартапы как отдельные компании, чтобы конкурировать со своим собственным бизнесом. Похоже, что есть большая ценность в том, чтобы быть небольшой, проворной и гибкой компанией, где решения могут приниматься намного быстрее.
Сэр Алек Иссигонис, британский автомобильный дизайнер, который с 18 лет работал в компании Morris Minor и продолжил разработку Mini, сказал:
“Верблюд - это лошадь, спроектированная комитетом”. Очевидно, Иссигонис рассматривал горб верблюда и дополнительную емкость для воды, его большие ноги и повышенный интеллект как дополнения, которые лошади просто не нужны. Его сравнение показывает, что комитеты регулярно не в состоянии распознать, когда продукт или решение “достаточно хороши”.
Это также говорит о том, что создание продуктов с помощью комитетов - это верный путь к разработке плохих продуктов. Размышления и решения, принятые комитетом или на основе консенсуса, могут привести к полезным выводам, продуктивным дискуссиям и разнообразным точкам зрения. Однако проекты и решения, принятые комитетом, не всегда приводят к улучшению продукта или появлению нового замечательного продукта. Это несколько странная идея, потому что большинство отличных продуктов создаются в результате совместной работы, так как же вы находите баланс между принятием разнообразного вклада и осознанием того, что вам этого достаточно?
В производственной системе Toyota и в японской культуре немаваси относится к неформальному процессу закладки фундамента и достижения консенсуса перед принятием решений. В переводе немаваси означает “обходить корни” в смысле копания вокруг корней дерева, чтобы подготовить его к пересадке.
Владелец продукта несет ответственность за максимизацию ценности продукта. Однако это не означает, что владелец продукта должен принимать все решения самостоятельно или принимать все решения в одиночку. Если вы пройдетесь по корням, то обнаружите, что многие решения могут быть делегированы, например, командам (Scrum), работающим над продуктом. Аналогичным образом вы можете оценить свою автономию и полномочия как владельца продукта, проверив, какие решения делегированы вам.
Итак, каковы некоторые характеристики великих владельцев продуктов, принимающих решения? Сначала великие лица, принимающие решения, слушают, а затем применяют подходящий стиль, специфичный для ситуации:
- Командуйте: Эти владельцы продуктов обладают сильным чувством срочности или просто не любят ждать. Они любят действовать и быстро принимают решения. Они также склонны принимать решения независимо от того, что думают другие люди. Они доводят дело до конца.
- Пейс-кар: Совершенно другой вариант гарантирует, что работа будет выполнена, но находится в окопах вместе с командой, следя за тем, чтобы они справлялись с последствиями принимаемых ими решений.
- Продавец: Некоторые владельцы продукта тратят значительное время на то, чтобы убедить людей в своей идее. Обычно решение по-прежнему остается за ними, но они убеждают людей в том, что это правильно.
- Мы вместе: Scrum нацелен на усиление команды, отсюда и фраза “Передайте это команде”. Хороший совет, но он замедляет процесс принятия решений, чтобы проверить, все ли согласны. Эти владельцы продуктов принимают решения, которые часто пользуются всеобщим уважением и поддержкой.
- Демократичный: Другой вариант часто приводит к голосованию большинством голосов. Это быстрее, и все вовлечены, но речь идет не о достижении консенсуса, а о поиске наиболее широко поддерживаемого результата.
- Коучинг: Эти владельцы продукта задают широкие вопросы: Как бы мы с этим справились? Если бы что-то пошло не так, что бы мы сделали? Они подталкивают команду к тому, чтобы самим задавать правильные вопросы. Обычно они преуспевают, когда продукт начинает масштабироваться.
Некоторые решения, которые вы принимаете, окажутся неправильными, а некоторые - правильными. Есть способы улучшить навыки принятия решений, и есть способы определить, какие решения стоят вашего времени, а какие нет. Это иногда называют законом тривиальности. В организациях неоднократно обнаруживалось, что руководители высшего звена, даже советы директоров, ведут долгие дискуссии о чем-то относительно неважном или недорогом.
Часто используемый пример - о том, где разместить навес для велосипедов, как он должен выглядеть и сколько это может стоить. Этот относительно дешевый проект обсуждается на совещании за совещанием, в то время как компании предстоит построить атомный реактор стоимостью в несколько миллионов долларов. Быстрые решения, без долгих обсуждений, принимаются вокруг реактора, несмотря на то, что он в миллион раз дороже, чем сарай для велосипедов. Интересно, что кажется, что чем дороже что-то, тем меньше времени мы тратим на обсуждение этого. Реактор настолько чрезвычайно дорог и сложен, что обычный человек не может в нем разобраться, поэтому предполагается, что те, кто над ним работает, это понимают. Напротив, каждый может представить себе дешевый, простой сарай для велосипедов, поэтому его планирование может привести к бесконечным дискуссиям, потому что каждый участник хочет внести свой вклад. Часто мы встречаем владельцев продуктов, которые сосредоточены не на атомном реакторе своего продукта, а на мелочах, которые легче понять.
Закон тривиальности - это то, что я никогда не забуду, и он больше подходит мне как “всплывающий пример”. В начале 2021 года я обучал владельцев продуктов в онлайн-компании по продаже цветов и букетов. Одна из владелиц продукта рассказала, как у нее были длительные обсуждения и споры с одним из ключевых заинтересованных лиц по поводу новой функции поиска в программном обеспечении. Эта ключевая заинтересованная сторона хотела иметь всплывающее окно, позволяющее пользователям искать цветы и добавлять их в букет.
Команда Scrum разработала другой вид функции поиска, который был проще и быстрее в использовании. Владелец продукта и заинтересованная сторона провели несколько долгих и интенсивных дискуссий по поводу этого небольшого и простого всплывающего окна. Тем временем, однако, заинтересованная сторона хотела отложить выпуск программного обеспечения до тех пор, пока все функции не будут полностью встроены — что-то вроде старой английской поговорки “пенни мудрый, фунт глупый”, я полагаю. В любом случае, я никогда не забуду это всплывающее окно.
Принимать все решения самостоятельно - не лучший способ продвижения вперед, но и делегировать все решения другим тоже не стоит. В повседневной практике мы часто обнаруживаем, что зрелость Scrum-команды влияет на объем делегируемых полномочий. Это работает для решений, которые руководители компаний делегируют владельцам продуктов, и это работает для решений, которые владельцы продуктов делегируют своим командам. Вы обнаружите, что делегирование ответственности и полномочий создает время и пространство, чтобы вы могли выполнять другую работу. Чтобы продвинуться в качестве владельца продукта, вам часто придется отказаться от некоторых мелких решений и обязанностей, прежде чем вы сможете приступить к выполнению более крупных обязанностей и получить больше полномочий для принятия более эффективных решений.
Техника, которую мы часто используем, когда говорим о принятии решений и делегировании полномочий, - это делегационный покер, описанный в "Менеджменте 3.0" Юргеном Аппело. Этот прием особенно хорошо работает, когда вы хотите обсудить, какие решения вы будете принимать сами, какие решения вы будете принимать вместе с командой, а какие решения вы будете делегировать им. Он также очень хорошо работает между двумя сторонами.
Как владелец продукта, вы часто оказываетесь в ситуации с тремя сторонами. Над вами есть руководство или руководители компании, есть вы и есть Scrum-команда. Некоторые пункты делегированы вам, а некоторые вы будете делегировать другим. Поэтому мы немного переняли технику делегирования полномочий, чтобы она была более применима для владельца продукта. Таблица 20.2 иллюстрирует, к чему мы пришли в итоге.
Решения уровня 1 - это решения, принимаемые другими сотрудниками организации без консультаций с владельцем продукта. Эти решения обычно принимаются руководителями компании и могут включать решения о видении компании, стратегии компании, ценностях компании, доступных бюджетах продуктов и стандартах соответствия. Когда решения принимаются на уровне 1, руководители компании сообщают вам о своих решениях.
Решения уровня 2 также принимаются вне вашего контроля. Окончательное решение по таким решениям по-прежнему принимают руководители компании, но теперь вы можете влиять на их решения. В этом случае руководители компании обращаются к вам и, возможно, к другим владельцам продуктов, чтобы оценить ваше мнение и перспективу. Решения уровня 2 обычно принимаются, когда стратегия компании влияет на стратегию продукта, или наоборот. Руководители компании, скорее всего, сообщат или продадут вам свое окончательное решение.
Решения уровня 3 принимаете вы, владелец продукта. Обычно эти решения касаются порядка начала невыполненной работы по продукту, цели и работы, которую необходимо выполнить в следующем спринте, или следующей проблемы клиента, которую нужно начать изучать. Решения, которые вы принимаете самостоятельно, обычно являются простыми или малорискованными решениями, требующими небольшого участия. Другие решения могут касаться того, кого из заинтересованных сторон пригласить на обзор спринта или какой объем бюджета предложить каждой заинтересованной стороне во время сеанса оценки стоимости. Что ж, давайте не будем создавать для этого комитет! Владельцы продуктов ускоряют процесс, также самостоятельно принимая решения.
Иногда, конечно, есть более важные и действенные решения, которые должен принимать Владелец продукта. Владелец продукта должен иметь последнее слово по таким вопросам, как видение продукта, стратегия продукта, цели и дорожная карта. Однако для принятия большинства таких решений они сначала беседуют с заинтересованными сторонами, узнают об их перспективах, а затем принимают решение. Именно в этом суть решений уровня 4. Владелец продукта принимает эти решения после консультаций с другими. Это очень похоже на уровень 2, где руководство компании консультируется с владельцем продукта, прежде чем окончательно принять решение. Но в данном случае все наоборот. Обычно это более сложные решения, которые сопряжены с риском, но требуют небольшого участия. Примерами могут служить порядок выполнения невыполненных работ по продукту, дорожная карта продукта высокого уровня или способы выражения и измерения ценности для предстоящих спринтов.
Решения уровня 5 принимаются по взаимному согласию группы и требуют поддержки со стороны других. Следовательно, вы должны убедиться, что эти другие являются частью решения. Если вы навязываете людям свое собственное решение в ситуациях, когда требуется участие, люди просто пожмут плечами, когда события пойдут не так, как планировалось, и, скорее всего, возложат вину на вас. В конце концов, это было ваше решение. Итак, на уровне 5 убедитесь, что решения - это наши решения, а планы - это наши планы.
Когда решения принимаются на уровне 6, они делегируются команде, но они держат вас в курсе или консультируются с вами перед окончательным принятием решений. Опять же, этот уровень во многом похож на уровни 2 и 4, но теперь это дело рук владельца продукта и разработчиков. Отличный способ поэкспериментировать с предоставлением принятия решений на уровне 6 команде - позволить им заниматься доработкой элементов списка невыполненных работ по продукту (PBI). Возможно, они смогут решить, как решить проблему клиента. Возможно, они смогут договориться о решении, критериях приемлемости и дизайне. Вам нужно быть в курсе каждой детали?
Когда вы достигаете 7-го уровня, решение полностью делегируется команде. Вы доверяете им принимать правильные решения, и вы не хотите или не нуждаетесь в участии в этих решениях. Часто это решения “как”, но они также могут иметь более серьезные последствия. Например, решение о том, какую технологию использовать, может повлиять на стоимость продукта. Другим примером может быть принятие решения о том, какое программное обеспечение, инструменты, методы или платформы разработки использовать. Возможно, вы сможете договориться о максимальном бюджете и позволить команде решить, является ли покупка инструментов или лицензий достаточно ценной для них.
Какие решения всегда должны приниматься на каком уровне? Это зависит от организации, зрелости владельца продукта, зрелости Scrum-команды и многих других элементов. Хорошей отправной точкой является обеспечение прозрачности текущей ситуации. Создайте прозрачность в отношении того, как принимаются решения и кто их принимает. Затем обсудите свои выводы с руководством и вашей командой. В качестве альтернативы, проведите семинар по делегированию в покер, чтобы определить текущий и желаемый опыт делегирования. Здесь перечислены общие решения и примеры для обсуждения.
Продукт
Что касается продукта, то эти решения должны быть приняты:
- Видение продукта
- Стратегия продукта
- Бизнес-модель
- Ценностное предложение
- Стратегия выхода на рынок
- Юридические требования/соответствие требованиям законодательства
- Продукты для включения в портфель продуктов
- Добавлять ли продукт или услугу в портфель продуктов, удалять ли продукт или услугу из портфеля продуктов, объединять или не объединять продукты или создавать варианты продуктов
Цели и задачи продукта
Что касается целей продукта, то должны быть приняты следующие решения:
- Финансовые цели и задачи продукта
- Операционные цели и задачи продукта, связанные с удовлетворенностью клиентов
- Цели и задачи продукта
Бюджет
Что касается бюджета, то эти решения должны быть приняты:
- Определение бюджета продуктов
- Определение бюджетов на инновации, техническое обслуживание, устранение неполадок, операции и т.д.
- Стоит ли тратить/инвестировать менее 10 000 долларов из бюджета, стоит ли тратить/инвестировать от 10 000 до 50 000 долларов из бюджета, стоит ли тратить/инвестировать более 50 000 долларов из бюджета, устанавливающего командный бюджет (для общественных мероприятий/командных ивентов)
Ценность
Относительно ценности должны быть приняты следующие решения:
- Как определить ценность
- Оценочная стоимость
- Как измерить ценность
- Целевые показатели выручки
- Целевые показатели экономии средств
Маркетинг и брендинг
Чтобы выйти на рынок, необходимо принять следующие решения:
- Позиционирование продукта или услуги
- Брендинг продукта или услуги
- Кампании/реклама продукта или услуги
Ценообразование
Относительно ценообразования должны быть приняты следующие решения:
- Стратегия ценообразования на продукт
- Тактика ценообразования на продукт
- Цена продукта/услуги для клиента
- Утверждение (стандартных) отклонений/исключений в цене
Инструменты и технологии
Следует принять следующие решения относительно используемой и/или необходимой технологии:
- Начинать ли процесс выбора нового инструмента/технологии, технологии, используемые для разработки продукта
- Приобретать ли инструменты/технологии стоимостью менее 1000 долларов в месяц
- Следует ли приобретать инструменты/технологии стоимостью более 1000 долларов в месяц
- Следует ли прекращать использование инструмента/технологии
Процесс выпуска
Относительно процесса выпуска должны быть приняты следующие решения:
- Как проводится процесс выпуска
- Когда выпускать продукт (инкремент)
- Следует ли откатывать/отзывать выпущенный продукт (инкремент)
Люди и команды
В отношении задействованных команд должны быть приняты следующие решения:
- Создать новую команду
- Расширить команду (по размеру/количеству людей)
- Сократить команду (по размеру/количеству людей)
- Остановить команду
- Необходимые навыки
- Нанять нового члена команды
- Уволить члена команды
- Как проводится процесс оценки эффективности
- Заработная плата членов команды
- Бонусы членов команды
- Командные бонусы
- Манифест команды/рабочие соглашения
- Встречи и мероприятия команды
- Праздники членов команды
- Мероприятия по тимбилдингу
- Рабочее время
- Покупка командного тренинга менее чем за 500 долларов с человека
- Покупка командного тренинга более чем за 500 долларов с человека
Управление списком невыполненных работ по продукту
Для списка невыполненных работ по продукту необходимо принять следующие решения:
- Размер списка невыполненных работ по продукту
- Добавить элемент списка невыполненных работ по продукту в список невыполненных работ по продукту
- Удалить элемент списка невыполненных работ по продукту из списка невыполненных работ по продукту
- Оценка размера/трудозатрат элемента списка невыполненных работ по продукту
- Оценка стоимости элемента списка невыполненных работ по продукту
- Как записываются/выражаются элементы списка невыполненных работ по продукту (например, история пользователя, свободный формат, утверждение гипотезы)
- Порядок списка невыполненных работ по продукту
Управление внешними сторонами и поставщиками
Для поставщиков необходимо принять следующие решения:
- Описание контракта
- Принятие контрактов (в соответствии со стандартными условиями)
- Принятие контрактов (в соответствии с нестандартными условиями)
- Принятие решения о соглашениях об уровне обслуживания или об уровне опыта
- Наем временного персонала/членов команды стоимостью менее 1000 долларов США в день
- Наем временного персонала/членов команды стоимостью более 1000 долларов в день
Это огромный список потенциальных решений, и он далек от завершения.
Начните с этого списка, добавьте свои идеи, исключите другие и используйте его, чтобы узнать, как следует принимать решения в вашей компании посредством открытого диалога.
- Что потребуется от организации, чтобы делегировать вам больше решений?
- Что это принесет с точки зрения ценности?
- Каковы могут быть риски?
- Что вы можете делегировать своей команде?
- Какое поведение или обязанности должна продемонстрировать команда, прежде чем вы доверите им самим принимать более эффективные решения?
Прелесть делегационного покера в том, что он превращает бинарную дискуссию (я решаю или я делегирую) в шкалу. Шкала оставляет гораздо больше возможностей для экспериментов и облегчает обсуждение, особенно если вы хотите продвинуться всего на один шаг по шкале. “Я знаю, что вы принимаете эти решения, но не могли бы вы проконсультироваться со мной?” - отличный вопрос, который поможет вам завоевать больше авторитета и увеличить свое влияние.