Привет, Хабр! Меня зовут Олег Брандин, я главный архитектор в РСХБ‑Интех. Сегодня расскажу вам свое понимание пути от ИТ‑стратегии и ЦиЗ СЦТ (Цели и задачи Стратегии цифровой трансформации) до формирования продуктовой команды и защиты бюджета в реалиях государственного сектора, а также как владелец продукта мог бы действовать, чтобы получить необходимые компетенции в команду.

При выстраивании продуктовой команды и развитии Частного облака (ЧО) в РСХБ я руководствуюсь подходом, который выработался на основе опыта решения задач на стыке бизнеса и разработке. Поэтому мне необходимо начать с того, как и почему появилось ЧО в нашем банке.

Облако — это виртуальная среда, реализующая бизнес‑модель «вычислительные ресурсы по запросу». Заказчику здесь и сейчас требуется некий объем вычислительных ресурсов, и они предоставляются именно тогда, когда нужно. Когда задача решена, ресурсы возвращаются в общую копилку.

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

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

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

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

Как правило, осознание этих аспектов влечет за собой трансформацию бизнес‑модели, и модели управления. Мы помним, что ИТ — это в первую очередь про оптимизацию и ускорение через автоматизацию. Поэтому чем дальше, тем сложнее находить способы сократить издержки на исполнении процессов за счет ИТ технологий. Приходится коренным образом перестраивать бизнес‑процессы так, чтобы они становились по‑настоящему «цифровыми». Мы живем в эпоху Четвертой технической революции, общепринятое название которой — Индустрия 4.0. Она характеризуется множественными изменениями бизнес‑моделей под влиянием развивающихся ИТ‑технологий, появлением новых цифровых бизнес‑моделей и разработки стратегий цифровой трансформации бизнесов.

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

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

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

• для нужд разработки за год создается почти 7000 запросов на создание ВМ;

• среднее время выполнения запроса 3,8 дня.

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

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

Давайте посмотрим, что у нас дано: фиксированный набор, параметризируемых бизнес‑процессов, на выходе которых появляется фиксированный набор артефактов. А бизнес‑задача звучит так: «ускорить бизнес‑процессы».

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

В перспективе ЧО предназначено для ускорения бизнес‑процессов связанных с выделением вычислительных ресурсов разработчику, за счет автоматизации рутинных действий, создания различных коробочных ИТ‑услуг и сервисов, например:

• создание, изменение и удаление виртуальных машин;

• база данных как сервис;

• web‑proxy как сервис;

• API для управления инфраструктурой с помощью кода.

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

Итак, перейдем к части про подход к формированию продуктовой команды.

Знакома ситуация, в которой вы приходите к руководству, говорите, что нужно 3 разраба, а вас просят описать задачи, которыми им предстоит заниматься? Это часто звучит по-разному, но суть одна: необходимо объяснить, что получит бизнес, инвестировав в дополнительных сотрудников.

Когда я пришел в РСХБ, команда, занимающаяся разработкой облака, была во многом стихийной. Продукт только вышел из стадии MVP, а это значит, что очень многое находилось на стадии «надо делать, но времени не хватает»: на ранних этапах продуктом занимались разные архитекторы, процессы не до конца изучены и формализованы, зоны ответственности размыты, а функции поддержки и сопровождения ложатся на команду разработки.

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

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

Следует помнить, что, задекларировав зоны ответственности, необходимо объяснить понятными словами, что именно в них входит, какие задачи решает задействованный специалист. Вот пример. Фраза «Зона ответственности архитектора решений: сохранение видения продукта, обеспечение архитектурной целостности, повышение эксплуатационной зрелости и эффективности бизнес‑процессов» хороша, когда надо экономно использовать место на слайде. Но что делает архитектор решений, придя на работу?

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

• управление архитектурой;

• управление разработкой;

• управление инфраструктурой;

• управление продуктом и проектами;

• разработка программного обеспечения.

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

Далее мы можем визуализировать в виде организационной диаграммы текущую и целевые структуры продуктовой команды:

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

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

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

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

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

Продуктовый подход

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

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

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

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

Приведу пример. Архитектор считает, что важнее развивать продукт «правильно». Он совершенно прав в том, что нечестно будет называть виртуальную машину с установленной программой PaaS’ом. Было бы хорошо, если бы научились разворачивать кластер, ставить на него нужное ПО, реализовать кучу различных интерфейсов, а также сделать сервис автоматически масштабируемым и отказоустойчивым. В общем, мы все знаем, о чем идет речь. Внутренне я с ним согласен, ведь такой подход кажется более системным, упорядоченным и передовым. Беда только в том, что бизнес не может ждать столько, сколько требуется на такую реализацию. Бизнесу здесь и сейчас нужно поставить, ну скажем, Kafk’у. И в работу берем задачу сделать шаблон ВМ с установленной сконфигурированной Kafk’ой в standalone конфигурации. Этот пример того, как команда работает над ВМ с предустановленным ПО ради решения текущей задачи бизнеса. Именно это решение важнее, именно оно помогает получить конкурентное преимущество здесь и сейчас. И, как мне кажется, этот пример показывает, насколько важно держать команду в контексте. 

Подход, о котором речь и который призван помочь, называется Lean Canvas. Что это и для чего? Продуктовый подход концентрируется вокруг ценностного предложения, Value Proposition. А его как раз необходимо правильно понимать и выстроить подходящую бизнес-модель. LC как раз помогает нам очень просто, компактно и наглядно описать наш будущий продукт на листе А4. В связи с тем, что реальные потребности потребителя могут меняться очень быстро, необходимо иметь возможность менять наше представление легко и просто. И компактность LC играет здесь на руку. Также важно понимать, что ценностные предложения для одного продукта могут быть разные. Я люблю автомобили, поэтому приведу пример простой и понятный из этой плоскости. Продукт — автомобиль. Ценностное предложение можно сформулировать либо как владение собственным автомобилем, либо как услугу такси. В этом примере для одного продукта два разных VP и два разных LC, реализующих разные бизнес-модели.

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

LC появился не как самостоятельная разработка, а как развитие более раннего подхода Business Model Canvas, разработанного Александром Остервальдом. Основным отличием является то, что LC подходит для описания нового продукта или планируемой трансформация бизнес-модели, а BMC, она же бизнес-модель Остервальдера, хороша, когда нужно структурировать существующий бизнес с целью представления его потенциальным инвесторам.

Справедливости ради, стоит сказать, что внутренний инвестор, или спонсор, такой же инвестор, как и внешний, и BMC подойдет для внутренних продаж прекрасно. Но так как ЧО довольно свежая концепция в РСХБ, то в моменте LC оказался удобнее. Поскольку эти фреймворки очень близки, то впоследствии не составит труда трансформировать при необходимости LC в BMC.

LC представляет собой таблицу из 9 блоков, которые заполняются в определенном порядке, а читается слева направо сверху вниз:

• Блок №1. Определяем целевую аудиторию

• Блок №2. Проблема и альтернативные решения

• Блок №3. Уникальная ценность продукта

• Блок №4. Как продукт решит проблемы

• Блок №5. Способы продвижения

• Блок №6. Как продукт принесет доход

• Блок №7. На что тратим деньги

• Блок №8. Ключевые показатели

• Блок №9. Скрытое преимущество

Я пробегусь по LC Частного облака, чтобы продемонстрировать пользу этого инструмента.

Я понимаю, что выдал огромное количество сложной информации, которая далека от разработки, и кажется, что ценность этой информации невелика. Но если посмотреть на один из постулатов продуктового подхода, о котором я говорил («вся команда понимает ради чего работает»), становится понятно, для чего я рассказывал в первой части доклада о видении продуктовой архитектуры и целях бизнеса. Без этого понимания очень сложно поддерживать мотивацию команды. LC позволяет показать наглядно эту ценность, взглянуть на нее быстро, буквально за минуты, трансформировать бизнес-модель продукта в ситуации, когда потребности бизнеса меняются в соответствии с рыночной обстановкой.

В модели LC также видно место и для структуры расходов на ФОТ, что позволяет положить еще один кирпичик понимания в фундамент продукта. А главное, когда мы смотрим на LC, становится легче понять, какой именно специалист нужен в команде здесь и сейчас. Представьте, что вы пришли к спонсору и попросили у него 13 FTE. Когда я готовил доклад, я представлял себе саркастически кислые лица тех, кто проходил этим путем и знает ответ.

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

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

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

Подытожу короткими выводами

• Банку требуется короткий Т2М, для этого нужен трансформированный бизнес-процесс, для реализации которого необходимы определенные мероприятия, в том числе запуск Частного облака.

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

• Чтобы достичь максимальной эффективности команды необходимо поддерживать актуальное видение развития продукта у технической команды.

• Всегда имейте актуальное описание продукта, например, с использованием фреймворка Lean Canvas.