PM book. Только все это есть теория, которую нужно приводить к своей практике.
 
Не  знаю как  насчет человека участвуюшего в разных проектах, но менеджер может одновременно управлять от 5 до 12 подчиненными. Это один из канонов процессного менеджмента.
 
Ну и насчет организации helpdesk: это не проектный менеджмент нужно смотреть, а в ITIL.

 
On 10/2/06, vladimir.sharun@ukr.net <vladimir.sharun@ukr.net> wrote:
Sergei Podnos wrote:
SP> Привет,

SP> Несколько комментариев (прошу рассматривать как личные а не как консалтинг, никому ничего не навязываю)

SP> Во первых для организации нормальной работы следует отталкиваться от того, что человек одновременно может делать качественно только одну задачу. Правда следует избегать распространенной ошибки, когда челеовек тупо ждет результатов выполнения какого то длинного скрипта и включает это время в рабочее :), за это время компания уже заплатила купив(или разработав) соответствующую вычислительную систему и ПО.
SP>
SP> Далее смотря что называть проектами, если речь идет о support activities(однотипных) то задача IT manager построить систему таким образом, что бы любое запрашиваемое действие могло быть классифицировано и соответственно оценено по времени выполнения. Далее просто количество людей*длина рабочего дня/среднестатическое время выполнения запроса усредненное по ансамблю категорий задач. Получите оценку для количества задач которое IT Отдел сможет обработать. Если ваша практика показывает, что задач больше добавляете людей если существенно меньше ищете куда их(людей) пристроить:)

SP> Второй вариант когда запрос нестандартный. В этом случае лучше всего предоставить исполнителю проанализировать вопрос и предоставить estimate того за сколько будет сделана данная работа. Если при этом возникнет желание сократить время выполнения то просто сказать "сделай в два раза быстрее" желаемого результата не принесет. Прийдется уточнить что собственно входит в проект. Если повезет, то возможно получится найти неоптимально выбранные пути решения, хотя скорее всего прийдется либо отказаться от части функциональности, либо добавлять ресурсы на проект, если он допускает распараллеливание. Я не рассматриваю вариант когда персонал действительно ленивый и от него лучше избавиться. Хотя для обнаружения этой проблемы периодически должны проводиться  performance review.

SP> Не забывать также, что любое завершенное нестадартное действие должно быть задокументировано и соответственно перейти в разряд стадартных для компании.
SP> Особенно на это криво смотрят так называемые "гуру" и как правило всячески сопротивляются документированию своих знаний :), но IT manager который хочет построить эффективную систему обречен либо начать(продолжать) накапливать формализованные знания, либо в результате получать прямую линию кардиограммы своей или подчиненных :)

SP> А вообще если есть тяга к конкретным цифрам в американском стиле советую посмотреть материалы по курсу подготовки Project Management Professional, там эти вопросы рассматриваются очень неплохо.

А де их посмотреть ?

То, что надо накапливать базу знаний - это понятно.

--
UKR.NET Postmaster
===================================================================
uanog mailing list.
To Unsubscribe: send mail to majordomo@uanog.kiev.ua
with "unsubscribe uanog" in the body of the message