Проект — это комплекс взаимосвязанных мероприятий, которые имеют уникальный результат и ограничены временными рамками и ресурсами.

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

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

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

1 Постановка задачи (фиксация цели проекта).

2 Планирование (выработка плана и бюджета).

3 Контроль и анализ исполнения, коррекция планов.

4 Закрытие проекта по формальной процедуре и анализ статистики.

Схема стандартного хода проекта показана на рисунке 1.17

Рисунок 1.17

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

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

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

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

1 Определение цели проекта и ее описание. Довольно часто проекты начинаются без четкой цели.

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

3 Для технологических стадий необходимо определить список задач, указать их последовательность и прогнозируемую длительность (зависит от назначенных ресурсов).

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

5 График работ в таких системах, как MS Project, получается автоматически, если определены задачи и ресурсы.

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

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

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

Рисунок 1.18

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

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

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

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

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

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

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

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

1 В какие сроки должна быть достигнута цель?

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

3 Каким способом измерить достижение цели?

4 Как распределены обязанности в проекте (кто за что отвечает)?

5 Согласен ли инвестор (заказчик) с определением цели и условиями ее достижения?

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

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

Перейдем непосредственно к нашему примеру. Менеджер получил постановку задачи, изложенную в техническом задании. Менеджер запускает Microsoft Project и приступает к планированию. Окно программы с перечислением этапов проекта представлено на рисунке 1.19. Этапы просто переписаны из технического задания.

Рисунок 1.19

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

Список и длительность задач

Ориентируясь на письменное техническое задание, менеджер должен назначить задачи для всех технологических этапов. Их перечень приведен на рисунке 4.

При постановке задачи необходимо иметь шаблоны проектов (project patterns). Такие типовые фрагменты (подпроекты) должны представлять собой корпоративный стандарт выполнения стандартных этапов. Тестирование вряд ли сильно отличается для разных задач и менеджеру не нужно каждый раз изобретать новые шаблоны.

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

Проанализировав задание, менеджер составил свое представление об их трудоемкости и ввел информацию о длительности работы, представленную на рисунке 1.20.

Рисунок 1.20

В MS Project появилась возможность указывать, что некоторые сроки являются ожидаемыми, а не точными. Рядом с такими сроками выставляется знак вопроса.

Последовательность задач

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

Рисунок 1.21

Советы и комментарии:

1 Точный срок следует указывать только для задачи " Начало проекта", все остальные сроки должны быть относительными. Таким образом, вы всегда можете легко перенести окончание проекта на другую дату, все сроки будут пересчитаны автоматически. Начало проекта в MS Project нужно отмечать в его свойствах или milestone.

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

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

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

Ресурсы

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

Рисунок 1.22

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

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

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

Рисунок 1.23. Лист ресурсов

1 Рекомендуем использовать дневные ставки для ресурсов. Это позволяет избежать ошибок в округлениях.

2 В MS Project возможно использование материальных ресурсов. MS Project может запоминать инвентарные номера, что очень удобно для учета. Повременную амортизацию ОС можно учитывать через параметр Std. Rate (" затраты по времени использования"). Списание на манер МБП можно учитывать через параметр Cost/Use (" единовременные затраты на использование"). В нашем примере для проекта требуется закупка сервера, по применяемой нами учетной политике затраты на сервер целиком списываются в проект.

3 Наличие перегрузки (overtime) — это, скорее всего, ошибка планирования, связанная с тем, что вы поставили одному исполнителю две задачи одновременно.

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

Кроме людских ресурсов могут быть и другие компоненты затрат. MS Project умеет учитывать и материальные ресурсы. Кроме того, существуют так называемые общефирменные расходы (ОФР). Однако их большинство софтверных компаний включает в стоимость человеко-часа специалиста, т.е. стоимость месяца Петрова это не его ЗП в $500, а еще $1000 общефирменных расходов отнесенных на него. В вопросе ОФР менеджеру следует обратиться к финансовому директору компании, если его беспокоит прибыльность проектов, то он вычислит норму ОФР на каждого сотрудника. В MS Project надо ее только ввести и автоматически получатся полные затраты. Если нужны более сложные механизмы разноски затрат интегрированные проектной системой, стоит поискать проектную систему более высокого уровня.

Поясним некоторые тонкости ценообразования на контрактные работы. Сначала вы договариваетесь на стоимость человеко-месяца и заносите ее в MS Project как Standart Cost Rate. Затем вы торгуетесь с исполнителем только о сроке, цена получается автоматически. После этого срок фиксируется в Base Line и превышение сроков по вине исполнителя не оплачивается (если вы не оговорили иное). Альтернативным вариантом является каждый раз согласование и цены и сроков, при этом цена записывается в Fixed Cost. В данном варианте стоимость человеко-месяца будет плавать, что усложнит планирование расходов, но возможно полезно в случаях, когда работы по своему характеру (стоимости за час) сильно отличаются.

Поясним значение округлений. При вычислении стоимости часа и дня из стоимости месяца, день в 8 раз точнее часа по количеству действительных знаков после запятой. Приведем пример. Стоимость человеко-месяца $1500, значит стоимость дня с точностью до 2-х знаков $68.18 (погрешность $0, 04 за месяц), а для часа - $8.52 (погрешность $0.48 за месяц). Видно, что если начислять стоимость как $1500 за месяц, погрешности не будет совсем, но многие менеджеры для небольших работ в несколько дней находят это неудобным, т.к. на глаз не сверить дневную ставку с Cost-задачей.

План с бюджетом

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

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

- длительность;

- трудоемкость;

- себестоимость;

- сроки;

- исполнители и ответственные лица.

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

Чем трудоемкость в этом примере отличается от длительности? MS Project понимает это так. Если упрощенно, то Work = Duration*N, где Work — трудоемкость, Duration — длительность, N — количество занятых ресурсов в задаче.

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

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

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

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

Рисунок 1.24

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

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

- планируйте обучение и качество. Это предотвращает типичные технологические риски;

- исследуйте риски и планируйте действия по их предупреждению. Об этом мы расскажем далее.

1.3. Управление рисками по PMI

Рассмотрим кратко основы теории управления рисками (рисунок 1.25).

Рисунок 1.25

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

1 Определение рисков. Необходимо провести анализ проекта с целью идентификации причин рисков.

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

3 Исполнение плана с отслеживанием рисков. Необходимо планирование антирисковых мероприятий и поиск новых рисков.

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

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

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

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

Рисунок 1.26

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

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

Риски — это не только дефекты, но и неправильное определение последовательности исполнения задач, неточная оценка длительности и т.п. Для преодоления этих рисков требуются более серьезные инструменты и подходы. Для анализа рисков по ошибкам в оценке длительности потребуется инструмент на базе Монте-Карло, например, Turbo Risk Manager или PERT. Мы рассмотрим применение таких инструментов далее.

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

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

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

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

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

2 Беседа показала, что сам сотрудник слабо ориентируется в реальных сроках задач. Это нормально, только менеджер концентрируется на сроках и перспективах. Сотрудника обычно волнуют локальные проблемы буквально в рамках нескольких рабочих часов.

3 Обсуждение показывает, что отчет о выполнении задачи в процентах ни о чем не говорит. Представления о процентах субъективно. Более важна информация о реальных затратах времени по проекту. Совершенные затраты рабочего времени - это уже статистика для принятия решений по незавершенным задачам. Можно потратить 50% времени и выполнить 30% объема работ — например из-за неверной оценки производительности ресурса. И если ранее планировалось сделать задачу за 10 дней, а исполнитель сделал за 20 дней, возможно, следующие сроки имеет смысл умножить на два.

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

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

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

2 В план могут быть приняты только сроки, согласованные между менеджером и сотрудником. Это позволяет разделить ответственность между ними и избежать ошибок при оценке сроков. В Microsoft Project встроена система рассылки сообщений TeamAssign через e-mail или Web. Данное сообщение является мини-контрактом относительно задачи между исполнителем и менеджером.

3 Для накопления достоверной статистики о реальных трудозатратах необходимо вести учет рабочего времени по проектам. Правильные контрольные вопросы о состоянии задачи (Team Status) следующие:

- на что уже было потрачено время (work complete)?

- сколько еще нужно времени (remain work)?

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

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

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

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

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

1 В Microsoft просто добавляют 30% к общей длительности плановых задач (Buffer time в 30%). Этот резерв расходуется на покрытие рисков.

2 Метод Load Factor (или на сколько умножить слова программиста), рекомендуемый группой XP. Статистический анализ проектов в малых группах разработки показал, что можно достаточно точно узнать реальный срок задачи, просто умножив слова исполнителя на некий коэффициент. Вот ориентировочные значения коэффициента:

- X = 2 — оптимистичная оценка;

- X = 3 — нормальный проект;

- X = 4-5 — применение нестандартных технологий.

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

Реальный_Срок =

(Оптимистичный_Срок +4* Ожидаемый_Срок + Пессимистичный_Срок)/6. Коэффициенты в данной формуле (4 и 6) получены путем анализа статистики большого количества проектов. Следует отметить, что схема PERT эффективна только в том случае, если действительно имеются различные оценки. Если менеджер хочет через PERT просто убедить себя, что его решение единственно правильно, то подгонка статистики не даст ничего, кроме положительного ответа. О том, как использовать средства автоматизации PERT-вычислений в Microsoft Project речь пойдет ниже.

4 Методика Монте Карло. Система моделирования рисков на базе Монте Карло более точны чем PERT (точность выше примерно на 10%), плюс такие средства позволяют задавать уровень риска в проекте. Примером такого средства для Microsoft Project является Turbo Risk Manager.

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

Калибровка сроков

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

Используя Load Factor, менеджер оценил пессимистичные сроки. В качестве ожидаемых сроков менеджер взял те, что получились путем согласования через Team Assign с исполнителями. За оптимистические взял свои первоначальные. Методом PERT пересчитал ожидаемые сроки. По сравнению с планом была недооценка трудоемкости в 226 человеко-часов.

Советы.

1 Колонки Variance могут показать вам отличие состояния проекта от первоначального плана. Вы может добавить эти колонки в любой вид просмотра.

2 Используйте копирование через Clipboard колонок PERT-диаграммы, таким образом вы сэкономите время.

Формальное закрытие проекта

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

Измеряемая цель

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

Подобная ситуация является типичным признаком потери контроля. Это понял и заказчик, назначив крайний срок сдачи (Dead Line). В MS Project существует средство для отметки Dead Line и оповещении о подходе к нему.

Рассмотрим причины потери контроля и способы его восстановления.

Иллюзия простоты (80%/20%)

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

Рисунок 1.27

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

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

1.4. План и требования должны изменяться совместно

Если проанализировать ситуацию, видно, что фактически происходит изменение задания (задач) проекта в результате процедуры приемки. На рисунке 1.28 приведен цикл изменения плана при корректировке задач по методике PMI.

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

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

Рисунок 1.28

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

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

Планирование итеративно, следующие стадии предсказуемы лишь статистически

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

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

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

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

Заказчик, получив большие статистические оценки, требует составить план работ из конкретных задач и начинает убирать оттуда " завышенные" и " ненужные" работы.

Если это произошло, проект обречен на потерю контроля.

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

Нужны измеряемые критерии завершения проекта (контрольные тесты)

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

Альтернативой формальному завершению проекта является бесконечное движение в сторону ожиданий. Рассмотрим, что может получиться в данном случае:

1 Ожидания по своей природе противоречивы, как и человеческие отношения. Многие желания логически несовместимы. Например, топ-менеджер хочет иметь больше аналитической статистики, а оператор хочет заполнять меньше аналитических полей. Удовлетворить оба эти ожидания логически невозможно, поэтому система, развивающаяся в данном направлении, может оказаться нерабочей из-за дефектов логики.

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

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

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

Формальное закрытие проекта

Сравним формальное закрытие проекта с проектом " без конца".

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

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

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

Тем не менее, многие предпочитают неформальное ведение проектов. Этот объясняется влиянием политических рисков. Формальный проект позволяет установить ответственность, и эта ответственность часто пугает как исполнителя проекта, так и заказчика. За неудачу формального проекта несут ответственность в равной степени и Исполнитель, и Заказчик. Оба подписались под требованиями к проекту и взяли на себя ответственность, причем эта ответственность носит личный характер.

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

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

Закрытие и оценка проекта

Менеджер поставил в план разработку документа, описывающего контрольные тесты (рисунок 1.29). Далее в соответствии с тестами продукт был приведен в порядок и в срок сдан заказчику.

Как видно по рисунку, проект примерно в 2 раза превысил ожидаемую себестоимость.

Тем не менее, следует отметить, что в условиях нашего примера проект был для менеджера новым и подвергался влиянию политических рисков. Достигнутый результат в данных условиях можно считать хорошим (нормальным). Данный вывод подтверждается и статистикой Standish Group: 53% проектов завершаются успешно, но с превышение бюджета в 1, 9 раза.

Рисунок 1.29. Тестирование результатов проекта

2. Анализ статистики

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

Именно поэтому важно разделить план на технологические стадии, состав которых не зависит от вида проекта.

Приведем типичные статистические показатели Канера-Фолка и прокомментируем их относительно нашего примера.

Продукт получается в среднем через 8 внутренних и 3 внешних версии. Из этого следует, что стоит планировать 8 версий, и, скорее всего, потребуется несколько проектов.

Для разработки ПО характерны следующие статистические показатели соотношения технологических стадий:

- разработка — 37%;

- сопровождение — 63%.

Этап разработки разделяется на стадии со следующими пропорциями:

- постановка — 34%;

- кодирование — 21%;

- тестирование — 45%.

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

Вопросы

1. Что такое проект?

2. Что такое ресурсы проекта?

3. На какие стадии можно разбить жизненный цикл проекта?

4. В какой документ включается смета расходов?

5. Куда входит конструкторская документация?

6. Какой документ завершает проект?

Тесты

1. Можно ли производственную деятельность назвать проектом?

+ Ответ 1. да, если говорить об определенном периоде

Ответ 2. нет, нельзя

Ответ 3. проект — это любая деятельность

2. Какие величины являются ресурсами проекта?

Ответ 1. материальные возможности

+ Ответ 2. деньги, время, люди, материалы

Ответ 3. финансы

3. Как поступить, если нужно переделать техническое задание?

Ответ 1. техническое задание не переделывается

Ответ 2. терепечатать его

+ Ответ 3. написать и подписать протокол согласования

4. Нужно ли в проекте проводить анализ существующей информации?

Ответ 1. нет, не нужно, так как всё делаем по техническому заданию

+ Ответ 2. поиск и анализ информации входит в эскизный проект

Ответ 3. анализ информации делается до проекта

5. Куда входит смета?

+ Ответ 1. смета расходов на проект — в ТЗ, смета расходов на объект — в ТП

Ответ 2. это отдельный документ

Ответ 3. рассчитывается в эскизном проекте

6. Нужно ли делать чертежи для технического предложения и ЭП?

Ответ 1. нет, не нужно

+ Ответ 2. обычно делаются эскизы

Ответ 3. да, нужен полный набор чертежей

7. Что такое зонирование территории?

Ответ 1. разбивка на квадраты

Ответ 2. это огораживание зон заборами

+ Ответ 3. разделение на зоны в зависимости от её предназначения

8. Какой критерий полноты информации об изделии на чертежах?

+ Ответ 1. изготовление и контроль изделия без вызова автора чертежа

Ответ 2. соответствие ГОСТ и нормалям