×Закрыть

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LinkedIn

52 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Эм, а зачем 3й менеджер нужен команде?

Вы не поняли — это один и тот же менеджер, есть просто несколько вариантов его позиции.

Дык в том-то и беда — третий сценарий поведения команде не нужен. Вместо ПМа у команды становится 2 заказчика (один изних с приставкой и.о.).

Менеджер — это наемный работник. Он «служит» компании, а не клиенту (если это, конечно, не outstaffing/bodyshop). Он не «депутат» от команды, чтобы отстаивать ее интересы (некоторым назначенным менеджерам из разработчиков с этим очень сложно смириться, отсюда и выгорание).
Для бизнеса ценностью являются как клиенты, так и сотрудники (команда). Но самое важное — репутация (как на рынке заказчиков, так и на рынке труда). И у тех и у других есть свои заморочки, которые могут нанести вред бизнесу — ее репутации, будущему компании (независимо от того, является она аутсорсинговой или разрабатывает свой продукт, ли и то и другое).

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

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

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

Валік,стаття цікава на 70%, пиши ще. Але останні 30 — це печаль... Якщо матимеш ча — почитай PMBOK. Є такий термін як «стейкхолдер» — людина, на яку проект може вплинути, або яка може вплинути на проект. То от: члени команди — це теж стейкхолдери

У випадку #3 може бути незадоволена команда, а це нічим добрим не закінчується.

Правильний варіант — найближчий до #2 без перегоряння і ще з кількома пунктами. Це можливо ;)

Ну по уму ПМ должен играть за успех проекта, а не за стейкхолдеров

Воно все дуже поруч

Оставлю здесь заезженую фразу из фейсбучка.

Мы нанимаем толковых людей, не для того чтобы говорить им что делать, а чтобы они говорили нам что делать.

Иногда лучше ничего не писать, чем писать такое)

Я же не против — если вы напишете лучше.... цель было кратко высказать мысль, почему ПМ не всегда делает то, что команду думает он должен делать. Если уж очень ужать мысль.

судя по всему, вы так менеджером и не стали.

Невозможно просто взять и стать менеджером (я вообще не очень люблю это слово) — вчера Вы пили англуляр, а сегодня бац и все... вы многим вещам учитесь постоянно.

Поддержу одного из комментаторов — показана модель с неслабым таким допущением, что заказчик — один, цельный объект.

Часто же должностные лица заказчика преследуют цели прямо противоположные бизнесу заказчика. Чем больше компания — тем это сильнее выражается.

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

Да согласен — это мое упущение...

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

Какое-то ограниченное видение вовлечения менеджера.

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

Тут многое зависит от личных качеств. Унылый человек вряд ли сможет держать команду в тонусе и отстаивать свою сторону адекватно перед клиентом. Плюс без понимания азов человеческой психологии будет вечно в трениях с командой/клиентом.

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

«Кто девушку кормит, тот ее и танцует» © Клиент платит деньги и менеджер остативает его интересы, кроме № 3 ничего не бывает.

Клиент платит деньги
вы только с физлицами работали?

я работаю с тикетами, над тем кто их автор не задумываюсь.

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

Такое тоже есть. Но любой менеджер он же не только хочет просто сделать все для заказчика и все. Да — можно выжать из команды все, но скорее всего команду вы потеряете и как факт в будущем понесете расходы по формированию новой команды либо будет вынуждены перенести расходы на заказчика. А если вы хотите удержать заказчика — то вам нужна стабильная команда, с которой заказчику будет комфортно работать — а это уже долгосрочная стратегия.

Хотя в оправдание к вашему примеру — вот пример вам директор корпорации Google Сундар Пичаи, когда большая часть команды Google Now, уволилась из компании из-за разногласий с новым гендиректором Сундаром Пичаи относительно пути развития проекта и при этом за 2015 год он получил бонус в 119 миллионов...

Google Now
Ну и результат мы видим, какая-то никому не нужная хрень. Пока у Гугла есть 2 приличных продукта — поисковик и распознавание речи. Тот же Андроид — еще то уродство.
Но у гугла прибыль не с продажи продуктов, а с рекламы.
Выпустит кто поисковик не хуже гугловского и гугл тут же потеряет кучу доходов.
А с андроидом, у меня есть ощущение, что он сейчас занимается тем же, чем занималась MS долгие годы в части конкурентной борьбы.

Какая клиенторцентричная точка зрения. Как насчет менеджера, который пытается удовлетворить запросы рынка?

Какие запросы рынка в аутсорсе? Что клиент сказал — именно то и нужно делать, а не умничать, даже если он говорит полную херню.
А для удовлетворения запросов рынка клиент наймет программистов и менеджеров рядом, а не где-то там аутсорсеров.

А что — где-то в статье упоминается аутсорсинг?

Подразумевается.

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

аутсорсинг головного мозга подразумевается

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

А если я HR-менеджер — кто мой клиент?

HR это конечно целая область — ну допустим вы HR Business partner и тогда заказчик скорее всего для вас Account Manager. У рекрутера (или сейчас называют Talent Acquisition specialist) — может быть либо непосредственно заказчик, либо тот же Аккаунт менеджер, по по-поему опыту очень редко может выступать сам клиент, обычно клиент просто формирует требования аккаунт менеджеру — мол нужно сделать то и то, а вы найдите мне команду. Хотя в том же EPAM на Barlays требовали определенных специалистов.

А глава компании, CEO — кто у него клиент?

Если это публичная компания — то акционеры, ну или по факту держатели основного пакета.

И вы считает, что основная задача CEO как менеджера — ублажить акционеров как клиентов?

А вы думаете нет ? Как он это делает — это уже его проблемы.

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

Вот предложенное определение:

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

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

Как насчет менеджера, который пытается удовлетворить запросы рынка?
Если это не магазин всё по пять, то со временем появляются т.н. крупные клиенты продукта, которым чхать на запросы рынка :) они хотят, чтобы делали так, как нужно сейчас им, а не какому-то там рынку.
Как насчет менеджера, который пытается удовлетворить запросы рынка
Я бы даже сказала — как насчет менеджера, который удовлетворяет запросы бизнеса, который его нанял.

Статья исходит из того, что работа ПМ-а состоит в согласовании противоположных друг другу потребности заказчика и программистов. Но это не так процентов на 80. Основная работа менеджера проекта это скорее согласование ожиданий и помощь всем сторонам для поддержания некоторого уровнем визибилити, управляемости и четкости проекта.

а еще есть вариант, где рисунок как во втором варианте, только работает без овертаймов и выгорания, да и вообще полосу нафиг убрать надо, команде лучше условия и денег, заказчику качественней и быстрей проект сделать, вот и все win-win, никто не должен страдать

Это все конечно хорошо — но бюджеты не резиновые, денег всегда есть столько и все.

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

или от части сотрудников....или зааутсористь проект еще куда-то... или.... вариантов всегда больше — чем один :))

4. Менеджер номинально присутствует в структуре, но реально является просто передаточным звеном между заказчиком и командой. Где-то форварднуть письмо, где-то зафолоапить что-нибудь, ну 1-2-1 провести, ассесмент там всякий )))
...
Тоесть, его нет на картинках выше, равновесная прямая дрейфует сама по себе по безкрайнему океану требований, хотелок и запущенных друг в друга какашек.

Это конечно «благородная идея» — давайте уберем менеджера, все общаются напрямую с заказчиком, все планируется командой, все честно ходят на митинги, собираются вовремя и обновляют статус и никто никого не пинает — такое может работать в небольшой команде, дальше все равно придется выделять кого-то (назовите его как хотите, хоть скрам-мастер, хоть ПМ, хоть Бог-Вуду), кто будeт координировать работу. Сам заказчик не захочет так работать с вами — просто по закону «кошелька Миллера» :))

Ну почему же, есть другая «благородная идея» заменить программистов системами визуального проектирования и единой компонентной базой на все случаи жизни.
Так что 1:1 )

единой компонентной базой на все случаи жизни.
Где же ее взять на все случаи жизни :))

Ну для начала ограничить количество случаев жизни.

Подписаться на комментарии