20 марта 2023 г.
Начиная с 2022 обострился дефицит ИТ-кадров на российском рынке труда. До прошлого года ситуация также была непростой, но конкуренция за кадры значительно выросла с началом СВО и частичной мобилизации. Небольшим и средним компаниям, особенно в таких сегментах как промышленное программирование тяжелее. В частности, их возможности конкурировать путём постоянного повышения зарплат, несопоставимы с аутсорсинговыми гигантами и акулами финтех-индустрии. Кроме того, они больше подвержены хантингу, у них выше вероятность утечки данных от ценных работников.
В условиях недостатка высококвалифицированных ИТ-специалистов растет роль эффективного формирования проектных команд. Не всегда удаётся довести количество специалистов до желаемого, и нагрузка на занятых в проекте разработчиков увеличивается. В этой статье попытаемся обобщить опыт нашей компании, позволяющий удовлетворить потребности проектов в условиях нехватки специалистов.
Рост зарплаты и бонусы ≠ рост мотивации
Эффективность команды — это сумма эффективности каждого её участника, и в значительной степени она зависит от мотивации. В российском, да и не только в российском ИТ, принято считать, что рост зарплаты и количество материальных стимулов определяют мотивацию разработчика. Наш опыт показывает, что это не является правилом, а материальная мотивации должна выстраиваться в соответствии с результатами, а не с формальными метриками или условными этапами работ.
По нашим наблюдениям, для многих российских программистов характерно когнитивное искажение, которое мы называем «невниманием к личному вкладу». Это нежелание трезво оценивать корреляцию между объемом выполненных задач и материальным вознаграждением. Из-за них возникают требования, основанные на ложных аналогиях с другими участниками ИТ-рынка, и предложения платить бонусы по сырым метрикам KPI за короткие итерации. Отказ от таких практик и требований увеличивает риск потери или замены специалиста, но, по нашему опыту, в целом улучшает и ускоряет проектные результаты.
В 2020 году мы обратили внимание на то, что использование дополнительных материальных поощрений разработчиков на основании план-факторных показателей негативно сказывается на рентабельности проектов. Один из проектов по внедрению 1С:ERP вообще стал убыточным. Анализ показал, что в прочих проектах запланированная рентабельность снижалась на 30% и более. Лишь незначительное количество сотрудников по итогам нескольких проектов показали полезный рост KPI в виде снижения количества сорванных дедлайнов, ускорения разработки и снижения количества ошибок.
За годы практики мы пришли к принципиально другому способу материального стимулирования. Теперь размер стимула и решение о выплате бонуса определяются по итогам завершенной крупной итерации — релиза или после завершения проекта целиком после сопоставления с реальным экономическим эффектом от реализации.
Это связано с тем, что на уровне плановых показателей данные не всегда достоверны, а результаты спринта (короткой итерации) не отражают полной картины и вклада конкретного сотрудника. Эти меры дали эффект, сотрудники перестали надеяться на гарантированные премиальные, стали ориентироваться на результат, а не просто на красивую ретроспективу короткого этапа. Скорость выполнения задач выросла, снизилась нагрузка на тестирование и количество доработок, повысился интерес сотрудников к выполнению бизнес-требований в противовес формально-технической стороне разработке.
Фокус на техническую конгруэнтность
Считается, что жесткие ограничения в выборе специалистов под узкоспециальные задачи редко характерны для ИТ. Общепринятый подход — учет компетенций в конкретном технологическом стеке и уровень специалистов (джуниор, мидл, сеньор, лид). По нашим наблюдениям, дополнительным критерием должен стать интерес разработчика конкретной предметной области, в которой ему предстоит выполнять задачи.
Мы называем это технической конгруэнтностью, т. е. общностью технических интересов компании и специалиста. Такие люди, например, интересующиеся техническими вопросами ERP-систем, системной интеграцией, АСУ ТП систем, в подавляющем большинстве случаев работают более эффективно, лучше обучаются, лучше понимают требования, высоко мотивированы. Специалисты, безразлично относящиеся к этим вопросам, пусть даже с более высокой квалификацией, менее эффективны, по ним выше текучесть.
Сервисное лидерство работает не всегда
Ещё один методологический момент, позволяющий увеличить эффективность — понимание, что в реальных условиях популярное сегодня сервисное лидерство не всегда работает так, как мы этого ожидаем. Речь о практике, широко распространенной за рубежом, где руководитель проекта является фактическим слугой команды и берет на себя максимум обеспечивающих функций, делегируя контрольно-надзорные полномочия техническому руководителю и Product Owner .
Такая модель в настоящих условиях требует коррекции. Дело в том, что в большинстве российских команд Agile-методологии (например, SCRUM) имеют массу «индивидуальных» особенностей, сложившихся исторически. В таких командах часто не предусмотрены некоторые роли, которые есть в классических SCRUM-командах. Эти методологические и ролевые различия при злоупотреблении сервисным лидерством приводят к сверхлояльности руководителей проектов. Как итог — снижение их руководящей роли, падение авторитета требований и задач, которые они ставят.
«Одеяло» реального лидерства закономерно перетягивают технические руководители, что смещает фокус команды на сугубо технические вопросы в ущерб бизнес-ценностям разрабатываемого продукта и организационным требованиям.
Наш опыт показывает, что помимо элементов сервисного лидерства руководитель проекта должен обладать компетенциями в применении старого доброго метода «кнута и пряника». Кроме того, вопреки широко распространенному в Agile лоялистскому подходу иногда должен уметь включать «авторитарного диктатора», способного жестко требовать результаты, соблюдение дедлайнов и методологической дисциплины, особенно когда в командах отсутствует SCRUM-мастер.
Применение модели Белбина
При приблизительно равном уровне специалистов и достаточных компетенциях для распределения в несколько проектов эффективность работы можно улучшить, используя командные роли по Белбину. Кратко модели можно представить следующим образом.
- Идеи
- Генератор идей — воображение, нестандартное мышление, игнорирует детали, слишком занят для нормального фидбека.
- Аналитик — вдумчив, рассудителен, проницателен, не умеет вдохновлять и побуждать к действию.
- Специалист — предан делу, эксперт, медлителен, ограничена область интересов.
- Действия
- Реализатор — надежен и трудолюбив, реализует идеи на практике, ригиден, тяжело принимает новое.
- Мотиватор — требователен и напорист, преодолевает препятствия, провоцирует и задевает людей за живое.
- Контролер — высокая точность, пунктуальность — святость дедлайна, тревожность, не может делегировать.
- Люди
- Координатор — зрелый и уравновешенный, ускоряет принятие решений, распределяет работу.
- Исследователь ресурсов — коммуникабельный экстраверт, умеет налаживать контакты, чрезмерно оптимистичен, быстро теряет интерес.
- Вдохновитель — неконфликтен, всегда готов сотрудничать, «душа команды», нерешителен в случае проблем.
Очевидно, что чистых представителей роли найти тяжело, но каждый специалист имеет выраженную склонность к той или иной ролевой модели (или нескольким сразу). Наш опыт показывает, что идеальные менеджеры проектов — это координаторы, мотиваторы и исследователи ресурсов. «Аналитики», «реализаторы» и «специалисты» хорошо работают вместе при разработке, а контролёры прекрасно чувствуют себя в тестировании.
Среди мотиваторов и специалистов часто попадаются успешные технические руководители и ведущие разработчики. В идеале включать в команду как минимум одного вдохновителя, если речь идёт о SCRUM-методологии на должности SCRUM-мастера. Генераторы идей архиполезны в командах проектов с высокой степенью новизны, но крайне неэффективны при выполнении сервисных задач, а также рутинных и типовых работах.
Итог
Для описания всех приемов повышения эффективности в ИТ-проектов едва ли хватит одной статьи. Мы написали лишь о тех, которые, как нам представляется, особенно актуальны сегодня и используются относительно нечасто. Кроме этого, позитивно влияет на работу использование алгоритмов и методик, исследованных в статье А. А. Захаровой, К. В. Захарченкова и Ю. В. Вайнилович «Повышение эффективности формирования проектных команд и распределения в ИТ-Проектах». Безусловно, предложенные нами способы не являются универсальными, т. к. многое зависит от специфики деятельности, особенностей конкретной компании и даже отдельной команды. Наш опыт, между тем, показывает практическую эффективность выбранных способов.
Источник: Владислав Таболин, генеральный директор ЕАЕ-Консалт