В своей повседневной работе я постоянно занимаюсь формированием новых и поддержкой существующих рабочих проектных групп и, по мере накопления опыта, я нашел субъективное подтверждение следующим постулатам:
- Сплоченные коллективы работают эффективней, чем разобщенные
- Взаимоотношения сотрудников рождаются в процессе совместной деятельности
- На достачное сплочение вновь образованной рабочей группы требуется в среднем 3 месяца совместной работы
Поскольку, такая деятельность ведется постоянно, у меня возникла потребность сформировать методику, которая облегчила бы работу и давала ответы на следующие вопросы:
- Как количественно оценить степень сплоченности рабочей группы и выразить это в виде измеримого показателя?
- Как сравнивать этот показатель с другими рабочими группами (В идеале - иметь возможность отсортировать рабочие группы по убыванию либо возрастанию данного показателя)?
- Как заранее спрогнозировать сплоченность для вновь создаваемых рабочих групп?
- Как количественно оценить степень вовлеченности каждого сотрудника?
- Как делать все это в любой момент времени дешево и быстро (т.е. без проведения специальных опросов, тестов, наблюдения, анкетирования, интервьюирования и т.п.)?
В итоге я сформулировал для себя такую методику, которую описываю здесь.
Методика эта простая, если не сказать примитивная, но она дает результаты, соответствующие действительности, здравому смыслу и субъективным наблюдениям.
Для начала я бы хотел описать несколько тезисов, описывающих окружение, в котором функционируют рабочие группы:
- Все сотрудники ведут свою работу только в рамках проектных групп.
- В компании одновременно ведется несколько десятков проектов и существует несколько десятков проектных групп.
- Каждый сотрудник может одновременно входить в несколько проектных групп.
- В компании постоянно формируются новые проектные группы и распускаются старые проектные группы
- Вместе с этим существуют устойчивые, длительно не изменяющиеся проектные группы
- Практикуется постоянное «пересаживание» членов одной группы в один кабинет
- Постоянно проводятся статус-митинги
Для того, чтобы посчитать какой-то показатель, нам нужны исходные данные. И раз уж я решил не проводить специального изучения, то мой выбор пал на ежедневные timesheet'ы (напомню, что это - исторические ежедневные данные о том, на каком проекте и сколько часов отработал каждый сотрудник и что он при этом сделал). Всего в анализе приняли участие данные порядка 300 сотрудников за 6 лет.
Описание методики.
Имея информацию о том, что какие-либо 2 человека в один и тот же день работали над одним и тем же проектом, я могу, на основе своего опыта, сделать вывод, что они, так или иначе, с большой степенью вероятности, взаимодействовали друг с другом (поскольку, как я отметил выше, они сидят в одном кабинете, работают нам общим проектом, ходят на общие статус-митинги и т.д.)
На основе информации о том, на каких проектах сотрудники были заняты в течении любого дня, мы можем построить дневную матрицу взаимодействия сотрудников – своеобразный «снимок» рабочего дня:
Здесь крестиком обозначены пары сотрудников, работавших совместно в этот конкретный день.
Последовательно создавая матрицы взаимодействия всего коллектива компании для каждого нового рабочего дня, можно подсчитать, сколько дней в прошлом (т.е. до этого дня) взаимодействовала каждая пара сотрудников в компании.
В ячейках видно ежедневно увеличивающееся кол-во дней в прошлом, в которых взаимодействовала каждая пара сотрудников.
Полагая, что для достижения максимального уровня сплоченности требуется 3 месяца (64 рабочих дня), я могу посчитать в процентах степень сплоченности каждой пары сотрудников в любой день.
Здесь, С – кол-во дней, которые пара сотрудников вместе работала на каком-либо проекте в прошлом, S – степень сплоченности пары сотрудников в процентах от максимального значения.
Усредняя степень сплоченности пар сотрудников, работавших на проекте в определенный день, можно получить уровень сплоченности всей проектной группы на этот день.
С течением времени уровень сплоченности стабильной группы (𝑆 проекта) повышается.
Добавление новых «незнакомых» сотрудников в группу ведет к падению 𝑆 проекта по причине низких показателей 𝑆𝑖 для новых пар сотрудников, которые, однако, с течением времени повышаются, увеличивая таким образом 𝑆 проекта, что соответствует замыслу методики.
Создание и запуск новой рабочей группы, сформированной из ранее уже работавших вместе сотрудников, сразу будет давать высокие значения 𝑆 проекта, что также соответствует замыслу методики.
А теперь я бы хотел привести несколько примеров динамик изменения уровня сплоченности с течением времени для различных проектов.
На этом графике мы видим, что для данного проекта была сформирована новая рабочая группа из ранее незнакомых сотрудников, группа достигла максимума сплоченности, оставаясь стабильной в течении некоторого времени, потом сплоченность группы падала (в нее привлекались новые члены), но затем ситуация вновь стабилизировалась.
А вот другой проект - также рабочая группа была сформирована "с нуля", зачем сработалась, но в отличии от предыдущего проекта, команда не оставалась стабильной - в ее составе происходили частые, но не большие изменения, что снижало уровень ее сплоченности, хотя и не значительно.
Другой пример - в команде проекта происходили более значительные изменения, что сильно снижало уровень ее сплоченности (падения показателя на графике более выраженные).
Далее я бы хотел привести еще два примера, над которыми читатель может поразмышлять самостоятельно
На всех предыдущих графиках мы наблюдали более или менее стабильный рост уровня сплоченности в спокойном состоянии.
Но этот уровень может не только расти, но и снижаться, как на следующем примере:
Это обусловлено наличием изначально малой по численности рабочей группы, в которую постоянно добавляются новые сотрудники.
Теперь, когда мы увидели, как выглядит изменение уровня сплоченности проекта, возникает вопрос - а как же можно посчитать уровень сплоченности программы (группы связанных проектов)?
Возникает желание предположить, что уровень сплоченности программы можно посчитать как среднее арифметическое уровней сплоченности входящих в нее проектов, но это будет неверно, т.к. например, высокие уровни сплоченности проектов могли бы дать на выходе высокий уровень сплоченности программы, хотя на самом деле сотрудники каждой проектной группы работают замкнуто и не имеют контактов с сотрудниками других проектов этой программы (т.е. не смотря на то, что уровень сплоченности каждой проектной группы может быть высокий, уровень сплоченности программы в целом может быть низкий).
Поэтому, можно сделать вывод от том, что уровень сплоченности программы нельзя считать как среднее значение уровней сплоченности ее проектов.
Получить степень сплоченности программы в определенный день можно усредняя степень сплоченности пар сотрудников, работавших в этот день вместе на каком-либо проекте, входящем в данную программу.
Далее я приведу несколько примеров графиков для различных программ.
Аналогично можно считать и уровень сплоченности всей компании .
Какова же практическая польза этих данных?
- Группы с низким уровнем сплоченности нуждаются в поддержке HR – для них мы можем планировать адаптационные мероприятия, тимбилдинги и т.п.
- Группы с высоким уровнем сплоченности мы можем рассматривать как источники кадров для создания новых рабочих группы.
Другой важной пользой является заблаговременный расчет уровня сплоченности новых групп, которые еще только планируются для старта проекта, что можно учитывать при ресурсном планировании. Это позволяет не только формировать уже сработавшиеся группы, но и облегчать интеграцию новых сотрудников.
Далее я привожу пример расчетов уровня сплоченности для нескольких планируемых групп.
Интересной дополнительной функций методики является возможность расчета покрытия (или охвата) сотрудников.
На основе матриц взаимодействия можно посчитать покрытие (охват) сотрудника – т.е. кол-во коллег, с которыми он взаимодействует в своей работе сейчас или взаимодействовал когда-либо.
Это позволяет выявить лидеров взаимодействия и аутсайдеров взаимодействия.
Аутсайдеры взаимодействия нуждаются в дополнительном контроле и поддержке, т.к. они, по сути, не интегрированы в деятельность компании.
Далее я приведу пример сортировки списка сотрудников по убыванию их охвата (при этом хорошо выявляются лидеры и аутсайдеры).
Также лидеров и аутсайдеров хорошо видно при визуализации охватов сотрудников.
Мы также можем посчитать динамику покрытия (охвата).
На графиках хорошо видно, как с течением времени меняется кол-во человек, с которыми взаимодействует сотрудник в своей работе.
А теперь немного социометрии. Выбирая пары сотрудников с максимальным уровнем сплоченности, можно получить выборки сотрудников, имеющих наибольший опыт взаимодействия с заданным сотрудником.
Например:
Объединяя социограммы, можно получить возможные пути передачи информации в компании, например:
- Что может моя методика
- Количественно оценить уровень сплоченности рабочей группы и компании
- Проследить изменение уровня сплоченности в динамике
- Оценить уровень сплоченности при ресурсном планировании
- Посчитать покрытие взаимодействия сотрудника
- Проследить динамику изменения покрытия взаимодействия сотрудника
- Выявить лидеров и аутсайдеров взаимодействия
- Достоинства методики
- Дешевизна – не требует отвлечения сотрудников от работы
- Может применяться произвольно, в любой момент
- Скорость – можно получать требуемые данные мгновенно
- Полная автоматизация
- Недостатки методики
- Нет учета антипатий – сотрудники могли работать вместе, но при этом относились друг к другу негативно (с другой стороны выявления антипатий - дорого)
Что мне хочется сделать дальше:
- Исследовать зависимость вероятности успеха проекта от степени сплоченности проектной команды.
- Найти связь командной динамики по Брюсу Такману и результатами, получаемыми по данной методике (мне кажется, такая связь должна быть).
