вторник, 28 декабря 2021 г. - www.msmirnov.ru

Тренды 2021 в ИТ РФ (мой взгляд)

Тезисно для себя зафиксировал основные замеченные, наблюдаемые на рынке ИТ в РФ в 2021.

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

Обзор не претендует на полноту и отражает исключительно мои наблюдения.

 

Что произошло

  • Пандемия резко популяризировала удаленку
    • ~35% сотрудников перешли на удаленку и не готовы возвращаться в офис (лучше увольнение, чем возврат в офис)
  • Резко обострилась конкуренция в банковском секторе РФ в части развития ИТ-сервисов (Сбер, ВТБ, Ренессанс, Альфа, Тинькофф, МКБ и др.)
  • Банки смягчили требования в части ИБ и разрешили удаленку
  • Острая потребность в ресурсах и удаленка открыла для банков региональные рынки труда
  • Банки стали предлагать удаленщикам из регионов московские зарплаты
  • Банки стали нанимать удаленный персонал низкой квалификации для реализации будущих проектов
    • Конкуренция за региональные ресурсы привела к резкому росту зарплат по всей стране (по нашим оценкам на 30-60%)
       

 

Что имеем по итогам 2021

  • Регионального рынка труда больше не существует – теперь существует только федеральный рынок
  • Чтобы получать московскую зарплату сотрудникам больше не надо переезжать в Москву
  • Рынок монополизируется федеральными игроками, которые выдавливают мелких игроков с рынка
  • Текучка персонала в регионах до 30% в год

 

 Какие перспективы?

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


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

четверг, 16 декабря 2021 г. - www.msmirnov.ru

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

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

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

И вот какие результаты я получил (всего было проанализировано 132 увольнения):


 

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

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

суббота, 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