суббота, 13 ноября 2021 г. - www.msmirnov.ru

Авторская методика количественной оценки сплоченности рабочих групп

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

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

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

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

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

 

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

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

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

Для того, чтобы посчитать какой-то показатель, нам нужны исходные данные. И раз уж я решил не проводить специального изучения, то мой выбор пал на ежедневные timesheet'ы (напомню, что это - исторические ежедневные данные о том, на каком проекте и сколько часов отработал каждый сотрудник и что он при этом сделал). Всего в анализе приняли участие данные порядка 300 сотрудников за 6 лет.

Описание методики.

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


Здесь крестиком обозначены пары сотрудников, работавших совместно в этот конкретный день.

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


В ячейках видно ежедневно увеличивающееся кол-во дней в прошлом, в которых взаимодействовала каждая пара сотрудников.

Полагая, что для достижения максимального уровня сплоченности требуется 3 месяца (64 рабочих дня), я могу посчитать в процентах степень сплоченности каждой пары сотрудников в любой день.


Здесь, С – кол-во дней, которые пара сотрудников вместе работала на каком-либо проекте в прошлом, S – степень сплоченности пары сотрудников в процентах от максимального значения.

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



С течением времени уровень сплоченности стабильной группы (𝑆 проекта) повышается.

Добавление новых «незнакомых» сотрудников в группу ведет к падению 𝑆 проекта по причине низких показателей 𝑆𝑖 для новых пар сотрудников, которые, однако, с течением времени повышаются, увеличивая таким образом 𝑆 проекта, что соответствует замыслу методики.

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

А теперь я бы хотел привести несколько примеров динамик изменения уровня сплоченности с течением времени для различных проектов.



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

 


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




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

 

 

Далее я бы хотел привести еще два примера, над которыми читатель может поразмышлять самостоятельно


 


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

Но этот уровень может не только расти, но и снижаться, как на следующем примере:

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

 

Теперь, когда мы увидели, как выглядит изменение уровня сплоченности проекта, возникает вопрос - а как же можно посчитать уровень сплоченности программы (группы связанных проектов)? 


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

 

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


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


Далее я приведу несколько примеров графиков для различных программ.





 

Аналогично можно считать и уровень сплоченности всей компании .


Какова же практическая польза этих данных?

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

 

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

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


Интересной дополнительной функций методики является возможность расчета покрытия (или охвата) сотрудников.

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

Далее я приведу пример сортировки списка сотрудников по убыванию их охвата (при этом хорошо выявляются лидеры и аутсайдеры).


Также лидеров и аутсайдеров хорошо видно при визуализации охватов сотрудников.

 

Мы также можем посчитать динамику покрытия (охвата).


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

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

Например:



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


Подведем итоги.

  • Что может моя методика
    • Количественно оценить уровень сплоченности рабочей группы и компании
    • Проследить изменение уровня сплоченности в динамике
    • Оценить уровень сплоченности при ресурсном планировании
    • Посчитать покрытие взаимодействия сотрудника
    • Проследить динамику изменения покрытия взаимодействия сотрудника
    • Выявить лидеров и аутсайдеров взаимодействия
  • Достоинства методики
    • Дешевизна – не требует отвлечения сотрудников от работы
    • Может применяться произвольно, в любой момент
    • Скорость – можно получать требуемые данные мгновенно
    • Полная автоматизация
  • Недостатки методики
    • Нет учета антипатий – сотрудники могли работать вместе, но при этом относились друг к другу негативно (с другой стороны выявления антипатий - дорого)

 

Что мне хочется сделать дальше:

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


Мой сайт - www.msmirnov.ru

пятница, 22 октября 2021 г. - www.msmirnov.ru

Зависимость размера ошибок при планировании проекта от его размера

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

Для ответа на этот вопрос я вновь проанализировал тот же набор из 2200 проектов за последние 5 лет и вот какие результаты я получил:

На графике показано изменение вероятности успеха проекта и ошибок при планировании в зависимости от размера проекта. 

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

Мой сайт - www.msmirnov.ru

вторник, 24 августа 2021 г. - www.msmirnov.ru

Зависимость вероятности успеха проекта от его размера

Недождавшись очередного Chaos report от The Standish Group я решил провести собственное исследование распределения вероятности успеха проектов в зависимости от их размеров и проанализировал результаты порядка 2000 (конечно не 50000, как у The Standish Group, но все же) проектов за последние 5 лет, выполненных в проектном офисе, которыж я руковожу.

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

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

И вот какие результаты я получил:

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

Основной вывод давно очевиден: разбивайте проекты на возможно мелкие фазы - это увеличивает шансы на успех.

Мой сайт - www.msmirnov.ru

понедельник, 4 сентября 2017 г. - www.msmirnov.ru

Не занимайтесь аутстаффингом. Заметки о вреде и безперспективности ИТ-аутстаффинга.

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

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

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

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

1. Исторически сложилось так, что при аутстаффинге заказчик получает результаты труда арендованных сотрудников, а все риски, связанные с выполнение трудового законодательства оставляет арендодателю. Т.е. заказчик не оплачивает отпуска, больничные, праздники, простои, неполную занятость, обучение и т.п. - все это приходится оплачивать компании-арендодателю из своей прибыли. Если для примера прикинуть, что маржа составляет 25%, и какой-то сотрудник отработает на нового заказчика 3 месяца, а потом уйдет на месяц в отпуск, который у него накопился за прошлое время работы, то компания-арендодатель потратит всю свою прибыль на оплату его отпуска и получится так, что за 4 месяца она не заработала ничего.

2. При отборе сотрудников заказчики, как правило, ориентируются на лучших специалистов, которых вы предлагаете. Предположим у арендодателя есть 20% ведущих специалистов, 20% новичков и 60% обычных сотрудников. Заказчики готовы будут рассматривать ведущих и часть обычных, но не новичков. Если арендодатель передаст в аренду, например, все 20% ведущих и большую часть обычных, то у него останутся на руках 20% новичков и часть обычных.

Возникнет вопрос - что с ними делать дальше?

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

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

Остается третий вариант - уволить. Но в этом случае арендодатель теряет часть компании, а, кроме того, теряет перспективы роста.

3. Предположим, что у арендодателя работают 30 сотрудников равной квалификации, причем первые 10 знакомы с технологиями А и В, вторые 10 с технологиями В и С, последние 10 с технологиями А и С.

Заказчику нужны сотрудники, знающие технологию А и он забирает первую и последнюю десятки сотрудников. Соответственно, у арендодателя остаются 10 человек со знанием В и С, которых ему некуда девать (см. пункт 2). Если повезет и придет другой заказчик, которому нужна технология В, то он пристроит ему часть людей, но часть все равно останется без дела.

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

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

6. Компания-арендодатель имеет постоянный риск переманивания сотрудников к заказчику. Особенно это касается ведущих специалистов.

7. Многие заказчики стремятся обеспечить постоянное пристутсвие арендованных сотрудников в собственном офисе. Иногда речь идет о переезде в Москву или Питер на 1-2 года. В этом случае риск потери сотрудников возрастает многократно.

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

Все это вместе в системе приводит к тому, что постепенно производство в компании-арендодателе деградирует все больше и больше, и компания теряет конкрутентные позиции на рынке вообще и на рынке кадров а частности.
Мой сайт - www.msmirnov.ru

понедельник, 24 апреля 2017 г. - www.msmirnov.ru

Заметки о ресурсном планировании проектной IT-компании

Ресурсное планирование, по моему мнению, является одной из самых важных активностей при управлении производством в проектной IT-компании.

Без качественного ресурсного планирования невозможна реализация проектов, невозможен рост и развитие компании.

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

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

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

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

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

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

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

    Матрица компетенций также позволяет осуществлять подбор сотрудников по заданным компетенциям, с учетом уровня владения, опыта и т.п.
  • Матрица текущей загрузки сотрудников.
    Этот инструмент позволяет визуально отобразить следующее:
    • Текущую занятость сотрудников (на каких проектах они заняты)
    • Планируемый срок высвобождения сотрудников
    • Простои сотрудников
    • Отсутствие сотрудников
    • Уровень переработок и пр.

      Здесь я привожу возможный вид части такой матрицы

  • Анализ изменения коэффициента утилизации (отношение кол-ва часов, отработанных всеми сотрудниками на прибыльных проектах к доступному кол-ву часов)

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

    По моим наблюдениям хорошим значением коэффициента утилизации является значений 0.8.

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

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

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

пятница, 16 декабря 2016 г. - www.msmirnov.ru

PRINCE2 - в двух словах

Вчера выступил с небольшим докладом для своих коллег "PRINCE2 - в двух словах"

Видео семинара доступно здесь:


Также тем, кому интересен PRINCE2 могу посоветовать посмотреть следующие мои ссылки:
  1. PRINCE2: Шаблоны документов на русском языке
  2. PRINCE2® Foundation certificate in Project Management (описание моей подготовки к экзамену)
Мой сайт - www.msmirnov.ru