Про роботу · 15 серпня 2016, 12:45 8758

Voodymyr Samoilenko, JS developer: Node.JS, React.JS, Angular

ПМ гадит... разработчику. Как быть? Что делать?

Всем привет!

На выходных в компании друзей делали разборы полетов по работодателям и вот обнаружили такую вполне типичную рабочую ситуацию.

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

Лично сам сталкивался с таким в большей или меньше степени.

Есть ПМ, сертифицирован как Скрам мастер, но полный ноль в разработке: может в гугле поискать и найти статейку, чтобы показать как хочет, но профессиональные термины называет жаргоном.

Есть девелопер.

Есть Jira с описанием задачи на 1-3 предложения. С учетом, что проект «портируется», такого описания задачи вполне хватает + на этапе получения задачи в работу дополнительный инструктаж голосом с ответами на вопросы разработчика.

Девелопер тут, ПМ — там.

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

Потом ПМ начал показывать «фокусы»:
1. Для приемки работы им: нужно после переноса задачи в тест — еще лично сообщить по слаку. Позже добавилась личная демонстрация через шаринг экрана.
2. На этапе приемки работы он вдруг «вспоминал» о еще небольшом уточнении. Иногда уточнения шли сериями: по одному за приемку. В итоге приемка проходила с пятой попытки.
3. Через неделю таких уточнений стало больше 3-х за один раз и они стали требовать уже на 5 минут, а реально по пару часов. Договорились, что ПМ будет открывать новые тикеты на расширения задач.

Прошла еще неделя. ПМ «забыл» о договоренности уточнение задачи — новый тикет. После напоминания все расширения задач начал открывать их как баги.
Появились "баги«/доработки на «Решенные» задачи.

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

Через неделю наш девелопер потерял место на славной галере, формулировка от руководства была такая:
«очень много багов за последний месяц, нам так не нужно»
:)

И теперь вопросы:
1. Стоит ли сразу стучать руководству на ПМа, когда он начинает выходить за рамки задачи?
2. Как правильно показать некомпетенстность ПМа в приемке работы?
3. Как пресекать самодеятельность такого ПМа?
4. Как бы Вы «строили работу» с таким ПМом?
5. Как можно сохранить свою репутацию в таком «окружении»?

Теми: PM

👍ПодобаєтьсяСподобалось0

До обраногоВ обраному0

Facebook

Twitter

Найкращі коментарі пропустити

Oleg Kariakin 16.08.2016 09:09

Есть хорошая книга «Съесть или быть съеденным», не совсем ИТ, но все же почитайте. Первое правило гласит — если начальник хочет вас съесть, он вас съест. Но вы можете удлинить этот срок записывая все в «свой дневник» — JIRA комментами, сохраняя себе все СС email-ов, высылая follow-up-ы на митинги — прикрывая жёпу по полной. И в случае такого кипиша можно показать что такого не было и не говорили. Но в наших реалиях захотят выгнять — выгонят.

1. Стоит ли сразу стучать руководству на ПМа, когда он начинает выходить за рамки задачи?

А как вы думаете PM стал PM-ом? Кто его назначил и за какие заслуги? И тут приходите вы и косвенно указываете на то, что начальник PM-а некомпетентен (ведь он его назначил).

2. Как правильно показать некомпетенстность ПМа в приемке работы?

Да никак, пока он начальник это невозможно. Он — начальник, ты — дурак. Чем тупее начальник, тем больше он в это верит.

Пункты 3-5 ИМХО надо валить на другой проект/контору, а PM пусть дальше «рулит».

Выгнали да и слава богу. Нафиг надо с придурками работать.

Перейти до дискусії

Andrusenko Dmytro 15.08.2016 16:02

1. Стоит ли сразу стучать руководству на ПМа, когда он начинает выходить за рамки задачи?

Нет. Это не работа руководства разбираться, что там должно входить в рамки конкретной задачи, а что — нет. Для этого ПМа и наняли, чтобы он разбирался. Раз ПМ решил так — значит он так считает будет лучше. К руководству стоит обращаться, когда деятельность ПМа прямо приводит к потере качества/производительности на проекте и вы можете это показать на пальцах с конкретными цифрами, а не просто лить воду и делиться эмоциями.

Как правильно показать некомпетенстность ПМа в приемке работы?

Для начале научиться правильно формулировать вопросы: показать кому и для чего?
Показывать самому ПМу бесполезно, если только он сам не просит у вас фидбек — только наживете себе врага. Показывать другим разработчикам — они сами должны все видеть, если есть что видеть. Показывать руководству — руководство не интересует детали приемки отдельных задач, т.к. для этого и наняли ПМа чтобы у него голова болела по организации этого и других процессов. У руководства другие метрики оценки компететности ПМа, чем у вас.
Допустим вам удалось доказать некомпетентность ПМа всем, кому вы хотели доказать, что дальше? Какой результат вы рассчитываете в результате получить, и почему так уверены, что не можете получить этот результат без доказательства некомпетентности ПМа? Вы считаете, что руководство будет учить ПМа делать его работу? Нет, не будет. Уволит ПМа и заменит на другого — не факт, что новым вы будете довольны больше, совсем не факт...

Как пресекать самодеятельность такого ПМа?

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

Как бы Вы «строили работу» с таким ПМом?

Зависит от того, как это влияет на мою работу, как разработчика, и на проект в целом.
1) Если есть места, которые можно, по моему мнению, улучшить — начал бы разговор с ПМом на эту тему, чтобы либо изменить что-то к лучшему, либо понять, почему лучше оставить как есть.
2) Если в результате 1) становится понятно, что улучшения нужны, но их не будет из-за «человеческого фактора» и дальнейшие разговоры с ПМом не имеют смысла — попутился бы донести руководству ситуацию на преокте с конкретными цифрами и объяснением, какие проблемы могут быть. Руководство очень хорошо понимает, когда с ним говоришь на языке конкретных цифр, которые можно легко конвертировать в величину денежных потерь.
3) Не зависимо от результатов 1) и 2) смотрел бы по личному желанию оставаться в проекте или уходить из него.
4) Зная, что у ПМа всегда есть какие-то «хотелки» во время приема задач, добавил бы сразу +10-20% ко времени при оценке задач.

Как можно сохранить свою репутацию в таком «окружении»?

Никак: «Я не могу дать вам формулу успеха, но готов предложить формулу неудачи: попробуйте всем понравиться.» © Джерард Своуп
Если ПМ ударился в микроменеджмент с горой баг-тикетов, а руководство приняло решение об увольнении только на основании числа баг-тикетов, не поинтересовавшить в причине их возникновения и не спросив мнение о ситуации самого разрабочика.... то пытаться тут что-то доказывть — это как метать бисер перед свиньями.
---------------------------
ПС: Мне лично кажется, что ситуация описана слишко однобоко и есть много моментов, которые вызывают дополнительные вопросы:
1) Не понятно, с какой целью ПМ ударился в микроменеджмент с принятием задач лично через скрин-шаринг. Это более напряжно и затратно, чем если посмотреть самому в удобное время и потом дернуть разработчика сообщить фидбек голосом, если есть необходимость.
2) Из 1) — если разработчиков на проекте несколько, а микроменеджить начали только избранных — тут скорее что-то связанное с самими разработчиками.
3) Если речь идет о портировании проекта, значит впринципе этот функционал уже написан и работает. Врядли там так уж много глобальных изменений — иначе это уже не портирование и переделка проекта. Соответственно непонятно, откуда ПМ умудряется постоянно брать эти «хотелки»: основной функционал уже определен, а синьерный разработчик с нормальным requirements gathering навыком большинство неоднозначных моментов сможет прояснить и закрыть на этапе уточнения требований по задаче. Без конкретных примеров судить невозможно, но равнозначным остается вариант, что разработчик мог поверхностно подходить к уточнению требований, по принципу «я примерно понял что нужно, сделаю как понял, если что потом скажут что доделать». Это вторая сторона медали, которая не исключает наличия первой, но может привести к точно такой ситуации, как была описана.
4) Очень странная поспешность увольнения. То, что за последний месяц «много багов в джире» — это не показатель для принятия кардинального решения. Вот так вот с ходу, не интересуясь причинами у самого разработчика? Слишком не типично. На место уволенного нужно кого-то нанимать, потом обучать и вводить его в проект и все равно нет 100% гарантий, что не получатся те же грабли или хуже. Так ради чего создавать самим себе лишние трудности поспешным увольнением? Тут на вскидку могут быть 3 варианта:
а) Разработчика так или иначе планировали уволить, просто подвернулся повод уволить по такой причине.
б) На самом деле причина не только в числе багов за последний, но были и другие притенизии к качеству/скорости работы, которые тут не озвучены. Не зная картины с точки зрения ПМа и руководства судить не получится, но в большинстве «типичных» конфликтных ситуаций между ПМами и разработчиками все бывает не так односторонне, как тут было описано (хотя справедливости ради стоит признать, что и именно так односторонне тоже бывает, но это уже не типичный кейс)
в) Таки имеем случай «самодурства», что может иногда встретиться в маленькой молодой конторе с нетехническим руководством, когда вместо того, чтобы разбираться с проблемами и вникать их просто назначают виновного и рубят с плеча. В таком случае нет смысла расстраиваться и беспокоиться и «репутации», т.к. хороший специалист без труда сейчас может устроиться в другую контору, где такого самодурства уже не будет.

Перейти до дискусії

Ctrl + Enter

anonymous 17.08.2016 19:43

Чтоб такого не было — ПМ должен оцениваться подчиненными и анонимно. Ну или же груповая заява какая-то, что с этим чуваком мы работать не можем. К сожалению в IT много упоротых ребят.

ПМ гадит... разработчику. Как быть? Что делать?

Найкращі коментарі пропустити

173 коментарі

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