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

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

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

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

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

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

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

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

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

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

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