top of page
logo_scrum_ua_white.png
Фото автораAlexey Krivitsky

Communities of Practice. Сообщества практики. Краткий сборник рецептов.



Статья переведена с английского Еленой Максимовой.


Оригинальная статья: Communities of Practice. Lightweight Cookbook - Питер Холл, Алексей Кривицкий, Юрий Малый, Наталья Тренина, Антон Видищев.


Эта работа распространяется под Creative Commons Attribution - International License (CC BY 4.0)

Лучшие сообщества практики, которые мы знаем:

  1. ... управляются болью, создаются при необходимости

  2. ... основаны волонтерами

  3. ... управляются участниками для участников

  4. ... создают достаточную долгосрочную ценность при балансировании краткосрочных потребностей своих членов

  5. ... исчезают, когда потребность исчерпывается


Мы также видели зомби-сообщества. Они:

  • Управляются сверху вниз - менеджмент решает, что нужно новое сообщество

  • Не удовлетворяют реальную потребность - участники не испытывают особой боли / необходимости решать вопросы (обычно это вызвано управлением «сверху вниз»)

  • Не несут реальной ценности - поднятые темы не имеют ценности для участников, обсуждаемые вопросы ничего не изменят на рабочем месте (обычно это вызвано тем, что вопросы спускаются «сверху»)

  • Устарели - когда-то была настоящая потребность и сообщество вокруг нее; теперь же потребность исчезла, но сообщество еще живет по инерции..


Зачем нужны сообщества практики?

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


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


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


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


Мы видели несколько типов сообществ:



A. Команды миссии (сноска 1)

Основная цель: внедрить новую практику, создать изменение, например, "организовать непрерывную поставку продукта".


B. Круги синхронизации (сноска 2)

Основная цель: координировать работу между командами, например, "еженедельная встреча о релизе приложения для Android"


C. Учебные группы

Основная цель: формирование определенных навыков, например, «функциональные языки»


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


сноска 2: Некоторые могут утверждать, что "круг синхронизации" - это не сообщество практики. Мы считаем, что это сообщество, т.к. он удовлетворяет условиям списка из 5 пунктов «Лучшие сообщества практики, которые мы знаем», приведенного выше (например, обеспечивает долгосрочную ценность для участников на добровольных началах).


Примеры сообществ, которые по нашим наблюдениям хорошо работали:


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


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


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


Команда миссии: Java-разработчики собираются в связи с предстоящим обновлением версии Java. Как только обновление завершено, группа распадается (до следующего обновления).


Сообщества, у которых были сложности:

  • ... не были сформированы на основе реальных потребностей сотрудников, а скорее на благих намерениях руководства: «они должны быть сообществом» (например, мы знаем о сообществе Scrum-мастеров, которые испытывали сложности, работали в разных частях организации, не имели общих целей или списка помех, и у них не было прав для изменений на системном уровне - так зачем же стоило беспокоиться о вкладе в сообщество?)


  • ... не могли предоставить своим членам достаточной долгосрочной ценности, т.к. люди были заинтересованы только в краткосрочных результатах (например, мы слышали о сложностях в "компонентных сообществах", где разработчики затрагивали много различных компонентов при разработке полезного функционала; но их затраты на участие в таком сообществе не были сбалансированы со стоящими перед ними краткосрочными целями - разработчики были лишь заинтересованы (мотивированы) быстрой разработкой фич, а не долгосрочным вкладом в развитие компонент и архитектуры системы в целом.)


Следите за насилием в сообществе!

Силовые структуры и структуры отчетности, замаскированные под сообщества


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


Пример: QA инженеры из кросс-функциональных команд, которые «отбывали свой срок» на службе бывшему боссу (QA менеджер давно исчезнувшего QA отдела), посещали еженедельные статус-встречи, чтобы держать своего босса в курсе новостей и поддерживать его самоценность.


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


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


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


«Архитектурное» сообщество во главе с архитектором, созданное, чтобы навязывать командам разработки стандарты без обратной связи "снизу вверх".


Роль лидера сообщества

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


Поэтому любой, кто видит потребность в создании сообщества, является потенциальным лидером сообщества!


И это можешь быть ты. Да - ты!


Что делают лидеры хорошо функционирующих сообществ:


  • Они очень четко заявляют о потребности создания сообщества и приглашают добровольцев.

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

    • Или же: они отправляют приглашение (с четко описанной потребностью в сотрудничестве) и смотрят, кто приходит и остается, чтобы работать дальше (после того, как уляжется первое любопытство).

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

  • Они предлагают, а затем помогают создать среду (инструментарий), поддерживающую текущую работу сообщества.

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

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


Советы и приемы:


Лидер сообщества:


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


  • Находит подходящие инструменты для коммуникации и работы в режиме онлайн / офлайн (основное внимание уделяет простейшим инструментам, например, Wiki, Google Docs).


  • Пытается поддерживать постоянный ритм в организации мероприятий.

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


  • Делает цели и планы видимыми и простыми для участия в них.


  • Изучает возможности работы сообщества без своего участия.


Вышестоящий менеджер / официальные руководители компании, в которой есть сообщества:


  • Убеждается, что люди знают, что создание сообществ приветствуется без каких-либо разрешений, и что работа сообществ полноправна, как и любая другая каждодневная работа:

    • Проводит время от времени общего для всей компании дня сообществ может быть хорошей идеей для достижения нескольких целей сразу:

    • Позволяет сотрудникам учиться и исследовать идею сообществ;

    • Создаёт среду для встреч, разговоров и решения насущных вопросов - чтобы избежать формирования ненужных сообществ;

    • Способствует формированию реальных сообществ на основе долгосрочного видения и реальных потребностей;


  • Выступаеть за автономию и самоорганизацию сообществ (вместо того, чтобы навязывать процессы и информационное наполнение сообществ):

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

    • Копирование Модели компании "Spotify" (с ее гильдиями и хартиями) - только потому, что это звучит и выглядит круто, может быть не слишком хорошей идеей.


  • Служит сообществу, когда его просят:

    • Если есть бюджет для сообщества - пусть сообщество решит, что они хотят с ним делать (вместо того, чтобы подсовывать внешние стимулы членам сообщества, которые подрывают ценность, которую люди фактически получают от работы сообщества)


Чао! И приятного аппетита в дегустации новых организационных структур!




Авторы статьи - команда «emerging koalas» на Scrum Coaching Retreat, Киев, май 2017 года: Питер Холл, Алексей Кривицкий, Юрий Малый, Наталья Тренина, Антон Видищев.


15 переглядів0 коментарів

Останні пости

Дивитися всі

Comments


bottom of page