Здравствуйте, Gaperton, Вы писали:

G>Результат оценивать, а не соответствие действий "общепринятому алгоритму", которого нет — не приходила такая свежая и неожиданная мысль в голову?

Ну, вы же сами сказали — прощелкал. Вот и оцениваем этот результат.

nvb>>Берем начинающего менеджера.

G>Берем.

nvb>> Он провалил сроки, из-за чего на компанию наложили штрафные санкции. Разбор полетов. Первый же вопрос к менеджеру: покажи список рисков. Нет? Понятно.

G>Что именно вам понятно, не объясните? А теперь допустим, что он есть. И что? Ну есть он, "а х-ли толку", как говорили в одном их анекдотов? Как будто наличие какой-то бумажки означает, что человек проанализировал угрозы, и выработал адекватный план с их учетом. И если его нет, это также не означает, что план не учитывал угроз. Это то же самое, что думать, что архитектура будет хорошая и адекватная, если ее описание вбить в руповский шаблон.

Конечно, не означает. Это означает лишь то, что риски и архитектура были визуализированы — то есть доступны для оценки и просмотра другим, более опытным человеком, и авторизованы им. Или не авторизованы. Или не просмотрены. Трудно залезть в мозги другому человеку, проще посмотреть на документ.

Да и самому РМу полезно такой документ иметь — правило 7+-2 никто не отменял. Это очень много значит.

Это первое. Второе — если уж брать нормальную компанию, в ней обычно хранятся списки проблем по прошлым проектам, которые переносятся в списки рисков на будущие проекты. Например, отказ заказчика оплачивать доп.изменения. Или, что одно и то же, полная апатия заказчика до окончания проекта и масса требований переделок по его завершению... да куча всего, вплоть до пофигизма юридического отдела. Совершенно не факт, что все проблемы из прошлого проекта перенесутся в будущий, но знать-то о них надо. И помнить надо. И учитывать надо. Я, например, честно признаюсь, не помню многих рисков из своих прошлых проектов — вот вчера на собеседовании обнаружилось . Сунуть новичку этот список под нос и потребовать составить для своего проекта подобный с учетом имеющихся данных — какой от этого вред, кроме пользы, как вы выражаетесь?

G>Давай я задам другой вопрос — кто проверял план, когда он был готов? В "инструкции" про это ничего не было сказано? А почему?

nvb>> А п.7.3 инструкции "Порядок выполнения проектов в компании ХХХ" ты читал? Почитай, узнаешь много интересного.

G>О, а мне понятно. Исполнение "инструкций" надо проверять _до_ окончания проекта провалом, уважаемый коллега. Либо выбросить их в топку.

nvb>>Понятно, что в большинстве случаев реально виноват не наш начинающий менеджер, а те люди, которые его не контролировали и не обучали его действовать по этой инструкции — у него-то самого опыта пока нет. Но такой разбор полетов, по крайней мере, лучше, чем "Что, сроки провалил? Урезаю зарплату на треть. В следующий раз уволю. Все, пока."

G>Такого разбора полетов по _завершению_ проекта быть не должно. По завершению проекта анализируется его ход — что было хорошо, что плохо, с целью извлечь выводы для их учета в дальнейшем. Вне зависимости от инструкций, и не на предмет соответствия им. Процедуры определяются в начале проекта, а не в конце.

Готов подписаться под этими вашими словами.

G>И разумеется, процедуры не гарантируют ровным счетом ничего касательно успеха проекта и его срока — процесс вероятностный.

Естественно, и процедуры смещают матожидание в сторону успеха. На сколько процентов — вот это вопрос спорный, и на него ответа нет.

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

nvb>>Потому что в первом случае он внимательнейшим образом прочитает — наконец-то — эту инструкцию и в следующем его проекте глупых ошибок будет существенно меньше. И винить он будет, большей частью, себя. А во втором случае... ну, мы не дети и понимаем, что возможна куча вариантов, которые для компании негативны все, как на подбор.

G>Какая вера в силу инструкций . Удивительное рядом. Можно пример такой инструкции с Вашей работы, коллега?

Нет!!! Это страшно подумать, что тут начнется, если будем ее обсуждать

Да нет у меня никакой веры в силу инструкций. Есть разные методы передачи знаний, культуры проектной деятельности и разные методы контроля. Ясное дело, при личном общении все это происходит на порядок быстрее и качественнее, чем при формальном "Читай ГОСТ, там все написано". Вы мне это пытаетесь доказать? Так я согласен.

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

Вопрос: у кого будет больше вероятность успешного завершения проекта? Не гарантия, а вероятность?