Дмитрий Козубский

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

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

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

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

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

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

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

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

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

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

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

1) Ничё не понятно. Но я так понимаю, Вам репозиторий надо поднять: https://git-scm.com/book/ru/v1/Git-%D0%BD%D0%B0-%D...
2) https://github.com/kemayo/sublime-text-git (из консоли наверное и то привычнее будет работать)
3) Заставьте ваших разработчиков писать вменяемые комментарии ко всем классам, методам и т.д. в соответстветствии phpDoc. Подробности тут:
manual.phpdoc.org/HTMLframesConverter/default

Как использовать ASP.NET Framework PHP программисту?

Боюсь что никак, ASP.NET это legacy технология microsoft и что бы ее использовать нужно быть c# программистом.
Технология своеобразная и с веб разработкой общего имеет мало, это попытка перенести Web forms в веб.
Был бы asp mvc - было бы немного проще, он местами и архитектурой похож на symphony2

Если вы не знаете c# и не знакомы с asp на уровне 1-2 летней практики, то естественно поддерживать их сайты на Asp.net вы никак не сможете.
Но это все не важно,

говорят любой php программист сможет легко в этом разобраться
asp.net
битрикс

лучше просто бегите оттуда.

Вы не путаете ORM с DBAL? ORM это не технология замены SELECT * FROM goods WHERE cost < 100.00 на $db->select()->from('goods')->where('cost < 100.00'). ORM это способ задания связи объектов и РСУБД. По сути позволяет абстрагироваться от способа хранения объектов вообще, с лёгкостью переходя от SQL к NoSQL, memcache, файлам или REST/RPC API на удалённом сервере, оперируя на уровне модели (если говорить о MVC и т. п.) простыми plain old objects, а их персистентность отдать контроллеру. Не $db->select()->from('goods'),, не mysql_query('SELECT * FROM goods'), а $goodsRepository->findAll(), а уж будет репозиторий формировать SQL запрос, читать файлы или память, а может стучаться на Гугл и парсить его вывод — его, репозитория, личное дело (а также разработчика(ов), отвечающих за подсистему хранения).

Кроме того ORM, как правило не исключает обращение к БД на уровне произвольных SQL запросов, оно лишь преобразуют результаты этих запросов в объекты модели предметной области (и наоборот), которые ничего не знают (в идеале) о таблицах, WHERE, HAVING и т. п.

ORM это не только инструмент архитектурного разделения областей ответственности объектов и классов приложения, а также инструмент облегчения разделения труда разработчиков: кто хорошо шарит в SQL вообще и особенностях конкретного движка в частности — работает по «ту сторону» ORM, оптимизирует его как хочет, может нормализовывать и денормализовывать, например; кто хорошо разбирается в дебетах и кредитах — работает с plain old objects в терминах предметной области и может вообще ничего не зная об SQL, ему лишь нужно знать, что он всегда может получить объект или их коллекцию обратившись к методам вроде findById() или findAll() и сохранить результат работы методом save() или flush().