Довольно часто после формальных процедур планирования и получения бюджета проектные документы оказываются мусорной корзине. Причина этого заключается, в том, что с самых первых шагов проекта могут выясниться серьезные недочеты в планировании, может быть обнаружено, что план подвержен значительным рискам. Необходимо провести довольно сложную работу по модификации плана. По политическим соображениям менеджер часто не может это сделать, боясь потерять лицо. В результате проект начинает развиваться неуправляемо.
В части II мы рассмотрим вопросы реального отслеживания проектов.
В нашем примере сложилась следующая ситуация: не успел проект начаться, как менеджер обнаружил, что его сотрудники не могут сразу приступить к работе, т.к. проект построен на новых технологиях и их необходимо изучить. Проанализировав ситуацию, менеджер планирует обучение и снова проходит процедуру утверждения бюджета и сроков.
Таких переутверждений бюджета и сроков можно делать бесконечно много, если не проанализировать причины подобных проблем. Они гораздо глубже конкретного недостатка квалификации персонала. Дело в том, что большинство прямых работ, следующих напрямую из задач проекта, порождает большое количество косвенных, которые связаны с их выполнением. Проблема заключается в том, что точно оценить состав и трудоемкость косвенных работ невозможно. Можно дать лишь статистические оценки. С другой стороны, косвенные работы часто обусловлены влиянием рисков на проект.
Для того чтобы косвенные работы не развалили проект, можно дать следующие рекомендации:
1) Планируйте обучение и качество. Это предотвращает типичные технологические риски.
2) Исследуйте риски и планируйте действия по их предупреждению. Об этом мы расскажем далее.
Рассмотрим теорию управления рисками.
По теории нужно выполнять следующие действия:
1) Определение рисков (Risk Identification & Quantification). Необходимо провести анализ проекта с целью идентификации причин рисков. При анализе рисков нужно сверяться со статистикой предыдущих проектов (Historical information). Риски должны быть оценены количественно (Risk Quantification). Должна быть статистическая оценка длительности/стоимости проектов с учетом рисков. Сами риски должны быть разделены на те, которые требуют специальных действий по предупреждению, и на те что не оказывают ощутимого влияния на ход выполнения проекта.
2) Исследование рисков (Risk Response Development). Необходимо четко определить риск, его последствия и вероятность, выработать стратегию его предупреждения. На данном этапе должен быть выработан план борьбы с рисками. Следует разработать как обязательные мероприятия, так и мероприятия для тех случаев, когда некий риск начал негативно воздействовать (запасной план). Необходимо предусмотреть временной и ресурсный резерв с учетом воздействия рисков.
3) Исполнение плана с отслеживанием рисков (Risk Control). Необходимо выполнение антирисковых мероприятий и поиск новых рисков.
Из теоретический рекомендаций следует важный вывод: план может и должен подвергаться изменениями в результате поиска и устранения рисков.Приведем примеры некоторых документов по работе с рисками, которые полезны в малых проектах.
Пример 1. Анализ риска
Определение риска | Условия: Заказчик требует
использования Z-технологии, с которой мы
не знакомы Следствие: Кодирование может занять больше времени |
Вероятность | Работы по кодированию могут
занять до 25% больше времени (фактор
продуктивности = 1.25).
Вероятное значение трудоемкости
кодирования: 1.25x20=25 человеко-дней |
Стратегия | Послать программистов на
обучение 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) Сотрудник заявил, что не участвовал в принятии решения относительно сроков по данной задаче. Это решение единолично принял менеджер, хотя срок явно занижен.
2) Беседа показала, что сам сотрудник слабо ориентируется в реальных сроках задач. Это нормально, только менеджер концентрируется на сроках и перспективах. Сотрудника обычно волнуют локальные проблемы буквально в рамках нескольких рабочих часов.
3) Обсуждение показывает, что отчет о выполнении задачи в процентах ни о чем не говорит. Представления о процентах субъективно. Более важна информация о реальных затратах времени по проекту. Совершенные затраты рабочего времени - это уже статистика для принятия решений.
Меня
критикуют
Замечание
1. Не согласен, что совершенные затраты
времени статистика для принятия решений по
незавершенным задачам – можно потратить 50%
времени и выполнить 30% объема работ –
например из-за неверной оценки
производительности ресурса.
Не спорю, имеет большее значение имеет статистика затрат по уже завершенным задачам. Например, если ранее планировалось сделать задачу за 10 дней, а исполнитель сделал за 20 дней, возможно следующие сроки имеет смысл умножить на два.
Каковы выходы из сложившейся ситуации?
1) Срок должен определяться в первую очередь исполнителем. Исполнитель, как правило - самый опытный эксперт в задачах данного рода. Не следует опасаться, что исполнитель сильно завысит сроки, скорее срок будет занижен. Дело в том, что исполнители очень редко учитывают в своих оценках необходимость косвенных работ.
2) В план могут быть приняты только сроки, согласованные между менеджером и сотрудником. Это позволяет разделить ответственность между ними и избежать ошибок при оценке сроков. В Microsoft Project встроена система рассылки сообщений TeamAssign через e-mail или Web. Данное сообщение является мини-контрактом относительно задачи между исполнителем и менеджером.
3)
Для накопления достоверной статистики
о реальных трудозатратах необходимо вести
учет рабочего времени по проектам. Правильные контрольные вопросы о
состоянии задачи (Team Status) следующие:
- на что уже было потрачено время (work
complete)?
- сколько еще нужно
времени (remain work)?
Microsoft Project позволяет через почту или браузер
автоматизировать отчетность исполнителей
о затратах рабочего времени и их прогнозах.
Информация, предоставляемая ими,
отображается в плане. Менеджер, сравнивая
план и факт (об этом подробнее ниже), может
судить об успешности хода проекта по срокам
и затратам.
Меня
критикуют
Замечание
1. Менеджер должен предусмотреть косвенные работы.
Необходимо мотивировать исполнителей
брать и исполнять напряженные планы, но
анализировать риски.
Все верно, об этом ниже.
В нашем примере менеджер попал в трудную ситуацию. Самым неприятным является то, что оценки сотрудников недостоверны и узнать полный состав работ невозможно.
Выходом является использование статистических методов прогнозирования. Рассмотрим типовые приемы.
1) В Microsoft просто добавляют 30% к общей длительности плановых задач (Buffer time в 30%). Этот резерв расходуется на покрытие рисков.
2)
Метод Load Factor (или на сколько умножить
слова программиста), рекомендуемый группой XP.
Статистический анализ проектов в малых
группах разработки показал, что можно
достаточно точно узнать реальный срок
задачи, просто умножив слова исполнителям
на некий коэффициент. Вот ориентировочные
значения коэффициента:
x2
- оптимистичная оценка
x3
- нормальный проект
x4-5
- применение нестандартных технологий
3)
Схема
PERT вычисления реального срока. Часто бывает, что разные оценки дают
разные сроки; в этом случае можно применить
метод расчет реального срока по следующей
формуле:
Реальный_Срок=(Оптимистичный_Срок+4*Ожидаемый_Срок+Пессимистичный_Срок)/6
Коэффициенты в данной формуле (4 и 6)
получены путем анализа статистики большого
количества проектов. Следует отметить, что
схема PERT эффективна только в том случае,
если действительно имеются различные
оценки. Если менеджер хочет через PERT просто
убедить себя, что его решение единственно
правильно, то подгонка статистики не даст
ничего, кроме положительного ответа. О том,
как использовать средства автоматизации
PERT-вычислений в Microsoft Project речь пойдет ниже.
Важное замечание. Приведенные статические коэффициенты являются лишь ориентировочными. Необходимо накапливать свою собственную статистику по ведению проектов для того, чтобы получить специфические для данной технологии и данных исполнителей калибровочные коэффициенты.
Как это часто и бывает на практике, обсчет реалистичных сроков для проекта менеджер стал выполнять после его начала. Если проект для менеджера новый, то подобная ошибка почти неизбежна. Используя Load Factor, менеджер оценил пессимистичные сроки. В качестве ожидаемых сроков менеджер взял те, что получились путем согласования через Team Assign с исполнителями. За оптимистические взял свои первоначальные.
Методом PERT пересчитал ожидаемые сроки. На рисунке в колонке Work Variance видно, что по сравнению с планом была недооценка трудоемкости в 226 человеко-часов.
Советы.
1) Колонки Variance могут показать вам отличие состояния проекта от первоначального плана. Вы может добавить эти колонки в любой вид просмотра.
2) Используйте копирование через Clipboard колонок PERT-диаграммы, таким образом вы сэкономите время. Скопируйте Duration (значения до запуска PERT) в колонки Optimistic, Expected, Pessimistic. Отредактируйте значения по необходимости.
Мы рассмотрели только часть действий по анализу исполнения и корректирующих воздействий. Обсужденные данных вопросов мы продолжим в следующей части.