Как выдержать сроки на проекте с 10+ командами в экосистеме?

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

 

 

Для начала представлюсь и расскажу, чем я занимаюсь.

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

Я руководитель проектов, занимаюсь электронным документооборотом в МТС.

Кроме этого, у меня достаточно большой проект по интеграции бизнеса и вузов – я читаю два авторских курса в Московском авиационном институте для студентов магистратуры, 5-6 курс. Это курсы «Архитектура высоконагруженных систем» и «Производство цифрового продукта». Я веду эти курсы, потому что считаю, что мало что-то знать и уметь – нужно делиться своими знаниями. Причем не только им отдавать кому-то знания, но и, в том числе, получать новые знания от этого взаимодействия.

 

Как выдержать сроки?

 

 

Теперь перейдем к основной тематике. Выдерживать сроки очень просто. Есть три основных подхода, про которые все говорят:

1. заложить дополнительное финансирование;

2. провести качественную аналитику;

3. грамотно управлять проектом.

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

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

Если вы руководитель проекта или аналитик, участвующий во внедрении проекта, рано или поздно вы столкнетесь с тем, что ваш проект станет частью внедрения в экосистему. Экосистема – это сейчас модно, особенно в России. Сейчас, куда ни глянь, все строят экосистемы. Возможно, 1С еще не назвала себя экосистемой, но боюсь, это ближайший шаг. Скоро вам скажут, что 1С – это экосистема: и продуктов, и вообще всего.

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

Но работать с экосистемой надо внимательно. Смотреть – какая экосистема, и что с ней делать. Мой доклад как раз будет про особенности работы с экосистемой.

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

 

 

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

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

Вам наверняка известны на слуху банковские экосистемы: зеленая экосистема – Сбер, желтая экосистема – Тинькофф, голубая экосистема – Газпромбанк. На чем строятся банковские экосистемы? Какая у них «услуга-спонсор»? Глобально – это банковская транзакция, банковская услуга. Банки берут комиссию за денежные переводы, берут проценты за выдачу кредитов и так далее.

А какая «золотая услуга» в экосистеме МТС? На чем в МТС базируется основной заработок? Сейчас в телекоме зарабатывают только на передаче данных. Передача данных – это и есть наша «услуга-фундамент», «золотая услуга», которая является долгосрочной. Передача данных всеми востребована, ее объем постоянно растет, особенно в пандемию, это массовая услуга. Если услуга не массовая и не долгосрочная, ничего на ней построить, к сожалению, нельзя.

Теперь давайте пример Яндекса. На какой услуге выехал Яндекс? С чего он начинался? Это вопрос спорный – у меня студенты спорят, какая услуга у Яндекса была основной изначально. Но я все-таки склоняюсь к тому, что основной у них была контекстная реклама и выдача в поиске за денежку. А уже потом стали разворачиваться Яндекс.Карты, появился Яндекс Go, Яндекс.Маркет и так далее. В любом случае все стартует с какой-то «золотой услуги».

Но если вы видите какую-то экосистему, в которой есть только одна «золотая услуга», это, наверное, нулевой уровень, и пока про экосистему говорить рано.

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

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

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

Вопрос в том, что нужны идеи, как это все использовать. Это к вопросу о будущих профессиях. Меня студенты спрашивают: «Какая будущая профессия самая востребованная?» По моему мнению, это аналитик данных. Причем не просто данных, а больших данных, big data. Потому что данных много – никто не знает, что с ними делать. И аналитики данных призваны придумать, дать нам идею, как этими данными воспользоваться. Анализ больших данных позволит нам грамотно построить экосистему второго уровня – это когда идут рекомендации от одного продукта к другому.

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

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

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

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

А мы говорим именно про пользу – про CJM, клиентский путь, который будет влиять сразу на несколько продуктов. Мы туда идем.

Давайте вернемся к управлению проектами. Как управлять проектами для разных экосистем? Все достаточно просто.

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

• На первом уровне уже появляется продуктовый подход. Мы добавляем бесшовный переход, чтобы развивать продукты – свои, чужие. Мы привлекаем в свою экосистему новые продукты, чтобы расти взрывным образом.
  Например, в экосистеме МТС порядка 650 продуктов – это 650 команд, которые работают на внутренний и на внешний рынок. Из всего многообразия этих продуктов вы видите только 10-20, которые относятся к вашему сегменту B2C – business-to-consumer. А есть еще сегмент B2B, B2G, B2O и т.д.

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

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

 

 

Теперь об управлении проектами при интеграционном подходе. Интеграционные проекты в экосистеме имеют следующие особенности:

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

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

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

Это была постановка проблематики – мы с вами договорились о том, что такое экосистема, расставили приоритеты.

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

 

Интеграционный подход при работе с экосистемой. Особенности, которые нужно учесть

 

Первый кейс – это участие скрытого стейкхолдера.

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

Все абсолютно верно, но у нас случился хитрый кейс, о котором я сейчас расскажу.

 

 

Нам нужно было разработать ЭДО для складских форм М-8 и М-15, которые оформляют при выдаче оборудования вовне какому-то юридическому лицу. Например, когда оборудование отгружается подрядчикам – чтобы они строили новые вышки, меняли сломавшиеся и так далее.

На слайде я представил схему:

• наша учетная схема на базе Oracle;

• продукт DocFlow, который отвечает за электронный документооборот;

• и необходимо было интегрироваться с продуктом «Маркетолог», который отправляет смс, чтобы подписывать данные документы простой электронной подписью.

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

 

 

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

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

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

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

 

 

Поэтому вам первый совет:

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

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

Здесь все достаточно просто, но про таких скрытых стейкхолдеров не надо забывать.

Кстати, если вас заинтересовал кейс про формы М-8 и М-15, у нас есть достаточно большая статья на Habr о том, как мы это внедряли, и что там было интересного и сложного.

 

Второй кейс связан с Legacy-системами.

 

 

Legacy-система – это устаревшая, но востребованная, обязательная система, сложная для изменения и рефакторинга.

В любой экосистеме всегда будет Legacy-система. И отказаться от нее у вас не получится, потому что именно эта Legacy-система обслуживает ту самую «золотую услугу», «услугу-спонсора», на которой базируется вся экосистема. Эта «золотая услуга» будет тянуть за собой Legacy-систему, и вы должны с ней считаться.

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

В принципе, ничего особенного – простая интеграция, которую поддерживали три команды.

 

 

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

Сначала мы предполагали, что добавляется еще одна интеграция, и на этом все. Но в этой схеме получилась хитрая история:

• Флагманский биллинг – это биллинг от «золотой услуги». Его трогать нельзя, дорабатывать сложно.

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

• А к внешним операторам ЭДО вообще никаких требований не предъявишь.

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

 

 

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

Legacy-систему не доработать – это либо очень дорого, либо очень сложно.

А написать с нуля адаптер – небольшой программный модуль, который через SELECT залезает в базу данных и какие-то данные из нее выбирает – гораздо проще и дешевле.

 

 

Для нашей задачи мы написали два адаптера – здесь на слайде они обозначены. Причем можно видеть, что второй адаптер, который подключался к нашей основной биллинговой системе, наши разработчики так и назвали – Адаптер.

Все достаточно успешно запустилось. Мы фактически не трогали Legacy-системы, а написали два дополнительных программных модуля.

Получается, что в этой интеграции участвовали пять команд – к нам присоединилась отдельная команда, которая писала эти адаптеры.

 

 

Но если вообще говорить про количество команд, которые участвовали в этом проекте, их было 10 штук. И это при том, что у нас небольшой проект в рамках экосистемы – у нас всего лишь электронный документооборот, который находится где-то сбоку. Конечно, наш ЭДО приносит много пользы, экономит бумагу – ежемесячно на бумаге мы экономим целый лес. И пиковые нагрузки у нас достаточно хорошие – допустим, за один день 1 мая 2023 года у нас ушло 367 тысяч документов. Но сам проект небольшой.

И все равно набирается порядка 10 команд:

• интеграционная команда;

• сервис тестирования;

• команда по интеграции с 1С;

• две команды техподдержки – уровня L1 и L2.

И все эти команды нужно собрать, обучить, чтобы они понимали, как это все работает – здесь тоже нужно соблюсти сроки.

 

 

Что делать, если в рамках экосистемы так много команд, и все – кто в лес, кто по дрова? У всех свои бэклоги, свои приоритеты, свои CJM, свои CLV – да все что угодно… А тут мы приходим со словами: «Нам нужен новый проект».

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

• Поэтому у нас в экосистеме МТС за развитием продуктов следят дополнительные рекомендательные органы – технологический комитет и продуктовый комитет. Без утверждения этими двумя комитетами ни одна продуктовая команда не может защитить свой бэклог и свое финансирование в рамках работы экосистемы:

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

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

• И потом уже можно спуститься на уровень согласования с заказчиками – заказчики могут повысить или понизить свои интеграционные приоритеты, мы можем с ними о чем-то договориться.

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

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

 

 

Итак, советы по работе с Legacy-системами:

• внимательно оценивайте, как влияет ваш интеграционный проект на ту Legacy-систему, которая обслуживает «золотую услугу».;

• и думайте о том, чтобы писать с нуля какие-то адаптеры к этой системе.

 

Третий кейс – это как раз оценка влияния каждой из команд, когда они прошли все комитеты, согласовали приоритеты с заказчиком, но все равно что-то работает не так.

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

 

 

Расскажу про оценку рисков команд на конкретном примере.

В рамках того же проекта мы дополнительно интегрировались с такой системой, как ЕИС. Это система госзакупок, где нужно вести контракты для госзаказчиков, выгружать первичные документы. Нам приходится работать с системой госзакупок, потому что у МТС достаточно много заказчиков. Но я не могу к себе притащить команду ЕИС: им задачи ставит госзаказчик – я не могу к себе госзаказчика притащить, чтобы с ним пообщаться, они вообще сидят где-то далеко в казначействе. А мне-то что делать? Мне с этой командой нужно работать.

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

Мы разработали теорию, что есть 8 пар рисков, которые могут друг другу противоречить в данном конкретном случае. Мы просто оцениваем эти риски относительно команды.

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

Или можете просто на бумажке все это нарисовать – там тоже будет все понятно.

 

 

Первый интересующий меня вопрос: какой приоритет в разработке у той команды, с которой я интегрируюсь?

У них может быть свой продуктовый приоритет или же приоритет моего проекта.

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

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

Посередине у меня стоит синий кружок – это просто центр.

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

 

 

Вторая пара, которую я смотрю: возможен ли учет наших требований?

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

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

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

 

 

Есть ли риски изменения продуктов, с которыми мы интегрируемся? Насколько часто этот продукт меняется?

У ЕИС с этим вопросом было достаточно много проблем, поэтому я оценил риск достаточно высоко.

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

История достаточно печальная, а договориться с ними сложно.

 

 

Дальше я смотрю на финансирование. Здесь есть три варианта:

• Или это конечный продукт.

• Или они свой продукт еще дорабатывают, и мы свой тоже дорабатываем, а потом вместе приходим к финалу.

• Или же это сервис или платформа, за которые нужно платить без конца.

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

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

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

 

 

Потом мы смотрим, какой у них бэклог задач.

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

В случае ЕИС ситуация более-менее стабильная – аварии у них бывают, но не так много, и они их быстро исправляют.

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

 

 

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

Здесь мы оцениваем ЕИС позитивно, но не слишком.

 

 

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

В случае с ЕИС у нас позитивный опыт. У них есть чат в WhatsApp, где присутствуют работники команды ЕИС. С ними можно пообщаться и какие-то сложные вопросы на лету выяснить.

В принципе, это позитивно. Но без начальника, конечно же, никак не обойтись.

 

 

И потом мы говорим про интеграцию – есть вообще интеграция или нет?

В случае с ЕИС у нас вообще замечательная история. Я поставил точку ровно посередине по одной простой причине. Нам нужно две интеграции:

• интеграция, чтобы отправить документ,

• и интеграция, чтобы подписать.

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

Получается очень интересная история: мы в автоматическом режиме документы все отправляем в ЕИС, а потом всем персональным менеджерам говорим: «Уважаемый персональный менеджер, зайди, пожалуйста, в личный кабинет оператора ЭДО и подпиши все документы лично в ручном режиме. Получается, что вроде бы интеграция есть, но она какая-то недоделанная. И с этим тоже риски.

 

 

Оценивая каждую команду, с которой мы интегрируемся, мы видим:

• зеленую зону, где мы можем расти и можем быть спокойны;

• и видим красную зону – это зона риска.

И дальше нам нужно подумать над этими точками зоны риска – можно ли их подвинуть к центру или перетащить какими-то усилиями в зеленую зону.

В каких-то случаях нельзя. Это называется «риски, которые нельзя победить». Мы их приняли к сведению и на этом остановились. Мы про них помним.

Но в некоторых случаях можно. Мы в нашем кейсе некоторые точки перетащили в зеленую зону – объединились с другими игроками рынка и стали выставлять требования уже не от имени одной компании, а стали выставлять требования от отрасли. И понятно, что мы конкуренты с «Билайн», «МегаФон», «Ростелеком», но в случае, когда мы делаем общее единое дело, мы уже не конкуренты, мы вместе работаем и сотрудничаем.

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

 

Заключение

 

 

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

 

 

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

• зрелость экосистемы – вы должны помнить, что экосистема бывает четырех уровней, и оценивать, что это в вашем конкретном случае;

• скрытых стейхолдеров;

• что есть Legacy-система, к которой фактически нельзя прикасаться, потому что она обслуживает ту самую «золотую услугу»;

• зрелость каждой конкретной команды, которая с вами работает.

Если принимать все это во внимание, ваш проект по интеграции с экосистемой пойдет немного лучше, и сроки работы с таким большим количеством команд будут входить в плановые – вы получите примерно то, что хотите.

Но, конечно же, риски всегда есть. Я вам не могу сказать, что мои рекомендации – это абсолютная пилюля, которая снимет все риски. Но об этом нужно думать.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART Анализ & Управление в ИТ-проектах.