Agile-подход в крупной компании: масштабирование через сообщества

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

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

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

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

Почему масштабировать Agile сложно

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

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

Более зрелые компании понимают: для взаимодействия между подразделениями и непрерывного улучшения нужны структурные организационные изменения.

Некоторые фреймворки масштабирования Agile прямо предлагают создавать группы сотрудников с общими интересами. Участники регулярно обмениваются опытом и знаниями и учатся друг у друга.

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

Исследование отвечало на два вопроса:

• Почему компании создают такие сообщества при масштабировании?
• Какие типы сообществ есть в крупных компаниях, которые работают по Agile?

В англоязычной литературе такие сообщества называют «Communities of Practice» (CoPs), то есть «профессиональные сообщества, ориентированные на практику». Дальше я буду использовать аббревиатуру CoPs.

Что такое профессиональные сообщества (CoPs)

Профессиональные сообщества (CoPs) — группы людей, которых объединяют общие интересы, проблемы или увлечённость темой. За счёт групповой динамики сообщество помогает участникам углублять знания и опыт через постоянное взаимодействие. Такие сообщества встречаются в разных контекстах: в организациях, в государственном управлении, в образовании и т. д. У CoPs три ключевые характеристики:

1. Область — общий интерес членов сообщества.
2. Сообщество — взаимодействие участников: сотрудничество, поддержка, обмен знаниями.
3. Практика — общий набор опыта, знаний и подходов, который складывается внутри сообщества.

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

Главная задача CoPs — создавать, расширять и распространять знания, а также развивать способности участников.

Люди приходят в сообщество благодаря своему опыту или интересу к теме. Границы CoPs часто размыты. Участников удерживают общая увлечённость, приверженность и причастность к группе и её экспертизе. В итоге CoP развивается и естественным образом прекращает существование, когда становится ненужным.

Сообщества различаются по охвату: работают внутри одной бизнес-единицы, охватывают несколько или даже выходят за границы компании. Степень официальности бывает разной — от неформальных групп до признанных в организационной структуре. Ещё CoPs различаются по размеру, продолжительности жизни, распределённости и однородности участников и способу создания (сверху вниз или снизу вверх). Наконец, они отличаются отбором участников (открытый или закрытый), вступлением (добровольное или обязательное) и поддержкой организации (высокая или низкая).

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

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

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

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

Пример: открытое стартап-сообщество «Кофаундер»

У открытого стартап-сообщества «Кофаундер» такие характеристики:

• Охват: межорганизационный. Участниками могут стать представители разных компаний.
• Членство: открытое для всех желающих. Присоединиться могут представители любых компаний.
• Уровень поддержки модератора: минимальный. Участники в основном общаются между собой без заметного вмешательства модераторов.
• Формат общения: неформальный. Участники свободно обмениваются идеями и знаниями в неформальной обстановке.
• Размер сообщества: крупный. Около 7000 участников на 2024 год, в основном русскоговорящих.
• Продолжительность существования: долгая. Сообщество устойчиво и развивается уже длительное время.
• Распределённость участников: широкая. Участники живут по всему миру, но основная часть — в России.
• Состав участников: разнообразный. В сообществе IT-предприниматели с разным уровнем опыта и специализацией.
• Способ инициации и отбора участников: открытый. Строгих критериев отбора нет.
• Вступление: добровольное и бесплатное. Поэтому сообщество доступно широкому кругу IT-предпринимателей.
• Выгода для участников: краткосрочная. Решения текущих задач, доступ к контактам, информации и знаниям.
• Выгода для организаторов: долгосрочная, стратегическая. Сообщество помогает исследовать рыночные запросы в определённой нише и глубже понимать рыночные тенденции.

Ведущие фреймворки масштабирования рекомендуют создавать CoPs

Фреймворки масштабирования — SAFe, Spotify, LeSS, Disciplined Agile и Nexus — рекомендуют крупным компаниям создавать профессиональные сообщества (CoPs).

• SAFe (Scaled Agile Framework) активно поддерживает CoPs для обмена знаниями, повышения квалификации и развития внутри организации. Сообщества помогают командам синхронизироваться, обмениваться опытом и внедрять лучшие практики.
• LeSS (Large-Scale Scrum) предлагает более простой подход к масштабированию Scrum. CoPs здесь важны для обмена знаниями и решения возникающих проблем. LeSS поддерживает культуру открытости и добровольного участия, и это улучшает координацию между командами.
• Disciplined Agile (DA) — гибкий подход, в котором CoPs развивают узкоспециализированные компетенции в больших Agile-средах. Сообщества помогают организациям учиться, делиться идеями и внедрять новые практики.
• Spotify Model. Сотрудники активно участвуют в сообществах. CoPs играют ключевую роль в культуре обмена знаниями и помогают масштабировать гибкие методы на всю организацию.
• Nexus ориентирован на Scrum и даёт инструменты для больших проектов с несколькими командами. CoPs помогают решать общие проблемы и вырабатывать решения, когда команд много.

Все эти фреймворки подчёркивают: профессиональные сообщества объединяют экспертов с разными навыками, помогают обмениваться опытом и развивать общие практики. CoPs поддерживают самоорганизацию и непрерывное обучение и используют весь опыт и знания внутри организации.

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

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

Кейс Nokia подчёркивает, насколько профессиональные сообщества важны для многокомандных Agile-процессов. В компании создали CoPs для координации команд и специалистов, и это поддерживало непрерывное улучшение. Темы сообществ — Scrum-мастерство, DevOps, UX — формировали сами команды.

В Spotify CoPs называются «гильдиями». Их задача — улучшать принятие решений, сотрудничество и обмен знаниями. Внимание уделяют составу сообществ, их охвату, распределению, частоте встреч, обучению, поддержке и разработке стратегий.

Как я проводил исследование: 39 интервью в 18 компаниях

Я провёл полуструктурированные интервью с экспертами и следовал профессиональным рекомендациям по качественным исследованиям, чтобы собрать данные строго. Качественный дизайн здесь подходит: создание CoPs в масштабируемых Agile-контекстах — реальная практическая проблема.

Исследование сочетает элементы исследовательского, описательного и объяснительного подходов. В таблице 2 — обзор участников.

Я провёл интервью с 39 экспертами из 18 компаний в 2 этапа. Названия компаний скрыты ради конфиденциальности.

Отбор был комбинированным: удобный и целенаправленный. С потенциальными участниками я связывался напрямую по электронной почте. При этом отбирал целенаправленно — экспертов, которые работают в масштабируемых Agile-организациях или уже создавали профессиональные сообщества. Я говорил только с теми, кто участвовал в сообществах как лидер, участник или заинтересованное лицо (например, менеджер, поддерживающий CoPs). Некоторые эксперты участвовали в нескольких CoPs в разных ролях.

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

Сбор данных

Первая серия интервью прошла с февраля по май 2023 года (23 эксперта, 13 компаний), вторая — с ноября 2023 года по январь 2024 года (16 экспертов, 5 компаний). Большинство интервью длились 40–60 минут. Каждое начиналось с введения, чтобы мы одинаково понимали ключевые понятия. Структура у всех интервью была одинаковой. После первой серии я немного её изменил, чтобы улучшить сбор данных и точнее выявлять проблемы и лучшие практики.

Интервью состояло из трёх последовательных фаз:

1. Вопросы о профессиональном опыте собеседника (например, об опыте работы в масштабируемых Agile-контекстах).
2. Вопросы о профессиональных сообществах в его организации.
3. В первой серии — вопросы о том, как исследования могут поддержать создание CoPs, во второй — о трудностях.

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

Анализ данных

Здесь представлена лишь часть собранных данных. Сначала я применил индуктивное кодирование и описал значимые фрагменты данных описательными кодами. Затем разделил эти коды на коды второго уровня абстракции:

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

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

Компании, в которых работают эксперты

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

• SoftwareCo1: 20–30 сотрудников в двух командах разрабатывают одно программное решение. E1 работает с обеими командами. Конкретную методологию масштабирования Agile компания не использует.
• InsureCo1: E2, E21 и E23 работают в IT-отделе немецкой части компании. Там применяют собственную методологию масштабирования Agile с элементами Spotify, LeSS и SAFe. Больше 2000 сотрудников работают в 20 трайбах, в каждом — до 25 команд.
• SoftwareCo2: в компании больше 30 000 разработчиков. E9, E12 и E16 работают над коммерческими проектами, E5 и E8 — над производственными программными продуктами, E3 — над доставкой ПО. Изученные подразделения сочетают элементы разных фреймворков.
• ConsultCo1: в разработке занято больше 6000 сотрудников. Методология масштабирования Agile зависит от проекта и часто основана на LeSS. E4, E11 и E18 работают над одним проектом для клиента: 450 сотрудников в 35 функциональных командах, сгруппированных в 8 программ, отвечают за 40 приложений.
• ConsultProj: E6 — консультант, который поддерживает проект компании с более чем 100 сотрудниками и 7 Scrum-командами. Проект сочетает элементы нескольких фреймворков.
• CarCo1: E7 работает в одной из областей корпоративной IT-компании — около 600 внутренних сотрудников и несколько доменов. В зависимости от области применяют разные фреймворки масштабирования Agile: SAFe, LeSS или их доработанные версии.
• CarCo2: E10 работает в корпоративной IT-компании — около 900 внутренних и внешних сотрудников в 120–140 командах. Методология масштабирования собственная, ориентированная на SAFe.
• ElectroCo: в IT-отделе больше 800 сотрудников в более чем 100 продуктовых командах, сгруппированных в домены и поддомены. E13 и E14 работают в нескольких доменах. Организация построена по модели, вдохновлённой Spotify.
• FoodCo: в IT-организации больше 2000 сотрудников в 150–200 командах в разных доменах. Методология собственная, основанная на LeSS. E15 работает на уровне всей IT-организации.
• ConsultCo2: дочерняя компания крупной консалтинговой фирмы, несколько сотен сотрудников. E17 — в команде примерно из 50 консультантов. Методология масштабирования Agile зависит от клиента.
• ConsultCo3: E19 — независимый консультант, который возглавляет и организует межорганизационное сообщество практиков (CoP) с участниками из нескольких организаций.
• HealthCo: в IT-организации больше 1000 сотрудников, работающих в проектах. В проекте E22 — около 250 разработчиков в 30 командах. Методология масштабирования собственная, с элементами SAFe.
• TeleCo1: в отделе E20 разработали собственную методологию на основе LeSS и Scrum-of-Scrums. 100 разработчиков в 8 командах создают программное решение.
• FashionCo: в IT-отделе около 400–500 сотрудников в разных доменах. Часть IT работает по Agile по собственной методологии, вдохновлённой SAFe. E24 работает вне структуры Agile-команд.
• TransportCo: в IT-компании применяют SAFe, всего занято больше 1300 сотрудников. E25, E26 и E28 работают в разных ART (Agile Release Train — «поезд релизов» в SAFe) и крупных решениях, E29 и E32 — независимо. TransportCo поддерживает дочерняя IT-компания, которая не использует конкретный фреймворк.
• RetailCo: в IT-компании больше 2500 сотрудников в разных департаментах. В департаменте E27 — около 230 сотрудников и 30 продуктовых команд. 20 «потоков» отвечают за междепартаментные проекты. IT-организация использует собственную методологию. E30 работает на уровне всего IT-департамента.
• TeleCo2: IT-отдел входит в технологическую область и насчитывает около 1000 сотрудников. Методология собственная, названия в ней взяты из Spotify. В 10–15 трайбах в общей сложности 30 команд. Все респонденты работают либо с несколькими командами, либо на уровне всего IT-департамента. E37 организует межкорпоративный CoP.
• InsureCo2: в Agile-части IT-компании больше 220 сотрудников в 4 потоках ценности по 4–8 команд, они работают по собственной методологии. Кроме того, в IT ведётся несколько проектов. E35 работает на уровне всего IT-департамента.

Зачем компании создают профессиональные сообщества: 9 причин

Исследование выявило разные причины создания CoPs. Основные из них:

1. Обмен знаниями. Сообщества разрушают барьеры и распространяют опыт. Например, в FoodCo создали CoP для Agile-коучей, чтобы не повторять одни и те же ошибки.
2. Сотрудничество. Сообщества помогают обмениваться идеями и решать задачи вместе. Например, участники Scrum-сообщества вырабатывают общие ценности и предложения по улучшению.
3. Развитие сотрудников. CoPs помогают сотрудникам учиться, расти и улучшать навыки.
4. Повышение эффективности. Сообщества помогают находить точки взаимной пользы и переиспользовать готовые решения, чтобы улучшить рабочие процессы.
5. Нетворкинг. CoPs знакомят участников с коллегами из других областей и ролей.
6. Распространение информации. Через сообщества до сотрудников доходят изменения и ключевая информация.
7. Расширение полномочий сотрудников. Сообщества помогают сотрудникам брать ответственность и участвовать в процессах.
8. Согласованность внутри организации. CoPs помогают координировать действия сотрудников в больших и географически распределённых проектах.
9. Поддержка Agile-трансформации. Сообщества распространяют Agile-практики и гибкость в организации.

Какими бывают сообщества в крупных Agile-компаниях

Ниже — характеристики изученных сообществ (CoPs) без погружения во внутреннее устройство (например, частоту встреч).

Инициация: больше половины CoPs созданы сверху

В большинстве организаций CoPs создавались сверху — по решению руководства, но есть и созданные снизу, по инициативе сотрудников. В некоторых компаниях мы встретили только сообщества, организованные сотрудниками (например, CarCo2, TeleCo1), или только руководством (ConsultCo1, ConsultProj, HealthCo). Мотивы создания CoPs со временем могут меняться. Например, в FoodCo Agile-сообщества сначала создавали отдельные люди, но позже руководство оценило их ценность и стало создавать сообщества и по другим темам, например по безопасности. В ConsultCo2 и ElectroCo первые сообщества создало руководство, а затем инициативу подхватили сотрудники.

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

Целевая аудитория: ролевые и тематические сообщества

Во многих компаниях есть и ролевые, и тематические CoPs. В некоторых — только один из типов (например, SoftwareCo1, ConsultCo1, ConsultProj, TeleCo1 и TeleCo2). Ролевые CoPs часто открыты для всех заинтересованных сотрудников, а не только для тех, кто занимает соответствующую роль.

Темы: не только Agile

Тем у CoPs много (см. таблицу 4). В каждой организации нашлось хотя бы одно сообщество, связанное с Agile, — чаще всего ролевое, например для Scrum-мастеров. Agile — популярная тема и для межкорпоративных сообществ. Другая распространённая тема — архитектура. Многие CoPs посвящены разработке ПО и конкретным технологиям или методам, например Citizen Development в TransportCo. Нашлись и сообщества по менеджменту, лидерству, тестированию, UI/UX и качеству. В некоторых организациях есть сообщества по облачным технологиям, трансформации и изменениям, бизнес-анализу, цифровизации и инновациям.

Открытость: большинство сообществ открыты

В большинстве организаций эксперты могут присоединиться к любому сообществу. Но в нескольких компаниях есть закрытые CoPs (ConsultProj, FashionCo, FoodCo и другие). Обычно они ролевые или созданы руководством. Ещё в ходе исследования нашлось закрытое межкорпоративное сообщество.

Признание: руководство почти всегда знает о сообществах

CoPs, созданные руководством, автоматически получают его поддержку. Сообщества, созданные сотрудниками, тоже получают признание и поддержку — формальную или неформальную. В некоторых компаниях CoPs возглавляют менеджеры. Например, в RetailCo сообществом Product Owners руководит глава продуктового отдела. Только о двух сообществах руководство не знало: о локальном сообществе Scrum-мастеров и об одном межкорпоративном.

Полномочия: сообщества часто влияют на решения

В ряде компаний CoPs принимают решения или влияют на них, особенно если сообщество создано для расширения полномочий сотрудников. В других полномочия зависят от конкретного CoP. Чаще всего сообщества разрабатывают руководства, стандарты и лучшие практики, которые заметно влияют на компанию.

Поддержка: бюджета обычно нет, но время участия оплачивается

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

Контроль: сообщества, созданные сверху, руководство контролирует

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

Участие: обычно добровольное

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

Охват: от нескольких команд до всей организации

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

Размер: от нескольких человек до нескольких сотен

Размер сообществ — от нескольких участников до нескольких сотен, в зависимости от масштаба компании и охвата сообщества. Тематические сообщества обычно больше ролевых и закрытых.

Что показало исследование

Самые частые причины создания внутренних профессиональных сообществ (CoPs) — обмен знаниями, сотрудничество, развитие персонала, повышение эффективности и укрепление связей между коллегами. Это подтверждает моё мнение: такие инициативы важны, особенно в крупных Agile-организациях.

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

Темы сообществ очень разнообразны и не ограничиваются Agile-практиками. Помимо Agile-сообществ, нашлось много CoPs по архитектуре, безопасности и другим темам.

CoPs создаются и по инициативе руководства, и по инициативе сотрудников. Например, сообщества по качеству часто организует руководство, а группы по новым трендам возникают снизу. Драйверы создания со временем меняются — когда сотрудники или руководство начинают видеть ценность сообществ.

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

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

Наконец, CoPs чаще всего охватывают всю организацию, особенно тематические. В компаниях с моделью «команда команд» сообщества работают на разных уровнях организации.

Ограничения исследования

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

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

Тем не менее, чтобы подтвердить причинно-следственные выводы, нужны дополнительные количественные исследования.

Что ещё предстоит изучить

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

Чтобы закрыть этот пробел, я провёл исследование с 39 экспертами из 18 организаций. Оказалось, что помимо стандартных преимуществ сообщества создают, чтобы расширить полномочия сотрудников, повысить согласованность работы и ускорить Agile-трансформацию. Сообщества занимаются не только Agile, но и классическими темами вроде архитектуры. Большинство из них открыты и добровольны, но инициатива не всегда исходит от сотрудников. Часто руководители сами создают CoP, чтобы команды могли принимать решения в рамках своей компетенции.

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

Исследование показывает роль CoPs в крупных проектах с гибкими методологиями. Оно пригодится практикам и может стать базой для дальнейших исследований. Выводы стоит подтвердить и расширить количественными методами, а на основе данных можно построить таксономию CoPs с учётом особенностей их применения в масштабной гибкой трансформации.

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

Как запустить сообщества в вашей компании

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

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

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