Karma framework что это
Прежде чем разбираться в понятиях 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. Этот круг работает над одноименным продуктом.
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%». Но то, что их нельзя посчитать, не значит, что таких параметров нет и их не надо учитывать.
Всё вместе, объективная и субъективная оценка, и даёт нам общую оценку нашей Кармы.
Для нас это очень масштабный и важный переход от классических матричных систем управления к плоской, которая полностью основывается на самоорганизующихся (а не управляемых сверху) командах. Для сотрудников такая система дает возможность гораздо яснее видеть результат собственной работы и границы своей зоны ответственности (потому что их определяет Предназначение Круга, частью которого он является). Для компании в целом — ускорение процессов и существенное снижение уровня бюрократизации. Учитывая, что у нас множество продуктов и сервисов, для нас такой подход стал весьма практичным.
Мы будем подробно обсуждать механику работы Кругов и системы в целом на бесплатных митапах. На первый из них, посвященный практикам самоорганизации и их совместимостью с компаниями крупного и среднего бизнеса, можно записаться на этой странице.
IT — пожалуй, всё ещё одна из самых динамичных отраслей, в которой всё меняется очень и очень быстро. Вчерашний стартап становится единорогом, а если повезёт больше — то и одним из крупнейших игроков.
Особенности 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%». Но то, что их нельзя посчитать, не значит, что таких параметров нет и их не надо учитывать.
Всё вместе, объективная и субъективная оценка, и даёт нам общую оценку нашей Кармы.
Для нас это очень масштабный и важный переход от классических матричных систем управления к плоской, которая полностью основывается на самоорганизующихся (а не управляемых сверху) командах. Для сотрудников такая система дает возможность гораздо яснее видеть результат собственной работы и границы своей зоны ответственности (потому что их определяет Предназначение Круга, частью которого он является). Для компании в целом — ускорение процессов и существенное снижение уровня бюрократизации. Учитывая, что у нас множество продуктов и сервисов, для нас такой подход стал весьма практичным.
Мы будем подробно обсуждать механику работы Кругов и системы в целом на бесплатных митапах. На первый из них, посвященный практикам самоорганизации и их совместимостью с компаниями крупного и среднего бизнеса, можно записаться на этой странице.
В этой, восемнадцатой статье из серии «Менеджмент цифрового мира» (оглавление) я буду рассказывать о фреймворках масштабирования Agile на большие подразделения или компанию в целом. Эту тему я уже начал в прошлой статье «Kanban и Lean - эволюция вместо революции»: Kanban также позволяет оркестровать работу в рамках компании, но он нем я здесь говорить больше не буду.
Отмечу, что ячейкой организации в любом случае является автономная самоорганизующаяся Agile-команда, поэтому совместимость способов управления с Agile-культурой является принципиальным требованием. Опыт показывает, что многие подходы менеджмента, основанные на уважении авторитета руководителя, полагаемого безусловным, или следовании за непогрешимым лидером не выдерживают столкновения с Agile-культурой: сотрудники могут просто уйти целой командой. И если руководство привыкло к такому стилю управления, то в Agile нет никакого смысла. С другой стороны, как я говорил в статьях «Три вызова цифрового мира» и «Цифровой мир: от физического труда — к умственному» методы регулярного менеджмента в цифровом мире перестают работать, а Agile-методы являются одной из работающих альтернатив, что подробно рассмотрено в статье «Agile – ответ IT на вызовы цифрового мира».
Фреймворки имеют разную сложность и рассчитаны на компании или подразделения разного размера. При этом большинство из них рассчитано на короткие цепочки создания ценности, когда одна кроссфункциональная команда делает продукт, поставляемый потребителям. Как я писал в статье «Место Agile-команд в компании», в условиях неопределенности и быстрого изменения условий работы компании в VUCA-мире короткие цепочки являются естественным способом организации труда, способным быстро реагировать на изменения, в отличие от стабильных условий функционирования, которые ведут к специализации и образованию длинных цепочек из функциональных подразделений.
Большинство фреймворков, о которых я буду говорить, ориентированы на обеспечение только основной операционной работы компании. Однако, следует учитывать, что границы ответственности команд могут быть существенно различны. Достаточно распространенной является практика, когда в ответственность команд передается найм и увольнение сотрудников, их обучение, а также финансовая ответственность за создаваемый продукт, то есть команда становится независимым подразделением.
В других случаях HR остаются независимым подразделением, так же как бухгалтерия и юридическая служба, и тогда их работа может быть организована как сервисная инфраструктура для команд, работающая по Kanban или одним из гибридных Agile-методов. Сохранение традиционной организации тоже возможно, однако, важно обеспечить хорошее качество сервиса и не служить препятствием для движения команд основного операционного контура.
И перед тем, как перейти к обзору фреймворков я хочу порекомендовать доклад Асхата Уразбаева «Фреймворки масштабирования Agile» на SECR-2017 со сравнением разных фреймворков.
Начну я с наиболее простого Scrum of Scrums, который появился раньше других. Он применяется в случае, если у вам в компании есть независимые Scrum-команды, каждая из которых делает свой продукт. Тогда для работы надо общими вопросами достаточно собрать команду Product Owner для обсуждения стратегии развития продуктов и координации усилий, и команду Scrum Master для обсуждения и координации вопросов организации. Если в командах есть Tech Lead, отвечающий за технологии и обучение им сотрудников, то добавляется еще координирующая команда из них.
Однако, бывают ситуации, когда одна команда не может обеспечить развитие продукта в требуемой темпе, ее мощности не хватает. Ведь размер команды ограничен, эффективно работает команда в 7-9 человек, а если их становится сильно больше, то необходимо дополнительное структурирование. Есть относительно простой способ нарастить команду до 15-20 человек, представленный на схеме. Это конструкция из мини-команд, каждая из которых состоит из опытного сотрудника и 1-2 стажеров, для которых опытный является наставником для стажеров. При этом операционные вопросы взаимодействия решаются командой из руководителей мини-команд.
Другой относительно простой способ – это собрать Integration Team из представителей отдельный команд, которая будет решать вопросы координации и зависимостей. Это предлагает Nexus и достаточно в случае, когда зависимости являются достаточно слабыми.
Более сложный фреймворк – Large Scaled Scrum (LeSS) (русское описание) – несколько команд на одном продукте с общим Product Owner, BackLog, спринтами, планированием, демо и поставкой, это позволяет объединить до 8 команд. У фреймворка есть huge вариант, применяемый для больших компаний и рассчитанный на работу 1000+ человек.
Ответственность команды не ограничивается выполнением основных производственных задач, она имеет много планов и фокусов, и логично, когда это реализуется через отдельные организационные структуры. Это мы видели на примере Scrum of Scrum, который организует две структуры управления – продуктовую и организационную, иногда дополняемую третьей, технологической. Более сложной конструкцией является Spotify фреймворк, который заслуживает отдельного рассмотрения.
Основной производственной единицей в ней является клан (tribe) в 100-200 человек, который работает над отдельным продуктом. Он представляет собой матрицу: делится на кроссфункциональные производственные отряды (squad) и функциональные отделы (chapter). Отряды реализуют новый функционал и состоят из специалистов разных специализаций, которые дополняют друг друга. А отделы координируют работы специалистов из разных команд, использующих общие технологии, решая такие задачи, как разработка мобильных интерфейсов в едином стиле, однородная работа серверной части или развитие технологий тестирования. Отметим, что отделы работают над применением технологий в рамках продукта, а вот для развития технологий в целом по компании существуют еще гильдии (guild) по интересам. По мере роста компании над кланами появились структуры следующего уровня – альянсы (alliance) и бизнес-единицы (business unit).
Конструкция – очень сложная и многоплановая и во многом обусловленная контекстом компании. Spotify ей делится, но с предостережением: «используйте наши опыт, но не пытайтесь тупо скопировать, оно не взлетит, мы это точно знаем, потому что у нас самих конструкция развивается и растет». Но много попыток именно механического копирования, обычно неудачных. А вот идеи заложены плодотворные.
При этом в самой компании Spotify организационная структура развивается очень быстро. И я хочу интересующимся порекомендовать доклад Yuliya Kurapatenkava на Saint TeamLeadConf-2018, в котором она рассказывала про логику развития (мой конспект есть в отчете с конференции, сам доклад по-английски). И вы можете сравнить то, что звучит в докладе с тем описанием фреймворка, которое доступно по ссылке в начале раздела и фиксирует состояние несколько лет ранее.
Здесь стоит рассмотреть практическое применение подобных фреймворков. Один продукт, над которым работают несколько команд, далеко не всегда означает единственный продукт в смысле софта, более того, часто речь идет об одном бизнес-продукте, поддержка которого со стороны софта требует общей серверной части и нескольких приложений на разных платформах – web и мобильных. Естественным образом для того, чтобы какой-то новый функционала стал доступен конечным пользователям, он часто должен быть реализован в серверной части и для каждой из платформ. И тут может быть два подхода: сделать команды, каждая из которых сосредоточенна вокруг каждого софтверного продукта, при этом только она работает с кодовой базой продукта и отвечает за его архитектуру. В этом случае для организации могут применяться фреймворки, подобные LeSS.
Однако, то что задача по реализации нового функционала делится на несколько, каждую из которых выполняет своя команда, сильно увеличивает количество необходимых синхронизаций и время разработки. Поэтому часто применяется и другой способ организации, кросс-функциональные команды, включающие специалистов по всем приложениям и делают все доработки для новой фичи. При этом возникает общее владение кодом, и надо дополнительно принимать меры для удержания целостности архитектуры каждого приложения, а также обучения и передачи опыта, потому что внутри команды такие специалисты не могут учиться. И это получается структура, похожая на клан в Spotify.
Так вот, в зависимости от потока задач и этапа развития компании предпочтительная структура может сильно изменяться. И сейчас IT-компании умеют достаточно быстро и успешно перестраивать свою структуру в зависимости от потребностей развития продукта. Я хочу сослаться на опыт компании ivi. На TeamLeadConf-2018 Евгений Россинский рассказывал, как они обеспечивали целостность продуктов и поддерживали знания разработчиков при переходе к кроссфункциональным командам от команд, собранных вокруг отдельных приложений. А через год TeamLeadConf-2019 он же рассказывал как за год они для решения задач реинжиниринга ядра продукта вернулись к командам, организованным по приложениям, провели реинжиниринг, а затем – снова перешли к кросс-функциональным командам, и все это - за один год, и продолжая мониторинг производительности, чтобы не допустить деградации.
Компания ivi предоставляет чистый цифровой продукт. Однако, похожая бизнес-структура сейчас характерна и для банков и для туроператоров, потому что их продукты сейчас все больше и больше перемещаются в цифровую сферу. Но, насколько я знаю, быстро пересобираться таким образом они еще не умеют, да и для IT опыт ivi является передовым. И, думаю, это может дать хорошее представление о том, какова она – динамично развивающаяся и перестраивающаяся современная цифровая компания, насоклько быстро она умеет изменяться.
Scaled Agile Framework (SAFe) является самым сложным Agile-фреймворком, но при этом – самым популярным. Это сложная конструкция уровня компании с управлением потоками создания ценности и архитектурой. На мой взгляд, популярность этого фреймворка сродни популярности PMBOK или RUP – в нем есть все и на все случаи жизни, и предлагается просто взять нужное. Те, кто читал мою статью «Развитие и провал регулярного менеджмента в IT» не удивятся моему мнению, что у это – неработоспособная конструкция, хотя и привлекательная в своем инженерном совершенстве. И он не будет работать по тем же самым причинам – его сложность превышает разумный предел, при этом обвинить сам фреймворк будет невозможно, всегда окажется, что это вы не смогли его правильно реализовать.
Но дело не только в сложности фреймворка: SAFe пытается за счет сложных регламентов превратить запутанную область в сложную, а это – невозможно (подробнее о сложности областей – в моей статье «Место Agile-команд в компании»). Однако, SAFe может быть полезен как теоретический источник, подобно PMBOK. Кстати, автором фреймворка является Дин Леффингуэлл (Dean Leffingwell), один из авторов RUP.
Довольно интересен фреймворк Enterprise Scrum предлагает переход от создания IT-продукта к поставке ценности, управляемой набором связанных метрик. К сожалению, в отличие от всего остального он не завершен. Его создатель Mike Beedle, кстати, один из авторов Agile-манифеста был, к сожалению убит в Чикаго весной 2018 года, и работа не завершена. Однако, на сайте есть достаточно подробная конструкция системы метрик, совместимая с Agile-методами управления, и, возможно, она вам окажется полезной при конструировании собственной, хотя в готовом виде ее, естественно, брать не стоит. Поэтому я и даю ссылку.
На этом я завершаю эту статью. Полное оглавление серии «Менеджмент цифрового мира» можно увидеть у меня на сайте. В следующей статье мы поговорим про кейсы Agile-трансформации. Продолжение следует…
Ростелеком — это гибкое сообщество непохожих друг на друга команд и очень разных людей, которых объединяет общая ценность: нам не всё равно, что мы делаем.
-Кирилл Меньшов, старший вице-президент по информационным технологиям Ростелеком
Karma Framework избавляет компанию от бюрократии и позволяет меньше думать об абстрактных конструкциях вроде должностных обязанностей, штатного расписания и оргструктуры, которые часто ведут к интригам, карьеризму и падению эффективности. Роли дают коллективу возможность быстро перестраиваться, а с помощью кругов мы формируем внутреннюю структуру так, как удобно самим сотрудникам.
Нашли опечатку? Выделите фрагмент и нажмите Ctrl+Enter.
Жители Тель-Цафа занялись садоводством уже 7000 лет назад
На распространение растительноядных динозавров на Аляске осадки повлияли сильнее температуры
Археологи обнаружили в Египте 85 древних гробниц и руины храма богини Исиды
Наука в приоритете
Чем занимаются ученые Петербургского Политеха: от высокотехнологичной 3D-печати до наноспутников
Жители Тель-Цафа занялись садоводством уже 7000 лет назад
Сифилис оказался в Китае задолго до экспедиций Васко да Гамы
Ночницы пожужжали как пчелы и шершни и отпугнули сов
Добровольцы нашли 1031 новый астероид на снимках телескопа «Хаббл»
Дикая лисица убила двадцать пять фламинго и одну утку в американском зоопарке
Химики получили графин с помощью обратимой реакции метатезиса
Добровольцы поищут движущиеся валуны на ядре кометы Чурюмова — Герасименко
Химики вырезали углерод из шестичленного гетероцикла
Теоретики уточнили частоты переходов в пионном гелии
Смешивание с электронами помогло приостановить вращение молекулярных ионов
Физики намагнитили гелиевый газ с помощью света
Химики получили графин с помощью обратимой реакции метатезиса
Магнито-оптическую ловушку установили на квадрокоптер
Вторая доза вакцины в ту же конечность усилила иммунный ответ у мышей
Паутина с автобусных остановок помогла оценить концентрацию и состав микропластика в воздухе
На распространение растительноядных динозавров на Аляске осадки повлияли сильнее температуры
Биоархеологи разобрались в рационе первых греческих земледельцев
Самое сложное
© 2022 N + 1 Интернет-издание Свидетельство о регистрации СМИ Эл № ФС77-67614
Материалы, опубликованные в разделе «Блоги», отражают позиции их авторов, которые могут не совпадать с мнением редакции.
Читайте также: