Эффективность технологической трансформации
Один из самых непростых вопросов для управленцев, отвечающих за технологии или корпоративную цифровизацию, это вопрос: «Насколько эффективна проводимая трансформация?». Такая постановка может быть сформулирована со стороны руководителя организации, совета директоров, акционера или бизнес-партнеров. Часто организация задается таким вопросом в условиях некоторой усталости от ожидания результатов трансформации, что добавляет эмоционального накала в дискуссию.
Управляющий директор Bereke Bank Рафаэль Валеев считает что уделять внимание вопросам эффективности, а не только результативности, нужно с самого начала реализации любой программы проектов и предлагает свою систему оценки эффективности и коммуникации относительно этого аспекта с партнерами. В колонке VC он подробно рассказал о том, какую методику он применяет, и как она ложится на реальную практику.
Что такое эффективность?
Давайте для начала разберемся: что такое эффективность, и чем она отличается от результативности?
- Результативность — это способность достигать результата и это первый навык, который должна освоить ваша функция или команда.
- Эффективность — это способность достигать результатов с наименьшими затратами и с наибольшими бизнес-эффектами.
Согласно PMI Pulse of the Profession 2023, который ежегодно публикует отчет о состоянии дел в проектном управлении, 70% проектов не достигают своих целей. Поэтому так важно уметь рассчитывать эффективность и предугадывать различные сценарии событий.
Одной из наиболее сложных зон для оценки эффективности является работа продуктовых команд разработки, которые являются ядром любой современной программы трансформации.
В современном технологическом банке или технологической корпорации технологическая функция выступает партнером бизнес подразделения, либо даже драйвером бизнеса. Работа над разными проектами обычно идет в кросс-функциональных командах. И эта кросс-функциональность обеспечена на разных слоях экспертизой как технологической, так и бизнес-функции.
Эффективность работы таких команд состоит из двух компонентов: «Ценность» и «Расходы». Обе компоненты формулы — это совместная ответственность как бизнеса, так и технологий, где Value — больше зона бизнеса, а Costs — зона первичной ответственности технологий. «Совместную ответственность» важно не путать с «коллективной безответственностью». Мы сконцентрируемся на знаменателе этой формулы, то есть на аспекте управления расходами.
Компонента расходов (Costs) прямым образом зависит от тонкой настройки следующих составляющих операционной модели технологической трансформации:
- Организационная структура
- Роли и ответственность
- Фреймворк продуктовой разработки
- Управление зависимостями и изменениями
- Платформенный слой и переиспользование
- Метрики и бенчмарки
Организационная структура: сбалансированная модель
Все множество организационных структур при корпоративных трансформациях, в которых я участвовал, можно упрощенно разделить на три типа:
- Диктатура технологий
Классическая структура с централизованным ИТ, где бизнес встает в очередь с задачами и проектами, а решения об их приоритезации на основе неведомого бизнес-смысла принимает технологическая функция. Кросс-функциональные команды существуют, но больше в формате разного набора технологических экспертиз. На текущий момент такая структура является архаизмом и встречается крайне редко. - Автономный бизнес
Диаметрально противоположный вариант — когда очень полномочный бизнес определяет набор технологических инициатив, и дальше технологическая функция фактически аутстаффит экспертизу. В максимуме в корпорации вообще не существует выделенной технологической функции, фактически она инкорпорирована в бизнес. Такой подход реализуется либо в очень незрелой организации, где такая структура явилась следствием борьбы за власть и автономию бизнеса, либо, наоборот, в чрезвычайно технологически зрелой компании, где технологии являются основой бизнеса. Такая структура может успешно существовать в единственном редко реализуемом варианте, когда бизнес создает внутри себя хорошую технологическую экспертизу, с полномочным CTO, которого сам готов воспринимать. Но в 9 из 10 случаев такая оргструктура приводит к гигантскому техдолгу, масштабным архитектурным просчетам и пренебрежению вопросами эффективности. - Я выступаю за более сбалансированный вариант. Когда от технологической функции выделен CTO (chief technical officer) на конкретный бизнес-блок, который вместе с куратором бизнеса структурирует одну или несколько макрокоманд (в некоторых методологиях такая команда называется трайб) с разными ролями на 50-150 человек. Технологическая экспертиза в количестве обычно превалирует: 85% этого трайба принадлежат ИТ-ролям. Дальше есть как продуктовая менеджерская вертикаль, так и инженерная.
СТО такого бизнес-направления безусловно отвечает за развитие хард-скиллов в командах, но также глобально — на уровне всей компании — есть центры компетенций, которые отвечают за найм людей в продуктовые направления, а также централизованно развивают экспертизу и методологию соответствующих экспертиз. Таким образом, оргструктура фактически представляет из себя куб.
Роль СТО бизнес-направления
СТО бизнес-направления — это одна из важнейших функций в такой оргструктуре, поэтому я хочу остановиться на ней и рассказать подробнее. Эта роль — реальный технологический бизнес-партнер для лидеров бизнеса, разделяющий как успехи, так и риски курируемого направления. Это выражается в их KPI, которые содержат в себе как IT’шные так и бизнесовые метрики.
Помимо обладания технологическими навыками СТО должен хорошо понимать предметную область и на основе этого понимания выстраивать приоритеты и собственный фокус. Невозможно выполнять все задачи на 100% хорошо. Всегда в портфеле проектов есть задачи с хорошим уровнем исполнения, а есть западающие. Тут СТО должен очень хорошо ориентироваться в контексте — всегда выделять условные TOP-3 задачи, которые важны для бизнеса в моменте.
Например, какой-либо бизнес планирует с нами на полугодие десять технологических проектов. Если в итоге мы запустим из этих десяти проектов три топовых и больше ничего, несмотря на фактическое выполнение только 30% необходимой работы, бизнес будет удовлетворен и будет считать нас надежным партнером. И это гораздо лучше, чем выполнить семь оставшихся менее значимых задач без трех топовых, но иметь “бумажную” продуктивность на уровне 70%. Повторюсь, какие именно три задачи в приоритете, — нужно определять, понимая контекст. Часто это совсем не то, что заявляется на комитетах в презентациях. Также в организационной структуре есть такая важная роль как Software engineering manager — SEM. Если СТО отвечает за все происходящее в технологиях на уровне одной конкретной бизнес-линии, то SEМ отвечает за 2-3 команды и подотчетен CTO.
Фреймворк SAFe
Следующий компонент эффективности трансформации —используемый фреймворк.
В качестве системы для продуктовых стримов может выступать любой фреймворк масштабируемого Agile, но я рекомендую Scaled Agile Framework, который задает адекватный для корпорации интервал планирования. Чаще всего это квартал. Кроме того, этот фреймворк решает еще одну значимую для эффективности задачу — снижает потери времени и ресурсов на зависимостях.
Большое преимущество именно SaFe — в очень хорошо проработанной библиотеке знаний, которая находится на ресурсе https://scaledagileframework.com/, а также в качественной методологии внедрения с развитой сетью профессионально сертифицированных консультантов. Мы уже несколько лет подряд очень плодотворно сотрудничаем с Алексеем Ионовым из ionovpartners.ru.
SaFe выделяет четыре уровня — командный, уровень программы, решения и портфеля, а также поддерживает разную степень внедрения от нескольких команд до организации в целом, включая управление стратегией.
Большое преимущество SAFe, в том что его можно внедрить быстро, не меняя кардинально структуру компании, поскольку эта методология является определенного вида компромиссом между гибкой и вертикальной организационной структурой.
SAFе предлагает очень конкретные инструменты работы на уровне масштаба корпорации. Отмечу два из них, которые меня когда-то особенно поразилили своим вкладом в повышение эффективности:
- PI- планирование:
Двухдневное планирование на несколько итераций вперед, — часто это квартал, когда команда получает от руководства обновленный бизнес-контекст, раскладывает по спринтам свои задачи, оценивает риски, запрашивает решение зависимостей от смежных подразделений и определяет свои цели на соответствующий период.
Мне кажется, именно в этой церемонии сконцентрировано много магии этой методологии. Происходит синхронизация и выравнивание понимания целей бизнеса по вертикали и горизонтали организации, заключается очень много полезных соглашений между смежными подразделениями. Самым главным результатом такой мини-стратсессии является всеобщий комитмент команд, менеджмента, стейкхолдеров, смежных подразделений по целям бизнеса на несколько итераций вперед. - Доска зависимостей
Большое значение для обработки зависимостей играет инструмент — доска зависимостей, которую составляют на PI-планировании. Конечно, в основном его ведут в инструменте визуализации, таком как Miro, но именно вживую он выглядит очень фактурно. На доске с планами команд натягиваются красные нити, отображающие зависимости, от одной команды к другой, либо от команд к подразделениям, находящимся вне макрокоманды. По количеству таких линий можно визуально оценить: насколько рискованным является бэклог конкретной команды, достаточно ли менеджмент организовал автономию, нет ли чрезмерного количества зависимостей на подразделение, не включенное в данную макрокоманду.
Зависимости: что такое зависимости и в чем их опасность для эффективной работы?
Я несколько раз упомянул, что мы много времени уделяем работе с зависимостями. И я действительно считаю, что управление зависимостями — это очень серьезный компонент эффективности. Зависимости напрямую влияют на Time-to-Market — насколько быстро продукт выходит на рынок. Очевидно, чем быстрее мы поставляем инкременты ценности Value, тем мы эффективнее. Time2Market в свою очередь зависит от LeadTime команд, участвующих в создании ценности.
В чем разница между Time2Market и LeadTime?
В Тime2Market входят все организационные процедуры:
- защита проекта внутри компании
- согласование бюджета,
- маркетинговая стратегия
Утрированный пример: мы задумали создать кредитную карту с каким-то новым видом кэшбэка. Дальше мы раскладываем задачу на этапы реализации. Дедлайны выпуска, допустим, наступают через полгода. Внутри этого полугода мы ведем много разработок в разных областях. Одна из таких разработок — это мобильное приложение: нужно сделать форму заказов такой карты, его отображение и сервис. Время разработки и выпуска функционала внутри конкретного приложения или платформы называется LeadTime. То есть LeadTime является составляющей Time2Market.
Обычно разработка проекта идет в разных командах. Продолжаем пример с нашей картой. Для запуска продукта нам нужно параллельно вести работы в карточном процессинге, в антифроде и мобильном приложении. То есть у нас работают несколько команд, у каждой из которых свой LeadTime по определенному функционалу.
Следующий этап — когда нам нужно все собрать воедино, провести интеграцию. По моей практике, именно на этом этапе обычно происходят самые большие потери для компании. Во-первых, нужно договориться о форматах взаимодействия между командами. Во-вторых, нужно синхронизировать команды по времени и графикам разработки.
Реальность еще сложнее — так как при запуске финтех продукта очень много работы находится в области комплаенса, юридической и бухгалтерской методологии.
Поэтому, для системного улучшения показателя Time2Market важно не только снижать LeadTime, а внимательно работать с зависимостями. Как я сказал выше, SAFe очень эффективен именно в этом.
Какие еще компоненты есть у эффективного ИТ-производств? Безусловно, это платформенные компоненты и их переиспользование в командах, это ваша экосистема разработки, а также, качественно выстроенная система метрик и работы с производственными бенчмарками. Также потенциально очень перспективной в плане повышения эффективности разработки выглядит технология генеративного ИИ в применении к производственному циклу создания программного обеспечения.
Данные аспекты я раскрою в следующей статье.