Как наставничество помогает удерживать сотрудников

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

При этом мы используем следующие виды наставничества:

1. Наставничество на испытательном сроке (самый простой и очевидный вид наставничества)
2. Наставничество в обучении (для изучения какой-либо специализированной технологии)
3. Наставничество при подготовке к сертификации (понятно из названия о чем идет речь)
4. Наставничество при переходе на новый проект (для изучения сложной предметной области проекта или объемных информационных систем, над которыми ведется работа)
5. Наставничество при работе со студентами-практикантами высших и средних учебных заведений.
   

Читатели моего блога наверняка обратили внимание, что последние несколько лет я занимаюсь изучением влияния сплоченности коллектива на различные аспекты его деятельности (например: Зависимость вероятности увольнения сотрудников от размеров рабочих групп или Как быстро одиночки уходят из компании) на основе своей методики Авторская методика количественной оценки сплоченности рабочих групп.

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

Я проанализировал порядка 1000 увольнений за 10 лет и вот какие результаты я получил:

1. Сотрудники, которые периодически выступают в качестве наставников для своих менее опытных коллег-стажеров в своей же компании работают в среднем в 2.5 (!) раза дольше, чем те, кто этим не занимается.
2. В свою очередь сотрудники-стажеры, у которых были наставники из числа своих более опытных коллег работают в компании в среднем в 1.5 раза дольше, чем те, у кого таких наставников не было.

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

Как быстро одиночки уходят из компании

В конце 2021 года я опубликовал статью "Зависимость вероятности увольнения сотрудников от размеров рабочих групп" http://michaelsmirnov.blogspot.com/2021/12/blog-post.html в которой показал, что "сотрудники, работающие в одиночку, обладают максимальной вероятностью увольнения" (это был основной вывод той статьи). 

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

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

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

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

На графике видно, что около 30-35% сотрудников увольняются через 2-3 месяца после начала работы в одиночку (т.е. их остается порядка двух третей от изначального количества). По истечении 6-ти месяцев из них уходят уже порядка 65%, а остается только одна треть. И через 2 года от начала работы в одиночку от исходного количества остается чуть меньше 20%, а более 80% увольняются.

Чем с большим количеством коллег взаимодействует сотрудник - тем выше его зарплата

Около 2-х лет назад я опубликовал пост "Авторская методика количественной оценки сплоченности рабочих групп" (http://michaelsmirnov.blogspot.com/2021/11/blog-post.html), в котором ввел понятие "Охват сотрудника", смысл которого заключается в подсчете кол-ва коллег, с которыми сотрудник работает на одном проекте в заданный период времени.

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

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

Я исследовал порядка 400 сотрудников и вот какую среднюю зависимость я в итоге выявил:

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

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

Особенно заметен резкий рост зарплаты при превышении порога в 80 коллег.

Сотрудники недооценивают своих руководителей или новое проявление эффекта Даннинга-Крюгера

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

Однако, недавно я обнаружил то, что называю внешним эффектом Даннинга-Крюгера, о котором хочу рассказать ниже.

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

Каждый критерий имеет свой вес в итоговой оценке (значение которого меняется в зависимости от специальности сотрудника, так же, как и набор самих критериев), но для простоты можно сказать, что итоговое значение оценки 360 лежит в пределах от 0 до 100%.

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

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

Продемонстрирую это на графике еще раз:

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

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

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

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

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

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

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

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

Всего я провел анализ примерно 2200 проектов за 6 последних лет и вот какие результаты я получил: 

 

 

Для наглядности приведу график зависимости:

 

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

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

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

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

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

 

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

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

 

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

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

 

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

 

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

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

 

 

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

 

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

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

 

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

 

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

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

 

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

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

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

 

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

 

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

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

 

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

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

 

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

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

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

 

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

 

 

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

 

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

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

Например:

 

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

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

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

 

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

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

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

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

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

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

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

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. Заказчики не заинтересованы в развитии арендованных сотрудников - т.е. они не желают нести дополнительные расходы по их обучению, не приветствуют ротацию сотрудников с целью получения нового опыта.

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

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

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

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

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

Основными задачами ресурсного планирования являются следующие:

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

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

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

 Такими факторами являются следующие:

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

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

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

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

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

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

Как отрицательная мотивация убивает качество

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

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

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

А теперь обещанные примеры-наблюдения.

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

• В компании Б решили депремировать разработчиков, если в их коде слишком много высоко-приоритетных багов.
  
  Какой был найден выход: договориться с тестировщиками о том, чтобы они не давали формальный ход высоко-приоритетным багам, а сообщали о них неформально.
  
  Результат: несоответствие формальных показателей качества продукта реальному качеству, и, как следствие, уход заказчика.
  
• В компании В решили депремировать аналитиков за низкое качество технических заданий, выявление большого количества несоответствий записанных требований реальному положению дел.
  
  Какой был найден выход: закрывать недочеты как "Не баг".
  
  Результат: низкой качество работы с требованиями.
  
• В компании Г решили депремировать специалистов тех.поддержи за большие задержки в ответах на запросы клиентов.
  
  Какой был найден выход: отвечать клиенту быстро, но невразумительно.
  
  Результат: низкое качество обслуживания клиентов.

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

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

Концепция развития персонала ИТ-компании

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

Вот они:

1. На рынке наблюдается острая нехватка специалистов по всем направлениям - разработчики, тестировщики, аналитики, тимлиды, руководители проектов.
2. Постоянно растущее многообразие технологий приводит к тому, что сейчас практически каждый новый проект предполагает освоение командой какой-то новой технологии.
3. Проектов на рынке много, больше чем людей, которые способны их качественно реализовать.
4. ВУЗы готовят специалистов с сильным академическим уклоном, при этом у них страдает подготовка по более "практическим" направлениям.
5. ВУЗы заинтересованы в интеграции с работодателями, но эта заинтересованность, как правило, продвигается отдельными энтузиастами, общей системы нет. В целом работодатели и ВУЗы дезинтегрированы.
6. Большинство ИТ-специалистов хотят учиться и развиваться и им следует обеспечить такую возможность.
7. Обучение и развитие специалистов должно идти согласованно с производством, чтобы с одной стороны обеспечить закрепление полученных знаний на практике, а с другой стороны гарантировать обучение именно в тех направлениях, в которых нуждается производство.
8. Сотрудники являются основной ценностью ИТ-компании, ее основным конкурентным преимуществом, наряду с производственными процессами.

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

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

Направления	Методы	Инструменты
Подбор	Профили (модели) компетенций
	Методы оценки компетенций кандидатов
	Кадровый резерв
	Работа с учебными заведениями	1. Студенческая практика 2. Преподавание в учебных заведениях 3. Знакомство со студентами старших курсов 4. Проведение олимпиад и конкурсов
	Хантинг сотрудников
	Мониторинг рынка труда
	Внутренний подбор
	Отслеживание карьеры ушедших сотрудников
Адаптация	Welcome-треннинг	План адаптации
	Формулирование зон ближайшего развитиия	Беседа с сотрудником, его руководителем, сохранение результатов во внутренней системе
	Наставничество
	Помощь в поиске жилья
	Оценка результатов прохождения испытательного срока
Ведение и развитие	Выявление личных мотивов сотрудников	1. Сохранение особенностей личных мотивов сотрудников по внутренней учетной системе 2. Формулирование зон ближайшего развития
	Категоризация персонала	1. Принципы категоризации персонала 2. Присвоение категорий 3. Сохранение категорий сотрудников по внутренней учетной системе
	Ежеквартальные цели сотрудников	1. Формулирование целей сотрудников совместно с их непосредственным руководителем 2. Сохранение текущих во внутренней учетной системе 3. Анализ результатов достижения целей 4. Сохранение истории целей во внутренней учетной системе
	Периодическая оценка сотрудников	1. Автоматизированная оценка через опросы во внутренней учетной системе 2. Автоматическое присвоение категории сотруднику 3. Сохранение истории результатов оценок по сотруднику во внутренней учетной системе
	Анализ изменения оценок сотрудников
	Обучение сотрудников	1. Внутренее обучение 2. Внешнее обучение 3. Сертификация 4. Наставничество
	Матрица компетенций	1. Формирование списка технологий и компетенций 2. Оценка сотрудников по знакомству с технологиями 3. Сохранение матрицы компетенций и ее истории во внутренней учетной системе 4. Внутренний подбор сотрудников на основе имеющихся компетенций для новых проектов
	Периодический анализ потребностей компании
	Профили (модели) компетенций
	Ротация сотрудников
Выведение	Интервью на выходе	Беседа
	Анализ результатов трудоустройства ушедших сотрудников