Как управлять ИТ-проектами в экосистеме на разных этапах развития

Руководитель проектов в МТС Digital Константин Архипов рассказывает об эволюции цифровых экосистем и главных рисках в проектах, где участвуют более 10 команд.

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

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

Уровень, когда экосистемы как таковой ещё нет. Она только в планах. На этом уровне происходит поиск «золотой» услуги.

«Золотая» услуга должна быть востребованной, массовой и перспективной на несколько лет вперёд. В МТС «золотые» услуги — телеком и передача данных, в Тинькофф — банковская транзакция, в Яндексе — поиск в браузере и контекстная реклама.

Говорить об особенностях управления проектами на этом уровне пока рано. Никаких изменений в управлении проектами ещё нет.

Этот уровень характеризуется бурным ростом продуктов, входящих в экосистему. Она фактически «засасывает» новые продукты в себя. При этом «экосистемность» таких продуктов поддерживается за счёт бесшовного перехода между ними.

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

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

В экосистеме накапливается огромное количество данных, которые можно агрегировать, и на их основе предлагать клиентам ноу-хау. Быстрее выводить на рынок новые продукты помогают платформы экосистемы (сервисные, технологические, интеллектуальные).

К 2023 году большинство экосистем в России достигли этого уровня. Управление проектами здесь становится более сложным. Появляются интеграционные проекты, где участвуют 10+ команд.

Здесь уже необходимо учитывать соблюдение следующих условий:

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

Риск — случайное и непредвиденное событие, которое влечёт за собой негативный сценарий управления проектом. Все риски, связанные с экосистемой, относятся к операционным рискам.

Рассмотрим основные.

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

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

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

Нужно ли привлекать к работе над проектом таких стейкхолдеров? Ответ очень простой — нужно. Необходимо искать всех заинтересованных лиц относительно каждого переиспользуемого продукта и нового бизнес-процесса. Руководитель проектов обязан заострить внимание своих аналитиков на этом риске.

Чаще всего legacy-система работает с «золотой» услугой, которая гарантирует финансовую устойчивость экосистемы. Дорабатывать такую систему достаточно сложно, долго и дорого. Если в новом интеграционном процессе есть legacy-система, будьте готовы к тому, что доработать её будет или невозможно, или крайне дорого для проекта.

Что в этом случае делать? Всё просто: писать к такой системе адаптер. По сути это дополнительный модуль экосистемы, который будет забирать данные из legacy-системы и конвертировать в нужный формат.

Руководитель проектов вместе с аналитиками и архитекторами обязан оценить стоимость и сроки доработки самой legacy-системы и рассмотреть вариант с разработкой адаптера.

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

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

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

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

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

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

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

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

Да! Наличие таких инструментов говорит о развитии экосистемы дальше. У экосистемы уровня развития 2+ уже появляются помощники продуктовых команд — комитеты экосистемы.

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

Что будет дальше, после 2+ этапа развития экосистемы? Этот вопрос интересует многих.

Мы в МТС движемся в сторону оказания клиенту услуги, которая будет влиять сразу на несколько продуктов — на их доход, CJM (customer journey map), CLV (customer lifetime value) и т. п.

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