Karma framework что это

Обновлено: 06.07.2024

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

От модели управления ИТ в компании зависит гибкость бизнес-процессов, быстрота реакции на вызовы рынка, появление новых сервисов для клиентов и многое другое. В «Ростелекоме» трансформация моделей управления ИТ проходит параллельно с диверсификацией продуктового портфеля и выходом компании на новые цифровые рынки. Компания двигается от классической иерархической структуры к более прогрессивным моделям управления. Переходные модели были основаны на широко распространенном матричном принципе подчинения. Однако и у них был ряд ограничений: сложность распределения ресурсов между различными направлениями бизнеса, проблемы реализации кросс-функциональных проектов, размывание ответственности между руководителями и многие другие, с которыми постоянно сталкивается большинство крупных компаний на рынке.

В конце 2019 года «Ростелеком» перешел от матричной к собственной — «плоской» модели управления в ИТ (Karma Framework), основа которой — самоорганизующиеся команды. Такая модель сочетает лучшие современные управленческие практики и культурно-ценностный подход, которые существенно повышают вовлеченность сотрудников в общий процесс и избавляют от сложных иерархических цепочек и бюрократии. В командах каждый сотрудник понимает свою роль, зону ответственности и стратегическую цель работы. При наличии у компании широкой продуктовой линейки, а также в условиях постоянных изменений рынка и стремительном развитии технологий только такой подход позволяет найти быстрое и эффективное ИТ-решение на любой вызов.

«Если вы спросите ИТ-директоров, что является самым большим препятствием для изменений в их организациях, наиболее распространенным ответом будет — корпоративная культура. В опросе ИТ-директоров 2018 года 46%[1] опрошенных назвали корпоративную культуру самым большим препятствием на пути к цифровой трансформации. Этот ответ не удивителен, ведь культура аморфна — ее трудно определить и очень трудно изменить». Старший вице-президент по информационным технологиям «Ростелекома» Кирилл Меньшов: «Трансформация модели управления и ИТ-культуры не была для нас самоцелью. Это реакция на те вызовы, которые ставит перед нами рынок, ответ на ожидания наших клиентов. Мы хотели стать еще эффективнее, быстрее, качественнее и одновременно с этим создать комфортную среду совместной работы. Свою стратегию мы строили не на внедрении пусть и самого современного, но единообразного подхода, а на развитии разнообразия практик и самоорганизации команд для решения ключевых бизнес-задач. Мы точно не в конце пути, нам еще многое предстоит сделать: как для наших клиентов, так и для сотрудников. Однако это был важный этап трансформации, и он позади. Внимание со стороны Gartner, а значит и мирового экспертного сообщества к нашей ИТ-трансформации вселяет в нас уверенность в верно выбранном направлении и говорит о самом высоком уровне профессионализма большой ИТ-команды группы компаний “Ростелеком”».

Ознакомиться с проектом «Ростелекома» можно на сайте компании Gartner по ссылке.

Gartner, Inc. (NYSE: IT) — ведущая мировая исследовательская компания, специализирующаяся на изучении рынка информационных технологий, член S&P 500. Компания снабжает бизнес-лидеров знаниями и инструментами для достижения критически важных целей сегодня и построения успешных организаций завтра. Комплекс экспертиз, основанный на данных исследований, позволяет клиентам принимать правильные решения по наиболее важным вопросам. Gartner — надежный консультант и объективный источник информации для более чем 15 000 компаний в 100 странах мира.

Прежде чем разбираться в понятиях Karma Framework, заглянем в историю.

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

В XX веке идеи Конта развиваются, например, в образовательной системе Нидерландов.

В 1926 году была учреждена школа под названием «Детский Общественный Семинар» (нидерл. Werkplaats Kindergemeenschap), которая построена на принципах самоуправления и социократии. Школа действует до сих пор, среди ее известных выпускников — предыдущая королева Нидерландов и ныне принцесса Беатрикс.

Главное, что объединяет социократию и холакратию — это отсутствие управленческих вертикалей, привычных отделов и департаментов.

А что такое Karma? Заглянем внутрь: пять букв — пять основных принципов:

K — KARMIC (карма и ценности)
A — ADAPTIVE (адаптивность — гибкость и ускорение реакций)
R — RELEVANT (релевантность — целесообразность и удобство)
M — MEANINGFUL (осознанность — самоорганизация на уровне смысла)
A — APPROACH (комбинированный подход)

Karma Framework идет дальше моделей социократии и холакратии

Иерархическая структура превращается в сложную систему вложенных кругов.

Это похоже на живой организм, состоящий из клеток. Клетки не выясняют, кто из них главнее и кто выше в иерархии, они просто заняты каждая своим делом.

K — KARMIC

Карма и ценности

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

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

Как кусок кода может вызывать эмоции?

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

Важно не только техническое совершенство продукта (хотя без него остальное вообще не имеет смысла), но и эмоции, которые остаются у клиента. И не только у клиента. Кармичность — это про эмоциональную вовлеченность и, в итоге, удовлетворенность всех участников процесса. В том числе самих сотрудников. Проще говоря, Karma Framework учитывает не только измеримые метрики, но и эмоции.

A — ADAPTIVE

Адаптивность — Гибкость и ускорение реакций

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

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

R — RELEVANT

Релевантность — Целесообразность и удобство

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

Было бы странным составлять единый план тренировок для сборных по футболу и шахматам. Karma Framework дает каждому кругу возможность самому выбрать операционную модель для реализации своего предназначения. Agile? Канбан? Пожалуйста, если он работает для этой задачи. Встречи раз в неделю? Каждое утро? Удаленная работа? WhatsApp или Telegram? Почта или таск-трекер? Что угодно. Вы сами решаете это внутри команды, исходя из задач. У каждого есть право голоса, задача лидера круга — собрать и учесть все мнения и все аргументы.

M — MEANINGFUL

Осознанность — Самоорганизация на уровне смысла

Все команды собираются, чтобы выполнить конкретное предназначение. Оно есть у каждой команды (или в терминах Karma Framework — круга). Например, предназначение всего ИТ Ростелеком — быть лучшим ИТ, с которым бизнес когда-либо работал, работает или будет работать. Принимая любое решение, выполняя любую задачу, важно спрашивать себя: зачем я это делаю? Приблизит ли мое действие всю команду к выполнению нашего предназначения?

Какую бы задачу ни выполнял человек, он будет решать ее гораздо эффективнее, если понимает, зачем он ее делает и почему она важна. Karma Framework должен уничтожить как класс все задачи, выполняемые «для галочки». Да, конкретная работа может быть рутинной, трудоемкой, но она всегда должна иметь смысл, а сотрудник должен понимать, зачем именно он ее выполняет.

A — APPROACH

Комбинированный подход

В мире ИТ существует множество готовых решений. Многочисленные фреймворки могут в чем-то подходить команде, а в чем-то — нет. Мы не обязаны выбирать что-то одно. Можно комбинировать, отбирая себе лучшее из каждого подхода.

Универсальных инструментов не существует. Для разных проектов эффективны разные инструменты, и уже очевидно, что один подход не может работать в большой, сложно устроенной и решающей самые разные задачи компании. Круги должны сами определять, какой подход эффективнее в их случае — а если что-то идет не так, оперативно менять тактику, не дожидаясь команды сверху. Потому что никакого «верха», который будет думать за круг, в Karma Framework нет.

Устройство кругов

Давайте рассмотрим базовый элемент Karma Framework — круг. О нем и о структуре управления на основе иерархии кругов расскажут эксперты в видео:

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

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

Как устроен круг?

Каждый круг обычно создается родительским кругом. К примеру: круг IT-Board, самый верхнеуровневый круг всего IT Ростелеком, создает круг поменьше: Wink. Этот круг работает над одноименным продуктом.

Тема до сих пор весьма хайповая, и админы, добавляющие в свои резюме словечко DevOps, автоматически рассчитывают на +100К к зарплате. Но мы не про это. Мы хотим рассказать про то, как Ростелеком ИТ внедряет CI/CD & DevOps в энтерпрайзовый ИТ-ландшафт и тяжелые монолитные Legacy-системы.

Первая часть нашего руководства будет про «Почему, зачем, как получить на это денег от бизнеса и как получается внедрять CI/CD в десятки проектных команд очень большой компании». Это интересная практическая информация для руководителей ИТ-подразделений и лидов. Вторая часть статьи – сугубо инженерная, с описанием прикладных подходов, инструментов и реализаций в зависимости от типа и технологического статуса проекта. И третий блок будет про процесс внедрения в рамках Karma Framework в круге. Поехали!

Ретро. Как всё начиналось

Примерно за год ИТ-разработка Ростелекома в определенном периметре выстроила современную инфраструктуру, основанную на микросервисной архитектуре с развертыванием в кластере OpenShift. Эту инфру мы потом назвали «Платформой Цифровых Продуктов», далее ПЦП. Мы позже подробнее опишем состав ПЦП.

Внедрение ПЦП позволило существенно перестроить работу некоторых команд, которые были лоцированы в одном структурном подразделении, с одной точкой управления. Это важно, так как у нас получилось создать в определенной степени технологический и методологический анклав и выстроить новые практики, которые отличаются от остальной корпорации — вплоть до того, что мы не поддержали промышленный корпоративный стандарт, и проекты, запускавшиеся в ПЦП, выводились в продакшн на конечных юзеров, но не передавались в общую эксплуатацию. По сути это означает, что продукты НЕ падали вообще и были вне контура эксплуатации. Но с СБ ИТ все договоренности мы имели и нужные мероприятия делали. Плюс несколько команд начали работать в продуктовом подходе по Agile. Разумеется, это стало возможным на определенном классе продуктов и сервисов, что мы запускали. В основном это были относительно легкие фронтовые и middleware-решения, которые легко создавались на основе микросервисов и быстро запускались — web-проекты, но с интеграциями в глубокий корпоративный бэкенд. Часть функционала и интеграции запиливались в микросервисы, которые могли использовать другие проекты. Тем не менее, для большой корпорации это был «космос» — оказывается, за 3-6 месяцев можно развернуть для конечных пользователей довольно большой проект или сервис с интеграцией в общий ИТ-ландшафт, опробовать бизнес-гипотезы и модели или просто включить в продуктовую линейку и возможности для клиентов. Сноска для понимания стартаперов: в больших компаниях со множеством региональных биллингов на миллионы людей раньше нельзя было взять и просто за 3-6 месяцев запустить на всю клиентскую базу новый продукт или сервис. Обычно успехом считалось, что это время уходит только на согласование бюджета и ТЗ. А продукт в коде появлялся не ранее чем через год. Еще здесь стоит заметить, что любой стартап через пару лет становится легаси ))

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

И вот тут-то оказалось, что массы — это разнокалиберные монолитные легаси-системы «глубокого залегания» порой циклопического масштаба и набора функционала с историей, уходящей вглубь веков. Класс систем типа АСР, CRM, аналитические системы, хранилища тарифных планов, системы ордеринга — в общем, чудный мир OSS/BSS. И вся наша микросервисная архитектура, весь наш DevOps, OpenShift и CI/CD — как попытка научить стадо слонов синхронному плаванию. Причем как чисто технологически, так и коммуникационно. Примерно полгода у нас ушло на исследование: насколько вообще применим пусть не микросервисный, а хотя бы компонентный инфраструктурный подход к монолитным системам. Еще сложнее оказалось объяснить и вовлечь ИТ-хэдов проектов и команд в исследование на тему как и главное — зачем распиливать на компоненты ядро, где вся логика зашита, например, в пакеты Oracle. Ну допустим. А далее эстафета достигает, достигает, достигает… бизнес-заказчиков. И бизнес задает главный вопрос жизни, вселенной и всего такого — а зачем мы будем платить за архитектурный рефакторинг систем, которые и так работают?

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

Вот на этом этапе и возникают докладчики на DevOps-конференциях с заявлениями, что в энтерпрайзе все это не летит.

Практики внедрения CI/CD&DevOps в Ростелекоме

Не то чтобы мы самые умные или упоротые. Но мы все же решили посмотреть, что есть за горизонтом событий. Даа, «мало, мало огня, мы хотим еще немного больше». Горит в Ростелекоме внутренний огонь!

Начали с простых внутрикорпоративных докладов и митапов для различных проектных ИТ-команд и для инхаус-бизнес-заказчиков. Это не дало результат с точки зрения конкретных внедрений CI/CD & практик DevOps в проекты за периметром ПЦП. Но когда ты этим занимаешься больше года, то повестка начинает проникать даже в весьма консервативные команды и дальние регионы компании. Дискурс меняется, и вдруг некоторые коллеги начинают козырять словом Kubernetes как своим! Это определенно шаг вперед.

Вскоре реплицировался инфраструктурный кластер с похожим на ПЦП подходом в макрорегиональном филиале Ростелекома в Краснодаре, где ребята стали внедрять практику DevOps и CI/CD процессы в новые проекты, но в более тяжелый класс систем, нежели web-решения. Появились общие подходы к автотестированию, юнит-тестированию, нагрузочному тестированию, подготовки к релизу, мониторингу. Потихоньку общий подход к архитектуре, основанной на микросервисах и компонентах, стал доминирующим для новых стартующих в разработку систем. Однако по-прежнему существующие монолитные легаси-системы жили своей жизнью.

Следующим шагом стала попытка организовать гильдии «девопсеров». Это горизонтально организованный коммуникационный формат, где различные проектные команды обмениваются опытом и практиками внедрения DevOps и CI/CD. Различные гильдии были созданы и по другим ИТ-специализациям. Формат какое-то время успешно поработал в части дальнейшего проникновения актуальных практик в различные ИТ-команды. Десятки DevOps-инженеров Ростелекома объединились и выносили задачки и свой опыт в общее тематическое инфополе. Но в итоге данный формат затух. Прежде всего потому, что сложно самоподдерживать мотивацию без целеполагания, оформленного в роадмап. Второй веской причиной затухания гильдий стало то, что этот формат без обязательств так и не позволил на системном уровне внедрять CI/CD в большие проекты и легаси-системы. Как ни крути, но не DevOps-инженеры принимают решения о переформатировании всего технологического и релизного цикла разработки или о рефакторинге.

Примерно за три года миссионерской работы знание и принимаемость темы DevOps и CI/CD в компании вышли за порог отрицания. Проделанная работа в итоге начала все же приводить к тому, что по крайней мере IT-команды стали экспериментировать и что-то использовать из инструментов интеграции и развёртывания, особенно в части тестирования и работы с git. И, наконец, мы начали пробовать внедрять CI/CD на некоторых системах тяжелого класса с монолитным ядром в БД и легаси-кодом, которые оказались по разработке в прямом операционном управлении.

Важный кейс и настоящий профит от ПЦП, от сложившегося подхода к архитектуре, разработке и набора инструментов мы получили для сетапа самого яркого огонька в корпоративном ИТ в России 2020 — это экосистемы. Концепция цифровых экосистем с кросс-связанностью и кросс-сервисами по всей продуктовой линейке отлично приземляется на микросервисную архитектуру. И у нас уже была готовая инфраструктура, откуда стали быстро расти экосистемные ростки Ростелекома. А что требуется для таких стейтмент-терминов как цифровая экосистема? Правильно — quick win. Чайки, налетайте!

Несмотря на заметные результаты, как ни странно, целевое дело пошло на проектах, которые начинали делать не мы, и проекты пришли к нам в Центр Компетенции digital-разработки Ростелеком ИТ в тяжелом нестабильном состоянии. До 90% ресурса команд уходило на багфикс и латание дыр. Техдолг уходил за горизонт полугода. О функциональном развитии можно было забыть. При этом системы были чрезвычайно важны и нужны бизнесу. Вот здесь и случились прорывы. Возвращаясь к вопросу бизнеса: «Зачем мы будем платить за архитектурный рефакторинг систем, которые и так работают?». А вот если системы еле ворочаются и критикал-баги зашкаливают, то разговор с бизнесом из томного превращается в конструктив. У вас как у ИТ-разработки появляется возможность найти у бизнеса понимание, что для сохранения жизнеспособности систем и затем их развития нужно не перепиливать все с нуля (на больших системах часто это вообще невозможно по технологическим или бюджетным причинам), а начать внедрять DevOps и CI/CD процессы с параллельным архитектурным рефакторингом, и начинать нужно с особенно критичных мест в системе и оптимизации релизного цикла. А внедрять можно даже в рамках существующего ресурса команды и бюджета. Мы, например, брали на себя коммиты, что через 3 месяца сократим затраты ресурса команды проекта на багфикс с состояния более 50% AS IS, в котором мы получили проект, до приемлемых в среднем по индустрии менее 20%. При том практически без роста бюджета и состава команды.

Что в итоге сработало. Круги и Karma Framework

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

Но реальный системный результат дало использование формата кругов в рамках Karma Framework. Поскольку «Ростелеком ИТ» – не внешний вендор (тоже важный момент, кстати), а инхаус-разработчик в группе компаний ПАО «Ростелеком», то мы работаем не за маржинальность, а за карму. Это не абстракция, а финансовая модель, помноженная на ключевые ценности. И, следуя фундаментальным ценностям, таким как открытость, честность, доверие и партнерство между ИТ и бизнес-заказчиками, мы как ИТ зарабатываем карму, или другими словами — свою репутацию и лояльность бизнеса, стараясь делать продукты качественно, быстро и за адекватные бюджеты. Для последнего, собственно, и нужны Devops & CI/CD, с точки зрения технологий и процессов.

Karma Framework — это оригинальная практика управления IT в Ростелекоме, которую мы внедряем последние годы, и даже Gartner включил Karma в число передовых мировых управленческих практик. Вполне заслуженно, надо сказать. Про Karma Framework можно рассказывать очень долго на разных уровнях абстракции, но для нашей темы достаточно пояснить, что суть фреймворка в плоской модели управления, где упор делается на самоорганизацию команд и горизонтальное взаимодействие команд посредством кругов. В одном круге с каким-либо предназначением может быть множество людей, представителей команд или целых проектных групп, которые объединены целью — выполнить предназначение круга.

В нашем случае предназначение Круга DevOps стало очень простым: внедрить подходы Devops и практики CI/CD на корпоративном масштабе во множество проектных команд и сделать это технологическим промышленным стандартом.

В отличие от других форматов, круг позволил выстроить системную работу с роадмапами, инструментами, стандартами и учётом кастомных нюансов. И мы наконец ушли от прекрасного, но малорезультативного евангелизма и обмена опытом в чатах, и занялись предметным внедрением Devops & CI/CD в очень разные классы проектов и систем. Как работает круг и фреймворк в целом, мы расскажем в следующих частях про внедрение Devops&CI/CD в энтерпрайзе.

А пока же эту бизнесовую по сути часть темы резюмируем двумя блоками обоснования и ответом на вопрос, зачем нужно внедрять Devops&CI/CD и платить за это. Плюс несколько ключевых поинтов.

Ускорить Time-2-market вывода продукта в целом или обновлений по линейному развитию легаси.

Экономия. Оплатить внедрение Devops&CI/CD и потратить N бюджета, чтобы на горизонте получить экономию в деньгах Y больше N. Или получить прибавку производительности команды, и это окупит N, а потом пойдет время чистоганом. Реальные горизонты наступления эффектов в энтерпрайзе — 6–12 месяцев. Бывает, что и за пару месяцев на проектах с нулевой зрелостью CI/CD можно окупить потраченный ресурс команды.

Сократить расходы на оплату ресурса команды, уходящего на багфиксы. В среднем по индустрии на зрелых проектах бизнес готов мириться с 20% затрат на саппорт на третьей ЛТП от бюджета развития. В целевом сокращается до 10%, а иногда уходит почти в ноль. И бизнес получает больше функционального развития.

Гораздо более стабильные продукты и системы. Это автоматически ведет к росту бизнес-маркеров типа NPS, экономии на 1-2 линиях, колл-центрах и т.д.

Нормализация работы и коммуникации бизнеса с ИТ. Исчезновение ментальных дисбалансов на темы «Кто кому должен и кто плохо работает».

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

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

Разработчики занимаются программированием и кодом, творчеством, а не разбором инцидентов и поиском их причин. Вообще, внедрение CI/CD влечет за собой повышение квалификации команды и более точного состояния, когда каждый специалист занимается своим делом.

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

Все нормальные айтишники хотят делать хорошие качественные продукты. Все хотят заниматься производительным трудом на благо продукту и использовать современные стеки и технологии. В энтерпрайзе это делать тяжелее. И внедрение Devops&CI/CD позволяет подкормить профессиональную совесть качественным нектаром.

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

Devops&CI/CD можно внедрять на любом уровне зрелости продукта и команды. Целый ряд вещей вообще не технологического порядка, а логистического и операционного. Часть инструментов и подходов можно внедрить очень дешево во всех смыслах. Даже в старых, тяжелых легаси-системах.

Devops&CI/CD не является синонимом Agile и вполне работает в классическом ватерфоле и фикспрайсовых моделях. Отдельные инструменты и подходы вполне можно использовать: ту же автоматизацию сборки, автотесты, Unit-тестирование, правильную настройку git(а) можно внедрять хоть где.

Однако, CI/CD наиболее эффективен в связке со Scrum или Канбан. По сути, это объединение продвинутых операционной и технологической методик работы с ИТ-конвейером. У нас есть несколько кейсов такого рода. И мы увидели большие перспективы наложения на Канбан-доску с ее этапами разработки, матрицы действий и инструментов CI/CD. Здесь просто золотая жила. И мы уже делаем оригинальный фреймворк о том, как поженить Devops&CI/CD с Канбан. В следующих частях темы Devops&CI/CD в энтерпрайзе мы расскажем и том, как устроена наша Платформа Цифровых Продуктов, и о том, как работают круг и фреймворк внедрения Devops&CI/CD в разные классы систем и проектов.

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

Особенности IT «Ростелекома» состоят в том, что мы не просто большая компания — мы очень большая компания, у которой множество разных сервисов и продуктов. Разных настолько, что между собой они могут быть не связаны вообще, но при этом развивать и поддерживать их надо. Например, есть команды, которые занимаются телеграммами. А есть ребята, поддерживающие наши продукты в сфере видеонаблюдения и EdTech.

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

В итоге — наличие множества разных KPI (да ещё и у каждого свои), не связанных с продуктом непосредственно. Получается не самая продуктивная среда.

Напрашивается вопрос — так что делать-то?

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

Аббревиатура KARMA — Karmic Adaptive Relevant Meaningful Approach, если подробнее, то:

Karmic — карма и ценности, мы учитываем не только метрики, которые можно измерить, но и субъективную и внешнюю эмоциональную оценку нашей работы и ее ценности.

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

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

Meaningful — работа на уровне смысла. Управление и самоорганизация формализуется исходя из предназначения команд, фокус не на задачах и проектах, а на их смыслах и целях.

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

Вот как это выглядит

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

Но все не так сложно, как выглядит. Вернее, сложным оно только выглядит.

Круговая модель взята нами из социократии. Мы выделяем 5 типов Кругов (на картинке они разного цвета), это:

Борд
Продукт или программа
Центр компетенций
Экспертное сообщество
Регион

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

Конечный заказчик доволен продуктом, значит, команда (Круг) выполнила свои KPI. Бизнес здесь доверяет IT в том, как именно команды будут создавать продукт. IT доверяет бизнесу в плане формирования самого продукта и постановки задач. Таким образом избегаем конфликтов и споров.

Важно понимать, что у каждого продукта в каждом регионе свои особенности. Если где-то заказчик (и команды) привыкли работать по waterfall — значит, пусть так и работают, главное, чтобы им было комфортно и чтобы они делали продукт. Если заказчик хочет самых свежих практик — пожалуйста, в рамках самоорганизованной команды они будут работать именно так. То есть никакой принудительной уравниловки и попытки протащить единственно верный Agile на все команды разом.

Здесь надо уточнить, что эффективность работы оценивается по довольно субъективным факторам. Это культурная часть самой модели: мы ставим отношения выше одномоментных результатов в цифрах. То есть лояльность клиента и его отношение к нам в целом важнее, чем KPI в цифрах. Задачи бизнеса и отношения между бизнесом и IT тоже важнее, чем цифры KPI. Меньше конфликтов и споров — больше удовольствия в работе и лучше результат.

Плоская организация подразумевает равноправие Кругов между собой. Каждый Круг — главный в своем предназначении. Между собой они общаются с помощью механизма ожиданий. Мы позаимствовали его у «бирюзовой» компании Morning Star. В похожей парадигме работает компания Вкусвилл

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

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

Наша Карма, как, наверное, и карма в индуизме, штука такая, что её нельзя один раз и точно измерить какими-то конкретными цифрами. Но это и не нужно, цифра не важна, важен тренд

Как ее оценить? У нас такой подход: мы используем объективную и субъективную оценки. Объективная, как можно понять, состоит из довольно практических элементов: NPS, e-NPS, оценка качества внутреннего сервиса, а также регулярные опросы и разного рода лайки в задачах и обещаниях. Всё это можно выразить в цифрах, посчитать и сравнить.

Субъективная же оценка — это эмоциональная оценка происходящего. Это уровень лояльности бизнеса и его заинтересованности в проекте. Вот эти параметры уже в цифрах не выразить — нельзя пойти и написать «Бизнес сегодня лоялен проекту на 35%» или «Индекс эмоциональной удовлетворенности лидера = 64%». Но то, что их нельзя посчитать, не значит, что таких параметров нет и их не надо учитывать.

Всё вместе, объективная и субъективная оценка, и даёт нам общую оценку нашей Кармы.

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

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

Старший вице-президент по информационным технологиям ПАО «Ростелеком» Кирилл Меньшов о работе в «кругах», 100-летнем портфеле технологий и войне за кадры

Американская исследовательская и консалтинговая компания Gartner включила опыт крупнейшего российского оператора связи — ПАО «Ростелеком» — в число передовых мировых практик в сфере управления IT-функцией организации. «Ростелеком» стал единственной технологической компанией из России, чей результат трансформации управления IT получил признание на таком уровне. По словам Кирилла Меньшова, новая модель организации IT-функции Karma Framework основана на создании самоорганизующихся команд, что позволяет оперативнее реагировать на изменения рыночной ситуации.

— Как вы пришли к необходимости использования Karma Framework и в чем ее ключевые отличия от моделей управления IT, которые использовал «Ростелеком» ранее?

— Чтобы это объяснить, потребуется небольшой исторический экскурс. Как и любая другая крупная компания, «Ростелеком» начинал с жесткой иерархической модели управления, где существовал единый центр принятия решений и задачи спускались сверху вниз. Однако со временем структура компании усложнялась. Менялась и модель управления. Жесткая иерархия перестала обеспечивать нужный уровень эффективности. Потому что получалось, что на каждом отдельном этапе работы все может быть в порядке, но в целом результат не соответствует поставленным целям. Затем мы пришли к модели Software Factory, которая предусматривает объединение разработчиков в фабрику по производству программных решений в соответствии с задачами, которые собирают у заказчиков аккаунт-менеджеры. Здесь есть свои сложности, главная из которых — приоритизация задач. Следующий этап — модель Product-line, она подразумевает разделение Software Factory на отдельные команды, каждая из которых сосредоточена на работе с конкретным внутренним заказчиком. В этой модели тоже возникает вопрос приоритетов. Поэтому мы пришли к Karma Framework — плоской модели управления, которая не предусматривает механистического администрирования работы IT-команд, а делает ставку на самоорганизацию и готовность команд, которые в этом случае называют «кругами», договариваться между собой.

— Получается, что для эффективной работы этой модели вам требуются более мотивированные и квалифицированные сотрудники. Насколько сложно их находить?

— Важно понимать, что созданная нами модель Karma Framework — это не операционный уровень взаимодействия внутри команд. Это система, которая направлена на изменение культуры управления IT в целом, новый способ организации IT-функции. Решение этой задачи обеспечивает 95% изменений, на новую модель как на механизм приходится только 5%. Сами команды могут продолжать работать по-старому. Среди «кругов» есть такие, которые отличаются достаточно высокой авторитарностью: там задачи внутри команды по-прежнему распределяются в соответствии с решением единоличного лидера. Где-то используют Scrum, канбан, где-то — другие подходы из ряда методологий Agile. Часть сотрудников пока вообще не ощущает, что работает в новой модели, хотя она уже действует, и мы видим, что результативность работы IT-подразделений повысилась, в некоторых случаях — в два-три раза. Однако переход на Karma Framework не означает, что нам необходимо проводить масштабное обновление персонала.

— От чего зависит стиль работы «кругов»?

— В рамках новой модели управления мы поставили перед собой задачу быть для бизнеса лучшим IT-партнером, с которым он работал, работает и когда-либо будет работать. Соответственно, мы фокусируемся на том, чтобы подобрать оптимальный подход к работе в случае каждого конкретного заказчика. Нужно отметить, что речь идет о внутренних заказчиках, то есть тех или иных подразделениях ПАО «Ростелеком». Сейчас в нашем периметре более 100 юридических лиц, айтишников у нас работает более 7 тыс. При этом мы предлагаем клиентам огромный продуктовый ряд. Часть технологий уже могут показаться полностью устаревшими, но люди продолжают и отправлять телеграммы, и пользоваться таксофонами. Другие пока применяются не так часто, как, например, цифровой профиль для доступа к различным услугам без лишних бумаг. Но мы понимаем, что постепенно они получат широкое распространение. Между новейшими продуктами «Ростелекома» и самыми, скажем так, технологически зрелыми около 100 лет развития. В этом промежутке масса других продуктов, над которыми работают сотни IT-команд. И подход в каждом случае нужно выбирать отдельно. Потому что на таком сложном технологическом ландшафте никто не может рассказать команде, как ей работать наиболее эффективно. Иерархические модели управления работают очень плохо.

— А в чем принципиальные отличия «кругов» от обычных отделов?

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

— А это не чревато конфликтами, скажем, из-за лучших кадров или других ресурсов?

— Учитывая, что цели у всех «кругов» общие, речь не столько о конфликтах, сколько о неизбежно возникающих «напряжениях». Karma Framework включает в себя механизмы их снятия. Стоит отметить, что наиболее распространенная причина появления «напряжений» — несоответствие результатов работы того или иного «круга» и его предназначения или обязательств. Нужно сказать, что в нашем менталитете, к сожалению, не очень высока культура разрешения конфликтов. В крупных коллективах они могут приобретать довольно серьезные формы и затягиваться на годы. Поэтому мы разработали инструменты, которые помогают снизить эмоциональность «напряжений» и не переводить их в персональную плоскость. Где-то ищется компромисс или предоставляется отсрочка выполнения обязательств, где-то они присваиваются существующему «кругу», где-то требуется создание нового.

— Чуть выше вы упомянули о влиянии пандемии. Согласно ряду исследований, в период распространения коронавируса обострилась ситуация с киберугрозами. Для «Ростелекома» информационная безопасность — одно из ключевых направлений бизнеса. Как вы отреагировали на активизацию злоумышленников?

— Еще до пандемии мы предлагали своим клиентам и использовали сами полный арсенал средств защиты информации от киберугроз. Конечно, коронавирус вызвал переход множества сотрудников самых разных организаций на удаленную работу, что могло потребовать пересмотра подходов к обеспечению информационной безопасности. Но на практике все зависит в первую очередь от степени паранойи каждого конкретного пользователя. Кто-то спокойно относится к тому, что сотрудники получают доступ к корпоративным информационным ресурсам с личных устройств и через домашний Wi-Fi. Кто-то стремится обеспечить их выделенными зашифрованными каналами. Кто-то выдает рабочие ноутбуки с серьезными системами защиты и использует сервисы удаленного контроля мобильных устройств и т. д.

— Насколько для IT «Ростелекома» важны подразделения компании, расположенные в южных регионах страны?

— Юг входит в число ключевых для нашей компании регионов. У нас 13 центров разработки IT-решений, и один из них находится в Краснодаре. Здесь же расположен и наш важнейших хаб — по значимости он на одном уровне с Москвой и Санкт-Петербургом.

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

— Мы уже дважды затрагивали кадровый вопрос. В целом «Ростелеком» испытывает нехватку квалифицированных айтишников или благодаря масштабам компании проблема дефицита IT-кадров перед вами не стоит?

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

Сложность набора новых сотрудников еще и в том, что модель управления Karma Framework предусматривает фокус на эмоциональной ценности активов для заказчиков. Внутри компании мы не зарабатываем денег напрямую. Поэтому среди наших метрик и KPI присутствует субъективная оценка работы «кругов». Насколько взаимодействие с ними комфортно с эмоциональной точки зрения? Сейчас общество как в России, так и во всем мире проходит кризис роста эмоциональности. Чтобы в этом убедиться, достаточно посмотреть, в каком тоне ведутся дискуссии в социальных сетях. В работе такой стиль общения вряд ли можно считать приемлемым. Заказчики подолгу работают с IT-командами, и очень важно, чтобы опыт этого рабочего взаимодействия был позитивным. Это обеспечит и достижение поставленных целей проекта. Поэтому мы свою ценностную модель фокусируем на эмоциональную оценку. И сотрудникам уже мало быть хорошими айтишниками. Им необходимо развивать в себе эмпатию и коммуникативные навыки.

Читайте также: