Руководство по управлению внедренческими проектами на базе MS Project 2000 и рекомендаций PMI

Содержание

О чем эта работа?

31% проектов завершаются провалом
53% проектов завершаются с перерасходом бюджета в среднем в 1,9 раза
только 16% проектов укладываются в срок и бюджет

Данные от консалтинговой компании Standish Group

Данная статья служит ответом на следующие вопросы:

Как добиться управляемости проектов?
Как оценить реальную стоимость проекта?
Как оценить реальный риск проекта?
Как эффективно использовать MS Project 2000 в проектах?

Менеджеров всегда волнуют проблемы контроля над деятельностью подразделения, улучшения прогнозирования, выполнения задачи в рамках бюджета и сроков, снижения рисков.

В качестве средства решения данных проблем были разработаны методики ведения деятельности с точки зрения проектов. Для проектных методик управления были разработаны различные средства автоматизации.

В данной работе мы рассмотрим методику ведения проектов в группе от 2 до 10 человек. Такая численность группы была выбрана потому, что таков типовой размер рабочей группы в средней российской компании. В качестве инструмента автоматизации ведения проектов используется MS Project 2000.

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

Проекты по внедрению ПО интересны также тем, что, как правило, очень рискованны. Вероятность выполнить проект, уложившись в бюджет и сроки по мировой статистике от Standish Group не превышает 31%. Поэтому мы сможем достаточно подробно рассмотреть вопросы управления рисками в малых проектах.

Меня критикуют

В таких разделах я буду приводить сделанные возражения экспертов и комментировать их сам.

Замечание 1. «Это еще не методика — просто некоторые советы по составлению расписания и обсуждение типичных проблем. Движение в нужном направлении, но начальные шаги. В целом — приятное впечатление.

Все верно, работа посвящена начальному обучению проектным методикам и обсуждению тонких мест полезных и экспертам. По своему опыту, я заметил, что наиболее легко усваивается материал в виде живых примеров, а не сверхподробных указаний. Кроме того, я намерено пропустил некоторые моменты проектного менеджмента, на которых обычно не возникает проблем, и наоборот очень подробно остановился на частностях, которые могут быть причинами серьезных трудностей. Если быть формально точным, это скорее полезные методические рекомендации, а не полноценная методика как PMBOK. Я намеренно по ходу примера «заставляю» менеджера делать ошибки, т.к. именно по последствиям ошибок легче запоминаются необходимые требования к проектному управлению. Кроме того, менеджеры совершают те или иные ошибки в управление почти всегда и их больше интересует как исправить ошибку, а не только как надо было сделать до начала работы.

Замечание 2. Что-то не видно определения проекта, что вы понимаете под проектом?

Вопрос-ловушка. Как гласит PMBOK «Проект — это мероприятие, которое имеет уникальный результат и ограничено временными рамками. Что не попадает под данное определение — операционная деятельность». Тонкость вот в чем, даже операционную деятельность можно рассматривать как проект, например, квартальный план работ производственного цеха серийной продукции. Временем ограничено? Да. Уникальность результата есть? Есть, т.к. результат уникален по временной характеристике его достижения. Польза от рассмотрения операционной деятельности в виде проекта есть? Есть, используя данный подход можно внедрить средства проектного планирования и добиться большей управляемости квартальных работ.

Введение. Краткая теория управления проектами

Как уже упоминалось, мы рассмотрим общую методику ведения малых проектов, поэтому, прежде всего, сделаем краткий обзор элементов теории управления проектами. Обзору теории ведения проектов посвящен данный раздел.

Литература

Приведем список литературы, на которой базируется наша методика. Далее мы будем ссылаться на данные документы и публикации.

ISO 9000 (стандарты, регламентирующие проектную деятельность и поддержание качества)
PMI Standards. A guide to the project management body of knowledge (набор полноценных методик по ведению проектов)
SEI. The Capability Maturity Model (стандарт регламентирующий требования к софтверным проектам)
В. Куперштейн. Современные информационные технологии в делопроизводстве и управлении (описание работы с MS Project с точки зрения пользователя)

Стандартный ход проекта

Стандартный подход к проектному управлению состоит из следующих этапов:

Постановка задачи (фиксация цели проекта).
Планирование (выработка плана и бюджета).
Контроль и анализ исполнения, коррекция планов.
Закрытие проекта по формальной процедуре и анализ статистики .

Во многих случаях под проектным управлением понимают только планирование, при этом, как правило, упускаются из вида документированная постановка цели и управление отслеживанием проекта (project tracking). Неудивительно, что по статистике такие проекты, как правило, значительно превышают запланированные бюджет и сроки, а также достигают не тех результатов, которые были запланированы.

Меня критикуют

Замечание 1. Не только в этом дело, не все ограничиваются планированием

Все верно, причин возможного кризиса больше, о них ниже.

Техника планирования

Этап планирования является одним из самых важных. На этом этапе определяются задачи, бюджет и сроки проекта. Довольно часто планирование понимают только как составление графика работ, упуская из вида управление ресурсами, составление бюджета и т. д.

Полноценная техника планирования включает в себя следующие этапы:

Определение целей проекта и их описание. Довольно часто проекты начинаются без четкой цели.
Определение технологических стадий. Для проекта должна быть выбрана технология реализации, определяющая стадии развития проекта. Одной из типичных ошибок планирования является несоответствие плана технологическому циклу.
Для технологических стадий необходимо определить список задач, указать их взаимосвязи (последовательность) и прогнозируемую длительность (зависит от назначенных ресурсов).
Необходимо согласовать вопрос о выделяемых проекту ресурсах. Следует отметить, что все ресурсы компании должны распределяться централизованно. Довольно часто возникает ошибка планирования, связанная с тем, что некоторые дефицитные ресурсы используются одновременно в двух разных проектах в одно и тоже время.
График работ в таких системах, как MS Project, получается автоматически, если определены задачи и ресурсы.
Если определить расценки на ресурсы, бюджет может быть получен также автоматически. Одна из типичных ошибок заключается в том, что бюджет назначают не обращая внимание на прогнозируемую себестоимость проекта.
Письменное задание, бюджет и график работ образуют формальный документ «План проекта». Довольно часто перед началом проекта некоторые из указанных документов отсутствуют, последствия этого мы рассмотрим ниже.

Меня критикуют

Замечание 1. График работ требует обязательного управления ресурсами. Выделение ресурсов должно соответствовать уже составленному графику работ — сначала исходя из ролей.

Это верно, но многие начинают использовать системы планирования просто для составления графика работ без указания ресурсов или вместо ресурсов указывая ответственных лиц за задачи (не одно и тоже). С точки зрения PMI это криминал, но с точки зрения планирования небольшого проекта иногда удобно. Поэтому я намеренно не акцентируюсь на управление ресурсами на первых шагах примера.

Замечание 2. План проекта включает и другие разделы — например, регламент управления, документооборот, анализ рисков и пр.План проекта требует большого количества обязательных формальных документов.

Все так. Но мы рассматриваем небольшие проекты, где выработка отдельных документов может быть сравнима с трудоемкостью самого проекта, поэтому я преднамеренно иду на упрощения.

Замечание 3. Разработка графика работ итеративный процесс — первоначальный график неоднократно корректируется с переназначениями ресурсов, если сроки не устраивают. Уже на этой стадии необходим анализ рисков

Как я уже отмечал, данная работа построена на рассмотрении примера, где менеджер делает ошибки по ходу планирования. Последствия отсутствия в плане антирисковых мероприятий мы увидим ниже.

Часть I. Составление плана и бюджета.

Типовые методы планирования. Бюджет и материальные ресурсы

Мы будем рассматривать наши рекомендации на сквозном примере проекта по адаптации и внедрению некого программного продукта. Часть I будет посвящена процедуре запуска проекта. Мы рассмотрим методы планирования, приемы составления бюджета с использованием человеческих и материальных ресурсов. По ходу дела мы будем совершать небольшие типовые ошибки, последствия и методы устранения которых мы рассмотрим в следующей части.

Постановка задачи

Проект должен начинаться с формулировки цели. При этом цель должна быть зафиксирована письменно в виде измеряемых показателей.

Документ «Постановка задачи» должен отвечать на следующие вопросы:

В какие сроки должна быть достигнута цель?
Какие условия достижения цели есть в наличии (бюджет, ресурсы, технология)?
Каким способом измерить достижение цели?
Как распределены ключевые обязанности в проекте (кто за что отвечает)?
Согласен ли спонсор с определением цели и условиями ее достижения?

В нашем примере цель проекта заключается в адаптации и внедрении некой системы документооборота. В нашем случае задание было письменным, не был определен только способ измерения того, что цель достигнута; последствия этого мы увидим далее.

Список этапов

Перейдем непосредственно к нашему примеру. Менеджер получил постановку задачи на адаптацию и внедрение некого продукта 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. Начало проекта в MS Project нужно отмечать в его свойствах!

Можно и свойством и milestone, последнее мне кажется удобнее, т.к. его можно таскать мышкой.

Замечание 2. Подневной отчетность может и нужна для некоторых проектов.

Все верно, конкретный характер подневной отчетности определяется спецификой проекта. Для небольших софтверных проектов, подневной отчетности обычно достаточно как отчет о фактических затратах рабочего времени.

Замечание 3. Связь задач по PMBOK должна быть на нижнем уровне, а вы рекомендуете делать их на уровне этапов проектов.

PMBOK тут не однозначен, там есть две рекомендации в зависимости от условий. Связь действительно рекомендуется на нижнем уровне, в тоже время рекомендует разбивать большой проект на модули и делать связи между модулями.

Ресурсы

После определения состава задач и их сроков менеджер назначает ресурсы для каждой задачи.

В результате после указания ресурсов менеджер автоматически получает график работ.

Совет. Если нужно производить учет административных расходов, т.е. затрат на управление проектом, можно использовать следующий прием. Нужно указать в MS Project 2000 менеджера в качестве ресурса на весь технологический этап. Соответственно продолжительности этапа будет производиться учет административных расходов по трудоемкости и себестоимости. Если менеджер ведет одновременно несколько проектов, можно указать процент нагрузки менеджера по данному проекту.

Меня критикуют

Замечание. Неверно — ресурсы определяют сроки, а не наоборот!

Это так, но как я отмечал выше многие менеджеры небольших проектов управляют сроками, но не берут на себя ресурсный менеджмент. Отдавая дань этому, поставил этап определения сроков до этапа определения ресурсов. Кроме того, следует учесть, что мы разбираем пример ведения проекта, недостатки ресурсного менеджмента в данном проекте будут видны далее.

Расценки на ресурсы

Часто после получения графика работ планирование заканчивается, однако в том случае, если необходимо еще утвердить бюджет проекта, требуется назначить расценки на ресурсы.

Советы

Наличие перегрузки (overtime) — это, скорее всего, ошибка планирования, связанная с тем, что вы поставили одному исполнителю две задачи одновременно.
Для планирования наиболее удобна повременная система начисления затрат. Это позволяет избежать сложных торгов со специалистами, работающим по подряду, относительно стоимости работ. Достаточно один раз согласовать стоимость человеко-часа, далее вопрос заключается только в обсуждении трудоемкости.
Рекомендуем использовать подневные ставки для ресурсов. Это позволяет избежать ошибок в округлениях.
В 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 — количество занятых ресурсов в задаче.

Часть II. Отслеживание проекта. Управление рисками. Модификация плана по ходу проекта

Довольно часто после формальных процедур планирования и получения бюджета проектные документы оказываются мусорной корзине. Причина этого заключается, в том, что с самых первых шагов проекта могут выясниться серьезные недочеты в планировании, может быть обнаружено, что план подвержен значительным рискам. Необходимо провести довольно сложную работу по модификации плана. По политическим соображениям менеджер часто не может это сделать, боясь потерять лицо. В результате проект начинает развиваться неуправляемо.

В части II мы рассмотрим вопросы реального отслеживания проектов.

Риски и косвенные работы

В нашем примере сложилась следующая ситуация: не успел проект начаться, как менеджер обнаружил, что его сотрудники не могут сразу приступить к работе, т.к. проект построен на новых технологиях и их необходимо изучить. Проанализировав ситуацию, менеджер планирует обучение и снова проходит процедуру утверждения бюджета и сроков.

Таких переутверждений бюджета и сроков можно делать бесконечно много, если не проанализировать причины подобных проблем. Они гораздо глубже конкретного недостатка квалификации персонала. Дело в том, что большинство прямых работ, следующих напрямую из задач проекта, порождает большое количество косвенных, которые связаны с их выполнением. Проблема заключается в том, что точно оценить состав и трудоемкость косвенных работ невозможно. Можно дать лишь статистические оценки. С другой стороны, косвенные работы часто обусловлены влиянием рисков на проект.

Для того чтобы косвенные работы не развалили проект, можно дать следующие рекомендации:

Планируйте обучение и качество. Это предотвращает типичные технологические риски.
Исследуйте риски и планируйте действия по их предупреждению. Об этом мы расскажем далее.

Управление рисками

Рассмотрим теорию управления рисками.

По теории нужно выполнять следующие действия:

Определение рисков (Risk Identification & Quantification). Необходимо провести анализ проекта с целью идентификации причин рисков. При анализе рисков нужно сверяться со статистикой предыдущих проектов (Historical information). Риски должны быть оценены количественно (Risk Quantification). Должна быть статистическая оценка длительности/стоимости проектов с учетом рисков. Сами риски должны быть разделены на те, которые требуют специальных действий по предупреждению, и на те что не оказывают ощутимого влияния на ход выполнения проекта.
Исследование рисков (Risk Response Development). Необходимо четко определить риск, его последствия и вероятность, выработать стратегию его предупреждения. На данном этапе должен быть выработан план борьбы с рисками. Следует разработать как обязательные мероприятия, так и мероприятия для тех случаев, когда некий риск начал негативно воздействовать (запасной план). Необходимо предусмотреть временной и ресурсный резерв с учетом воздействия рисков.
Исполнение плана с отслеживанием рисков (Risk Control). Необходимо выполнение антирисковых мероприятий и поиск новых рисков.

Из теоретический рекомендаций следует важный вывод: план может и должен подвергаться изменениями в результате поиска и устранения рисков.

Приведем примеры некоторых документов по работе с рисками, которые полезны в малых проектах.

Пример 1. Анализ риска

Определение риска	Условия: Заказчик требует использования Z-технологии, с которой мы не знакомы Следствие:Кодирование может занять больше времени
Вероятность	Работы по кодированию могут занять до 25% больше времени (фактор продуктивности = 1.25). Вероятное значение трудоемкости кодирования: 1.25×20=25 человеко-дней Вероятное значение длительности кодирования: 1.25×4= 5 месяцев
Стратегия	Послать программистов на обучение Z-технологии. Стоимость обучения $2,200. Ожидаемое значение фактора продуктивности должно снизится до 1.1 Сделать одного из программистов экспертом. Выделить ему 1 день в неделю на изучение Z-технологии и выработку внутренних стандартов по ее использованию. Это должно снизить фактор продуктивности до 1.0. Всего затрат на работу эксперта — 5 рабочих дней.

Пример 2. Список рисков (Risk list, Risk Log)

Номер риска	Приоритет	Дата обнаружения	Ответственный	Описание	Стратегия (порядок разрешения)	Текущее состояние
7	1	5.1.2001	Петров	Система требует новых драйверов	Произвести бетта-тестирование на новых драйверах	На старых драйверах система не работает. Риск высокий. Назначено совещание.
2	2	5.7.2001	Сидоров	Заказчик требует использования Z-технологии	Провести обучение Выработать внутренние стандарты	Обучение завершено. Есть некоторые проблемы со сборкой системы. Риск средний.

Как видим форма очень похожа на традиционный баг-лист (Bug List).

Только статистика позволяет оценить значимость рисков

Проект обычно подвержен очень большому количеству рисков, запланировать мероприятия по борьбе со всеми практически невозможно. Что же делать?

Следует обратиться к статистике. Нужно посчитать, какие виды рисков вызывают наибольшее количество проблем. На рисунке приведен график дефектов продукции в зависимости от видов дефектов.

Видно, что работает правило 80/20. Примерно 20% рисков создают 80% угрозы. Именно на них следует обращать основные усилия. В технологичных проектах обычно риски предотвращаются обучением, контролем и поддержанием качества (тестированием и др. методами).

Совет. Для того, чтобы эффективно бороться с рисками, нужно вести статистический учет возникающих проблем по видам рисков. В данном качестве может быть использована система учета дефектов продукции.

Меня критикуют

Замечание 1. Статистики может не быть. Кроме того, у рисков есть обыкновение во времени меняться.

Что тут сказать? Если нет статистики для принятия решения, то и само решение будет оставлять желать лучшего. Насчет изменения рисков, нужно делать их отслеживание как указано выше.

Замечание 2. Риски не только дефекты, а например неправильное определение последовательности исполнения задач, неточная оценка длительности и т.п.

Для софтверных проектов, есть особенность. Фактически любая команда выдающая продукты хорошего качества имеет систему регистрации дефектов и их отслеживания (Bug Tracking System). Можно не изобретать велосипед и все рисковые проблемы фиксировать там, для этого потребуется завести новые категории проблем («неверное планирование», «недооценка сроков», «ошибка постановки задачи» и т.д.). В таком случае вы сможете пользоваться развитой отчетностью по проблемам из системы отслеживания дефектов, кроме того, вы сможете использовать и механизмы отслеживания проблемы, т.е. на проблему будет гарантированная реакция ответственного лица.

Согласование и отчет

После утверждения нового плана обучение прошло успешно и в сроки закончилось необходимой сертификацией. Сотрудник успешно преступил к выполнению первой задачи. Однако в день ее завершения он сообщил, что «задача готова на 90% и требуется еще 1 день». На следующий день он ответил то же самое.

На рисунке показан вид просмотра проекта Tracking Gantt, на котором видно отличие первоначального плана от фактического исполнения.

Что можно сказать о сложившейся ситуации? Постоянное утверждение исполнителей, что задача готова на «90% и нужно еще чуть-чуть» — верный признак проваленной задачи.

В нашем случае менеджер понял это, вызвал сотрудника на откровенную беседу и стал выяснять глубинные причины срыва сроков. Они оказались следующими:

Сотрудник заявил, что не участвовал в принятии решения относительно сроков по данной задаче. Это решение единолично принял менеджер, хотя срок явно занижен.
Беседа показала, что сам сотрудник слабо ориентируется в реальных сроках задач. Это нормально, только менеджер концентрируется на сроках и перспективах. Сотрудника обычно волнуют локальные проблемы буквально в рамках нескольких рабочих часов.
Обсуждение показывает, что отчет о выполнении задачи в процентах ни о чем не говорит. Представления о процентах субъективно. Более важна информация о реальных затратах времени по проекту. Совершенные затраты рабочего времени — это уже статистика для принятия решений.

Меня критикуют

Замечание 1. Не согласен, что совершенные затраты времени статистика для принятия решений по незавершенным задачам — можно потратить 50% времени и выполнить 30% объема работ — например из-за неверной оценки производительности ресурса.

Не спорю, имеет большее значение имеет статистика затрат по уже завершенным задачам. Например, если ранее планировалось сделать задачу за 10 дней, а исполнитель сделал за 20 дней, возможно следующие сроки имеет смысл умножить на два.

Проблемы и решения

Каковы выходы из сложившейся ситуации?

Срок должен определяться в первую очередь исполнителем. Исполнитель, как правило — самый опытный эксперт в задачах данного рода. Не следует опасаться, что исполнитель сильно завысит сроки, скорее срок будет занижен. Дело в том, что исполнители очень редко учитывают в своих оценках необходимость косвенных работ.
В план могут быть приняты только сроки, согласованные между менеджером и сотрудником. Это позволяет разделить ответственность между ними и избежать ошибок при оценке сроков. В Microsoft Project встроена система рассылки сообщений TeamAssign через e-mail или Web. Данное сообщение является мини-контрактом относительно задачи между исполнителем и менеджером.
Для накопления достоверной статистики о реальных трудозатратах необходимо вести учет рабочего времени по проектам. Правильные контрольные вопросы о состоянии задачи (Team Status) следующие:
- на что уже было потрачено время (work complete)?
- сколько еще нужно времени (remain work)?

Microsoft Project позволяет через почту или браузер автоматизировать отчетность исполнителей о затратах рабочего времени и их прогнозах. Информация, предоставляемая ими, отображается в плане. Менеджер, сравнивая план и факт (об этом подробнее ниже), может судить об успешности хода проекта по срокам и затратам.

Меня критикуют

Замечание 1. Менеджер должен предусмотреть косвенные работы. Необходимо мотивировать исполнителей брать и исполнять напряженные планы, но анализировать риски.

Все верно, об этом ниже.

Методы вычисления реальных сроков задач

В нашем примере менеджер попал в трудную ситуацию. Самым неприятным является то, что оценки сотрудников недостоверны и узнать полный состав работ невозможно.

Выходом является использование статистических методов прогнозирования. Рассмотрим типовые приемы.

В Microsoft просто добавляют 30% к общей длительности плановых задач (Buffer time в 30%). Этот резерв расходуется на покрытие рисков.
Метод Load Factor (или на сколько умножить слова программиста), рекомендуемый группой XP. Статистический анализ проектов в малых группах разработки показал, что можно достаточно точно узнать реальный срок задачи, просто умножив слова исполнителям на некий коэффициент. Вот ориентировочные значения коэффициента:
- x2 — оптимистичная оценка
- x3 — нормальный проект
- x4-5 — применение нестандартных технологий
Схема PERT вычисления реального срока. Часто бывает, что разные оценки дают разные сроки; в этом случае можно применить метод расчет реального срока по следующей формуле:
Реальный_Срок=(Оптимистичный_Срок+4*Ожидаемый_Срок+Пессимистичный_Срок)/6
Коэффициенты в данной формуле (4 и 6) получены путем анализа статистики большого количества проектов. Следует отметить, что схема PERT эффективна только в том случае, если действительно имеются различные оценки. Если менеджер хочет через PERT просто убедить себя, что его решение единственно правильно, то подгонка статистики не даст ничего, кроме положительного ответа. О том, как использовать средства автоматизации PERT-вычислений в Microsoft Project речь пойдет ниже.

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