Мы будем рассматривать наши рекомендации на сквозном примере проекта по адаптации и внедрению некого программного продукта. Часть I будет посвящена процедуре запуска проекта. Мы рассмотрим методы планирования, приемы составления бюджета с использованием человеческих и материальных ресурсов. По ходу дела мы будем совершать небольшие типовые ошибки, последствия и методы устранения которых мы рассмотрим в следующей части.
Проект должен начинаться с формулировки цели. При этом цель должна быть зафиксирована письменно в виде измеряемых показателей.
Документ "Постановка задачи" должен отвечать на следующие вопросы:
1) В какие сроки должна быть достигнута цель?
2) Какие условия достижения цели есть в наличии (бюджет, ресурсы, технология)?
3) Каким способом измерить достижение цели?
4) Как распределены ключевые обязанности в проекте (кто за что отвечает)?
5) Согласен ли спонсор с определением цели и условиями ее достижения?
В нашем примере цель проекта заключается в адаптации и внедрении некой системы документооборота. В нашем случае задание было письменным, не был определен только способ измерения того, что цель достигнута; последствия этого мы увидим далее.
Перейдем непосредственно к нашему примеру. Менеджер получил постановку задачи на адаптацию и внедрение некого продукта Web Work Flow. Менеджер запускает Microsoft Project 2000 и приступает к созданию компьютерной модели проекта. Как видим менеджер приступил к этому не пройдя полного согласования задач и целей проекта, эта организационная ошибка приведет к последствиям, которые мы рассмотрим ниже.
После запуска MS Project 2000 менеджер сразу видит список для ввода задач с графической схемой проекта (Gantt Chart). Слева находятся переключатели видов списков.
В самом начале составления плана менеджер вводит список этапов, соответствующих технологии внедрения.
Замечание для опытных пользователей. Как можно заметить, внешний вид MS Project 2000 не претерпел значительных изменений по сравнению с MS Project 98. Из новинок можно отметить новый вид просмотра проекта Network Diagram, который заменил Pert Chart. Новый вид позволяет просматривать проекты в виде графической схемы, как ранее в PERT-диаграммах, при этом добавлена возможность работы с иерархическими задачами, как в диаграммах Gantt.
Совет. Включите Summary Task для того, чтобы видеть обобщенную статистику по проекту (общая длительность, трудоемкость, стоимость и т.д.).
Ориентируясь на письменное задание, менеджер назначил задачи для всех технологических этапов.
Меня
критикуют
Замечание. "Должны быть типовые фрагменты (подпроекты) – корпоративный стандарт выполнения стандартных этапов. Тестирование вряд ли сильно отличается для разных задач и нечего менеджеру каждый раз изобретать велосипед."
Могу только согласится. Шаблоны проектов (project patterns) необходимы. Вопрос насколько они удачно сделаны. Абстрактно или из успешной практики? Выше тоже применяется шаблон, состоящий в использовании стандартных технологических этапов. Данный шаблон позволит получить единую статистику по этапам всем проектов, но как увидим дальше страдает недостатком именно из-за отсутствия выделения подпроектов.
Проанализировав задание, менеджер составил свое представление об их трудоемкости и ввел эту информацию. При этом менеджер не исходил не столько из квалификации и количества исполнителей, сколько из своих интуитивных представлений о длительности этапов. Подобный подход встречается у тех менеджеров, которые не берут на себя заботу об управлении ресурсами их скорее волнует просто расписание этапов. Последствия такого подхода мы увидим ниже.
Замечание для опытных пользователей. В MS Project 2000 появилась возможность указывать, что некоторые сроки являются ожидаемыми, а не точными. Рядом с такими сроками выставляется знак вопроса.
Ориентируясь на приоритеты задач и особенности технологии, менеджер назначил последовательность задач. MS Project автоматически выделил красным цветом критический путь проекта, т.е. те задачи, которые определяют его длительность. Чтобы сократить критический путь, менеджер попробовал начать следующую технологическую стадию до завершения предыдущей.
Советы и комментарии.
1) Точный срок следует указывать только для задачи "Начало проекта", все остальные сроки должны быть относительными. Таким образом, вы всегда можете легко перенести проект на другую дату, все сроки пересчитаются автоматически.
2) Все технологические этапы следует завершать контрольными точками. Дело в том, что по технологии некий законченный результат может быть получен только в определенное время, и именно в данный момент следует провести контрольный осмотр проекта. Жестко и подневно контролировать исполнение отдельных задач часто не имеет смысла, т.к. исполнителям обычно приходится исполнять задачи не в том порядке, как указано в плане. Все это не значит, что подневная отчетность не нужна, она нужна в виде отчетов о затратах рабочего времени, о чем речь пойдет далее.
3) Не используете связи между задачами разного уровня. В этом случае один технологический этап привязывается к внутренней структуре другого этапа. Это сковывает свободу модификации планов в рамках отдельных этапов. Если используются связи только на одном уровне (задача-задача, этап-этап), вы можете без затруднений изменить состав и последовательность задач внутри некого этапа.
4) Сокращение критического пути проекта за счет преждевременного начала задач очень рискованно. Сокращайте критический путь за счет подготовительных работ (обучение, моделирование и т.д.). В нашем случае можно одновременно с постановочными работами запланировать прототипирование, и за счет этого сократить кодирование и общую продолжительность проекта. Сокращение критического пути проекта фактически всегда приводит к увеличению затрат на подготовительные работы. Иными словами, сокращение длительности проекта, как правило, приводит к повышению его себестоимости или рисков.
Меня
критикуют
Замечание 1. Начало проекта в MS Project нужно отмечать в его свойствах!
Можно и свойством и milestone, последнее мне кажется удобнее, т.к. его можно таскать мышкой.
Замечание 2. Подневной отчетность может и нужна для некоторых проектов.
Все верно, конкретный характер подневной отчетности определяется спецификой проекта. Для небольших софтверных проектов, подневной отчетности обычно достаточно как отчет о фактических затратах рабочего времени.
Замечание 3. Связь задач по PMBOK должна быть на нижнем уровне, а вы рекомендуете делать их на уровне этапов проектов.
PMBOK тут не однозначен, там есть две рекомендации в зависимости от условий. Связь действительно рекомендуется на нижнем уровне, в тоже время рекомендует разбивать большой проект на модули и делать связи между модулями.
После определения состава задач и их сроков менеджер назначает ресурсы для каждой задачи.
В результате после указания ресурсов менеджер автоматически получает график работ.
Совет. Если нужно производить учет административных расходов, т.е. затрат на управление проектом, можно использовать следующий прием. Нужно указать в MS Project 2000 менеджера в качестве ресурса на весь технологический этап. Соответственно продолжительности этапа будет производиться учет административных расходов по трудоемкости и себестоимости. Если менеджер ведет одновременно несколько проектов, можно указать процент нагрузки менеджера по данному проекту.
Меня
критикуют
Замечание. Неверно – ресурсы определяют сроки, а не наоборот!
Это так, но как я отмечал выше многие менеджеры небольших проектов управляют сроками, но не берут на себя ресурсный менеджмент. Отдавая дань этому, поставил этап определения сроков до этапа определения ресурсов. Кроме того, следует учесть, что мы разбираем пример ведения проекта, недостатки ресурсного менеджмента в данном проекте будут видны далее.
Часто после получения графика работ планирование заканчивается, однако в том случае, если необходимо еще утвердить бюджет проекта, требуется назначить расценки на ресурсы.
Советы.
1) Наличие перегрузки (overtime) - это, скорее всего, ошибка планирования, связанная с тем, что вы поставили одному исполнителю две задачи одновременно.
2) Для планирования наиболее удобна повременная система начисления затрат. Это позволяет избежать сложных торгов со специалистами, работающим по подряду, относительно стоимости работ. Достаточно один раз согласовать стоимость человеко-часа, далее вопрос заключается только в обсуждении трудоемкости.
3) Рекомендуем использовать подневные ставки для ресурсов. Это позволяет избежать ошибок в округлениях.
4) В MS Project 2000 возможно использование материальных ресурсов. MS Project может запоминать инвентарные номера, что очень удобно для учета. Повременную амортизацию ОС можно учитывать через параметр Std. Rate ("затраты по времени использования"). Списание на манер МБП можно учитывать через параметр Cost/Use ("единовременные затраты на использование"). В нашем примере для проекта требуется закупка сервера, по применяемой нами учетной политике затраты на сервер целиком списываются в проект.
Меня
критикуют
Замечание
1. Кроме людских ресурсов могут быть и
другие компоненты затрат.
Все так. MS Project 2000 умеет учитывать и материальные ресурсы. Кроме того, существуют так называемые общефирменные расходы (ОФР). Однако их большинство софтверных компаний включает в стоимость человеко-часа специалиста, т.е. стоимость месяца Петрова это не его ЗП в $500, а еще $1000 общефирменных расходов отнесенных на него. В вопросе ОФР менеджеру следует обратиться к финансовому директору компании, если его беспокоит прибыльность проектов, то он вычислит норму ОФР на каждого сотрудника. В MS Project вам надо ее только ввести и вы получите полные затраты. Если вам нужны более сложные механизмы разноски затрат интегрированные проектной системой, стоит поискать проектную систему более высокого уровня.
Замечание
2. У вас нет рекомендаций по использованию
выравнивания (resource
leveling).
Я не стал их давать, т.к. в небольшом проекте часто равномерное распределение нагрузки проще сделать вручную и использование leveling многих начинающих пользователей пугает своей "непредсказуемостью". Дадим краткие рекомендации по выравниванию. Оптимально использовать выравниваение, если у вас более 10-20 задач без четких сроков начала, или вы не можете указать последовательность задач, но можете указать их приоритеты. Задайте приоритеты и запустите Resource Leveling в MS Project 2000 включив опцию выравнивания "Priority; Standart". Программа автоматически поставит задачи последовательно для ресурсов исходя из их приоритетности.
Замечание
3. Если вы согласовали трудоемкость и
соответственно цену, то все – начисление
зарплаты уже не повременное, что-то у вас не
так.
Поясним некоторые тонкости ценообразованиия на контрактные работы. Сначало вы договариваетесь на стоимость человеко-месяца и заносите ее в MS Project 2000 как Standart Cost Rate. Затем вы торгуетесь с исполнителем только о сроке, цена получается автоматически. После этого срок фиксируется в Base Line и превышение сроков по вине исполнителя не оплачивается (если вы не оговорили иное). Альтернативным вариантом является каждый раз согласование и цены и сроков, при этом цена записывается в Fixed Cost. В данном варианте стоимость человеко-месяца будет плавать, что усложнит планирование расходов, но возможно полезно в случаях когда работы по своему характеру (стоимости за час) сильно отличаются.
Замечание
4. Не понятно насчет округлений. А дни не
округляются?
При вычислении стоимости часа и дня из стоимости месяца, день в 8 раз точнее часа по количеству действительных знаков после запятой. Приведем пример. Стоимость человеко-месяца $1500, значит стоимость дня с точностью до 2х знаков $68.18 (погрешность $0,04 за месяц), а для часа - $8.52 (погрешность $0.48 за месяц). Видно, что если начислять стоимость как $1500 за месяц, погрешности не будет совсем, но многие менеджеры для небольших работ в несколько дней находят это неудобным, т.к. на глаз не сверить дневную ставку с Cost задачи.
После назначения расценок на ресурсы менеджер автоматически получил план с бюджетом.
Из этого документа видны следующие основные параметры проекта:
-
Длительность
- Трудоемкость
- Себестоимость
- Сроки
- Исполнители и ответственные лица
Совет. Данные по трудоемкости (Work) и себестоимости можно использовать для ценообразования проекта. В нашем случае можно умножить трудоемкость на выходную цену человеко-месяца и получить внешнюю цену проекта. Например, если выходная цена человеко-месяца $2000, а трудоемкость 2 человеко-месяца, то внешняя цена проекта $4000. Конечно цена может быть скорректирована из маркетинговых и стратегических соображений.
Меня
критикуют
Замечание
1. Чем трудоемкость в вашем примере
отличается от длительности?
Так как это понимает MS Project 2000. Если упрощенно Work=Duration*N, где Work - трудоемкость, Duration - длительность, N - количество занятых ресурсов в задаче.