Эпизод #0: знакомство
Привет, хабр! Меня зовут Алена, я системный аналитик. Еще 2 года назад я развивала робототехнику в России, а потом случилось присоединение к команде «Группы Астра» и переезд в Иннополис. Мне очень откликнулся тогда посыл будущих коллег: «Меняем ход ИТ». Быть причастной к чему-то глобальному и важному — эта мысль давно зрела внутри меня. Так началось мое погружение в клубок процессов, завязавшийся внутри растущей компании.
Моя роль была совершенно новой. Техническая дирекция тогда только создавалась и на старте нас было всего 3 человека, а сейчас уже более 80. Перед нами поставили глобальную цель: систематизировать процессы и построить матрицу совместимости продуктов.
Когда я подступилась к задаче, решила ориентироваться на лучшие практики рынка, в том числе на Microsoft. Пыталась адаптировать на наши процессы заинтересовавший меня опыт других, но на реалии «Группы Астра» он полностью не перекладывался. У зарубежных коллег процессы совместимости давно автоматизированы — настолько, что конечный пользователь продукта может в любое время получить по запросу автоматизированный отчет на совместимость. Нам же в начале работы пришлось делать это вручную.
На сегодняшний день мы в компании уже реализовываем автоматизированный процесс и в будущем придем к полной автоматизации. Теперь подробнее о вводных.
Дано:
Постоянно подключающиеся к контуру компании новые продуктовые команды, что соответствовало обозначенной стратегии M&A, а так же вновь возникающие продукты внутри компании. Все это влечет за собой значительное увеличение времени и ресурсов для интеграции новых команд и продуктов в текущие бизнес-процессы.
Не всегда синхронизированная внутренняя коммуникация. Все новоприбывшие привыкли в большинстве своем существовать в реалиях маленького коллектива, где каждый друг друга знает и нет необходимости учитывать окружающий контекст. Соответственно, политик и практик взаимодействия для поддержания единого инфополя тоже не существовало.
Непрерывность развития экосистемы продуктов. Она подвижна, адаптируема и это неизбежно. Количество наших продуктов постоянно растет вместе с ростом команды, увеличением сложности управления продуктами, необходимостью поиска новых инструментов для координации работы. Также растёт сложность в обучении новых сотрудников — нужно прикладывать больше усилий для поддержания корпоративной культуры.
Ниже поделюсь опытом выстраивания экосистемы продуктов и настройки слаженной работы между плохо знакомыми продуктовыми командами. Расскажу, когда и как использовать матрицу ролей, чтобы уменьшить время на постановку задачи. Что сделать для упрощения коммуникации между командами и как повысить уровень вовлеченности коллег.
Эпизод #1: звездная пыль
Идея строить экосистему продуктов начала зарождаться в 2017 году, а активно к ее реализации мы приступили в 2021 году — поняли, что пришло время. Нужно было закрывать новые потребности клиентов и пройти в очень сжатые сроки путь западных вендоров, на который они потратили десятки лет. Один из доступных способов: обогатить свой продуктовый портфель и привлечь другие продукты. Его мы и выбрали.
Представим, что нам надо собрать экипаж на космический корабль. Мы объединили в одну команду разных супергероев и ждем, что произойдет чудо. Они якобы будут понимать друг друга с полуслова и случится синергия. Но чудо не происходит. Проблема в том, что они с разных планет и разговаривают на разных языках.
Каждый новый продукт в портфеле компании — это отдельный супергерой. У него своя суперсила, зона действия и уникальные комбинации, в которых он может сочетаться с другими продуктами. Или работать обособленно, что тоже возможно.
Стратегия слияния и поглощения новых продуктов способствовала увеличению энтропии. С одной стороны, на лицо очевидный прирост классных людей, талантливых команд. С другой — у всех присоединившихся коллективов по-своему отстроенные процессы. Идея создать единую экосистему обрастала дополнительными условиями.
Формирование бизнес-процессов не всегда успевало за масштабированием компании и игнорировать рост стало невозможно. Пора было менять подход.
Эпизод #2: вызовы роста
Когда новый продукт попадает в портфель компании извне, он должен адаптироваться к условиям существования среди других продуктов. Принятым в «Группе Астра» методологиям разработки, разветвленной структуре, устоявшимся релизным циклам, регламентам и рабочим инструментам, процессам согласования нововведений, и даже таким базовым вещам, как корпоративные каналы связи. Адаптация может сопровождаться болезненными но неотъемлемыми практиками: от изменения привычной методологии создания продукта до, банально, внедрения нового корпоративного мессенджера.
Из этого вытекает несколько основных параметров, по которым наши продуктовые команды различаются:
1. Разный уровень зрелости команд.
В Астре есть состоявшиеся коллективы, которые работают на рынке более 15 лет со штатом +100 человек. Например, команда, разрабатывающая ОС Astra Linux и входящая в «Группу Астра» компания ISPsystem — и это если не брать в расчет другие команды, не относящиеся к продукту непосредственно, но отвечающие за сервис. Например, ДВиС (Дирекция внедрения и сопровождения) численностью 425 человек. Есть и такие команды, которые присоединились уже полностью сформированные, со своими лучшими практиками — ICL Astra Services, подключившиеся в начале 2023 года. Они вошли в контур как совместное предприятие и имеют бóльшую автономность. Бывают и совсем молодые коллективы, которые сначала присоединяются ламповым составом, после чего начинают активно расти в рамках компании и переходят на стадию поиска кандидатов. Например как команда, занимающаяся разработкой продукта GitFlic.
2. Разные стадии жизненного цикла продукта.
Наш флагманский продукт, операционная система Astra Linux SE, за 15 лет обрела свои устоявшиеся правила. Есть и молодые продукты на стадии MVP, у которых процесс выработки норм и правил еще только формируется. Всем продуктовым командам нужно вместе в какой-то мере синхронизироваться, понимать стадии развития продукта и вытекающие отсюда потребности, чтобы выстраивать совместную работу.
Здесь оговорюсь, что мы не ставили перед собой цели полностью синхронизировать релизные циклы всех продуктов в нашем портфеле. Однако выстроить общую продуктовую картину, чтобы понимать созависимость, прорабатывать интеграции и другие формы взаимодействия продуктов, — в этом и есть наша цель.
3. Отличающиеся бизнес-процессы внутри команд.
Это раскрывается подробнее на разной скорости релизов, разных подходах к формированию MVP, разном темпе работы и отличающихся дальнейших Release Notes. И, конечно, разном темпе разработки в целом.
У нас действуют преимущественно Scrum и Kanban. Проблема в том, что если нужно проработать общую функциональность для двух продуктов, команды которых работают по разным методологиям, процесс может тормозиться. Например, Kanban-команда задачу в бэклоге начинает реализовывать сразу. А команда, работающая по Scrum, приступит к доработке той же функциональности только в следующем спринте.
Подобные шероховатости вызывают цепную реакцию. Чем больше в системе становится элементов, тем более ярко видна созависимость.
Эпизод #3: из темной материи в...светлое будущее
Шаг 1. Сбор в космическую экспедицию: получаем картину о продуктах AS IS
Упорядочивать все перечисленное выше мы начали с исследования. Идею, модель расчета и методологию анкетирования позаимствовали от команды ICL Astra services, но адаптировали подход под себя. В итоге получилась интеграция классического аналитического исследования стейкхолдеров по опросным листам с методологией создания продуктового портфеля. В финале исследования мы хотели получить наглядную картину с выведенными критериями, которые позволили бы оценить степень зрелости продукта. Затем на этой основе планировали построить гипотезы о дальнейшем треке развития продукта.
Исследование началось во II квартале 2023 года. Сначала мы определили цель исследования, утвердили список участников, всех входящих в исследование продуктов, в том числе на стадии MVP и/или замороженных продуктов.
Затем стартовал этап разработки анкеты и сбора данных — это заняло около 4 недель. Решили опрашивать по 1-2 человека от каждой продуктовой команды. В основном это были менеджер продукта и владелец продукта. Выбор пал на данные роли, так как эти люди видели цельную картину и смогли детально рассказать о продукте без привлечения дополнительных коллег, что усложнило бы проведение исследования.
При разработке анкеты мы основывались на параметрах, по которым собирали продуктовый портфель:
Общая информация по продукту: область применения, компоненты, технологии, стек, стадия жизненного цикла продукта, отвечающая стандартам «Группы Астра» и т.д.
Широта применения продукта: ценность, объем рынка, конкуренция, аналоги и т.д.
Уровень зрелости продукта по его внутренним показателям, что является аналогом УГТ (Уровень готовности технологии): функционал, уровень компетенций команды, зрелость архитектуры, уровень технической документации и т.д.
Параметры, отражающие спрос на наши продукты у текущих клиентов за каждый предыдущий квартал: воронка продаж, количество проданных лицензий и т.д.
Мы намеренно не использовали открытые вопросы в анкете, чтобы было проще валидировать и агрегировать полученные данные. Коллеги из продуктовых команд должны были выбирать из перечня заранее сформулированных ответов, однако они могли оставлять комментарии — при финализации результатов мы это учитывали.
В рамках этих же 4 недель мы точечно возвращались к респондентам для уточнения деталей ответов, если требовалось что-то раскрыть или если ответы были неоднозначными. Например, со стейкхолдерами многосоставного продукта Astra Infrastructure Cloud случилась ситуация, когда выбрать заранее сформированный в анкете вариант ответа было невозможно. Данный продукт зависит от других продуктов и продуктовых команд в его составе — то есть компонентов. Поэтому в анкете менеджер и владелец продукта Astra Infrastructure Cloud указывали, что за разработку/доработку и поддержку отвечают продуктовые команды компонентов платформы. Заранее подготовленные варианты ответа им совсем не подходили.
Хочется отдельно отметить сложность работы с разными каналами коммуникации, которые нам пришлось задействовать, чтобы охватить всех продакт-менеджеров и владельцев продукта из разных команд. Кому-то приходилось писать в личные сообщения, для кого-то была удобнее почта, кто-то просил отправить в корпоративный мессенджер. Это как раз иллюстрация того, с чем предстояло бороться тогда и над чем еще предстоит продолжить работу.
Еще примерно одна неделя после анкетирования потребовалась нашей рабочей группе для анализа результатов и формирование отчета. Мы провели взвешенную количественную оценку от 1 до 5 по каждому критерию, входящему в параметры продукта. Для этого была заранее сформирована модель оценки. Так нам удалось сегментировать продуктовый портфель по области применения, целевой аудитории и т.д. Эти результаты легли в основу отчета, который мы представили топ-менеджменту компании.
Благодаря опросу нам удалось собрать информацию по архитектурным блокам продукта, используемому стеку, российским и зарубежным аналогам, ответственным за продукт людям из команды и другим параметрам. Общая картина потихоньку начинала складываться, пусть и пока в сыром виде.
Промежуточные итоги
Когда у нас перед глазами появилась наглядная картина, мы смогли отслеживать количество продуктов на стадии MVP, проверять гипотезы, наблюдать динамику и срок перехода на новую ступень, планировать мероприятия для успешного выхода на рынок. Мы обрели возможность работать над стратегией продуктового портфеля: добавлять новые продукты, выпускать старые, или фокусироваться на развитии ключевых продуктов.
Благодаря консолидированным данным стало видно, как и почему меняется ТОП-5 продуктов в компании по продажам, которые зависят напрямую от уровня зрелости. Рейтинг возглавляют продукты, которые достаточно давно на рынке, у них налажены релизные циклы, обширный ключевой функционал, закрывающий потребности клиентов, хорошо подготовленная техническая документация и выстроенная работа технической поддержки.
Теперь если мы видим, что какой-то продукт выбивается по срокам, — вовремя принимаем меры и усиливаем команду. Например, когда мы заметили отсутствие положительной динамики по критерию зрелости одного из продуктов, причина крылась в нехватке архитектора в команде. Направили ресурсы на поиск нужного кандидата и, к счастью, в следующей итерации увидели переход продукта на новую стадию.
При первом подходе создания продуктового портфеля мы заметили, что зрелые продукты, в арсенале которых есть демо-лаборатория, имеют большую лояльность у клиентов. Демо-лаборатория — это площадка для демонстрации продукта потенциальным клиентам. Ее наличие повышает спрос, а это напрямую влияет на успех продукта. Так мы убедились, что в демо-лабораторию однозначно нужно инвестировать.
И еще один важный инсайт, порожденный сведенными результатами исследования. Мы осознали, что пересматривать и корректировать продуктовый портфель нужно на протяжении всего времени его существования. Здесь можно использовать, например, методы матрицы BCG или массив GE/McKinsey. Это поможет определить, какие продукты следует развивать, поддерживать, или, возможно, заморозить на текущий момент.
Лирическое отступление: «темная материя» проникает в процесс исследования
Отдельно хочу сказать о сопротивлении к участию в исследовании со стороны продуктовых команд. Перед стартом проекта мы запустили коммуникацию, где подробно описали цель исследования и вовлеченных в этот процесс коллег. Подсветили, что вся полученная в ходе исследования информация останется исключительно в рамках проектной группы и результаты будут представлены в обобщенном виде. Несмотря на это, мы все-равно получали уточняющие вопросы, сталкивались с недоверием и нежеланием делиться информацией.
Поделюсь одним из самых запоминающихся случаев сопротивления. Это ситуация, когда одна из команд на наш запрос заполнить информацию о продукте сообщила, что они являются другой компанией и ничего разглашать не будут. Случилось столкновение с пережитками старой культуры, когда все могли сосуществовать более-менее обособлено в компании меньшего масштаба. Однако, пора было меняться.
Еще один случай произошел с командой, которая по степени развития продукта уже требовала большой коллектив, но при этом все еще существовала в немногочисленном составе. Это привело к ситуации, когда люди работают на пределе, совмещают несколько функций, а владелец продукта напоминает «человека-оркестр». В таком контексте любой внешний контроль, пусть даже со стороны коллег и с благой целью, воспринимался заведомо негативно.
Другая сложность, с которой мы столкнулись, — при заполнении анкеты коллеги хотели описать продукт лучше, чем было на самом деле. Им не всегда удавалось рассказывать о происходящем с продуктом без прикрас. Тогда как задача была как раз в том, чтобы адекватно оценить картину и понять, куда ресурсы необходимо добавить, чем помочь, как сделать лучше для всех.
Упомяну также разное представление в разных командах о внутренних сервисах компании. Многие коллеги восприняли выделенную подструктуру в нашем лице как готовый сервис, который сразу облегчит их работу после присоединения к группе компаний. Но это был только первый шаг на пути к выстраиванию отлаженного процесса. У нас не было за спиной опыта и наработок в масштабе всей «Группы Астра». Их предстояло только создать и тут необходимо было обоюдное и равнозначное участие.
Все описанное выше — нормальная реакция на изменения в компании. Люди в большинстве своем не любят перемены и надо быть к этому готовым. И мы очень благодарны коллегам за вовлеченность в этот процесс.
Шаг 2. Сложить созвездия: делаем матрицу совместимости продуктов
При построении экосистемы нам важно создавать безотказную, безопасную работу продуктов в связке, закрывающую задачи клиентов своим функционалом. Для этого мы решили создать матрицу совместимости продуктов «Группы Астра».
Матрица совместимости продуктов — это сводная таблица с информацией о продуктах компании, их принципах совместной работы и совместимости с версиями ОС.
Почему нам было важно сделать матрицу:
Когда продукты совместимы, они могут легко объединяться и работать вместе, создавая бесшовное взаимодействие для пользователей без дополнительных переключений и настроек.
Когда продукты работают вместе, они увеличивают ценность друг друга и дают пользователю больше возможностей.
Команды с высокой степенью совместимости продуктов могут быстрее и легче внедрять новые технологии и продукты в существующую экосистему.
Изначально, когда мы прорабатывали макет первой матрицы совместимости, решили размещать всю необходимую информацию в одной сводной таблице. Она получилась внушительного размера, и когда коллеги поделились обратной связью, мы стали пересматривать формат. Тогда родилась идея разделить матрицу на слои.
Поэтому сейчас — это многоуровневый аналитический инструмент, разделенный на несколько слоев.
Первый слой. Матрица совместимости продуктов линейки «Группы Астра» между собой (кроме ОС Astra Linux SE). Сюда входят продукты на этапе эксплуатации и их варианты совместимости с учетом текущих версий.
Второй слой. Матрица совместимости продуктов «Группы Астра» с нашим флагманским продуктом — Операционной системой Astra Linux SE. Это выделено в отдельный слой. Поскольку сама по себе операционная система — это достаточно сложный продукт с множеством нюансов в виде встроенных средств защиты информации, в таком виде пользователю легче воспринимать возможные сочетания совместимости.
Третий слой. Матрица совместимости продуктов линейки «Группы Астра» со сторонними ОС (помимо ОС Astra Linux SE). Здесь отражены возможности интеграции нашей экосистемы продуктов.
Подробнее с итоговым вариантом матрицы можно ознакомиться на официальном сайте компании в разделе Документация.
Когда мы ее создали, это структурировало наши знания на новом уровне. Но возникает другой вопрос: как между продуктами и подразделениями в компании налажена коммуникация и возможно ли в принципе достичь какой-то согласованности?
Шаг 3. Выстраиваем внеземную коммуникацию
Когда мы начали систематизировать картину по продуктам, в компании существовало много инструментов для корпоративного общения — внутренний мессенджер, справочник сотрудников, адресная книга...Но это не помогало понять, кто за что отвечает.
Представим, что вы обнаружили ошибку в документации. Раньше нужно было зайти в справочник сотрудников, разобраться, к какому подразделению относится продукт, найти ответственного менеджера. Затем связаться с ним в корпоративном чате, ждать ответа и привлечения нужного коллеги через него. Только после этого задачу принимали в работу. Должно было пройти около 30 минут.
Чтобы сократить период простоя, мы разработали расширенную матрицу ролей. В ней есть два уровня: ответственные роли на уровне группы компаний и ответственные в рамках каждой продуктовой команды.
Теперь мы идем в расширенную матрицу ролей и за одну итерацию находим контакт ответственного за документацию по конкретному продукту. Задача берется в работу сразу тем, кому она адресована. Мы сократили количество звеньев в цепочке и время на решение задачи с 30 до 6 минут.
Но даже когда появились такие ощутимые бенефиты, как более прозрачная структура и отработанная коммуникация, мы сталкивались с вопросами от продуктовых команд: «а зачем нам все это делать?»
Шаг 4. Через тернии к...популярно объясняем новый экосистемный подход
Представим себя на месте продуктовой команды. Вы внутри думаете о развитии продукта, ведете активную разработку. Внезапно к вам приходят и говорят: «теперь мы будем строить экосистему, развивать продуктовый портфель, взаимодействовать с другими продуктовыми командами! Подключаемся!»
Продуктовые команды тем временем начинают проходить все 5 стадий принятия:
В этот момент важно вовремя прояснить суть изменений. Зачем все это? К чему мы идем и какая наша глобальная цель?
Мы решали эту задачу комплексной коммуникацией. Помимо отдельной работы с каждой продуктовой командой проводили и продолжаем проводить:
TechDays — офлайн-конференции внутри компании 2 раза в год. Там мы общаемся вживую, слушаем технические доклады от коллег и синхронизируемся на глобальном уровне в перспективе на ближайшие полгода.
ТехКоммьюнити — регулярно мы собираем представителей команд для обсуждения промежуточных результатов. Это онлайн-формат встреч продуктовых команд, который проходит примерно раз в квартал. Он вносит понимание, кто на каком этапе находится и позволяет командам налаживать совместную работу.
Технический совет — раз в полтора месяца мы организуем мероприятие, где топ-менеджмент обсуждает стратегию и целеполагание. Здесь принимаются более глобальные решения и затем транслируются продуктовым командам.
ТехСреда — еженедельные технические митапы. Это также онлайн мероприятие, где точечно освещается одна техническая тема каждую неделю. Можно погрузиться в разные продуктовые и не только продуктовые команды, их проблемы, понять, над чем сейчас идет работа. Формат позволяет более оперативно отслеживать внутренние изменения.
Эти мероприятия стимулировали межкомандное общение, выявляли проблемы и сильные стороны в моменте.
Шаг 5. Надо просто взять и сделать: создаем шаблон страницы продукта
Рассогласованность между командами и продуктовыми артефактами мы решили с помощью обвязочных процессов. Привели к единому стандарту этапы планирования, документирования, тестирования, управления конфигурациями и версиями продуктов, сбора и анализа данных, обучения и поддержки.
В этом нам помог продуктово-сервисный подход. Помимо работы самой продуктовой команды, он дает каждому продукту инфраструктуру и сервисную обвязку на уровне компании. Туда можно включить услуги пресейла, разворачивание автоматизированных стендов, постановку на техподдержку, разработку базы знаний по продукту и многое другое.
Шаблон страницы продукта работает по двухступенчатой схеме:
У нас есть продукт на определенной стадии зрелости. Команда заполняет информацию в шаблон страницы и получает сервис, соответствующий этапу развития продукта.
Когда сервис получен, команда быстрее выходит на новый уровень развития своего продукта, поскольку не тратит свои ресурсы на обвязочные процессы.
Разберем пример, когда продукт уже прошел стадию MVP и перешел на этап пресейла. На предпродажной стадии команда может работать над улучшением продукта, проводить демонстрации для потенциальных клиентов и так далее.
Мы просим команду заполнить информацию о продукте, чтобы предоставить соответствующий стадии пресейла сервис, принятый в «Группе Астра». Это собственный автоматически разворачиваемый эталонный стенд. Он поможет в контролируемом окружении проверить работоспособность продукта, продемонстрировать продукт в действии и получить обратную связь от первых пользователей.
Для плавного перехода на следующую стадию и понимания, в какой момент какой сервис доступен, мы создали автоматические Playbook'и. С ними командам стало проще понимать, что нужно сделать для получения конкретного сервиса благодаря чек-листам.
Шаг Х. Что делать дальше?
Следующий этап — добавить гибкости в продуктовые пространства. И здесь нас ждет еще много работы. Поскольку на текущий момент все нововведения приходится добавлять продуктовой команде вручную в каждое отдельное пространство, объясняя попутно «зачем?», «что?» и «почему?».
Например, мы изменили шаблон дорожной карты развития продукта. Он стал детальнее и теперь с ним удобнее делать долгосрочное планирование. Проблема в том, что часть продуктов уже завели в свои продуктовые пространства старый шаблон дорожной карты и теперь поменять мы его сможем только руками самой продуктовой команды. А это всегда добавляет дополнительные сложности.
С 2023 года началась консолидация дорожных карт всех имеющихся продуктов и она продолжается на текущий момент. В продуктовых командах перестройка и понимание пользы проведенной нами работы еще приживается. Зато топ-менеджмент и коммерческий отдел сразу ощутили, насколько удобнее и прозрачнее стали процессы в компании.
Результаты
Сейчас наш продуктовый портфель можно представить в виде такой схемы.
Мы изменили мышление в компании от локального, сосредоточенного на одном продукте, к сквозному и направленному на все продуктовые команды.
Нам удалось создать практику общего планирования и целеполагания. Получилось уйти от разрозненных действий на уровне отдельного продукта и приблизиться к выбору оптимального решения с точки зрения доставки ценности заказчику.
И главное — мы объединили продуктовые команды и наладили коммуникацию между ними. Теперь они сами инициируют взаимодействие, строят планы и реализовывают их. Например, один из лидов нашей разработки поделился со смежной продуктовой командой результатом внедренного фреймворка и другая команда взяла это на вооружение.
Отдельно как результат выделю актуализацию продуктового портфеля. Очевидно, что это итерационный процесс — с течением времени всегда могут появляться новые продукты, в то время как другие могут стать менее прибыльными или подходящими. Продуктовый портфель должен регулярно пересматриваться и обновляться. В нашей компании актуализация данных продуктового портфеля происходит каждый квартал.
Работа над выстраиванием экосистемы продуктов помогла компании скорректировать глобальную стратегию и двигаться в направлении облачной интеграции. Здесь отмечу, что важна не столько синхронизация всех продуктов со всеми, а та продуктовая связка, которая будет себя оправдывать в рамках облака. При этом разработка «облачной стратегии» накладывает обязательное условие — все продукты должны быть совместимы с ОС Astra Linux SE.
Это не итоговый результат, а только начало пути долгого выстраивания экосистемы продуктов. И мы будем следовать заданному курсу. Сейчас происходит переработка подхода взаимодействия с командами с нашей стороны. Возможно, нам стоило быть более мягкими с командами и подобрать адресные способы получения информации к каждому. Это был первый совместный опыт такого масштаба и собственные шишки набивали как мы, команда исследователей, так и команды продуктов.