3Часть I. Составление плана и бюджета. Типовые методы планирования. Бюджет и материальные ресурсы
Мы будем рассматривать нашу методику на сквозном примере проекта по адаптации и внедрению некого программного продукта. Часть I будет посвящена процедуре запуска проекта. Мы рассмотрим методы планирования, приемы составления бюджета с использованием человеческих и материальных ресурсов. По ходу дела мы будем совершать небольшие типовые ошибки, последствия и методы устранения которых мы рассмотрим в следующей части.
3.1Постановка задачи
Проект должен начинаться с формулировки цели. При этом цель должна быть зафиксирована письменно в виде измеряемых показателей.
Документ "Постановка задачи" должен отвечать на следующие вопросы:
В какие сроки должна быть достигнута цель?
Какие условия достижения цели есть в наличии (бюджет, ресурсы, технология)?
Каким способом измерить достижение цели?
Как распределены обязанности в проекте (кто за что отвечает)?
Согласен ли инвестор (заказчик) с определением цели и условиями ее достижения?
В нашем примере цель проекта заключается в адаптации и внедрении некой системы документооборота. В нашем случае задание было письменным, не был определен только способ измерения того, что цель достигнута; последствия этого мы увидим далее.
3.2Список этапов
Перейдем непосредственно к нашему примеру. Менеджер получил постановку задачи на адаптацию и внедрение некого продукта Web Work Flow. Менеджер запускает Microsoft Project и приступает к планированию.
П
осле
запуска MS Project менеджер сразу видит
список для ввода задач. Слева находятся
переключатели видов списков.
В самом начале составления плана менеджер вводит список этапов, соответствующих технологии внедрения.
Совет. Включите Summary Task (Сводная Задача) для того, чтобы видеть обобщенную статистику по проекту (общая длительность, трудоемкость, стоимость и т.д.).
3.3Список задач
Ориентируясь на письменное задание, менеджер назначил задачи для всех технологических этапов.
Комментирует Владимир Либерзон
Замечание. "Должны быть типовые фрагменты (подпроекты) – корпоративный стандарт выполнения стандартных этапов. Тестирование вряд ли сильно отличается для разных задач и нечего менеджеру каждый раз изобретать велосипед."
Могу только согласится. Шаблоны проектов (project patterns) необходимы. Вопрос насколько они удачно сделаны. Абстрактно или из успешной практики? Выше тоже применяется шаблон, состоящий в использовании стандартных технологических этапов. Данный шаблон позволит получить единую статистику по этапам всем проектов, но как увидим дальше страдает недостатком именно из-за отсутствия выделения подпроектов.
3.4Д лительность задач
Проанализировав задание, менеджер составил свое представление об их трудоемкости и ввел эту информацию.
Замечание для опытных пользователей. В MS Project появилась возможность указывать, что некоторые сроки являются ожидаемыми, а не точными. Рядом с такими сроками выставляется знак вопроса.
3.5Последовательность задач
Ориентируясь на приоритеты задач и особенности технологии, менеджер назначил последовательность задач. MS Project выделил красным цветом критический путь проекта, т.е. те задачи, которые определяют его длительность. Чтобы сократить критический путь, менеджер попробовал начать следующую технологическую стадию до завершения предыдущей.
Советы и комментарии.
Точный срок следует указывать только для задачи "Начало проекта", все остальные сроки должны быть относительными. Таким образом, вы всегда можете легко перенести проект на другую дату, все сроки пересчитаются автоматически.
Все технологические этапы следует завершать контрольными точками. Дело в том, что по технологии некий законченный результат может быть получен только в определенное время, и именно в данный момент следует провести контрольный осмотр проекта. Жестко и подневно контролировать исполнение отдельных задач часто не имеет смысла, т.к. исполнителям обычно приходится исполнять задачи не в том порядке, как указано в плане. Все это не значит, что подневная отчетность не нужна, она нужна в виде отчетов о затратах рабочего времени, о чем речь пойдет далее.
Без нужды не используете связи между задачами разного уровня. В этом случае один технологический этап привязывается к внутренней структуре другого этапа. Это сковывает свободу модификации планов в рамках отдельных этапов. Если используются связи только на одном уровне (задача-задача, этап-этап), вы можете без затруднений изменить состав и последовательность задач внутри некого этапа.
Сокращение критического пути проекта за счет преждевременного начала задач очень рискованно. Сокращайте критический путь за счет подготовительных работ (обучение, моделирование и т.д.). В нашем случае можно одновременно с постановочными работами запланировать прототипирование, и за счет этого сократить кодирование и общую продолжительность проекта. Сокращение критического пути проекта фактически всегда приводит к увеличению затрат на подготовительные работы. Иными словами, сокращение длительности проекта, как правило, приводит к повышению его себестоимости или рисков.
Комментирует Владимир Либерзон
Замечание 1. Начало проекта в MS Project нужно отмечать в его свойствах!
Можно и свойством и milestone, последнее мне кажется удобнее, т.к. его можно таскать мышкой.
Замечание 2. Подневной отчетность может и нужна для некоторых проектов.
Все верно, конкретный характер подневной отчетности определяется спецификой проекта. Для небольших софтверных проектов, подневной отчетности обычно достаточно как отчет о фактических затратах рабочего времени.
Замечание 3. Связь задач по PMBOK должна быть на нижнем уровне, а вы рекомендуете делать их на уровне этапов проектов.
PMBOK тут не однозначен, там есть две рекомендации в зависимости от условий. Связь действительно рекомендуется на нижнем уровне, в тоже время рекомендует разбивать большой проект на модули и делать связи между модулями.