[Алгоритмы, Управление проектами, Agile] ДНК (Деление на команды) – визуализация взаимосвязей людей и команд

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 7 месяцев
Сообщений: 27286

news_bot ^® написал(а)
29-Апр-2021 17:31

Цитировать

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

Jira – тикет-системе для управления задачами
Confluence – вики-системе для управления требованиями
Bitbucket – системе управления кодом

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

Точка – это человек или команда.
Линия между точками – свидетельствует о наличии связи, которая является агрегатом взаимодействий, найденных в источниках данных, которые мы определили у людей. У линии связи есть свой вес, начало и конец.

Поиск точки отсчёта
Основа командной работы – общение. Можно было бы подумать, что, как людей объединили, так они и будут взаимодействовать друг с другом, но есть нюансы.

Как же люди на самом деле, работая, общаются, и общаются, работая?
Есть ли какие-то паттерны?
Зависят ли они от реальной структуры команды?
Как структура общения влияет на метрики эффективности?

Ответы на эти вопросы мы можем найти с помощью нашего продукта.
Как «читать» ДНК?
ДНК рассказывает нам, как фактически работают люди, как они взаимодействуют друг с другом в рабочем процессе, в том числе и за пределами Sbergile-периметра.
Например, при создании нового трайба (группы взаимосвязанных команд, сформированных вокруг определенного продукта и бизнес-цели, отвечающих за общий бизнес-результат) мы сможем понять по цифровым следам уже сложившиеся связи и использовать эту информацию при создании оптимальной структуры.
С другой стороны, появилась новая задача – «нарезать» команды так, чтобы улучшить lead time (LT), то есть время от начала разработки до вывода продукта в ПРОМ. LT делится на два этапа: непосредственное время команды и время ожидания. Последнее, в свою очередь, зачастую свидетельствует о зависимостях между командами.
Когда же мы визуализируем взаимосвязи таким образом, то можно задаться вопросом: а как нам синхронизировать эти команды, как лучше объединять людей, чтобы сделать минимальным количество внешних (по отношению к команде) связей?
Можно увидеть, что участники команды не общаются друг с другом, при этом активно взаимодействуют с внешними контрагентами и экспертами, то есть выходят за рамки своего круга.
Встречаются «песочные часы» – так мы называем сотрудника, который в равной степени взаимодействует с двумя командами. И нет однозначного решения, в какую из них его нужно поместить. Он может быть владельцем продукта, который пилят обе команды, а может быть уникальным экспертом – «узким горлышком». Такую связь нужно как-то разрывать: «размножать эксперта», пересматривать подход, но это решается уже за пределами нашего продукта.

Есть еще «люди-снежинки». Это, когда группа людей, которая между собой никак не общается, объединена через центр – конкретного специалиста, с которым они взаимодействуют.

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

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

Выявляя подобные исключения, мы получаем возможность изменить ситуацию, подключить административный ресурс, чтобы помочь командам эффективно решать свои задачи.
Что под капотом?
В бэке стандартно – ELK-Stack (Elasticsearch, Logstash и Kibana).
На React мы написали приложение, которое умеет забирать из индекса в Elastic через самописное API данные, к которым был применен алгоритм кластеризации, тем самым отсекая слабые (незначимые) связи и визуализировать эти данные в виде плотных сообществ.
Вы спросите, как мы отсекаем незначимые связи? По результатам предварительного исследования мы определили два самых сильных алгоритма.
1. Алгоритм ACY
ACY – алгоритм от Яндекса. Агломеративная кластеризация. Подробнее в статье тут.
2. Алгоритм MCL
MCL – марковский процесс, случайные блуждания по Маркову.
Весь алгоритм описан на следующих страницах Марковский алгоритм кластеризации и MCL — a cluster algorithm for graphs. В итоге применяем именно его.
Алгоритм кластерного анализа основан на потоке (случайном блуждании) в графе. Изначально разработан для выделения кластеров в простом графе, однако может быть применен к любым объектам, для которых задана матрица сходства/различия. Данный алгоритм является быстрым и масштабируемым алгоритмом кластеризации. В нашем случае алгоритм был доуточнён пятью модификациями.
Мы запускаем его для того, чтобы выделить части плотно связанных между собой членов мини сообществ. Например, у нас есть граф на 100 человек. Мы хотим выделить группы не более 12 человек, состоящие из тех, кто наиболее плотно друг с другом взаимодействует при решении рабочих задач.
Алгоритм продукта даёт возможность минимизировать количество внешних зависимостей между группами, найти узкие места и предложить варианты для дальнейшей оптимизации структуры команд и трайбов.
Какие планы по развитию?
Мы в стадии пилотирования продукта: вовлекаем команды в изучение ДНК и собираем обратную связь, чтобы понять, куда двигаться дальше, какие фичи реализовать в первую очередь.
Но даже сейчас это работающий инструмент, который можно использовать, когда требуется подготовить и спланировать оптимальную организационную структуру. Он позволяет снизить административную нагрузку на Agile-коучей и всех тех, кто задействован в процессе «нарезки» команд, за счет полуавтоматического получения данных о коммуникациях или существующих зависимостях по тому или иному продукту или процессу.
В перспективе мы постараемся еще глубже погрузиться в наши источники, чтобы обогатить данные о связях. Хотя и сегодня открываются интересные вещи, которые могут быть полезны как существующим командам, так и их руководителям.
Спасибо Сергею Артюхову, исполнительному директору, лидеру кластера «Аналитика и визуализация данных производственного процесса» в Сбере и его коллегам за то, что поделились рассказом о новом продукте для кластеризации команд.
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_algoritmy (Алгоритмы), #_upravlenie_proektami (Управление проектами), #_agile, #_agile, #_upravlenie_proektami (управление проектами), #_graf (граф), #_rabota_komand (работа команд), #_trajb (трайб), #_agilekomanda (Agile-команда), #_delenie_na_komandy (деление на команды), #_blog_kompanii_sber (
Блог компании Сбер
), #_algoritmy (
Алгоритмы
), #_upravlenie_proektami (
Управление проектами
), #_agile

Профиль ЛС

Ответить на тему

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

Текущее время: 21-Сен 22:35
Часовой пояс: UTC + 5