Назначение руководителя
У проекта должен быть руководитель, как ни банально это звучит. Речь идет вот о чем. Руководитель – это не просто лицо, назначенное руководить. Руководитель – это: а) лидер команды, то есть тот человек, за которым готовы идти ее участники, невзирая на трудности; б) лицо, обладающее полномочиями по распределению и привлечению ресурсов в объемах, достаточных для успешного выполнения проекта, в условиях рисков и изменений; в) это один человек. Часто в проектном управлении мы оперируем не персонами, а ролями. Так, например, в проекте может быть 3 программиста и 0,5 системного аналитика, причем в реальной жизни это 5 человек: один программист на полной занятости, 3 программиста на пол-ставки и один участник, совмещающий роли программиста и аналитика. Менеджер проекта также может участвовать в нескольких проектах. Но в одном проекте должен быть только один главный менеджер.
Распределение задач по людям
Разбив общую задачу на терминальные подзадачи, мы обладаем списком требуемых ролей исполнителей и их количеством. При назначении на эти роли конкретных людей нужно учесть многие факторы, вплоть до психологической совместимости участников команды. О”Коннел предлагает придерживаться следующих основных постулатов:
Удостовериться, что напротив каждой задачи стоит имя исполнителя.
Принять во внимание другие занятия исполнителей.
Попытаться максимизировать силы команды, которую вы получили.
Первые два тезиса не требуют особых пояснений. Что касается третьего – речь идет о том простом факте, что, по оценкам исследований, «КПД», вносимый «однотипными» членами IT-команды, например программистами, может изменяться на порядок, то есть один участник команды может при определенных условиях заменить собой десяток. Поэтому, распределяя работы, следует принять во внимание индивидуальные особенности каждого члена команды, его предпочтения, достоинства, недостатки и связанные с этим риски.
Результаты назначения исполнителей отражаются на диаграмме Ганта. Другие диаграммы, поддерживаемые современными пакетами программ для проектного управления, позволяют в автоматизированном режиме отслеживать ситуации «перегрузки» ресурсов, поиска критичных задач и т.п.
Управление ожиданиями
Пройдя первые четыре этапа в управлении проектом, мы заложили модель будущего: мы знаем – кто, когда и с какими исходными данными возьмется за ту или иную часть проекта. При благоприятном стечении обстоятельств менеджеру проекта остается только пожинать лавры.
Однако, жизнь вносит коррективы даже в самые продуманные планы. Исполнитель может заболеть, уволиться или просто не уложиться в отведенные сроки; электроэнергию в офисе могут отключить; может отказать аппаратура, операционная система и т.д. и т.п. Это – простейшие примеры рисков. Естественный выход – запас ресурсов (в первую очередь - временных) на непредвиденные расходы. Каковы его размеры? В [7.5] предлагается 15%. Между тем, 50%-е резервирование, конечно же, дает большую уверенность, чем 15%-е. Где же оптимальная цифра? Очевидно, у каждого проекта должны быть свои оценки: размер резерва обратно пропорционален опыту команды, прямо пропорционален сложности задачи и т.п.
Можно долго рассуждать на тему размеров оптимального запаса, однако здесь есть следующий немаловажный фактор: в 95% случаев руководители, ответственные за распределение ресурсов не готовы выделить и 1%. Напротив, часто возникают случаи, когда инвестор требует завершить проект до ранее намеченного срока, либо в тот же срок, но с большим объемом функционала. Искусство менеджера заключается, в том числе, и в резервировании ресурсов, несмотря на возражения инвестора и в умении противостоять его давлению. С практическими примерами можно ознакомиться в [7.5].
АИС – это программно-аппаратная система, предназначенная для автоматизации целенаправленной деятельности конечных пользователей, обеспечивающую, в соответствие с заложенной в неё логикой обработки, возможность получения, модификации и хранения информации.