Оптимизируем процесс сквозного проектирования — от бизнес-идеи до инфраструктуры
Алексей Грибанов, директор департамента архитектуры проектов «Ростелеком», поделился с Bercut тем, как строится процесс изменений в крупнейшем в России интегрированном провайдере цифровых услуг и решений. Алексей рассказал, об устройстве сквозного проектирования от бизнес-идеи до инфраструктуры: ролях, зонах ответственности, инструментах, а главное — ключевых подходах организации.
Сложная сегментация IT-ландшафта — наследие прошлых лет — и огромное количество единовременно исполняемых проектов и программ являются не самыми удобными предпосылками для формирования процесса сквозного проектирования систем. Тем не менее, вопреки и отчасти благодаря всему этому «Ростелеком» смог обеспечить контроль за связанностью изменений и движение к нужному состоянию IT-ландшафта.
Что из себя представляет Ростелеком?
Восемь предприятий, предоставляющих услуги связи в различных регионах России, в 2011 году были объединены в одну крупную компанию на базе телком-оператора «Ростелеком». Таким образом десять сопряженных между собой ИТ-ландшафтов, каждый из которых ранее являлся самостоятельным отдельным телеком-оператором, привнесли свое наследие в корпорацию. Сегодня «Ростелеком» — это еще и группа компаний, в ее состав входит более 30 организаций. Интересы каждой из них оказывают определенное влияние на все внутренние процессы холдинга.
Недавно к корпорации присоединился альтернативный оператор мобильной связи Tele2, дополнив своими системами самый масштабный ИТ-ландшафт компании в стране, содержащий свыше 3000 информационных систем. Штат ИТ-специалистов «Ростелекома» превышает 6000 человек, распределенных по всем регионам Российской Федерации. И все они вовлечены в те или иные процессы холдинга; более 2000 сотрудников ИТ подразделений непосредственно участвуют в развитии информационных систем.
Исторические предпосылки
С самого начала развития ИТ-ландшафта «Ростелекома» в 2011 году компания в течение длительного времени придерживалась принципа: «Быстрее, выше, сильнее!».
Нам хотелось поскорее вывести на рынок новые сервисы и продукты, предоставить как можно больше решений и возможностей для наших клиентов.
Это стремление привело к невыгодному сценарию развития ИТ-ландшафта, когда бизнес полностью определяет правила игры, а специалист становится заложником требований заказчика. Во многих бизнес-подразделениях отношения с вендорами выстраивались напрямую, и это привело к тому, что запросы на изменения ландшафта подразумевали внедрение новых систем, а не просто добавление новых функциональностей, так называемых фич. В результате ИТ-ландшафт наполнился большим количеством монолитов, огромным объемом данных и функциями, за которые параллельно отвечают несколько различных систем. При этом все они работали в тесной взаимосвязи, и влияние одной системы нарушало стабильность работы прочих систем и дальнейшее их развитие. К тому же увеличивалась стоимость содержания самих систем из-за пробелов в знаниях специалистов об их устройстве, росла зависимость от вендоров.
Прежде чем перекраивать структуру и вносить изменения в процессы принятия решений, необходимо было переосмыслить устоявшиеся роли и направления развития информационных технологий. Для изменения ситуации «Ростелеком» использовал комплексный подход.
Мы определили, что ИТ-специалисты — это не просто люди, выполняющие заказы, а сотрудники, способные полноценно участвовать в развитии компании. В процессе такой культурной трансформации стало очевидно, что нам требуется создать новые процессы. Соответственно, в нашей структуре должны появиться совершенно новые роли. Мы приступили к изучению внутренней ИТ-структуры и увидели, что у нас есть проектные менеджеры, ИТ и бизнес-аналитики, исторически находящиеся в бизнес-подразделениях. Но, учитывая масштабы холдинга, количество систем и заказчиков, с которыми мы взаимодействуем, стало понятно, что ролью одного аналитика нам не обойтись. Помимо детализированной проработки задач в зоне ответственности аналитиков, важно принимать решения, оценивая их влияние на весь ИТ-ландшафт. По этой причине появилось еще несколько ролей, связанных с архитектурными решениями.
ИТ-культура
Чтобы обозначить контрагентам из внутренних подразделений понятную позицию ИТ, был сформирован ИТ-манифест, декларирующий отношение ИТ к проектам и заказчикам. Для повышения эффективности ИТ, был разработан и внедрён принципиально новый подход к формированию самоорганизующихся кругов, который назвали «Karma Framework».
Мы сформулировали для себя задачу не просто выполнять запросы, которые нам поступают, а стать действительно эффективными. Сотрудники ИТ-подразделения в шутливой форме, но с полной серьезностью заявили всем, что могут быть полезными и подходят ко всему ответственно, назначив себе показатель эффективности «карма ИТ» (которая растет при надлежащем исполнении своей работы).
Роли в управлении архитектурой
В ряде случаев бывает сложно провести границу между аналитиками и архитекторами, но в масштабах корпорации это стало возможным. В попытке описать бизнес-процессы «Ростелекома» как организации, выделены пять слоев, каждый из которых раскрывает определенную грань компании со стороны бизнес-подразделений и в зоне ответственности ИТ.
Это слои информационной архитектуры, одновременно содержащие в себе описания данных, с которыми работают бизнес-подразделения; логических данных в информационных системах; прикладной и интеграционной архитектур с учетом взаимосвязей между большим количеством систем; и технической архитектуры, включающей в себя все техническое обеспечение.
Безусловно, для описания всех архитектурных слоев и управления ими одного специалиста недостаточно, поэтому было введено несколько новых ролей:
корпоративного и информационного архитекторов — они смотрят на ИТ-ландшафт в целом и принимают участие в стратегическом планировании его развития на ближайшие 3–5 лет;
технических архитекторов, отвечающих за размещение в центре обработки данных (ЦОД) виртуальных сред и информационных систем, а также за сетевую связность между всеми этими конструкциями;
solution-архитекторов, от которых требуется чуть менее детальная проработка. Это самые массовые должности. Занимающие их сотрудники работают с проектами и первыми принимают инициативы от бизнес-подразделений, обсуждают проекты с аналитиками и делают первые прогнозы по реализации полученной бизнес-задачи или инициативы;
- архитектора по интеграции.
Архитектор не может жить одним проектом и мыслить горизонтами одного бизнес-заказа, его задача — определить пожелания заказчика и сформулировать решение, позволяющее получить результат не только на сегодняшний день, но с перспективой дальнейшего ценностного развития продукта. Это возможно только при условии правильно выстроенной внутренней коммуникации.
Задача архитектора – предложить лучшее архитектурное решение для «Ростелекома», не ограничиваясь решением задачи конкретного бизнес-заказчика.
Чтобы обеспечить управляемое взаимодействие между сотрудниками на стадии подготовки проекта к защите на архитектурном комитете, была введена практика предзащиты. На ней архитектор делится с коллегами своими планами по тому или иному решению, обсуждает с ними взаимосвязи со структурами, службами и прочими проектами и рассказывает, как он планирует учитывать эти зависимости. Зачастую в работе ИТ-архитекторов «Ростелекома» может параллельно находиться около 60 и более проектов, по многим из них специалисты готовят архитектурные решения в моменте. Вторая цель, которая решается предзащитными встречами, — выявление похожих проектов, уже реализованных ранее. В процессе проверки может выясниться, что в ИТ-ландшафте уже существуют заготовки, подходящие компоненты, а иногда и целая система, развитие которой может принести желаемый результат. Одновременно с этим решается задача кросс-контроля: при длительной работе над одним проектом сложнее выявлять его недостатки, а взгляд со стороны помогает выявить недочеты. Командная работа и коммуникация с коллегами способствует накоплению собственных корпоративных знаний о ИТ-ландшафте.
Фазы типового проекта в «Ростелекоме»
На стадии предпроектного анализа мы отправляем к заказчику сразу трех специалистов: руководителя проекта, ИТ-аналитика и архитектора. Они готовят solution-архитектуру, детальное описание требований и первичную оценку затрат на реализацию проекта. Спустя какое-то время после запуска этот организационный процесс начал давать сбои: участилась эскалация вопросов по действиям того или иного специалиста, затягивались сроки выполнения задач. Чтобы выявить причины этих сложностей, мы проанализировали взаимосвязи сотрудников на стадии предпроектного анализа.
Процесс происходил следующим образом:
1. Аналитик принимает от бизнес-заказчика запрос (детализирует информацию, помогает точно и системно их описать), готовит бизнес-требования к проекту.
2. Одновременно подключается solution-архитектор, который получает у заказчика важную для него информацию и определяет, какие системы и их функции нужны проекту.
3. Solution-архитектор передает обработанную информацию ИТ-аналитику для подготовки документов, которые передаются в разработку.
На данном этапе стали поступать жалобы от технических архитекторов на отсутствие необходимой информации. Мы погрузились в процесс взаимодействия сотрудников и поняли, где именно происходит коммуникационный сбой.
4. Руководитель проекта подключает технического архитектора.
5. Технический архитектор получает задачу на проработку виртуальных сред и размещение кода в конкретных ЦОД, после чего запрашивает у руководителя проекта дополнительную информацию. У руководителя проекта нет этой информации, и он пытается найти ее самостоятельно из доступных ему источников.
6. Технический архитектор выполняет работу, далее руководитель проекта формирует заявку на изменение инфраструктуры и создание виртуальных сред и передает ее в службу развития инфраструктуры.
7. Коллеги принимают заявку, рассматривают и зачастую возвращают без внесения каких-либо изменений, с дополнительными комментариями.
8. В связи с этим, руководитель проекта снова идет к техническому архитектору пытается уточнить детали. Начинается стадия 3-сторонних переговоров. Тем временем, проектная команда находится в информационном вакууме.
9. Результатом исполнения всех заявок становится создание виртуальных сред, которые позволяют командам разработки разворачивать написанный ими код.
Тем временем, руководитель проекта вязнет в микроменеджменте и сборе информации, что негативно сказывается на скорости и управляемости проекта в целом.
На этапе разбора сложившейся ситуации вскрылись и следующие факты. При разработке технической архитектуры и формировании заявок на выделение виртуальных сред, технический архитектор ожидает получить компонентную архитектуру проекта и матрицу доступов, т. е. описание в терминах IP-адресов, портов и хостов, на которых размещены те или иные компоненты. В документации, которой обладает руководитель проекта, этой информации нет, и он начинает искать ее в сомнительных источниках. Технический архитектор возвращает техническую архитектуру, которую руководитель проекта передает в подразделение развития инфраструктуры и сети. Результат деятельности возвращается в виде виртуальных машин, требующихся доступов, которые отправляются в разработку. Следовательно, не хватает роли специалиста для написания компонентной архитектуры и матрицы доступов.
Описание ошибок:
Было принято решение пересмотреть принципы работы всех специалистов, вовлеченных в процесс, и теперь он выглядит следующим образом:
- Заказчик готовит бизнес-требования.
- ИТ-аналитик принимает их и начинает с ними работать.
- Параллельно с бизнес-требованиями начинает работать solution-aрхитектор, который готовит компонентную архитектуру с матрицами доступов и передает информацию напрямую техническому архитектору.
- Технический архитектор, с этого момента, не просто готовит проект размещения, а напрямую взаимодействует с подразделением инфраструктуры и сети для совместной проработки нюансов размещения виртуальных машин в центрах обработки данных. Далее, он самостоятельно передает команде разработки информацию о созданных виртуальных средах и доступах.
Таким образом мы снизили объем информационной нагрузки на руководителя проекта. Что важно для меня как руководителя функции архитекторов, мы существенно повысили уровень ответственности специалистов, привлеченных к реализации проекта. С этого момента они по-настоящему вовлеклись в процесс внесения фактической ценности в проект. В результате мы повысили моральный настрой и качество работы проектной команды.
Выводы:
1. Даже в классической методолгии процессов, нужно быть готовыми к изменению процессов
2. Любое действие должно иметь смысл. Если его нет - избавляйтесь от действия.
3. Нужнее те, кто делает результат "под ключ", а не закрывает только этап процесса
4. Нужно быть готовыми выходить за рамки. PUSH THE LIMITS!