Как должен вести себя нормальный PM?

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

Стать пм-ом
Заставить пма писать код

Сменить место

Добрый вечер!

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

Если пройтись по конкретике:

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

2) После оглашения оценки по задаче всегда можно ждать справедливого вопроса "Почему так много?". Для таких случаев надо уметь (а лучше уже иметь готовую) декомпозировать задачу на составляющие, оценку для которых легче аргументировать или обосновать на основании исторических данных. Всегда можно попробовать убрать неопределенность в требованиях, если это поможет снизить оценку. Если оценка даже после уточняющей беседы (к примеру заказчик может более четко описать задачу) не изменилась, то можно попробовать предоставить варианты в духе "Если мы откажемся от фишки X, то я сделаю эту задачу на два дня быстрее", чтобы дать понять, что оценку можно менять, согласившись на урезание требований.

3) Как было замечено выше, хорошим решением будет начать пользоваться трекером, который будет показывать текущую загруженность и планы на ближайшее время. Также по нему можно будет отслеживать историю выполнения задач и использовать её в качестве подкрепления для оценок.
В идеале, трекером должны начать пользоваться и пиэмы, чтобы можно было в рамках него проставить приоритет по проектам и задачам. Но в крайнем случае можно начать пользоваться им единолично и даже это поможет улучшить ситуацию. Часть времени будет уходить на управление своими задачами, а не их реализацию, но даже несмотря на это, структурирование задач очень поможет. Даже если трекером начнете пользоваться только Вы, всегда можно направлять менеджеров в него для мониторинга ваших текущих задач.

4) В описанной структуре между несколькими менеджерами проекта и программистом явно не хватает промежуточного слоя. Это может быть и ИТ-менеджер и куратор разработчиков и тимлид. Понятно, что в некоторых компаниях не могут позволить себе нанять отдельного сотрудника, координирующего действия. В таком случае явно возникает (а точнее уже возникла) проблема в оргструктуре, когда один разработчик должен выполнять работу для нескольких менеджеров.

5) В случае, когда менеджер перестал доносить до Вас желания заказчика, виноват, естественно, он. К сожалению, исправлять его косяки кроме Вас больше некому. В таком случае можно смело в любой отчетности указывать, что срыв сроков произошел ввиду отсутствия у Вас актуальных требований заказчика. Если вовремя это не проговорить, в конце виновным сделают Вас и доказать что-либо будет намного сложнее. В случае с трекером будет явно видно какая задача была поставлена на реализацию.

6) Однозначно надо описать сложившуюся проблему (она же риск нереализации проектов в срок) вышестоящему руководству. Не надо думать, что им всё равно. Речь об их деньгах и им предлагают митигировать риски.

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

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

Один pm целый день у меня расспрашивал за сколько я сделаю ту или иную задачу

Это нормально, так все и делают. А как иначе-то оценить производительность программиста и о чем вести речь с заказчиком?

Команда садится за стол, втыкает в ТЗ, задают вопросы заказчику, обсуждают, перерабатывает его в последовательность задач. Потом каждую оценивают в часах (конечно же включая туда изучение ранее незнакомого, возможный багфиксинг). Около дня это и выходит. В результате у ПМа на руках примерная (+/- 20%) оценка времени, необходимого на выполнение. С этим он идет к заказчику и общается.

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

Вы же не уложились в сроки, поэтому интерес не праздный. Конечно, на выходных - это уже некоторая фаза отчаяния.

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

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

Вы тут вообще не при чем.
Это проблема вашего руководства/владельцев.

Единственное что можете сделать вы - поговорить с руководством, рассказать им какая жопа.
Не прислушаются - валить в другое место.

По-моему, вам стоит поучиться правильно оценивать время на ту или иную задачу. Логично, что регулярный срыв сроков будет вести к конфликтам. ПМ не может оценить, за сколько вы сделаете задачу.

Проблема у вас не в ПМ-ах, а в отделе маркетинга. Ищите долгосрочные проекты и перестаньте работать по принципу конвейера. Кроме того, если дедлайны такие жесткие, почему бы их не сместить заранее на больший срок?

Стоит донести своё недовольство до руководства, посмотреть, как они отреагируют. Вариантов развития после этого может быть много: может начальству уже давно не нравится, как вы работаете? Или наоборот, их все устраивает, но они понятия не имеют, что ПМы постоянно "щелкают кнутами".

Кроме того, вы так говорите, как будто вы единственный программист в компании. У других таких проблем с этими людьми нет? Я думаю, если даже половина программистов недовольна, то к вам прислушаются.
...либо пошлют нахер, но тогда вы будете понимать, с чем вам дальше придется иметь дело.

Насчет звонков по выходным - а вы проговаривали, что звонить вам во внерабочее время не надо?

Понравились все ответы, но решил добавить свои 5 копеек.
Уясните (себе и менеджеру) кто за что отвечает.

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

За что же отвечает менеджер? Конечно, за организацию работы, а значит, за сроки. Правда, ваша беда, что менеджеры не хотят за это отвечать и будут спихивать неудачи на вас.

Теперь переходим к практике. Вы с менеджером прикидываете дела (допустим, понедельно). Но вы должны вести дневник ежедневно и вписывать туда, что сделали (буквально две - три фразы) и какие возникли проблемы. О проблемах сообщать, а раз в неделю контролировать ход работ с менеджером. Как только будут к вам претензии, вы сможете показать, из-за чего нарушился ход проекта.

Вы пишете всё в основном о своих проблемах и как вам некомфортно.
Начальству на ваши проблемы и комфорт - пох совершенно.
Либо они в курсе, что текучка ПМов и борятся с этим/не могут побороть это, либо не в курсе, а это значит им пох, на прибыль это не влияет, либо они считают что не влияет.

Если хотите изменить ситуацию, то надо идти к начальству с решением ЕГО, начальства, проблемы, а не вашей. А какие у начальства проблемы - вы не в курсе судя по вопросу.

Если дело не во мне а PM - ах то выйти к начальству с предложением как лучше находить кандидатов или каким он должен быть на эту должность.

Нафига начальству ваши предложения? Известно, что начальство существующая ситуация не устраивает и они хотят других ПМов? Решать ваши проблемы и создавать вам комфорт с ПМами начальство не будет.

Для начала выясните, почему текучка ПМов.

ЗЫ: Лайфхак. Сухие факты и доводы воздействуют гораздо хуже, чем эмоции. Если придёте и поскандалите, то это будет эффективнее. Но скандалить нужно уметь.