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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Похожие статьи:
5 лет назад Дмитрий Гайворонский уехал работать по контракту в Google на позицию Technical Project Manager, а через год перешел в Amazon Web Services....
Цьогоріч Україна святкує 30-річчя незалежності. Ми не могли оминути таку дату та провели невеличке опитування серед...
Компанія Intellias оголосила про придбання Digitally Inspired, IT компанії, яка базується у Великій Британії та фокусується...
Розробники застосунку спільно з фахівцями Повітряних сил створили алгоритм, що надає інформацію про регіон...
Время от времени я читаю лекции технической тематики. В этой статье хочу рассказать, зачем я это делаю...
Яндекс.Метрика