20 марта 2023 г.

Владислав Таболин

Начиная с 2022 обострился дефицит ИТ-кадров на российском рынке труда. До прошлого года ситуация также была непростой, но конкуренция за кадры значительно выросла с началом СВО и частичной мобилизации. Небольшим и средним компаниям, особенно в таких сегментах как промышленное программирование тяжелее. В частности, их возможности конкурировать путём постоянного повышения зарплат, несопоставимы с аутсорсинговыми гигантами и акулами финтех-индустрии. Кроме того, они больше подвержены хантингу, у них выше вероятность утечки данных от ценных работников.

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

Рост зарплаты и бонусы ≠ рост мотивации

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

По нашим наблюдениям, для многих российских программистов характерно когнитивное искажение, которое мы называем «невниманием к личному вкладу». Это нежелание трезво оценивать корреляцию между объемом выполненных задач и материальным вознаграждением. Из-за них возникают требования, основанные на ложных аналогиях с другими участниками ИТ-рынка, и предложения платить бонусы по сырым метрикам KPI за короткие итерации. Отказ от таких практик и требований увеличивает риск потери или замены специалиста, но, по нашему опыту, в целом улучшает и ускоряет проектные результаты.

В 2020 году мы обратили внимание на то, что использование дополнительных материальных поощрений разработчиков на основании план-факторных показателей негативно сказывается на рентабельности проектов. Один из проектов по внедрению 1С:ERP вообще стал убыточным. Анализ показал, что в прочих проектах запланированная рентабельность снижалась на 30% и более. Лишь незначительное количество сотрудников по итогам нескольких проектов показали полезный рост KPI в виде снижения количества сорванных дедлайнов, ускорения разработки и снижения количества ошибок.

За годы практики мы пришли к принципиально другому способу материального стимулирования. Теперь размер стимула и решение о выплате бонуса определяются по итогам завершенной крупной итерации — релиза или после завершения проекта целиком после сопоставления с реальным экономическим эффектом от реализации.

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

Фокус на техническую конгруэнтность

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

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

Сервисное лидерство работает не всегда

Ещё один методологический момент, позволяющий увеличить эффективность — понимание, что в реальных условиях популярное сегодня сервисное лидерство не всегда работает так, как мы этого ожидаем. Речь о практике, широко распространенной за рубежом, где руководитель проекта является фактическим слугой команды и берет на себя максимум обеспечивающих функций, делегируя контрольно-надзорные полномочия техническому руководителю и Product Owner .

Такая модель в настоящих условиях требует коррекции. Дело в том, что в большинстве российских команд Agile-методологии (например, SCRUM) имеют массу «индивидуальных» особенностей, сложившихся исторически. В таких командах часто не предусмотрены некоторые роли, которые есть в классических SCRUM-командах. Эти методологические и ролевые различия при злоупотреблении сервисным лидерством приводят к сверхлояльности руководителей проектов. Как итог — снижение их руководящей роли, падение авторитета требований и задач, которые они ставят.

«Одеяло» реального лидерства закономерно перетягивают технические руководители, что смещает фокус команды на сугубо технические вопросы в ущерб бизнес-ценностям разрабатываемого продукта и организационным требованиям.

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

Применение модели Белбина

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

  • Идеи
    • Генератор идей — воображение, нестандартное мышление, игнорирует детали, слишком занят для нормального фидбека.
    • Аналитик — вдумчив, рассудителен, проницателен, не умеет вдохновлять и побуждать к действию.
    • Специалист — предан делу, эксперт, медлителен, ограничена область интересов.
  • Действия
    • Реализатор — надежен и трудолюбив, реализует идеи на практике, ригиден, тяжело принимает новое.
    • Мотиватор — требователен и напорист, преодолевает препятствия, провоцирует и задевает людей за живое.
    • Контролер — высокая точность, пунктуальность — святость дедлайна, тревожность, не может делегировать.
  • Люди
    • Координатор — зрелый и уравновешенный, ускоряет принятие решений, распределяет работу.
    • Исследователь ресурсов — коммуникабельный экстраверт, умеет налаживать контакты, чрезмерно оптимистичен, быстро теряет интерес.
    • Вдохновитель — неконфликтен, всегда готов сотрудничать, «душа команды», нерешителен в случае проблем.

Очевидно, что чистых представителей роли найти тяжело, но каждый специалист имеет выраженную склонность к той или иной ролевой модели (или нескольким сразу). Наш опыт показывает, что идеальные менеджеры проектов — это координаторы, мотиваторы и исследователи ресурсов. «Аналитики», «реализаторы» и «специалисты» хорошо работают вместе при разработке, а контролёры прекрасно чувствуют себя в тестировании.

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

Итог

Для описания всех приемов повышения эффективности в ИТ-проектов едва ли хватит одной статьи. Мы написали лишь о тех, которые, как нам представляется, особенно актуальны сегодня и используются относительно нечасто. Кроме этого, позитивно влияет на работу использование алгоритмов и методик, исследованных в статье А. А. Захаровой, К. В. Захарченкова и Ю. В. Вайнилович «Повышение эффективности формирования проектных команд и распределения в ИТ-Проектах». Безусловно, предложенные нами способы не являются универсальными, т. к. многое зависит от специфики деятельности, особенностей конкретной компании и даже отдельной команды. Наш опыт, между тем, показывает практическую эффективность выбранных способов.

Источник: Владислав Таболин, генеральный директор ЕАЕ-Консалт