Top.Mail.Ru
/
/
Командный артефакт «Звёздная карта»
Командный артефакт «Звёздная карта» (Star Map)

Школа скрам-мастеров

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

При составлении командного артефакта «Звёздная карта» часто возникают следующие вопросы:
  • Когда лучше приступить к составлению?
  • Как правильно её составить?
  • Каким результатом должна завершиться сессия?
На создание Звёздной карты обычно требуется от 60 до 90 минут.
Запуск и перезапуск команды
Для начала рассмотрим ситуацию, когда команда только запускается и впервые готовит данный артефакт на встрече. Этот процесс помогает создать общее понимание и согласованность в работе.

Первый ключевой вопрос, который возникает: «Какие компетенции необходимы для создания продукта?»

На этом этапе важно договориться, будет ли Звёздная карта охватывать только Delivery-процесс (поставка ценности) или включать также Discovery-процесс — этап подготовки элементов бэклога продукта до статуса «Готов к взятию в спринт». Это решение определяет фокус карты и её влияние на стратегию работы команды.

После ответа на первый вопрос команда переходит к заполнению таблицы:

  • Горизонтальная часть отводится для перечня необходимых компетенций или ключевых этапов работы.
  • Вертикальная часть содержит список всех участников команды, что позволяет соотнести компетенции с конкретными людьми.
Перед тем как приступить к заполнению Звёздной карты, важно договориться о легенде, которая будет служить основой для интерпретации данных в таблице. Легенда помогает команде ответить на два ключевых вопроса:

1) Какие у нас риски?
Это включает определение bus factor — показателя, который отражает, насколько работа команды зависит от отдельных участников. Например, если выполнение ключевой задачи зависит только от одного человека, риск высокий.

2) Как мы можем закрыть эти риски?
Команда обсуждает, как можно увеличить bus factor, чтобы больше участников владело необходимыми компетенциями. Это может включать кросс-функциональное обучение, документирование процессов или перераспределение знаний и задач внутри команды.
Bus factor — это показатель риска в команде, определяющий, насколько она уязвима перед потерей знаний и навыков из-за ухода ключевых участников. В буквальном смысле термин подразумевает, что если определённое количество участников команды «сойдёт с дистанции» (например, попадёт под автобус, что является шутливым выражением), команда, а вместе с ней и продукт/проект окажется в критической ситуации.

Основные аспекты bus factor:
  • Численный показатель: Bus factor — это число, показывающее, сколько участников команды нужно убрать, чтобы продукт/проект или организация стали неработоспособными. Например, если bus factor продукта/проекта равен 1, то достаточно одного человека, чтобы продукт/проект оказался под угрозой.
  • Оценка зависимости: Этот показатель помогает оценить зависимость команды от отдельных участников. Чем ниже bus factor, тем больше продукт/проект зависит от одного или нескольких ключевых участников.
  • Знания и навыки: Bus factor показывает, насколько критичными являются уникальные знания и навыки определённых людей. Если только один человек владеет знаниями о важных частях продукта/проекта, его потеря серьёзно угрожает всей работе.
Примеры и значение:
  • Низкий bus factor (1−2): Опасная ситуация, когда продукт/проект полностью зависит от одного или двух человек. Если они покинут команду или не смогут работать, продукт/проект будет парализован.
  • Высокий bus factor (5 и более): Означает, что продукт/проект устойчив и не зависит критически от одного участника. Знания и навыки распределены между многими членами команды, что повышает устойчивость к изменениям в составе.
Способы увеличения bus factor:
  1. Документирование процессов: Ведение подробной документации о продукте/проекте и ключевых процессах.
  2. Обучение и наставничество: Регулярный обмен знаниями между участниками команды, чтобы снизить зависимость от отдельных людей.
  3. Кросс-функциональность: Создание команд, где участники обладают разными навыками и могут заменять друг друга.
  4. Дежурства и ротация: Введение практики ротации ответственных за различные части продукта/проекта для увеличения распределения знаний.
Держа в голове эти вопросы, команда договаривается о легенде, которая будет использоваться для заполнения Звёздной карты. Легенда должна быть простой, понятной и отражать уровень компетенции участников, а также их готовность к обучению и передаче знаний.

Например, она может выглядеть так:
  • Ментор 🤓 — владею навыком на высоком уровне и могу обучать других.
  • Гуру 🧐 — владею навыком на высоком уровне, но не могу обучать.
  • Атлет 😜 — уверенно владею навыком, но не хочу обучать.
  • Студент 🎓 — имею базовые знания, но нуждаюсь в помощи и наставничестве.
  • Младенец 👶 — ничего не знаю, но очень хочу учиться.
  • Зомби 🧟 — знаю, но предпочёл бы забыть или больше не заниматься этим.
В моей практике встречались разные легенды для заполнения Звёздной карты, и когда команда делает это впервые, важно дать ей примеры. Это помогает участникам зацепиться за конкретные модели и избежать путаницы или необходимости переделывать карту позже.
В приведённой легенде вы могли заметить, что я сделала акцент на категории «могу обучать», «не могу обучать» и «не хочу обучать».

Здесь важно понимать разницу:
  • «Не могу обучать» означает, что у человека есть желание, но пока не хватает навыков, чтобы делиться знаниями. Это ценная информация: вы можете совместно составить план по развитию необходимых навыков у такого участника.
  • «Не хочу обучать» даёт сигнал о том, что человек либо временно не готов к этой роли, либо у него был негативный опыт в прошлом. Этот статус стоит воспринимать как информацию к размышлению, но не повод для немедленного обсуждения.

Также интересен статус «зомби 🧟: знаю, но хочу забыть». В одной из моих команд участник предложил добавить этот статус, чтобы обозначить: хотя он обладает определённой компетенцией, он хотел бы минимизировать свою вовлечённость в эту область. Этот статус стал сигналом для других, что к нему стоит обращаться только в критически важных случаях.

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

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

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

Когда все участники завершили заполнение, фасилитатор (или Агент изменений) объявляет 15-минутный перерыв. В это время он анализирует полученные данные, выявляя потенциальные риски и зоны для улучшения.

После перерыва команда возвращается, и фасилитатор презентует основные выводы.

Например, он может указать на:
  • компетенцию, которую знает только один человек, и при этом никто не хочет её изучать.
  • направления, где навыков не хватает, но есть участники, готовые учиться.
Есть желающие обучаться, но никто не хочет обучать
На каждую компетенцию, где есть подобный bus factor необходимо составить план с конкретными шагами и ответственными. Если этого не сделано, то риск не закрыт.
Пример плана (не самый лучший, но и такое бывает):

Риск: компетенцией JS владеет только Юра (bus factor)

Как снизим риск: так как никто не хочет в команде обучаться JS Юра обговорит этот вопрос со своим лидером компетенций, чтобы кто-то из другой команды балансировал нашу команду на период отсутствия Юры

Когда: на следующей ретроспективе Юра расскажет что решили.

Как поймем, что риск закрыт: Юра и участник смежной команды составят план дежурства/ротации, чтобы подготовиться заранее
Есть bus factor и никто не хочет обучаться
Если вы видите, что кто-то хочет обучаться, но при этом нет никого желающего обучать, не спешите призывать к ответственности тех, кто знает, но не хочет обучать. Это их выбор и самое худшее, что вы можете сделать — это начать монолог нравоучений. Лучшее, что вы можете сделать, это подсветить команде, что есть вот такая ситуация: с одной стороны есть те, кто готов обучаться, с другой те, кто не хочет обучать. Что команда думает по этому поводу. Держите паузу, порой полезно держать неприлично долго. В какой-то момент у команды начнут появляться мысли:
  • можно пойти на курсы;
  • можно попроситься к смежникам;
А также в какой-то момент тот, кто не хотел обучать, может сказать, что готов, но при определённых условиях и это хороший первый шаг.
Есть желающие обучаться и есть те, кто хочет обучать
Если вы заметили, что есть bus factor на компетенции, но при этом есть и желающие обучаться и желающие обучать, не спешите радостно проскакивать этот момент. Важно, чтобы участники проговорили и записали их дальнейшие шаги.
Пример пункта плана, когда есть кто хочет обучаться и есть те, кто готов обучать

Риск: компетенцией React владеет только Коля (bus factor)

Как снизим риск: Коля будет обучать Олю React-у 2 раза в неделю

Как поймем, что риск закрыт: через месяц Оля сама может делать задачи уровня Junior
Когда участники команды сделают свои договорённости прозрачными, станет понятно надо ли здесь на что-то обращать дополнительно внимание. Например, месяц — это много или мало.
И всё?
Если вам кажется, что на этом всё, то вы заблуждаетесь. Вы заблуждаетесь!

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

Порой подведя итоги, что и как получилось у каждого человека, может привести к тому, что тот, кто до этого сидела в состоянии «Не буду я учиться» или «Не буду я обучать» начинает сомневаться в своих решениях и передумать
А что если у нас ни запуск и ни перезапуск команды?
Случается когда «Звёздную карту» необходимо обновить или составить в разгар работы команды. В таких случаях вы можете это сделать или на отдельной встрече, договорившись об этом с командой или же на ретроспективе. Из личного опыта могу сказать, что я не рекомендую это делать на ретроспективе, так как она существует для других задач. Возможно, ваша команда будет готова «продлить» ретроспективу на 60−90 минут и после завершения остаться на составление данного артефакта.
Можно ли заполнять ассинхронно?
И да и нет. Если на совместной встрече вы договорились о том, какие компетенции выносите на «Звёздную карту», а также договорились о легенде, то можете рискнуть и перенести это в ассинхронное заполнение. Учтите, что кто-то может тянуть с заполнением, ждать пока другие заполнят и у вас должен быть чётко определен срок до какого заполняют, чтобы провести анализ. Далее вы снова собираетесь на презентацию результатов и выработку плана действий.

На этом всё по составлению «Звёздной карты», если у вас появятся вопросы, пожалуйста, пишите нам, мы обязательно на них ответим.

Будьте в курсе

Подпишитесь, чтобы не пропустить полезные статьи