Перезагрузка. Руководство McKinsey по преодолению конкуренции в эпоху цифровых технологий и искусственного интеллекта - читать бесплатно онлайн полную версию книги автора Lamarre (ч. 3)

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

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

ПРИМЕР СПЕЦИАЛИСТА ПО ИССЛЕДОВАНИЮ ДАННЫХ

IC - индивидуальный вклад

EL - Экспертное руководство

PL - руководство персоналом

EX - Executive

IC 1

IC 2

Младший специалист по исследованию данных Ассоциированный специалист по исследованию данных

IC 3

IC 4

IC 5

Специалист по анализу данных

Старший специалист по анализу данных Ведущий специалист по анализу данных

Заместитель директора, данные

Наука

Директор, данные

Наука

Старший директор, наука о данных

Главный специалист по науке о данных

Менеджер по науке о данных

Старший менеджер по науке о данных

PL 9

EL 9

PL 8

EL 8

PL 7

EL 7

PL 6

EL 6

EX 10

Директор по науке о данных

VP,

Наука о данных

Главный специалист по данным и аналитике (CDAO)

ПРИЛОЖЕНИЕ 12.1

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

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

Создайте цифровой "буткемп на рампе".

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

Такое обучение, как правило, носит достаточно индивидуальный характер, поэтому его лучше всего разрабатывать внутри компании. Отдел цифровой трансформации часто составляет эту программу и опирается на команду L&D компании, чтобы помочь сформировать и управлять обучением. Как правило, такое обучение проводится в формате буткемпа (интенсивного, в течение всего дня, в течение недели), чтобы дать старт запуску капсул (см. пример типичного расписания буткемпа в Приложении 12.2).

Создайте учебные программы для талантливых специалистов в области цифровых технологий

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

Пример запуска стручка bootcamp

Командные рабочие сессии Размышления

ДЕНЬ 1

ДЕНЬ 2

ДЕНЬ 3

ДЕНЬ 4

ДЕНЬ 5

Начало (приветствие руководства, почему мы здесь, более широкая история преобразований)

Определите рабочие соглашения/нормы для команды

Определение MVP (согласование определения MVP, составление сюжетной карты, проект MVP продукта)

Понять, что такое devops и как его использовать (конвейер CICD и платформа для разработчиков).

Поделитесь с руководством (демонстрация работы команды, сбор отзывов от руководства)

Ретроспектива учебно-тренировочного лагеря

Обзор и моделирование Agile (Согласование определения Agile, менталитета и поведения, Agile-практик для команд.

Моделирование)

Составление карты заинтересованных сторон (схема взаимодействия с заинтересованными сторонами, разработка карты заинтересованных сторон)

Создание бэклога (согласование определения бэклога, практика написания пользовательских историй)

Определите каденцию спринта

Создание дорожной карты продукта (согласование определения дорожной карты продукта, подготовка проекта дорожной карты продукта)

Определение миссии/видения (согласование миссии, разработка заявления о видении)

Планирование спринта 1 (пересмотр пользовательских историй для спринта 1, пересмотр оценки, уточнение критериев приемки)

Определение готового/определение сделанного

Доработка пользовательских историй для 2-3 спринтов (оценка историй, уточнение критериев приемки, планирование 2-3 спринтов)

(Необязательно)

Время командной работы (команда продолжает дорабатывать артефакты, внедряет модель взаимодействия с заинтересованными сторонами, планирует события спринта, настраивает инструменты командной работы)

Согласование OKR (Согласование определения OKR, OKR

практика письма, составление командных ОКР)

Оценка (Что такое точки рассказа? Методы оценки и планирование покера, практика оценки пользовательских историй)

Понимание нашей технологической среды и архитектуры данных (что важно для целевого цифрового решения).

Подготовка к демонстрации (артефакты, созданные в течение недели, формат демонстрации)

Ретроспектива

Примечание: Команды могут изменять это расписание в зависимости от наличия команды, часовых поясов и

очная/виртуальная/гибридная модель работы

(Необязательно)

Время командной работы (доработка артефактов, созданных в течение дня)

(Необязательно)

Время командной работы (доработка артефактов, созданных в течение дня)

(Необязательно)

Время работы в команде (настройка инструментов для совместной работы)

(Необязательно)

Время командной работы (сухой прогон демо-версии, настройка логистики демо-версии)

При разработке маршрутов обучения важно различать семейства навыков. Не поддавайтесь искушению рассматривать все технические роли как взаимозаменяемые ("они все инженеры") и предоставлять им одинаковое меню вариантов обучения. Пути обучения фронтенд-разработчика, владельца продукта или UX-дизайнера заметно отличаются друг от друга. Очевидно, что эту работу могут выполнять только самые старшие технологи. Пути обучения также должны быть организованы по уровню квалификации и согласованы с карьерным ростом и вознаграждением.

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

Поскольку навыки, развиваемые в таких программах, как правило, не являются специфическими для вашей компании, лучше всего передать обучение на аутсорсинг таким организациям, как Coursera, Udacity, Cloud Academy и Udemy, которые предлагают широкий выбор программ. Многие компании предоставляют своим цифровым сотрудникам ежегодную стипендию на обучение и предоставляют им возможность самим найти лучшее предложение для своих конкретных нужд.

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

Переквалификация с помощью буткемпов

Переквалификация - это процесс переобучения человека для другой роли. Это может быть серьезным мероприятием, которое может занять от шести до 12 месяцев и более (в это время сотрудники не смогут выполнять свои повседневные обязанности). В связи с этим загрузочные курсы кодирования являются одним из наиболее эффективных способов развития технических навыков (например, JavaScript, CSS, C#, Ruby, Python) для различных ролей (например, front-end разработчик, back-end разработчик).

Примерный путь обучения инженера по облачным технологиям

Специфика ролиСпецифика платформы Способы работы

Повышение уровня компетентности

НОВИЧОК

КОМПЕТЕНТ

ЭКСПЕРТ

УЗНАТЬ

Что такое Контейнеры для ServerlessCloud riskEfficient Cloud Cloud? производство вычисления разработка

Стоимость облака

Виртуализация и Применение облачных Безопасность облачных управлениеГибридное развертывание облачных технологий с учетом особенностей бизнеса Модернизация моделей сценарии Эластичные CSP-приложения с

Облако Anthos

Введение в DevOpsCloud Cloud SREИнфраструктура и контейнерыРазработка

Ведение журнала, Надежность CSP CSP CloudEssential CSPmonitoring , andCloud fundamentals Облачная инфраструктура - наблюдаемость в инфраструктуре

масштабирование инфраструктуры и Облако CSP

автоматизация

Основные сведения о CSP Начало работы Привлечение

Инфраструктура Terraform для заинтересованные стороны

Фонд Начало работы Облако CSP

с Kubernetes

двигатель

Основные принципы CSP Scrum 101

Инфраструктура

Основные услуги Работа с

кросс-функциональные MVP-мышление

команды

Решение проблем

Принятие основ Agile

Определите постановку бизнес-задачи для реализации

Создание и управление облачными ресурсами

Установка и настройка облачной среды в CSP Cloud

Развертывание и управление облачными средами с помощью CSP Cloud

Облачная архитектура: Разработка, внедрение и

APP

Облако Выполните Управление

основополагающий Автоматизация Оптимизация затрат Инфраструктура Инфраструктура для CSP

задачи Облако CSP с Kubernetes

Terraform Движок

Наиболее эффективным подходом является сотрудничество со специализированными компаниями, предлагающими подобные буткемпы, такими как Turing School, Hack Reactor, CODE и LeWagon. Лучшими кандидатами для участия в таких программах обычно становятся люди, обладающие эмпатией, смелостью и сильным мышлением роста, способные решать логические задачи и страстно любящие программирование. Некоторые из лучших инженеров-программистов McKinsey вышли из таких программ. Тем не менее, переквалифицировать большое количество людей сложно и дорого. Программы переквалификации обычно используются для талантливых людей, в которых компания хочет инвестировать. Они могут быть особенно эффективны для компаний с количественным или инженерным составом.

Ниже приведен набор вопросов, которые помогут вам определить, какие действия следует предпринять:

Достаньте свою "дорожную карту" талантов - такая же ли она подробная и всеобъемлющая, как и ваша технологическая "дорожная карта"?

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

Развились ли ваши HR-практики для поиска, найма и удержания лучших цифровых талантов (например, предварительный отбор и предложение за четыре недели, убедительная EVP и т. д.)?

Признана ли ваша компания местом, где хотят работать лучшие таланты?

Верят ли ваши лучшие сотрудники в то, что они смогут вырасти и построить многообещающую карьеру в вашей компании (проверьте показатели оттока лучших сотрудников - знаете ли вы риск "ключевых людей")?

Есть ли у вас карьерная лестница, в которой ценятся отличные технологи в той же степени, что и в той, в которой ценятся отличные менеджеры?

Что вы делаете, чтобы помочь своим техническим специалистам освоиться в бизнесе и продолжать развивать их мастерство?

Принятие новой операционной модели

Изменение архитектуры организации и управления для обеспечения быстроты и гибкости

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

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

Ну, а встать и поднять сотни, если не тысячи, из них - это уже другая история.

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

Глава 13: От выполнения agile к тому, чтобы быть agile. Понимание того, что требуется помимо базовых изменений в процессах для того, чтобы agile pods работали с максимальной эффективностью и отдачей.

Глава 14: Операционные модели, поддерживающие сотни agile pods. Три ведущих варианта операционных моделей, которые появились, чтобы перейти от горстки гибких команд к поддержке сотен таких команд на всех уровнях предприятия: цифровая фабрика, продукт и платформа и гибкость в масштабах предприятия.

Глава 15: Профессионализация управления продуктами. Владельцы продуктов - эффективные руководители agile-подразделений. Они являются стержнем любой операционной модели и нуждаются в приоритетном внимании и инвестициях.

Глава 16: Дизайн клиентского опыта: Волшебный ингредиент. Те компании, которые действительно ориентированы на клиента, вкладывают средства в понимание мотивов пользователей и воплощают их в опыт, который удовлетворяет потребности и доставляет удовольствие.

Примечание

1. Daniel Brosseau, Sherina Ebrahim, Christopher Handscomb, and Shail Thaker, "The journey to an agile organization," McKinsey.com, May 10, 2019, https://www.mckinsey.com/capabilities/people-and- organizational-performance/our-insights/the-journey-to-an-agile- organization; "The drumbeat of digital: Как играют команды-победители", McKinsey Quarterly, 21 июля 2019 г., https://www.mckinsey.com/ capabilities/mckinsey-digital/our-insights/the-drumbeat-of-digital-how- winning-teams-play.

От

"делать

agile

" к "быть

agile

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

-Тина Фей

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

Многие компании экспериментируют с agile в рамках ИТ-организации или за ее пределами. При правильном внедрении даже небольшое количество agile-команд может быстро принести пользу (см. Рисунок 13.1). Но компании сталкиваются с проблемами, когда они слишком много внимания уделяют agile как набору процессов и недостаточно - как новому способу определения приоритетов и концентрации ресурсов на главном. В таких ситуациях руководство Agile - это лучший подход к разработке

Сравнение эффективности работы опытных agile-команд с командами, использующими все остальные методы разработки

ДЕШЕВЛЕ

БЫСТРЕЕ

ЛУЧШЕ

Повышение производительности, единицы сложности1 на ЭПЗ/неделю

Уменьшите отставание от графика,

Проекты, не выпущенные в срок

Меньше остаточных дефектов,

Ошибки в программном обеспечении2

Agile:

+27%

Базовая линия без гибкости

Сбор и проверка данных для 1000+ выпусков ПО (технические характеристики, уровень персонала, этапы, уровень дефектов и т.д.).

Разработка исторического базового показателя эффективности на основе сложности и трудоемкости проекта

Ловкость: -30%

Сравнение с группой аналогов, состоящей из отдельных отраслевых проектов

Agile -70%

Единицы, обладающие большим количеством структуры или информации, часто в нескольких временных и пространственных масштабах

Проблема, приводящая к аварийному завершению работы программы или выдаче некорректных результатов

Источник: База данных отраслевого программного обеспечения Numetrics - 1 321 проект и аналитика с помощью запатентованного алгоритма нормализации (2021 год)

ПРИЛОЖЕНИЕ 13.1

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

Начнем с agile-методологий. Существует несколько разновидностей: scrum (по названию команды), kanban, SAFe (Scaled Agile Framework) и другие. Каждая из них имеет свой собственный язык, каденции и виды деятельности, что иногда приводит к жарким спорам о том, какая из них лучше.

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

Миссия с измеримыми результатами. Руководство дает каждому подразделению четкую миссию, основанную на общей цифровой "дорожной карте". Каждая миссия должна быть нацелена на конечные результаты (или ключевые результаты), которые можно измерить и которых группа может достичь в разумные сроки (в месяцах или кварталах, а не в годах).

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

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

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

По их словам: Освободите свои продуктовые отряды

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

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

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

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

Мы, безусловно, выиграли от этой модели, и мне не звонили люди в любое время дня и ночи с вопросами: "Что мне делать с этим проектом? Как мне принять это решение?" Они могли самостоятельно принимать решения по своим продуктам, при этом отчитываясь, чтобы мы были в курсе происходящего.

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

Том Век, ИТ-директор по корпоративным технологиям компании Johnson & Johnson

Три церемонии, которые имеют наибольшее значение для повышения эффективности agile

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

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

Определение миссии и OKR

Это самая важная церемония, потому что именно тогда руководство задает направление и устанавливает ожидания (см. №1 на иллюстрации 13.2). Миссия - это работа, которую подгруппа выполняет в течение года или более длительного срока. Руководство и владелец каждого подразделения разбивают миссию на цели и ключевые результаты (OKR) и устанавливают конкретные квартальные задачи для подразделения. OKR, как правило, приписываемые детищу покойного генерального директора Intel Энди Гроува, доказали свою эффективность в том, чтобы сфокусировать команды на воздействии, а не на деятельности. На практике это сложнее, чем кажется, и часто является основной причиной неудач в agile-развертываниях1. Подразделение преобразует свои цели в дорожную карту продукта или решения, в которой подробно описывается, как оно будет достигать ожидаемых результатов.

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

По их словам: OKRs - согласование того, что важно

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

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

Еще один важный момент, который сильно отличается от того, что было до них, - это то, что OKR делают акцент на том, что выглядит потрясающе, в отличие от того, что было бы безопасно и дало бы наиболее предсказуемый результат. Это перевернуло вопрос: "Хорошо, в течение следующих 90 дней, каких наилучших результатов мы могли бы достичь?"

Дело не в том, чтобы стараться выглядеть хорошо в своих KPI. Речь идет о стремлении быть удивительным. Мне нравится это сочетание: полностью реализовать амбиции, а затем, учитывая ограниченные возможности, решить, что мы будем делать в первую очередь? Что, по нашему мнению, двигает иголки, и какие иголки имеют наибольшее значение?"

-Дейдре Пакнад, соучредитель и генеральный директор компании WorkBoard

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

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

Продвижение и тестирование в ходе спринта

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

Пример ОКР

Программное решение для поддержки корпоративных служб управления персоналом

ЦелиКлючевые результаты Сроки

1.1

Радовать наших клиентов и каждый раз дарить им положительные моменты, которые имеют значение

1.2

1.3

2.1

Сокращение прямых затрат, связанных с продуктом

2.2

2.3

3.1

Улучшение удержания клиентов за счет стабилизации продукта

3.2

3.3

Разработка целостного, согласованного пользовательского опыта для всех трех персон со 100% реализацией пользовательских маршрутов

Доведите показатель выпуска безошибочных отчетов для клиентов до 95% с ~80%.

Увеличьте среднюю NPS до ~40 с ~13 для продукта V

Внедрение и стимулирование использования функций самообслуживания для снижения количества звонков на 10%.

Автоматизируйте отчеты для запросов, которые получают более 100 запросов на обслуживание в квартал

Сократите расходы на хостинг на 20 %.

Соответствие времени безотказной работы продукта SLA (99,995%) в течение всего года

Сократите количество критических инцидентов до 63 (с 83), а количество "горячих" исправлений - на 50% (с 4 до 2).

Добивайтесь того, чтобы количество принятых дефектов было ниже, чем количество разрешенных дефектов

ПРИЛОЖЕНИЕ 13.3

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

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

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

Конкретные церемонии спринта описаны на Рисунке 13.4.

Управление с помощью ежеквартальных обзоров деятельности (QBR)

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

Требуется время, чтобы продумать, как именно QBR будут встраиваться в цикл планирования компании - как QBR должны быть связаны со строгим планированием и бюджетированием? Как они должны быть скоординированы с ежеквартальными и ежемесячными заседаниями исполнительного комитета? Заменяют ли они обзоры инвестиционных комитетов?

QBR иногда критикуют за то, что они добавляют больше встреч в повестку дня руководства. При правильном применении это не так. На самом деле QBR могут сократить количество совещаний руководства на 75 %, как показано на примере одного из американских банков, приведенном в Примере 13.5.

Agile-церемонии

ЦЕРЕМОНИЯ

ОПИСАНИЕ

ОЖИДАЕМЫЕ РЕЗУЛЬТАТЫ

FREQUENCY

Бэклог

Элементы в бэклоге

Бэклог содержит ряд

Каждый спринт

рафинирование

приоритетны и

пользовательских историй, которые были

(2 недели)

отлажены, чтобы обеспечить

расставлены приоритеты, хорошо документированы

готовы к предстоящему

ed, и являются всеобъемлющими

спринт и 1-2

достаточно, чтобы потенциально сформировать

следующие спринты

бэклог следующего спринта

Планирование спринта

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

Приоритетные эпосы и истории1 распределяются по спринтам

Каждый спринт

объем работы, который

состоит из нескольких элементов в спринте

Были определены допущения, риски и зависимости

отставание

Ежедневные посиделки

Служит для оценки хода спринта и определения

У каждого члена команды есть 1+ задачи на день

Ежедневно

возможные барьеры

Статус пользовательских историй/задач был обновлен

Блокирующие устройства, если таковые имеются, были подняты

Обзор спринта

Возможность для команд представить новые функциональные возможности, разработанные в недавно завершившемся спринте

Обратная связь предоставляется для обновления или добавления будущих пользовательских историй

Каждый спринт

Sprint

Используется для оценки спринта

Сильными сторонами команды были

Каждый спринт

Ретроспектива

производительность и определить

определены

возможности улучшения

Решение проблем для команды

а также сильные стороны для

улучшения были

команда

определены и назначены

Ежеквартальный обзор деловой активности

Выполняется на старте проекта и каждый квартал для согласования OKR и дорожной карты продукта

Приоритетные эпосы и истории распределяются по спринтам

Были определены допущения, риски и зависимости

Каждый квартал

Установлены OKR на следующий квартал

Эпики: большие куски работы, обеспечивающие полную функциональность (включают несколько историй и охватывают несколько спринтов) Пользовательские истории: функция с точки зрения конечного пользователя

Упорядочение работы управленческих форумов в связи с внедрением QBR

Пример американского банка,

ДО ВНЕДРЕНИЯ QBR

по характеру управления

Форум ликвидирован

Форум сохранен

Готовность к изменениям

Форум изменен

Технологическая и производственная готовность

Операционный и технический риск

Финансирование

Измерение воздействия

Форумы

Часы

От:

30+

~75,000

Для:

~50,000

Изменения:

-75%

-35%

Ежемесячная линия автобуса. Финансовый обзор

Обзор бизнес-кейсов (ИТ-компонент)

Совещание по утверждению технологических лидеров

Совещание по бизнес рискам и контролю

Комитет по технологическим продуктам (x12)

Комитет по рассмотрению новых инициатив

Комитет по обзору BAU

Форум профильных экспертов

Обзор бизнес-кейсов (ИТ-компонент)

Прием проектов (на основе каталога услуг)

Идентификация заинтересованных сторон

Ежемесячный инвестиционный комитет

Готовность производства

Архитектурный совет

Консультативный совет по изменениям (x2)

Прямой впуск (x5) (по индивидуальным запросам)

ПОСЛЕ ВНЕДРЕНИЯ QBR

Scrum@Scale Cadence

Консультативный совет по изменениям (x1)

Архитектурный совет

Готовность производства

Ежеквартальный деловой обзор

Надзор за рисками на второй линии защиты

Ежемесячный финансовый обзор по направлениям деятельности

Руководящий комитет по стратегии развития направления бизнеса

Примечание

Джон Дорр, "Измерять то, что важно", Penguin Random House, 2018; Мэтт Фитцпатрик и Курт Стровинк, "Как измерить успех в цифровых технологиях? Пять показателей для руководителей компаний", McKinsey.com, 29 января 2021 года, https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/ how-do-you-measure-success-in-digital-five-metrics-for-ceos.

Глава 14.

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

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

-Стив Джобс

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

Чтобы поддерживать такое количество команд, компаниям нужна более формальная операционная модель. Эта глава посвящена трем фундаментальным моделям:

(1) цифровая фабрика, (2) продукт и платформа и (3) корпоративная гибкость. Все эти три подхода зависят от контекста и цифровой зрелости компании, но они используют одни и те же строительные блоки.

Организационные строительные блоки

Любая цифровая операционная модель состоит из трех организационных блоков (см. Рисунок 14.1):

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

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

Группа модулей продукта или опыта, работающих над одним и тем же сквозным путешествием (например, над приемом клиентов) или процессом (например, над оптимизатором доходности), называется доменом (как описано в главе 2). Домен обычно состоит из 10-20 подсистем и возглавляется владельцем домена.

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

Строительные блоки гибких операционных моделей

Клиенты/пользователи

Под

Практика или глава

Подборки продуктов (или путешествий)

Функции поддержки и управления

Платформенные капсулы

ЧТО МЫ ИМЕЕМ В ВИДУ

ПРИМЕРЫ

Под: Самодостаточная, кросс-функциональная команда, несущая сквозную ответственность за предоставление продукта, опыта или услуги.

Альтернативная таксономия: отряд, ячейка, agile-команда

(см. ниже)

Подборки продуктов (или путешествий): E2E-доставка услуги или решения клиенту или пользователю.

Оптимизатор урожайности

Рекомендации по ценообразованию

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

Привлечение клиентов Поиск продуктов на сайте

Платформенные модули: Объединение схожих технологических активов и людей,

Продукт данных Customer 360

и финансирование для предоставления услуг (многоразового использования) продуктовым/путешественным капсулам.

Набор для машинного обучения Основная система

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

Обеспечение инфраструктуры

Практика или глава: Организационная конструкция, отвечающая за профессиональное развитие сотрудников (отдельно от

дневное направление, выполняемое капсулой).

Альтернативная таксономия: гильдии, практические сообщества

Инженеры по обработке данных Инженеры-программисты

Владельцы/менеджеры продуктов

Платформы также обычно содержат 15 подсистем или более, и возглавляются менеджером платформы. Типичные платформы включают (a) платформы данных, такие как Customer 360, (b) корпоративные системы, такие как ERP или CRM, (c) платформы как услуги (PaaS), такие как приложения для аутентификации пользователей или алгоритмы машинного обучения, и (d) платформы инфраструктуры (IaaS), предоставляющие такие услуги, как облачные вычисления и хранение данных.

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

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

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

Варианты разработки операционной модели

По нашему опыту, существует три основных варианта построения гибкой операционной модели: (1) модель цифровой фабрики, (2) модель продукта и платформы и (3) гибкая модель в масштабах всего предприятия (см.

Рисунок 14.2). Каждая модель включает в себя элементы описанных выше строительных блоков продукта, платформы и раздела.

Три варианта конструкции операционной модели

ВАРИАНТ 1

ВАРИАНТ 2

ВАРИАНТ 3

Цифровая фабрика

Продукт и платформа

Ускорение в масштабах предприятия

Описание

Отдельное цифровое подразделение, которое создает цифровые

Модель объединяет бизнес, технологии и

Расширение преимуществ гибкости за пределы

решения для бизнеса

операции в капсулах, сосредоточенные

цифровые/технологические, как многие

устройства, использующие современные

по улучшению качества обслуживания клиентов

основные операции и

гибкие методы работы

пользовательский опыт

функции могут принести пользу

и междисциплинарный

(так называемые продуктовые капсулы)

от гибкого сотрудничества

стручки

и капсулы, посвященные

строительные услуги для повторного использования

(так называемые платформенные капсулы)

Типичный

10-50 стручков

50-1,000+ стручков

1,000+ капсул

конфигурация

Затрагивает менее 2% организации

Затрагивает 20-40% организации

Затрагивает 80 % организации

Главная

Самая простая модель

Интеграция бизнеса,

Создает в масштабах всего предприятия

преимущество

внедрить

Технологии и оперативное управление

внимательно и адресно

гибкая культура

эволюция платформ

Пререквизиты

Согласование БУ в финансировании и операционной деятельности

Требуется модернизация ИТ (например, талант,

Организационная готовность к полному

модель завода

архитектура, облако,

гибкое движение

DevSecOps)

ПРИЛОЖЕНИЕ 14.2

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

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

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

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

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

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

Цифровая модель завода

Модель цифровой фабрики часто является правильным местом для начала, поскольку она автономна и относительно быстро внедряется (обычно 12-18 месяцев до полной готовности к работе, хотя можно начать работу за несколько недель).1 На крупных предприятиях цифровые фабрики создаются в рамках подразделений, в то время как в небольших компаниях одна фабрика обслуживает несколько бизнес-подразделений. И горнодобывающая компания BHP, и Scotiabank внедрили модели цифровых фабрик, когда начали свои цифровые преобразования. В каждой из них было от четырех до пяти цифровых фабрик, обслуживающих различные подразделения, с координационным наложением для максимального повторного использования и стандартизации кода2.

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

На рисунке 14.3 показано, как одна из ведущих мировых гостиничных компаний организовала свою цифровую фабрику, в которой работает более 400 сотрудников.

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

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

Цифровая фабрика отвечает за работу платформенных капсул. Они финансируются централизованно или на основе разделения расходов с бизнес-подразделениями. Как правило, две трети ресурсов фабрики обычно направляются в продуктовые капсулы, а одна треть - в платформенные капсулы.

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

Цифровая модель работы завода

Пример гостиничного бизнеса Предполагаемые ЭПЗ (внутренние и внешние)

Discovery

25-30

PODS

15-20

45-50

25-30

Владельцы продуктов

Ведущие разработчики QA

Специалист по изучению данных Data eng.

Дизайнеры

Тренер по Scrum Agile

Архитектура

Бренды

DOMAINS

Конвертировать

Приложение И т.д.

CMS1 и DAM2

15-25

.com - содержание и домашняя страница

.com - Предложение

Страницы отеля

Основные бренды

Бренд, интегрированный с доменом .com

Конвертировать

Оставайтесь

Привлечь

И т.д.

Оплата

15-20

Система бронирования

1-10

API4

10-30

Данные

15-20

ТЕХНОЛОГИЧЕСКИЕ И ИНФОРМАЦИОННЫЕ ПЛАТФОРМЫ

1. CMS = система управления контентом; 2. DAM = управление цифровыми активами; 3. OTA = онлайновое туристическое агентство; 4. API = интерфейс прикладного программирования; 5. CDP = платформа клиентских данных

CMS

Средства массовой информации и контент для отелей

Оплата онлайн

Платежное решение для отелей

Ввод и вывод данных

Поиск, наличие и бронирование

OTA3 и каналы + D-Edge

Управление API и портал

Открытое распространение

Перекрестные продажи (услуги третьих лиц)

Управление данными

Платформа данных и CDP5

Продукты данных

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

От финансирования проектов к постоянному финансированию

ФИНАНСИРОВАНИЕ ПРОЕКТА

ПОСТОЯННОЕ ФИНАНСИРОВАНИЕ

БЮДЖЕТИРОВАНИЕ

Составление бюджета по проектам на ежегодной основе

Целевой годовой бюджет устанавливается на уровне предприятия и домена (не по проектам)

ФОНДИНГ

До 50% финансирования уходит на незапланированные или менее приоритетные работы

Дополнительное финансирование выделяется по достижении вех/этапов

ОБЗОР

Проекты пересматриваются и определяются по приоритетности ежегодно или два раза в год

Ежеквартальный обзор и определение приоритетов во время QBR

ПРИЛОЖЕНИЕ 14.4

Модель продукта и платформы

Модель "продукт и платформа" (P&P) используется большинством компаний-разработчиков программного обеспечения, ведущими мировыми розничными сетями, такими как Amazon, и ведущими мировыми банками, такими как JPMorgan Chase.3 Каждая из них приняла свою версию этой модели, поскольку она сближает бизнес, операции и технологии для ускорения инноваций в сфере обслуживания клиентов и создания более масштабируемой модели с помощью услуг на основе платформы.

Модель P&P - это более развитая версия цифровой фабрики, и ее развертывание происходит в гораздо больших масштабах. Если в модели цифровой фабрики может быть от 10 до 50 капсул, то в модели P&P, как правило, несколько сотен, а иногда и более тысячи капсул для крупных компаний.4 Это связано с тем, что модель затрагивает все технологические ресурсы и значительную часть ресурсов бизнеса и операций. На рис. 14.5 показана схема размещения модели P&P на 1000 с лишним капсул для одного из ведущих международных банков.

Модель продукта и платформы

Пример для международного банка

Розничная торговля

банковское дело

Богатство

управление

Бизнес

банковское дело

Коммерческая

банковское дело

Оптовая торговля

банковское дело

Активы

управление

Инвестиции

банковское дело

Партнеры по сбыту

Стратегии предприятия

Стратегии

Стратегии предприятия (общие, цифровые, технологические, клиентский опыт, операционная деятельность и т.д.)

Стратегии и OKR

Филиалы

Распространение

Консультанты, мобильный salesforce

Консультанты, прямые

RMs

Цельнозерновые салеры

Продажи

Путешествия

Сегментные операционные системы

Сегмент Сегмент

Опс Опс

Сегментные операционные системы

Сегмент Сегмент

Опс Опс

Ассистирование (отделения, контактный центр, коллекторы, мошенничество)

Самообслуживание (банкомат)

ПРОДУКТЫ / ПУТЕШЕСТВИЯ

Платформы для выхода на рынок (ориентированные на бизнес)

Ежедневные банковские операции Карты для ипотеки и HELOC

Экономия, инвестиции

Ежедневные советы по инвестированию

Институциональное богатство Розничное богатство

Путешествие E2E 1

E2E Путешествие 2

E2E Путешествие 3

...

Путешествие E2E 1

E2E Путешествие 2

E2E Путешествие 3

...

E2E Путешествие 1

E2E Путешествие 2

E2E Путешествие 3

...

E2E Путешествие 1

E2E Путешествие 2

E2E Путешествие 3

...

E2E Путешествие 1

E2E Путешествие 2

E2E Путешествие 3

...

Корпорация.

Оплата как услуга

Управление данными.

Корпоративные услуги

Опыт коллег

Соответствие требованиям

Включение

Обеспечение

Платформа и практические инструменты

Инфраструктура

Данные как услуга (DaaS) Оплата как услуга

Защита (кибер, AML, мошенничество)

Операции и риски

Вовлечение клиентов

Обслуживание

Основной продукт Кредит

Фронт-офис eTrading

Цифровой клиент

Операции жизненного цикла. Инновационная ликвидность

Общий

ПЛАТФОРМЫ

Обеспечение Предприятие

платформы

Модель P&P отличается от цифровой фабрики по трем параметрам:

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

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

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

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

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

Мы считаем, что модель P&P станет доминирующей в отраслях, где технология является основным фактором, определяющим производительность.

Как внедрить функции контроля в команды по разработке продуктов и платформ

Хотя в идеале в каждом agile-подразделении есть выделенные ресурсы функции контроля, на практике это невыполнимо. Первое, с чего следует начать, - это возложить на подразделения ответственность за свои риски в качестве первой линии обороны. Это позволит избежать проблемы "не моя работа", которая может привести к небрежной работе подразделений.

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

Как управление рисками встроено в гибкую операционную модель

Пример американского банка

Капсулы (первая линия обороны)

Функции контроля (вторая линия обороны)

Ведущий домен

Профессионалы в области управления рисками

Соответствие требованиям

Надзор за рисками

Главный специалист по соблюдению нормативных требований

Владелец продукта

Специалист по рискам

Владелец продукта

Кредит

Процентная ставка Ликвидность Цена

Операционная кибербезопасность

Главный кредитный директор

Руководитель отдела рыночных рисков

Надзор за ОУР

Проводит оценку рисков при планировании выпуска и при необходимости привлекает специалистов по рискам второй линии

Стратегические технологии борьбы с мошенничеством

Другие

ПРИЛОЖЕНИЕ 14.6

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

Как оценка рисков включается в процесс разработки

МОНИТОРИНГ

Каждый квартал

Идентификация рисков

Первоначальная оценка

(при необходимости)

Оценка рисков на основе всеобъемлющей таксономии рисков для выявления рисков на гранулированном, эпическом уровне

Автоматические триггеры для привлечения

Назначение специалистов по рискам

специализированные функции управления

Специалисты по рискам назначаются для

совместная разработка/консультирование мер по снижению рисков

Во время спринта

Уточненная оценка рисков

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

Рабочий процесс по снижению рисков

Выявление и автоматическое формирование историй по снижению рисков в бэклог подсистемы

Приборная панель

Мониторинг уровня рисков и их снижение на протяжении всего жизненного цикла

Смягчение последствий выполнено

Истории, назначенные членам стручков, бизнесу или рискам

профессионалов для выполнения мер по снижению воздействия

После спринта

Отчетность и соблюдение требований

Документирование действий по снижению рисков для обеспечения соответствия требованиям и ретроспективное обсуждение спринта

Отчеты о соблюдении требований

Автоматически создаваемые и настраиваемые отчеты

ПРИЛОЖЕНИЕ 14.7

Лучшие компании не только оцифровывают процесс выявления рисков, но и автоматизируют контроль над ними ("безопасность как код"). Своевременное устранение существенных рисков - важная составляющая достижения скорости. Этот вопрос подробно рассматривается в главе 22.

Модель гибкости в масштабах предприятия

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

Однако при внедрении agile за пределами цифровых/IT-команд требуются новые конструкции agile-команд, не ограничивающиеся междисциплинарными группами, а соответствующие специфике выполняемой работы (см. рис. 14.8). Например, самоуправляемые команды часто используются в контакт-центрах для обеспечения сквозной ответственности за результаты работы с клиентами и затраты, что способствует постоянному совершенствованию. Пул функциональных экспертов "от потока к работе" используется, когда функция (например, финансовая, кадровая, юридическая и т. д.) хочет гибко направить свои ресурсы на удовлетворение самых насущных потребностей, часто в бизнес (это называется "от потока к работе", потому что ресурсы "текут" туда, где есть "работа"). Наконец, "сетевые команды" часто используются в сетях дистрибуции и продаж/магазинов, чтобы обеспечить координацию и согласование на ежедневном уровне при меньшей иерархии и большем практическом руководстве.

Компании, перешедшие к полномасштабной корпоративной модели agile, такие как ING, Spark NZ или Walmart (Мексика), сосредоточились на переосмыслении всей организации как сети высокопроизводительных команд, каждая из которых стремится к четкому, ориентированному на конечный результат бизнесу и обладает всеми необходимыми навыками для его достижения.5

На рис. 14.9 показан планшетный вид корпоративной модели agile для оператора связи среднего размера. Он развернул команды сетевых элементов в дистрибуции каналов, чтобы выровнять организацию и ускорить обмен передовым опытом. В контакт-центрах были развернуты самоуправляемые команды для повышения ответственности за обслуживание клиентов, что дало впечатляющие результаты. В области корпоративных функций использовалась модель "поток - работа", позволяющая быстрее перераспределять ресурсы на критически важные проекты. Наконец, основной бизнес был организован в кросс-функциональные группы (или стручки), как мы описывали их ранее в модели P&P.

Четыре архетипа гибких подразделений

МЕЖФУНКЦИОНАЛЬНЫЕ ПОДРАЗДЕЛЕНИЯ

САМОУПРАВЛЯЕМЫЕ КОМАНДЫ

Пример: Продуктовые команды (pods)

Используется на цифровом заводе, а также в P&P

Пример: Контактный центр

Каждая команда отвечает за комплексное обслуживание определенной группы клиентов.

Руководство владельцем продукта

Маркетинг

Под 1

Под 2

Под 3

Под 4

Под 5

Наука о данных

Инженерия данных

Дизайн

FLOW-TO-WORK

Пример: Функциональные эксперты

Направлены в команды с наиболее острыми потребностями

Управление на основе KPI

Команда 1

Команда 2

Команда 3

СЕТЕВЫЕ ЭЛЕМЕНТЫ

Пример: Рассылка

(магазины, отделы продаж)

Координация света

Специальные проектные группыЭксперты по бассейнам

Команда 1

Ежедневные встречи

Команда 2

Команда 3

Проектная группа 1

Функциональные эксперты

Проектная группа 2

Проектная группа 3

ПРИЛОЖЕНИЕ 14.8

Эта модель позволила сократить общее количество сотрудников более чем на 20 %, при этом повысив уровень удовлетворенности клиентов и общий доход на одного клиента. Что немаловажно, этот результат был достигнут при одновременном повышении удовлетворенности сотрудников, которая достигла уровня NPS +78 через три года после преобразований (по сравнению с +22).

Ускоренная операционная модель в масштабах всего предприятия

Оператор связи среднего размера

Организационные блоки Agile

Многофункциональные капсулы

Самоуправляемые команды

Пулы "поток - работа

Элементы сети

Подразделения по распределению и доставке товаров по каналам

Каналы и подразделения доставки

Розничные магазины

Бизнес-центры

Продажи и продажи и

Сервис ЮгСервис Север

Профессионалы Полевые услуги ДоставкаДоставка

Сервис Выставление счетов и взыскание задолженности

Операции Операции

Контактные центры

Контактные центры: Регистрация/использование

Контактные центры: Премиум

Контактные центры: Аутсорсинг

Возможность выставления счетов

ИТ-путь к производству

Эволюция сети

Физическая инфраструктура

Приложения

Безопасность

Сеть и инфраструктура

Данные и автоматизация

Функции

Домен канала

Мобильный

Сегментные домены

Домены продуктов

Широкополосная связь

Цифровые услуги

Голос и совместная работа

Управляемые данные

Услуги

Оптовая торговля

Бизнес

Потребитель

Платформы Домены

Omnichannel

Домены

Управление стоимостью

Бренд и корпорация. Comms

Agile

Юридическая

Нормативные документы

Финансы

ПРИЛОЖЕНИЕ 14.9

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

Примечания

Сомеш Кханна, Надежда Константинова, Эрик Ламарр и Вик Сохони, "Добро пожаловать на цифровую фабрику: Ответ на вопрос, как масштабировать цифровую трансформацию", McKinsey.com, 14 мая 2020 г., https://www. mckinsey.com/capabilities/mckinsey-digital/our-insights/welcome- to-the-digital-factory-the-answer-to-how-to-scale-your-digital- transformation.

Раг Удд, "Повышение скорости создания стоимости с помощью цифровых фабрик", BHP, 4 мая 2020 г., https://www.bhp.com/news/prospects/2020/05/pushing- the-velocity-of-value-with-digital-factories; Уилл Эрнандес, "Почему Scotia- bank строит "цифровые фабрики"", American Banker, 18 октября 2019 г., https://www.americanbanker.com/news/why-scotiabank-is- building-digital-factories#:~:text=Мы%20хотели%20построить%20воспроизводимое,могли%20сделать%20реально%20хорошее%20программное обеспечение.

Таня Чхабра, "Бизнес-модель Amazon | Как Amazon зарабатывает деньги?", Feedough, 21 февраля 2023 г., https://www.feedough.com/ amazon-business-model/; Бьянка Чан и Картер Джонсон, "JPMorgan добавляет 25 "мини-директоров" в рамках масштабного плана по увеличению численности 50-тысячной технологической организации и переводу банка на работу, более похожую на стартап", Business Insider, 15 апреля 2022 г., https://www

.businessinsider.com/insider-jpmorgans-massive-shift-product-oriented-

tech-operating-model-2022-4.

Оливер Боссерт и Дрик Десмет, "Игра на платформе: Как работать как технологическая компания", McKinsey.com, 28 февраля 2019 г., https://www. mckinsey.com/capabilities/mckinsey-digital/our-insights/the- platform-play-how-to-operate-like-a-tech-company.

См. "Проворная трансформация ING", McKinsey Quarterly, 10 января 2017 г., https://www.mckinsey.com/industries/financial-services/our-insights/ ings-agile-transformation; "All in: От восстановления к гибкости в Spark New Zealand", McKinsey Quarterly, June 11, 2019, https://www.mckinsey. com/industries/technology-media-and-telecommunications/our- insights/all-in-from-recovery-to-agility-at-spark-new-zealand; "Финансовый отчет и отчет ESG за 2020 год", Walmart (Мексика), 31 декабря 2020 года, https://informes.walmex.mx/2020/en/pdfs/2020_Financial_and_ESG_ Report.pdf.

Глава 15.

профессионализация управления продуктами

Получить хороших игроков легко. Сложнее заставить их играть вместе.

-Кейси Стенгел

Хотя внедрение гибкой операционной модели требует от компаний развития множества способностей (как описано в главах 13 и 14), две из них заслуживают более пристального внимания в силу своей важности: управление продуктами и проектирование клиентского опыта (о чем пойдет речь в главе 16). Решающим отличием многих технологических компаний от их коллег из других отраслей является степень внедрения этих возможностей - наряду с культурой разработки программного обеспечения и использованием данных и аналитики - в их работу.

Создание глубины управления продуктами обычно является одной из основных целей переквалификации в ходе цифровой трансформации и трансформации с использованием искусственного интеллекта. Есть две основные роли: владелец продукта, который руководит подсистемами, и старший специалист по продукту, владелец, который возглавляет группу подсистем или домен. Владельцы продуктов абсолютно незаменимы, поскольку сочетают в себе важнейшие операционные и стратегические навыки, в том числе: понимание потребностей бизнеса, глубокое понимание клиента и прочное знание технологий (см. Рисунок 15.1).

Навыки великого владельца продукта

Основы работы с клиентами

Ориентация на рынок

Деловая хватка

Технические навыки

Мягкие навыки

Способность разрабатывать ориентированный на клиента опыт на протяжении всего пути принятия решения покупателем

Способность глубоко понимать тенденции рынка, партнерские экосистемы и конкурентные стратегии

Удобство работы с бизнес-стратегией, приоритизация портфеля,

продвижение на рынок, ценообразование, отслеживание ключевых показателей эффективности и финансовых показателей

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

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

ПРИЛОЖЕНИЕ 15.1

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

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

По их словам: Переход в мир управления продуктами

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

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

-Кен Мейер, директор по информации и опыту компании Truist

Работая в тесном сотрудничестве с руководителями доменов и дизайнерами пользовательского опыта, владельцы продуктов несут полную ответственность за весь жизненный цикл продукта - от сбора информации о клиенте до разработки решения и его внедрения. Владелец продукта отвечает за выполнение конкретного набора четких OKR, которые он оценивает и пересматривает во время QBR, где приоритеты могут меняться. Они знают, как направлять разработку технически сложных решений, следить за тем, чтобы agile-подразделения работали над правильными проблемами клиентов/пользователей, и создавать инновационные решения этих проблем. Важно отметить, что владельцы продуктов отвечают за весь свой бэклог, включая базовые задачи по обслуживанию, такие как исправление ошибок, а не за создание новых функций продукта. Это обеспечивает их ответственность за качество создаваемых продуктов и помогает сократить технический долг.

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

Карьерный рост и профессиональное развитие

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

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

Более высокие должности (главный директор по продуктам, старший директор, вице-президент) несут широкую ответственность за наиболее важные продукты или их совокупность. Они определяют стратегию для всего портфеля продуктов и несут ответственность за весь жизненный цикл всех продуктов. Их команды могут достигать 5 000 человек, а некоторые из них подчиняются непосредственно генеральному директору.

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

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

ПУТИ КАРЬЕРНОГО РОСТА

Индивидуальный вклад Менеджер по персоналу

Сотрудники ДО

Владелец продукта

Старший сотрудник отдела кадров

Экспертная трасса

Главный специалист

Заслуженный работник ДО

Управленческий трек

Вице-президент по продуктам

Группа PO

Директор по продуктам

Ассоциированный специалист

РОЛИ И ОБЯЗАННОСТИ

Экспертный трек: Заслуженный специалист

Руководящая должность: Директор по продукту

Сфера ответственности

Организационное влияние

Работает над передовыми технологиями, продуктами или клиентским опытом.

Работает над флагманскими или стратегическими продуктами, сталкивающимися с жесткой конкуренцией

Работает над стратегическими продуктами, важными для критически важных клиентов (B2B), руководителей и членов под

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

Способность создавать и возглавлять кросс-функциональную команду "рок-звезд".

востребован другими сотрудниками ДО и коллегами как наставник и педагог

Помогает в наборе, удержании и обучении коллег по ДО и инженеров

Работает над управлением рентабельностью флагманского продукта или группы продуктов (или маршрута).

Руководит работой над несколькими функциями или продуктами, обеспечивая видение и управление производительностью

Способность заручиться поддержкой старшего руководства в различных сферах деятельности

Способность управлять бюджетом для реализации конкретных проектов и идей

Способность создавать, обучать и управлять эффективностью работы команды ДО

Обучает своих коллег по ДО и других коллег передовым методам работы

Отвечает за набор, удержание и обучение сотрудников ДО

Влияние на рынок

Представляет идеи и является автором публикаций на технические темы

Развивает прочные отношения с экосистемой - разработчиками OSS, партнерами и т. д.

Легко доносит видение продукта до клиентов и партнеров и привлекает первых последователей

Служит внешним лицом продукта/продуктовой группы

Развивает отношения со стратегическими партнерами, влиятельными лицами и клиентами

Легко доносит видение продукта до клиентов и партнеров

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

ПРИЛОЖЕНИЕ 15.2

Владелец продукта: система навыков

Важнейшие навыки для сотрудников ДО

КЛИЕНТСКИЙ ОПЫТ

Дизайн-мышление: Подход к решению проблем и принятию решений на основе эмпатии и дизайна

Клиентоориентированность: Фокус на изучении потребностей и болевых точек клиентов для повышения ценности

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

ОРИЕНТАЦИЯ НА РЫНОК

Тенденции развития отрасли и конкурентов: Знание актуальных рыночных и технологических тенденций, на основе которых разрабатывается стратегия развития продукта

Инновации: Выдвижение инновационных идей и внесение вклада в развитие бизнеса

ДЕЛОВОЙ ДОКУМЕНТ

Видение продукта и дорожные карты: Разработка концепции продукта и итеративной дорожной карты на основе потребностей пользователей

Выход на рынок: Помощь в разработке плана GTM для эффективного роста и внедрения продукта

Расстановка приоритетов: Поддерживайте приоритетность работ и определяйте разумные цели, ориентированные на ценность для пользователей.

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

ТЕХНИЧЕСКИЕ НАВЫКИ

Планирование и реализация технологий: Совместно с экспертами разрабатывайте осуществимые решения для MVP и релизов

Способы работы: Сделать правильно

компромиссы с командами для непрерывного совершенствования

Управление рисками: Управление рисками, привлечение других людей для согласования результатов и потребностей бизнеса

Управление бэклогами: Создание и управление бэклогом совместно с командой (командами) для удовлетворения потребностей пользователей

ЛИДЕРСТВО В ПРОИЗВОДСТВЕ

Эффективное исполнение: Совместное владение, управление и приоритизация ориентированных на пользователя результатов продукта

Коммуникация: Управление коммуникациями с заинтересованными сторонами и спонсорами

Вдохновляйте и влияйте: Станьте идейным лидером, вызывающим последователей благодаря своим идеям

Развитие персонала: Создание высокоэффективной командной культуры на основе страсти, доверия и сотрудничества

Сотрудничество: Совместное создание функций и содействие согласованию зависимостей между командами для повышения ценности.

РАЗВИТИЕ НАВЫКОВ ПО ОБРАЗЦУ - ВОВЛЕЧЕНИЕ ПОЛЬЗОВАТЕЛЕЙ И ОБРАТНАЯ СВЯЗЬ

РАЗРАБОТКА ПРОФЕССИОНАЛ ЭКСПЕРТ

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

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

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

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

Хорошего владельца продукта не так-то просто воспитать. Требуется время, поддержка и практика - управление продуктом - это ремесло, которому нужно учиться годами. Некоторые загрузочные курсы для владельцев продуктов, длящиеся около восьми недель, могут предложить интенсивное обучение для развития конкретных навыков (например, как разрабатывать опросы клиентов, как создавать OKR, как писать пресс-бриф и FAQ для планируемого продукта и т. д.). Лучшие программы сочетают аудиторные занятия с погружением в процесс обучения, в ходе которого моделируются реальные проблемы клиентов.

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

Такие программы, ориентированные на продукт, могут быть полезны для создания фундамента навыков, но сами по себе они недостаточны. Мы часто видим, как люди, закончив эти программы по развитию навыков, возвращаются в привычную рабочую среду, где они не могут использовать свои новые навыки. Для создания настоящего ремесла управления продуктом необходимо, чтобы команды использовали одни и те же артефакты (например, инструменты и шаблоны), одинаково понимали, за что отвечает владелец продукта, и использовали схожие процессы анализа на встречах QBR.

Программа повышения квалификации по управлению продуктами на местах и в форумах

Пример для финансового учреждения США

Полевой проект (20 часов)

Когорта из ~100 человек; программа выполняется ~3 месяца

ФОРУМ 1

Фаза открытия

ФОРУМ 2

Фаза жизнеспособности I

ФОРУМ 3

Фаза жизнеспособности II

ФОРУМ 4

Этап строительства

Изучение Понимание

цель проблемное пространство и определение видения продукта

Сопереживание пользователю и определение "как" (инновационный, а не инкрементный подход)

Донесение информации о ценности и взаимодействие с клиентами и инженерами

Претворение идеи продукта в жизнь

Форум5 часов обучения Понимание

проблемное пространство

и возможности рынка

Документ о требованиях к рынку

Конкурентный анализ Определение видения продукта

Пресс-релиз и часто задаваемые вопросы

Холст бизнес-модели

Карта дорог

5 часов

Определение приоритетов портфеля (с опорой на данные)

Понимание потребностей пользователей и основных неудовлетворенных потребностей

Персона пользователя (включает методы исследования)

Путешествие как таковое

Определение того, как мы хотим решить проблему неудовлетворенных потребностей

Предстоящее путешествие

Прототип

5 часов

Определение и измерение успеха

Показатели успешности продукта

Цели и основные результаты

Общение и взаимодействие с клиентами

Заявление о позиционировании

Одностраничный продукт

Питч-дек для клиентов

Преобразование идеи продукта в требования

Документ с требованиями к продукту

5 часов

Обзор фазы сборки и подхода к непрерывной разработке

Мышление минимально жизнеспособного продукта

Постоянное уточнение и определение приоритетов

Бэклог продукта

Развитие лидерских качеств - Влияние без полномочий

Обзор и цели демонстрационного дня

Полевая подготовка

Ядро

Навыки ДО

Ориентация на рынок Деловая хватка

Основа для работы с клиентами

Деловая хватка

Основа для работы с клиентами

Технические навыки

Деловая хватка

Основа для работы с клиентами

Мягкие навыки Технические навыки

Деловая хватка

ПРИЛОЖЕНИЕ 15.4

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

По нашим прогнозам, большинство современных владельцев продуктов будут тратить не менее 30 % своего времени на внешнюю деятельность, например на взаимодействие с клиентами и партнерской экосистемой. Такое взаимодействие не будет ограничиваться потребительскими продуктами - по мере того, как ИТ становится все более популярным, владельцы B2B-продуктов будут напрямую общаться с конечными пользователями, а не добывать обратную связь через многочисленные уровни торговых посредников.

Примечание

1. Чандра Гнанасамбандам, Мартин Харриссон, Джереми Шнайдер и Рикки Сингх, "Что отличает топ-менеджеров по продуктам от остальных", McKinsey.com, 20 января 2023 г., https://www.mckinsey.com/ industries/technology-media-and-telecommunications/our-insights/ what-separates-top-product-managers-from-the-rest-of-the-pack.

Глава 16.

Дизайн клиентского опыта

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

-Сьюзан Сарандон

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

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

Эта ценность так же реальна для B2B-компаний, как и для B2C. Мы обнаружили, что в тяжелой промышленности дизайн пользовательского опыта (UX) так же важен для того, чтобы операторы на передовой приняли новые цифровые решения. Любой компании, серьезно относящейся к цифровой трансформации и внедрению ИИ, необходимо развивать потенциал UX-дизайна следующими четырьмя способами.

Сначала наймите отличных дизайнеров

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

Начните с небольшого ядра, возможно, 5-10 CX-дизайнеров, и развивайтесь дальше. Мы обнаружили, что отличных дизайнеров клиентского опыта можно нанять из других отраслей, дизайнерских фирм или даже из аспирантуры. Ведущие учебные заведения все чаще предлагают программы MBA, включающие дизайн-мышление.

Знайте, что вы ищете. Дизайнеры не все одинаковы. Роли дизайнеров, как правило, группируются вокруг четырех компетенций (см. Рисунок 16.1). Прежде чем нанимать и наращивать свой потенциал в области дизайна, четко определите, какие компетенции вам действительно нужны.

Различные компетенции в области дизайна

КЛЮЧЕВЫЕ КОМПЕТЕНЦИИ

ОСНОВНЫЕ МЕТОДЫ*

Дизайн услуг

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

Картина бизнес-модели Чертежи, карты экосистемы Матрица приоритетности функций

Умеет мыслить системно, т.е. системное мышление - рассматривать компоненты как часть большого целого

Основы решения проблем

Ведущие семинаров по дизайну

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

Инструменты: Figma, Sketch, Adobe Creative Suite

Исследование дизайна

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

Руководства по проведению интервью Опросы

Способность проводить опросы и тестирование юзабилити

Personas

Путешествия, карты рабочих процессов

Владение передовыми методами для обеспечения достоверности результатов и обобщения полученных знаний

Анализ путей, с аналитикой

Инструменты: Dovetail, UserTesting.com

Знание и расширение знаний в области аналитики и других методов количественных исследований

дизайн

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

Концепции опыта, модели взаимодействия Информационная архитектура, навигация

Способность разрабатывать последовательные решения, отвечающие потребностям пользователей и соответствующие лучшим практикам

Картинки-прототипы

Инструменты: Figma, Sketch,

Adobe Creative Suite

Визуальный дизайн

Владеет навыками композиционного равновесия, теории цвета, иконографии и т.д.

Владеет шаблонами и системами визуального дизайна, включая, но не ограничиваясь архитектурой бренда

Знание передовых методов разработки визуальных систем и документации

Выражение и расширение бренда Доски настроения, библиотеки активов Рамки дизайна взаимодействия

Модели проектирования Omnichannel Визуальный дизайн

Инструменты: Adobe Creative Suite, Sketch, Invision

* Основные методы не являются исчерпывающими

ПРИЛОЖЕНИЕ 16.1

Инвестируйте в процесс разработки CX-дизайна

Подход к CX-дизайну можно четко определить как процесс, состоящий из двух частей: разработать правильную вещь, а затем разработать правильную вещь.

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

Для проведения потребительских исследований существует все больше методик, но они требуют четкого представления о том, какой инструмент лучше всего подходит для той или иной цели (см. Рисунок 16.2).

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

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

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

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

КОЛИЧЕСТВО

QUANTITATIVE

Ответы на вопросы "Почему"

Глубокое понимание поведения и эмоциональных потребностей пользователей

Выявление потребностей, о которых пользователи даже не подозревают Основано на наблюдениях; способность к совместному творчеству с пользователями

Ответы на вопросы "Сколько и как".

Количественная оценка данных и обобщение результатов на основе выборки населения

Основывается на мнениях и подтверждает гипотезы или решения статистически достоверными данными

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

Такие инструменты, как Figma, позволяющие гораздо быстрее создавать прототипы для тестирования высокофункциональных продуктов или услуг без необходимости написания кода, предвещают ускорение проектирования за счет технологий. Новые технологии с низким/отсутствующим кодом и генеративный ИИ, такие как GPT-4, также быстро изменят характер этого процесса разработки. Функциональность Drag-and-drop, которая автоматически генерирует код в фоновом режиме, сокращает время разработки с недель до дней или с дней до часов. Это позволит командам, занимающимся разработкой опыта, получить больше времени для тестирования и доработки своих продуктов и услуг.

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

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

Сделайте UX-дизайн частью вашей команды с самого начала

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

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

Увязывайте каждый элемент CX-дизайна с ценностью

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

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

Примечания

См. "Повышение влияния на бизнес за счет клиентоориентированности и цифровой гибкости", McKinsey.com, 30 июля 2021 г., https://www.mckinsey.com/ capabilities/mckinsey-digital/our-insights/driving-business-impact- through-customer-centricity-and-digital-agility.

Бенедикт Шеппард, Хьюго Сарразин, Гарен Куюмджян и Фабрисио Доре, "Бизнес-ценность дизайна", McKinsey Quarterly, 25 октября 2018 г., https://www.mckinsey.com/capabilities/mckinsey-design/ our-insights/the-business-value-of-design.

Ниже приведен набор вопросов, которые помогут вам определить, какие действия следует предпринять:

Согласны ли руководители высшего звена с операционной моделью, позволяющей сотням подразделений внедрять цифровые инновации?

Соответствуют ли OKR для каждого подразделения приоритетам бизнеса?

Являются ли "контрольные функции" (например, финансовые, юридические, регуляторные) частью вашего гибкого процесса наряду с бизнесом и технологиями?

Каким образом ваши финансовые и управленческие процессы согласованы для обеспечения более гибкой операционной модели?

Как вы оцениваете достижения в скорости и маневренности, которые делает ваша организация?

Сколько ваших команд и решений возглавляет высококлассный владелец продукта?

Входят ли специалисты по клиентскому опыту и дизайну в состав ваших agile-команд, и достаточно ли рано они вовлечены в процесс?

Технологии для скорости и распределенных инноваций

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

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

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

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

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

Глава 18: Более оперативный и ценностный подход к облаку. Сосредоточьтесь на значимых областях бизнеса при переносе приложений в облако, чтобы обеспечить максимальную рентабельность инвестиций в облако.

Глава 19: Инженерные практики для скорости и качественного кода. Автоматизация разработки и развертывания программного обеспечения является основой для создания и выпуска высококачественного программного обеспечения.

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

Глава 21: Поставка цифровых решений производственного уровня. Создание условий для безопасной, контролируемой и масштабируемой среды производства с помощью автоматизации.

Глава 22: Встраивание безопасности и автоматизации с самого начала. Автоматизация проверок безопасности на протяжении всего процесса разработки программного обеспечения. Это ускоряет общую скорость разработки и гарантирует, что все цифровые решения будут безопасными и надежными.

Глава 23: MLOps, чтобы ИИ мог масштабироваться. Модели AI/ML - это "живые организмы", которые требуют мониторинга и постоянного переобучения данных. Именно поэтому для масштабирования ИИ необходимы инструменты автоматизации MLOps.

Примечание

1. Томас Элснер, Питер Майер, Герард Рихтер и Катя Цолпер, "Что нужно ИТ-директорам от руководителей компаний и советов директоров, чтобы сделать ИТ готовыми к цифровым технологиям", McKinsey. com, 1 декабря 2021 г., https://www.mckinsey.com/capabilities/ mckinsey-digital/our-insights/what-cios-need-from-their-ceos-and- boards-to-make-it-digital-ready; Steve Van Kuiken, "Boards and the cloud," McKinsey.com, November 18, 2021, https://www.mckinsey.com/ capabilities/strategy-and-corporate-finance/our-insights/boards-and- the-cloud.

Глава 17.

Раздельная архитектура обеспечивает гибкость разработки и масштабируемость операций

Мы формируем наши здания, а они в свою очередь формируют нас.

-Уинстон Черчилль

Архитектура платформы поддерживает системы взаимодействия (front end) и системы учета (back end), а также данные и аналитику, необходимые для разработки решений и управления цифровыми преобразованиями и ИИ. Лучшие архитектуры обеспечивают гибкость, стабильность и скорость, чтобы гибкие подразделения по всей организации могли создавать решения, необходимые для реализации цифровой дорожной карты. Ключевая концепция заключается в том, что распределенная и разрозненная архитектура необходима для того, чтобы команды могли собирать модульные и многократно используемые компоненты (см. Рисунок 17.1).

Четыре основополагающих изменения для модернизации архитектуры для цифровых технологий

Системы взаимодействия

Унифицированное ядро данных и аналитики

Системы учета

3 От фиксированного к эволюционирующему