Мотивация и системы мотивирования

NPS – показатель для коммерсантов, тимлида фронтенд-разработки, маркетологов, но не для разработчика. Не потому что он неважен или переоценен. Разработчикам с мотивацией первого типа он параллелен их миру. Разработчик скорее развернется к потребителю, если поймет, что коллеги Толя и Оля зарабатывают втрое больше него, поскольку их продукт угадывает, что хочет потребитель, а он сам слишком увлекся внутренней красотой создаваемого и потому сидит на окладе. Впрочем, нет, он скорее объяснит происходящее «происками», если вообще заметит. Другой вариант, который может сработать, – это если ваш разработчик одержим идеей властвовать над миром (что нередко встречается среди представителей архетипа NT). Тогда процент пользователей его продукта

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

прирост пользователей

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

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

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