2) Да, очередная ротация Судя по предложениям работы — старые ушли, нужны новые.

Для этого, опять таки, нужна команда. То есть, в первую очередь — коммуникация.
К сожалению, я не знаю, почему так происходит, но — бОльшая часть знакомых мне программистов даже не пытаются документировать свои наработки в каких-то областях… Ну, и возникают случаи, когда за двумя соседними столами сидят два программиста, которые делают одно и то же, натыкаются на одни и те же грабли… Только с запаздыванием примерно в неделю… И никто никому ничего не сообщает.
Возможно, одна из причин — “сдельная оплата” — то есть, первый программист, который продрался через дебри библиотек и потратил 20 часов вместо 10 — получит зарплату за 10 (и еще 10 — за свой счет), а второй, в случае если первый опишет все эти бока — аналогичную задачу сделает за 5 часов (и получит за 10, то есть 5 часов в плюс). Естественно, первому программисту невыгодно описывать свои решения — в этом случае он хотя бы сможет аргументировано (”Вот, не только я потратил на это 20 часов, все тратят по 20 часов”) “выбить” из менеджмента те самые 10 часов. И для себя, и для других программистов с теми же “затыками”.
Что, соответственно, невыгодно ни компании, ни заказчику… Но — такова схема работы.

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

resource management — это вообще одтельная песня
Да. Этому нужно учиться (и никакие ms project-ы тут не помогут) — особенно сложно понять, что этапы разработки нелинейны, человеко-часы это нечто абстрактное и не соответствует действительности (за сколько времени 10000 кошек съедят одну мышку?), помнить что есть эффект переключения задач, знать кто что лучше умеет (нет смысла сажать PHP программиста на документирование ASP модуля в то время, как ASP разработчик изучает AJAX). И прочие мелочи…

прицип “сделал свою работу, найди себе другую” должен быть.
Да, это хорошо бы. В тот период, когда у нас была такая возможность — так и делали. Подходишь к PM-у, говорить “я тут освободился”, берешь проект, смотришь, выбираешь таски которые можешь сделать, делаешь… Все довольны и счастливы.
В случае же, когда один человек занят на трех проектах одновременно — это плохо. Но это случается все чаще и чаще…

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

Но, насчет “если работа приносит уныние” — скорее всего, так и прийдется поступать. Потому что — поддержка проектов превращается в поддержку заказчиков… (и обычно — “у нас там скрипт нужно подправить”, а мы с вами уже работали)… А я ведь могу гораздо большее… Но — забит всякой мелочью, которую бы новичкам давать, как раз для разгона и тренировки… А так — ни себе, ни людям…

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

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

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

risk management, time management, resources management, configuration management. осуществлении передачи знаний, передачи опыта, ресурсов, эффективном использовании времени…
Антон, я пока что (за свою, правда, недолгую карьеру) таких менеджеров, которые бы делали это все, не видел. Ни менеджеров, ни программистов.
Риск менеджмент — это “давайте накинем процентов 20 времени на всякий случай”.
Resource Management часто заключается в следующем: “Ты сейчас свободен? Тут проект намечается, готовься”.
Про time management, configuration management, передачу знаний и так далее — вообще речь не идет. Все “как-нибудь сами”…
Процесса, как такового, нет… Он нигде не описан, каждый делает во что горазд…

Может, действительно, поступить по методу Антона Наумова?