Подходы к масштабированию для людей и команд
Модель, которую мы наблюдали на практике в различных организациях, заключается в том, что старший руководитель говорит что-то вроде:
“Итак, над продуктом работают семьдесят человек. Поскольку мы решили внедрить Scrum, нам нужно, чтобы вы организовали их в отдельные команды”, - объяснил генеральный директор.
В этой фразе было так много интересного, но мы решили взглянуть на этот комментарий генерального директора с целостной точки зрения на продукт.
“Вам нужны все семьдесят человек, чтобы создать этот продукт?” спросили мы. “Ну, я не знаю, - ответил генеральный директор, - но именно столько людей работало над этим, и я не думаю, что с меньшим количеством людей дело пойдет быстрее”.
Во многих организациях масштабирование не считается экспериментом. Многие организации используют подход "скопируй и вставь" при внедрении Scrum для повышения гибкости или получения других преимуществ. Они видят, что другие компании в их отрасли внедряют “модель Spotify”, поэтому они делают то же самое. Они осознают свои существующие роли, позиции и структуру в общей картине Scaled Agile Framework (SAFe) и думают, что внедрение SAFe framework (или модели Spotify, или другой) поможет им стать более гибкими. Они надеются, что это действие копирования и вставки работает безупречно, но часто это не так. В большинстве случаев возникают или усугубляются новые и более сложные проблемы. Даже если копирование и вставка сработали, масштабирование часто создает новый набор проблем и вызовов.
________________________________________________________________________
Что могло пойти не так?
Айко, ИТ-менеджер и непосредственный начальник Noa, посмотрел на Noa с большим недоверием, покачал головой и попробовал еще раз. “Послушайте, нам нужно быстрее создавать и выпускать функции, поэтому я связался с этой компанией, которая помогала нам в прошлом. Я говорю вам, они могут ускориться и добиться большего прогресса”.
Ноа не знала, как ответить. Конечно, стремление ускорить выполнение работ было бы весьма красноречиво по поводу скорости, с которой они выпускали на рынок новые продукты. Большинство их экспериментов провалились, что помешало им создать продукт и функциональность, которые никому не были нужны. Однако выяснить, что нужно клиентам, оказалось довольно сложно.
“Я не верю, что увеличение числа сотрудников ускорит нашу работу, Айко”, - начала она.
Айко покачал головой и перебил: “Послушайте, если мне нужно напечатать в два раза больше журналов, то добавление еще одной машины решит проблему. Ваши команды сейчас выпускают программное обеспечение каждые две недели, поэтому, если мы добавим еще две команды, мы легко сможем сократить это время вдвое”.
“Но, Айко, работа, которую мы выполняем, не так проста, как печать журнала”, - возразила Ноа.
“Представьте, что ваш журнал постоянно менялся. Представьте, что после печати каждой партии журналов в них приходилось вносить множество изменений. Представьте, что печатный станок, который вам нужен, никогда раньше не создавался, а люди, которые вам понадобятся для создания этого пресса и печати журналов, никогда раньше не работали вместе. Конечно, добавление людей только замедлит процесс.”
Поняв, что метафора, которую она использовала, ему не помогла, Айко покачал головой. “Следующее, что ты мне скажешь, это то, что мы будем работать быстрее, если сократим численность команды”, - рявкнул он на нее.
Ну, на самом деле...” - подумала Ноа.
________________________________________________________________________
Добавление команд для работы над продуктом часто приводит к снижению отдачи. В какой-то момент это создает дополнительные зависимости, отдельные точки отказа, проблемы с коммуникацией, потребности в согласовании и больше общего хаоса, чем решает, часто выводя все усилия из-под контроля. Большая проблема с масштабированием заключается в том, что к нему подходят не как к эксперименту, а скорее как к чему-то с заданным результатом.
Фундаментальная проблема заключается в том, что эффективное масштабирование - сложная задача. Это зависит от контекста, и это не то, что вы можете скопировать у кого-то другого. Поэтому вместо этого проведите несколько экспериментов, чтобы выяснить, как масштабировать в вашем конкретном и уникальном контексте. При определении таких экспериментов можно применять те же стратегии тестирования и обучающие карточки, которые мы обсуждали в главе 18 “Как разрабатывать и оценивать эксперименты и тесты”. Вот несколько примеров:
- Мы считаем, что мы можем естественным образом расширить команды, добавив людей в существующую команду. Как только они освоятся, что можно измерить по среднему времени выполнения задачи, мы можем нанять еще одного нового сотрудника без снижения достигнутой ценности, измеряемой <метрикой>.
- Мы считаем, что наши старшие разработчики могут взять двух учеников, которые за четыре спринта вырастут до уровня, достаточного для создания собственной команды. Мы гарантируем их способность проектировать, внедрять и развертывать функцию XYZ, чтобы подтвердить это предположение.
- Мы считаем, что сокращение численности команды до трех человек позволит нам добиться большей отдачи за более короткий промежуток времени, который может быть измерен с помощью <метрики>.
- Мы считаем, что наличие одного владельца продукта для нашего цифрового продукта, работающего со всеми пятью цифровыми командами, повысит скорость принятия решений, управление зависимостями и ценность, получаемую за спринт. Чтобы проверить это предположение, мы проведем эксперимент в течение следующих двух спринтов, в котором мы сокращаем число существующих пяти владельцев продукта до одного владельца продукта для всех пяти команд. Мы измерим <метрику> и будем правы, если <условие>.
Обратите внимание, что каждый из этих экспериментов по масштабированию описан как тест с желаемыми результатами и поддающимися измерению результатами. Результаты экспериментов затем могут быть проверены и адаптированы для принятия решений, основанных на данных, в вашем конкретном и уникальном контексте.
Не существует таких вещей, как лучшие практики в разработке продукта. Есть только те практики, которые адекватны в определенном контексте.
Масштабирование ставит перед владельцем продукта ряд уникальных задач:
- Поддерживать тесные отношения со всеми разработчиками становится сложнее по мере увеличения числа вовлеченных людей.
- Наличие большого количества команд, работающих над продуктом, может привести к увеличению времени, затрачиваемого на понимание уникальных проблем и возможностей, которые предлагает технология.
- Четкое определение элементов невыполненной работы по продукту - задача не для одного человека. Это предполагает взаимодействие, обсуждение, вопросы и ответы. Повышение уровня понимания людьми проблемы, которую необходимо решить, требует времени, но времени на общение со всеми становится все меньше.
- Порядок составления списка невыполненных работ по продукту основан на многих элементах, таких как ценность, риск, возможности, сроки, зависимости и другие. Когда несколько команд работают с одним списком невыполненных работ по продукту, может стать сложнее обеспечить занятость всех. На практике это кажется важным для многих людей. Однако заключается ли в том, чтобы все были заняты, чтобы быть отличным специалистом по продукту?
- Сделать видение, стратегию и цели, которые должны быть достигнуты, прозрачными и хорошо понятными для всех участников, может стать сложнее.
Итак, как эффективно справляться с этими проблемами? Давайте сначала рассмотрим распространенный антипаттерн, используемый во многих организациях, прежде чем перейти к некоторым альтернативным решениям.
Типичный антипаттерн для масштабирования людей и команд
Как правило, когда продукт становится успешным, когда он набирает обороты и когда мы чувствуем необходимость добавить больше людей в команду (команды), реализуется общий антипаттерн масштабирования. Помните, что вы находитесь в конкретной и уникальной ситуации, поэтому следующее может относиться к вам, а может и не относиться. Однако это пример, который вы, скорее всего, узнаете. Визуальное представление следующей истории представлено на рисунке 19.1.
Представьте, что вы единственный владелец продукта, и вы владеете одним продуктом и управляете им. У вас также есть одна Scrum-команда для работы и один список невыполненных работ по продукту для управления. Все отлично и идет гладко. После некоторых первоначальных успехов с продуктом и работы со своей командой вы обеспечили дополнительное финансирование и теперь рассматриваете возможность найма большего числа разработчиков. Допустим, вы решились на это, и теперь у вас есть четыре команды разработчиков, работающих над вашим одним продуктом.
Вы по-прежнему являетесь единственным владельцем продукта, но испытываете некоторую перегруженность. Вы получаете много вопросов от разработчиков. Вам нужно многое объяснить о видении, стратегии, целях и функциях для создания. Вы чаще встречаетесь с заинтересованными сторонами и проводите больше времени с разработчиками над доработкой бэклога продукта. В какой-то момент вы слышите, как кто-то говорит, что “каждой команде нужен владелец продукта”. Теперь у вас сложилось впечатление, что каждой Scrum-команде нужен свой собственный владелец продукта, и, таким образом, вы решаете нанять одного (менее опытного) владельца продукта для каждой команды. Эти владельцы продуктов теперь установлены между вами и командами.
Вы думали, что добавление большего числа владельцев продуктов облегчит вам жизнь, но обнаруживаются новые и дополнительные проблемы. Вам становится все труднее эффективно тратить свое время. Вы оказываетесь в тупике между проведением времени с заинтересованными сторонами и обучением новых владельцев прокси-продуктов продукту, проблемам клиентов, рынку, а также вашему видению и стратегии.
Вы также замечаете, что в командах нарастает напряжение. Владельцы продукта-посредника перегружены командами, которые привыкли взаимодействовать с вами напрямую, будучи дальновидным, представителем клиентов, способным сотрудничать и принимать решения владельцем продукта, которым вы были. Они сообщают, что становятся медленнее, более зависимыми от других и испытывают проблемы с интеграцией.
Чтобы повысить наглядность выполняемой работы, каждый владелец продукта proxy создал журнал невыполненных работ на уровне команды для своих команд. В то же время теперь вы отвечаете за управление общим списком невыполненных работ по продукту. В результате вам теперь также необходимо тратить значительное количество времени на координацию и синхронизацию вашего списка невыполненных работ с списками невыполненных работ на уровне команды. Кроме того, вы должны интегрировать командные дорожные карты с вашей дорожной картой продукта. Количество совершаемых ошибок растет, необходимы дополнительные встречи для общения и согласования позиций, но напряженность продолжает расти.
“Нам нужны более опытные владельцы продуктов”, - неоднократно говорят вам команды и заинтересованные стороны.
Звучит знакомо? За последнее десятилетие нас попросили помочь в десятках организаций, которые столкнулись с этой проблемой или с ее небольшими вариациями. Многие компании внедряют Scrum, руководствуясь неправильными принципами. Например, фраза “Каждой Scrum-команде нужен владелец продукта” не означает, что каждой Scrum-команде нужен свой собственный эксклюзивный владелец продукта. Как раз наоборот; вполне вероятно, что владельцу продукта потребуется несколько команд для работы над своим продуктом, особенно если это большой и сложный продукт. Многие организации уже представляют собой сложные системы со сложными продуктами, сложными структурами и архитектурами. Усложнение структуры приводит к хаосу. Добавление нескольких владельцев продукта во многом похоже на добавление сложности, а не на ее уменьшение. Итак, в целом, наличие крупных продуктов с несколькими владельцами продукта просто не очень полезно.
Лучший подход к масштабированию сотрудников и команд
Как мы упоминали ранее, ваша ситуация уникальна — и, вероятно, довольно сложна. Не существует волшебного решения или "серебряной пули" для исправления этой ситуации. Эта глава о масштабировании является частью позиции экспериментатора не просто так — потому что вам нужно будет провести эксперименты и узнать, что лучше всего работает в вашем уникальном контексте.
Есть несколько моментов, которые следует учитывать:
Упрощение — есть только один список невыполненных работ по продукту. Устраните отставания отдельных команд. Наличие нескольких списков невыполненных работ по одному продукту создает зависимости, необходимость согласования и синхронизации списков невыполненных работ. Это скорее добавляет сложности, чем уменьшает их. Напротив, наличие только одного списка невыполненных работ по продукту, заказанного владельцем продукта для решения проблем и удовлетворения потребностей клиентов, приводит к большему сосредоточению на результатах, которые должны быть достигнуты, и меньшему - на результатах, которые должны быть доставлены.
Наличие одного списка невыполненных работ по продукту также повышает прозрачность, проясняя направление развития продукта и цели, над достижением которых работают команды. Это позволяет командам найти общий язык, и теперь каждая команда может спросить себя: “Как мы можем внести свой вклад в достижение этой цели?”
Действия по управлению продуктом, выполняемые разработчиками. Еще один шаг, который необходимо предпринять, - определить доверенного владельца продукта с наибольшим потенциалом и назначить его учеником Владельца продукта. Однако не помечайте этого человека как владельца продукта или ученика владельца продукта. Они не являются владельцами продукта; они учатся у Владельца продукта. Они выполняют работу, связанную с управлением продуктом, поэтому вместо Владельца продукта называйте их разработчиком.
Scrum использует термин разработчик для обозначения людей, которые вносят свой вклад в создание продукта. По нашему опыту, этот термин несколько сбивает с толку, поскольку разработчик также используется для описания того, кто создает программное обеспечение или код, то есть инженера—программиста. Однако в контексте Scrum роль разработчика не ограничивается разработкой программного обеспечения. Разработчиком в Scrum может быть любой, обладающий любыми навыками, необходимыми для создания, продажи, продвижения на рынок или доставки продукта.
Итак, рассматривайте разработчика в Scrum как “разработчика продукта”.
Таким образом, ученики могут помочь Scrum-команде в качестве разработчика. Они являются членами группы (product) Разработчики, однако, не сосредоточены на создании программного обеспечения, кода или тестов. Вместо этого они сосредоточены на выполнении работы по управлению продуктом. Они могли бы, например, внести свой вклад в работу Scrum-команды, регулярно обзванивая клиентов, проводя конкурентные и рыночные исследования, участвуя в семинарах по проектированию или решению проблем, проводя анализ данных и презентацию или выполняя любые другие действия по управлению продуктом.
Как и в любой модели обучения подмастерьев, у подмастерьев должен быть четкий путь обучения, и они должны выполнять конкретные задачи и обязанности под наблюдением владельца продукта. Однажды у них может появиться свой собственный продукт, но пока они являются разработчиками, уделяющими особое внимание управлению продуктами и добавляющими навыки управления продуктами в Scrum-команду.
Важной целью этой настройки является создание самодостаточных и самоуправляемых команд. Когда Scrum-команды работают как зрелые, высокопроизводительные и самоуправляемые команды, они должны быть способны решать более широко определенные задачи. Они должны иметь возможность напрямую взаимодействовать с заказчиками и пользователями, искать проблемы для решения и определять эксперименты для проведения.
Задумайтесь на мгновение над этим вопросом: предлагаю ли я команде решать проблемы или предлагаю им задачи для выполнения? Если ваш ответ больше относится к задачам, которые необходимо выполнить, может оказаться опасным даже рассматривать возможность масштабирования. Не усложняйте ситуацию масштабированием. Сначала создайте самоуправляемую команду, а затем рассмотрите возможность масштабирования, если это необходимо.
Подходы к масштабированию продукта или услуги
Во время одного из наших подкастов мы говорили о масштабировании с большой группой владельцев продуктов и менеджеров по продуктам. Мы показали им три разных изображения дорог и дорожного движения, как показано на рисунке 19.2. Затем мы спросили их, какое изображение имеет наибольший смысл в отношении масштабирования и почему. Интересно, что мы получили несколько разных ответов.
Некоторые люди сказали, что картинка А, изображающая переполненный перекресток, имела для них наибольший смысл, потому что на ней изображен полнейший хаос. Они воспринимали масштабирование как наличие множества команд, множества различных интересов, множества различных продуктов и сотен людей в небольших и крупных командах, пытающихся продвигать свою собственную цель, но мешающих в процессе другим. Для них масштабирование казалось большой тарелкой спагетти — перепутанной кашей.
Другие люди сочли, что картинка В была лучшей аналогией. На ней изображено огромное пересечение автомагистралей, которые часто встречаются вблизи многих городов США. Если вы не сталкивались с ними воочию, вы наверняка видели их в фильмах. Эти массивные перекрестки состоят из шести или более полос движения, въездных и выездных съездов, надземных и подземных переходов и т.д. Они созданы для решения проблем с дорожным движением, но во многих случаях проблемы с дорожным движением все еще существуют. Люди, которые сочли эту картину хорошей метафорой масштабирования, заявили, что их организация создала массу инфраструктуры, проводила совещания и сессии согласования и добавила в рабочий процесс новые методы решения проблем масштабирования. Другими словами, организация создала очень сложную структуру и способ работы, что сделало ее еще более сложной, чем она была раньше. Она применила очень сложное решение сложной проблемы.
Рисунок C иллюстрирует прямую и пустую дорогу через тихий лес. Этот рисунок был выбран лишь горсткой людей. Но именно эта метафора имеет для нас наибольший смысл. Масштабирование - это простота. Масштабирование - это не добавление слоев и сложных структур. Речь идет о том, чтобы упростить работу, улучшить поток ценности и сохранить скорость. Поэтому масштабирование в большинстве случаев должно быть обсуждением удаления накипи, а не увеличения масштаба. Не принимайте большую сложность. Не боритесь со сложностью с помощью сложных решений — найдите простые. Речь идет о возвращении к основам, к тому, что важно, об оптимизации предоставления ценности.
Сосредоточьтесь сначала на продукте, затем на людях и командах
Когда люди говорят о масштабировании, это часто происходит потому, что у них в компании работает много людей. Они говорят о масштабировании команд, расширении возможностей и о том, как эффективно организовать всех этих людей в команды.
Особенно среди Agile-тренеров и Scrum-мастеров масштабирование, по-видимому, стоит на первом месте, что имеет смысл, поскольку эта перспектива фокусируется на человеческой и процессной стороне масштабирования. Как нам вырастить мотивированную команду? Как мы справляемся с дефицитом навыков? Что становится основой? Как они интегрируют работу в единый продукт?
Когда менеджеры и топ-менеджеры компаний говорят о масштабировании, они часто указывают на важность согласования. Откуда мы знаем, что все работают над правильными вещами? Конечно, они заняты, но эффективно ли это? Какие прогнозы мы можем сделать? Каких целей мы не достигаем и почему нет? Какими зависимостями необходимо управлять? Что мы можем пообещать клиентам и совету директоров?
Мы редко говорим о третьем аспекте масштабирования. Это тот аспект, о котором мы, как специалисты по продукту, должны говорить. Речь идет о масштабировании самого продукта. С этой точки зрения мы не говорим об организации людей в команды. Мы не говорим о согласовании работы или управлении зависимостями. Мы говорим о масштабировании продукта. Как мы можем увеличить доходы или повлиять на клиентов? Как мы можем вывести наш продукт на новые рынки? Как мы можем повысить нашу эффективность без увеличения сложности или затрат?
Например, продукты "программное обеспечение как услуга", как правило, очень хорошо масштабируются, если они созданы правильно.
Но почему бы нам не поговорить о масштабировании продукта? Возможно, это потому, что мы являемся частью более крупной организации, возможно, корпоративного уровня, и может показаться, что нам нужна структура для структурирования того, как сотрудники будут сотрудничать. Или, может быть, это потому, что мы имеем дело с большой сложностью процессов, инструментов, продуктов и других структур в нашей организации. Кажется, что мы часто пытаемся решить сложные проблемы, создавая комплексные решения, и ваша организация была бы не первой, кто столкнулся бы с такими проблемами, как слишком много зависимостей внутри команд и между ними, зависимость от знаний и опыта менеджеров по продуктам... или, возможно, медленное принятие решений?
Итак, когда вы говорите о масштабировании, обязательно ориентируйтесь на перспективу. Вы говорите об одном и том же виде масштабирования? Что нам показалось довольно интересным, так это то, что большинство людей, обсуждая эту тему, используют фреймворки масштабирования. Но, если масштабирование продукта - это то, о чем мы, как специалисты по продукту, должны заботиться больше всего, тогда почему мы тратим так много времени на разговоры о таких фреймворках, как LeSS, Nexus и SAFe? Почему мы больше не говорим об эффективном масштабировании продукта?
Восемь эффективных стратегий масштабирования продукта
Давайте рассмотрим восемь стратегий, которые можно использовать для масштабирования продукта. На рисунке 19.3 представлены различные стратегии масштабирования.
На дворе 1992 год, и Microsoft выпускает первую версию Microsoft Office. Почему? Это произошло не потому, что клиенты выразили в этом потребность. Excel устранял конкурентов (Lotus 123), но Word изо всех сил пытался конкурировать с WordPerfect. Создав набор продуктов, Microsoft создала линейку продуктов, настройка которой не требовала больших дополнительных усилий, но при этом предлагала клиентам уникальное ценностное предложение. Если вы уже использовали Excel, то почему бы не купить и Word? С тех пор Microsoft неоднократно использовала этот метод, который называется пакетированием (бандлингом), как способ масштабирования продукта. Распространенными примерами продуктов, использующих этот принцип масштабирования, являются Microsoft, Adobe, McDonald's, Burger King и универсальные интернет-провайдеры, телевизионные и телефонные компании.
Перенесемся на 3 года вперед, и авиакомпания EasyJet поступает с точностью до наоборот. Она берет роскошь авиаперелетов и сокращает ее до предметов первой необходимости, в процессе отказываясь от продукта. Вы все еще можете получить дополнительные услуги и удобства, но теперь это “настоящие” продукты. Такой способ масштабирования продукта обычно называется анбандлингом. Этот метод используется, например, различными бюджетными авиакомпаниями, веб-сайтами туристических компаний и отелей, а также производителями автомобилей.
Вы заметили этот большой черный ящик на корме великолепного фрегата Королевских ВМС Нидерландов? Эта штука - детектор баллистических ракет дальнего радиуса действия SMART-L. Вы можете разместить фрегат в удобном месте и защитить регион от угрозы обрушения на вас ракет, если они прилетят из космоса. Отличный продукт, не так ли? Что ж, оказывается, вы не можете разместить фрегат повсюду на земле. На этой планете есть несколько мест, где мы найдем то, что называется “земля”. Поэтому Thales Group (создатель такой технологии) распределяет продукты по доменам. Имитируя радар SMART-L, существует также наземный радар L-диапазона. Thales рассматривает его как отдельный продукт. Распределяя продукт по доменам, компания может оптимизировать свои продукты по различным параметрам и переменным, используя при этом одну и ту же технологию. Это помогает упростить очень, очень сложный продукт.
Используемая технология также может быть использована для масштабирования продукта. Можно утверждать, что есть преимущества в поддержании единой кодовой базы для любой платформы, на которой вы развертываете. Но, как продемонстрировала Electronic Arts со своей популярной игрой The Sims, создание уникальных возможностей на разных платформах может принести огромную пользу. Это может быть способ масштабирования продукта для различных целевых аудиторий, отраслей или опыта клиентов.
Компания TomTom начала с одного продукта - культовой навигационной “коробки” на приборной панели вашего автомобиля. В течение нескольких лет они выпустили множество различных вариантов устройства, каждый из которых ориентирован на определенную нишу рынка. Внутри компании вариантов было еще больше, потому что в некоторых продуктах использовалось различное оборудование и использовались услуги нескольких поставщиков. Конечно, это создало дополнительную сложность в продуктовом портфеле TomTom, но также дало возможность командам предлагать уникальные решения.
Платформинг - это противоположная стратегия создания вариантов продукта. При использовании стратегии платформинга различные компоненты продукта интегрируются в одну платформу. Примерами таких продуктов являются Amazon AWS, Google Cloud и Facebook. Эти продукты могут использоваться как платформа внутри компании или продаваться как продукт за ее пределами. Менеджеры по продуктам не могут достаточно часто задавать себе следующий вопрос: что мы можем убрать из продукта? Создание продуктов на платформе помогает уменьшить зависимость, обеспечивает более простую и стандартизированную интеграцию и предлагает альтернативные возможности для бизнеса.
Канадская робототехническая компания сменила стратегию с промышленной робототехники на автономных автоматизированных работников, ориентируясь на новый рынок. Компания использовала свои знания, опыт и технологии для создания складских роботов. Компания объединила своих относительно простых промышленных роботов с данными, искусственным интеллектом и концепциями машинного обучения, превратив их в “умных сотрудников” склада (роботов). Эти роботы-сотрудники (которые никогда не устают) используют обучающие алгоритмы для прогнозирования моделей заказа продукции на предстоящие недели. О, и они автоматически уступают дорогу и людям тоже.
Окончательный способ масштабирования вашего продукта мы видели на Picnic. Picnic - это компания, которая стала невероятно успешной как служба доставки продуктов "прямо к вашему порогу", потому что она интегрировала всю цепочку поставок и вышла непосредственно к потребителю. Это масштабирует продукт в том смысле, что риски и маржа цепочки теперь поглощаются прибылью и убытками самого продукта. Этот способ масштабирования называется стратегией масштабирования канала.
Как владельцы продуктов способствуют масштабированию продукта
Работая в корпоративной компании, вы можете чувствовать себя всего лишь маленьким винтиком в большом механизме. Однако считайте, что владелец продукта - это свечи, создающие искру в этом двигателе. Наличие отличных владельцев продукта имеет огромное значение для продукта, для его клиентов и пользователей, для команд, работающих над продуктом, и для организации, предоставляющей его. Итак, участвуйте в этих разговорах о масштабировании вашего продукта; предлагайте рекомендации, видение и направление. Вот еще несколько вещей, которые вы можете сделать для эффективного масштабирования:
- Поделитесь с разработчиками знаниями о вашем бизнесе, клиентах, пользователях, рынке и предметной области. Помогите им со временем расширить свои знания.
- Обеспечьте прямую коммуникацию и обратную связь между клиентами, пользователями и Scrum-командой. Не будьте единственным контактным лицом. Объединяйте людей.
- Убедитесь, что видение продукта и стратегия понятны всем. Почаще делитесь своим видением.
- Убедитесь, что есть четкая, измеримая и мотивирующая цель продукта, над которой нужно работать.
- Убедитесь, что существует четкая, ориентированная на достижение целей дорожная карта, известная заинтересованным сторонам и командам.
- Убедитесь, что список невыполненных работ по продукту ясен, упорядочен, виден, прозрачен и доступен для всех.
- Уделите необходимое количество времени различным заинтересованным сторонам и разработчикам.
- Пригласите на работу Scrum-мастера, который сможет тренировать, наставлять и оказывать содействие команде, заинтересованным сторонам и организации.
- Проводите надлежащий профессиональный Scrum при поддержке отличного Scrum-мастера.
Ключевые уроки и инсайты
На этом завершается часть IV, в которой вы изучили позицию экспериментатора. В этой части вы узнали, как великие владельцы продуктов-экспериментаторов подходят к инновациям, тестированию и экспериментам. Вы изучили различные подходы к внутренним инновациям и инновациям, внедренным извне, и узнали, как каждый подход обеспечивает разные результаты и понимание.
Вы также изучили, как инновации в бизнес-модели, проведение маркетинговых исследований и обучение у других организаций за пределами вашей отрасли могут стимулировать инновации в вашем продукте. Вы изучили кривую истинности, модель, помогающую вам выбирать правильные виды экспериментов, и узнали, как их проектировать, используя тестовые карточки и обучающие карточки. Наконец, вы изучили различные подходы к масштабированию и удалению накипи с выигрышных продуктов для будущего роста и то, как масштабирование часто неправильно ориентировано больше на людей и команды, чем на масштабирование продукта. Чтобы создавать выигрышные продукты на рынке, владельцам продуктов и менеджерам по продуктам необходимо применять любознательный, обучающийся и непредубежденный подход к управлению продуктами. Им необходимо использовать данные, инсайты, тестирование и эксперименты для подтверждения идей и предположений. В некоторых случаях сгодится ваше внутреннее чутье. Однако в большинстве случаев эксперименты и валидация - это правильный путь, если вы хотите максимизировать ценность своего продукта на рынке.