В чьи ворота забивает менеджер

Тема навеяна статьей «О плохих и хороших PM’ax». Сразу скажу, тут не будет жалоб кто плохой, а кто хороший. Постараюсь взглянуть на этот вопрос с теоретической стороны.

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

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

Итак, ситуация: команде нужно выбрать командного лидера. Обычно на эту позицию выдвигается либо самый активный, либо тот, кто хочет карьерного роста, либо лучший программист, который «мечтает перевернуть мир». Ну и самый плохой вариант, но, к сожалению, довольно не редкий — кто-то хочет +$500, а получить это повышение другим способом нельзя, кроме как перейти в «высшую лигу».

И вот теперь начинается самое интересное — наш менеджер может вести себя по одному из трех сценариев.

1) Менеджер пытается удовлетворить потребности команды

Изобразим нашу ситуацию графически:

Линия на графике — это линия равновесия. Для простоты, скажем, уровень оплаты труды — то есть мы соглашаемся выполнять определенный объем «хотелок» клиента только за эти деньги. Ну и понятно, что наш шкурный интерес — повысить ЗП за тот же самый объем, а интерес клиента — понизить этот уровень оплаты за тот же самый объем.

У команды может быть много пожеланий. Например, все программисты хотят новые технологии, ReactJS вместо pure-JS, MacBook вместо ПК, рефакторить все под чистую, работать из Таиланда, когда хочется и т.д. и т.п. Удовлетворить их потребности — это естественная реакция, и часто это присуще программистам, которых выбрала команда: «Команда меня выбрала = значит, я должен удовлетворять пожелания команды».

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

Замечу, что такая форма тоже работает и характерна в основном для профсоюзов.

2) Менеджер пытается удовлетворить потребности и команды, и клиента

Такой управленец постоянно работает овертайм, приходит рано, уходит поздно, кодит, планирует, отвечает на телефон в 11 ночи, а то и после 12. В общем, человек оказывается между «молотом и наковальней», быстро выгорает и уходит. Или просто физически не справляется с объемом работ. Как результат — провал спринта, релиза или итерации.

Так что если менеджер «плохо выглядит и с пессимизмом смотрит в будущее» — это случай #2, который все отказываются замечать. Решение чаще всего вот такое — «Менеджер-снежинка». Тренинги тоже могут помочь, но все равно необходимо вмешательство руководства.

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

3) Менеджер пытается удовлетворить потребности клиента

В этой ситуации менеджер начинает отстаивать интересы заказчика. Что мы имеем на выхлопе: клиент видит, что менеджер понимает и принимает его требования (какими бы бредовыми они не были), и доверие к такому менеджеру возрастает. Именно в такой ситуации менеджер может выпросить какие-то льготы или пожелания для команды — потому что клиент ему доверяет и скорее всего подразумевает, что эти пожелания отразятся либо на качестве, либо на объеме работ, либо на их стоимости.

Таким образом, растет доверие к менеджеру и у команды: команда видит, что через этого менеджера можно что-то решить. Это не значит, что вас будут любить — это значит, что вас будут уважать.

Вместо выводов

Я прекрасно понимаю, что есть нюансы, есть разные клиенты, есть разные проекты — я просто хотелось показать основы, а не лазить в дебри проектного менеджмента. Я лично прошел все три стадии, и на третьей стадии оказался только тогда, когда реально стал работать on-site.

Так что если ваш менеджер резко скинул джедайский плащ и ушел на темную сторону клиента — это не значит, что он «урод и предатель и его нужно спалить». Это значить, что он решает поставленную перед ним задачу, и его задача — сделать счастливым клиента, а через это сделать счастливым и вас.

Похожие статьи:
Ідея чотириденного робочого тижня почала ширитися світом відносно недавно — у відповідь на все частіше вигоряння працівників...
Компания Microsoft с сегодняшнего дня начинает официальные продажи гаджета Microsoft Band 2, который является прямым продолжением...
Як завжди восени, аналізуємо вступну кампанію в українські університети та розповідаємо про найцікавіші тенденції...
Дорогие друзья,Во вторник 27го сентября киевский офис Ciklum в рамках Speakers’ Corner приглашает вас на встречу, посвященную...
Новые версии Electron 1.0 Rust 1.9 OrientDB 2.2 QEMU 2.6.0 Grafana 3.0 Redis 3.2 Qt Creator 4.0.0 Linux 4.6 Perl 5.24.0 Red Hat Enterprise Linux 6.8 Мнения...
Яндекс.Метрика