1. Вивчення інтерфейсу Microsoft Project.

Изучаем среду Microsoft Project 2000

Microsoft Project 2000 прошел длинный путь развития в течении нескольких лет. В
настоящее время интерфейс Microsoft Project 2000 делает управление проектом почти столь же
легким как ведение вашего личного календаря. Если Вы пользовались другими продуктами
Microsoft, Word или Excel, меню и инструменты в Microsoft Project 2000, напомнят вам старых
друзей. И хотя много представлений Microsoft Project 2000 могут быть немного подавляющими
сначала, они позволяют Вам выбрать перспективу, с которой Вы можете контролировать
выполнение вашего проекта в любое данное время.
В этой главе описано окружение Microsoft Project 2000 и инструменты, которые есть в
вашем распоряжении. Вы попробуете перемещение среди различных представлений и работу с
некоторыми из инструментов, необходимых для создания проекта.

Первый взгляд на Microsoft Project 2000

Несмотря на то, что Microsoft Project 2000 не поставляется с Microsoft Office 2000, это - член
семейства Microsoft Office. Следовательно, Microsoft Project 2000 использует стандарты Microsoft,
меню и панель инструментов Microsoft Office.
Совет
Если Вы использовали Microsoft Outlook, Вам будут знакомы некоторые особенности
Microsoft Project 2000, включая меню представлений в левой части экрана, которое позволяет Вам
переключаться между представлениями и функциями в Microsoft Project 2000. В Microsoft Project
2000 это меню называется меню представлений(view bar).

Запуск Microsoft Project 2000

Когда Вы в первый раз запустите Microsoft Project 2000, вы увидите окно Microsoft Project
2000 и в правой части экрана новую систему Помощи (см. Рисунок 2-1). Эта помощь предлагает
ряд полезных пунктов для пользователей плохо знакомых с Microsoft Project или с этой версией
Microsoft Project.

1
Рисунок 2-1: Начальный экран, после запуска Microsoft Project 2000.
Совет
Если Project 2000 не появляется в вашем меню Старт, Вы можете использовать команду
Выполнить. Для этого Вы должны найти исполняемый файлом Winproj.exe, который обычно
располагается в C:/PROGRAM FILES/MICROSOFT OFFICE/OFFICE на Вашем жестком диске. Вы
также можете запустить Microsoft Project 2000 сделав двойной щелчок на любом файле Project.
Файлы Project имеют расширение .mpp.
На данном этапе Вы имеете возможность выполнить следующие действия:
 Что Нового (What's New). Выберите этот пункт, чтобы видеть информацию о новых
возможностях в Microsoft Project 2000.
 Предварительное знакомство (Quick preview). Выберите этот пункт, чтобы видеть краткое,
визуальное описание процесса управления проектом.
 Учебник (Tutorial). Выберите этот пункт, чтобы видеть демонстрацию основных
возможностей Microsoft Project 2000.
 Карта Project (Project Map). Выберите этот пункт, чтобы увидеть последовательность
действий необходимых для управления проектом.
 Помощник (Office Assistant). Выберите этот пункт, чтобы увидеть помощника, готового
ответить на любой Ваш вопрос, но только по-английски.
 Ссылки (Reference). Выберите этот пункт для получения широкого разнообразия
материалов, например, поиск неисправностей, советы, клавиатурные сокращения,
информация о назначении ресурсов, задач и времени, а также об основах применения VBA
в Microsoft Project 2000.
Ссылка
В Главе 3 более детально изложены способы эффективного использования помощи.
 Кнопка Закрыть. Если Вы готовы приступить к созданию проекта Вы можете закрыть
Помощь, нажав на кнопку Закрыть в правом верхнем углу. После того как Вы закроете окно
Помощи Вы видите новый чистый проект, как показано на рисунке 2-2.

2
Совет
Вы можете повторно просмотреть это окно в любое время, выбрав Help  Contents and
Index. Кроме того, Вы можете просмотреть Предварительное знакомство, Учебник и Карту Project
выбрав Help  Getting Started.
Новая возможность
В Microsoft Project 2000, Вы можете выполнить ручное заполнение в большинстве
представлений. Вы можете использовать ручное заполнение для ввода информации в ячейки, так
же как и при иcпользовании Excel.
Microsoft Project 2000 всегда открывает новый проект в представлении диаграммы Ганта.
Вы познакомитесь с другими представлениями в этой книге, но Вы, вероятно, большое количество
вашего времени при работе над проектом будете использовать представление диаграммы Ганта.
Это представление предлагает все богатство информации о вашем проекте в едином
представлении.
Ссылка
Для детального изучения представлений доступных в Microsoft Project 2000, см. Главу 6.
В Microsoft Project 2000, Вы найдете большое количество советов. Советы и подсказки Вы
можете увидеть практически в любой точке вашего экрана (см. Рисунок 2-3).

Диаграмма Ганта
Диаграммы Ганта имеет две главных секции: таблица Ганта и диаграмма Ганта. После того,
как Вы введете информацию о задаче в табличную часть диаграммы Ганта(в левом части), в
правой части диаграммы будет отражено графическое представление о введенной задаче
(название, начало, продолжительность и другое). Графическое представление диаграмма Ганта (в
правой части) помогает Вам увидеть распределение времени и отношения среди задач, как
показано на Рисунке 2-4.

Рисунок 2-2: Чистый проект не содержит никакой информации о проекте.

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

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

Рисунок 2-3: Вы можете в любой момент воспользоваться помощью или подсказкой.

4
Рисунок 2-4: Типовой проект в представлении Ганта. Табличная часть с деталями задач и
диаграмма Ганта.
Одна из сильных сторон Microsoft Project 2000, это то, что Вы можете легко переключится
из представления Ганта в другие представления. После небольших экспериментов по
переключению представлений, Вы сможете видеть информацию о выборе времени, бюджете, или
назначениях ресурсов более подробно, или выбрать общую картину Вашего проекта. Вы можете
также настраивать любые из представлений в зависимости от того, какую информацию Вы хотите
получить. Например, Вы можете использовать разделитель, который находится между таблицей
Ганта и диаграммой Ганта, чтобы отрегулировать размер окон. Перемещение этого разделителя
вправо показывает большее количество колонок данных о вашем проекте в таблице Ганта.
Перемещение разделителя влево увеличивает представляемую диаграмму Ганта.
В дополнение, так же легко как Вы можете изменить пропорции отображения графической
и табличной частей представления, Вы можете изменить масштаб отображаемых данных. Вы
можете увеличить масштаб отображения времени в диаграмме Ганта с помощью кнопки Увеличить
(Zoom In) или уменьшить масштаб отображения времени с помощью кнопки Уменьшить (Zoom
Out). Даже большие многолетние проекты Вы можете настроить для отображения ежедневных
задач, и так же легко перейти к ежемесячному или ежеквартальному отображению данных.
Обратите внимание, что каждый из окон представления Ганта имеет собственную полосу
прокрутки, поэтому Вы должны использовать соответствующую полосу прокрутки для выбора в
соответствующем окне.

Использование меню Microsoft Project 2000

Меню Microsoft Project 2000 в настоящее время работает подобно меню всех продуктов
Microsoft Office, команды доступны "по требованию". То есть когда Вы открываете меню в первый
раз, Вы видите небольшой набор команд, который по предположению команды разработчиков
Microsoft Вы будете использовать наиболее часто. Кроме того, в нижней части меню, Вы видите
кнопку с парой стрелок (см. Рисунок 2-5). Если Вы щелкнете на этой кнопке (или задержитесь на
ней в течении нескольких секунд), будут показаны все команды свойственные данному меню (см.
Рисунок 2-6). Как только Вы выберете эту команду, эта команда будет появляется в меню при
следующем открытии.

5
Новая возможность
Настраивающиеся меню является новой особенностью Microsoft Project 2000.
Вы можете изменить это поведение подобно меню предыдущих версий Project, в которых
все команды появились в меню одновременно после открытия. Чтобы изменить поведение меню
воспользуйтесь диалогом Customize в меню Tools.
Ссылка
Диалог Customize описан подробно в Главе 18.
Некоторые команды и меню Microsoft Project 2000 в верхней части экрана Вам знакомы,
например, Save (Сохранить), Print (Печать) и некоторые другие. Другие команды и меню на панели
инструментов являются специфическими инструментами, характерными только для Project.

Рисунок 2-5: Первоначально, вы видите только часть команд в раскрывающемся меню.

6
Рисунок 2-6: После паузы или щелчка на кнопке с двойными стрелками, меню раскрывается
полностью.
В таблице 2-1 переведены и описаны функции каждого меню.

Таблица 2-1

Меню Microsoft Project 2000

Menu Доступные функции

Меню
File Открыть и закрыть новый или существующий файлы, сохранение или печать
Файл файла, настройка параметров страницы и свойств документа, отправка файла
по электронной почте и маршруту.
Edit Вырезать, копировать и вставить текст или объект; управление данными с
Правка помощью команд: заполнить, очистить, удалить; связь и удаление связи между
задачами; применение команд найти, заменить, перейти.
View Выберите различные представления вашего проекта, просмотр стандартных
Вид отчетов, выбор инструментальных панелей, использование функции
масштабирования изображения, работа с колонтитулами.
Insert Вставка новых задач и проектов, колонок в представлениях, вставка
Вставка различных объектов в ваш проект, включая рисунки, диаграммы Excel,
документы Word, клипы, гиперссылок.
Format Форматирование текста, графического изображения задач и временной
Формат шкалы, расположения представлений.
Tools Запуск функций правописание и автозамена, доступ к возможностям работы в
Сервис рабочей группе, установление связей между проектами, изменение рабочего
календаря или ресурсов. Вы можете также настраивать стандартные
представления и функции с помощью команд организатор, настройка,
параметры, или выполнить запись макросов. Выполнить контроль выполнения
проекта.

7
Project Просмотр информации о задаче или проекте, просмотр примечаний,
Проект использование команд фильтр и сортировка. Изменение структуры задач в
проекте.
Последние два меню, Окно и Справка, содержат команды для расположения окон и
доступа к справке, соответственно.
Ссылка
См. Главу 3 для получения большей информации об эффективном использовании Справки
в Microsoft Project 2000.
Как Вы видите на Рисунке 2-7, в меню одновременно располагаются иконка, название
команды и сочетание клавиш, для быстрого вызова данной команды с помощью клавиатуры. Этот
способ помогает Вам изучить различные способы выбора команд в Microsoft Project 2000.
Обратите внимание на наличие дополнительного меню, которое иногда называется –
дополнительное меню или каскадное меню. Черный треугольник направленный вправо от команды
указывает на присутствие дополнительного меню.

Рисунок 2-7: В меню одновременно присутствует символ инструмента, его описание и

сочетание клавиш для быстрого вызова. Наличие каскадного меню еще больше
увеличивает Ваш выбор.

Панели инструментов
Вероятно, Вы уже знакомы с инструментами в программах Windows и порядок их
расположения на панели инструментов. Когда Вы открываете Microsoft Project 2000, Вы видите две
панели инструментов: Стандартная и Форматирования, как показано на рисунке 2-8.

Рисунок 2-8: Панель инструментов Стандартная и Форматирования.

Когда Вы откроете Microsoft Project 2000, возможно Вы увидите обе панели в одной строке,
при этом обратите внимание, что Вы не видите панели инструментов полностью, как на рисунке 2-
8. Вы можете изменить поведение панелей инструментов с помощью следующей команды: Tools 
Customize  Toolbars, после этого Вы должны снять флажок в команде Standard and Formatting
toolbars share one row, после этого Вы увидите обе панели инструментов одна над другой. Если Вы
хотите для увеличения места на экране держать обе панели инструментов в одном ряду, доступ к
другим кнопкам Вы можете легко получить с помощью кнопки More Buttons в конце Вашей панели
инструментов, и затем, щелкните кнопку, которую Вы хотите использовать.
Совет
Экранная подсказка легко поможет Вам найти кнопку More Buttons, если Вы задержите Ваш
курсор на несколько мгновений над кнопкой.
Ссылка
Чтобы изменить внешний вид панели инструментов используйте диалог Настройка
(Customize). Работа с этим диалогом подробно обсуждается в главе 18.
В некоторых программах инструменты являются контекстно-зависимыми, то есть функция
изменяется в зависимости от операции, которую Вы в данный момент выполняете. В Microsoft
Project 2000 некоторые инструменты могут быть недоступны, выглядят как тускло-серые и не

8
реагируют на щелчок мыши. Это зависит от действий, которые Вы выполняете в данный момент
при работе Microsoft Project 2000.
Примечание
Если Вы производите вставку объекта из другого приложения, например, Excel или
PowerPoint в Ваш проект Вы можете обратить внимание на появление инструментов из этого
приложения при Вы выборе этого объекта. Поэтому, Вы можете использовать инструменты другой
программы, чтобы изменить объект без необходимости выхода из Microsoft Project 2000. Как только
Вы перейдете к работе над проектом, вновь происходит восстановление меню Microsoft Project
2000. Для этого Вы должны произвести щелчок мыши в любом месте Вашего проекта, с тем, чтобы
снять выделение с внедренного объекта.
В дополнение к панели Стандартная и Форматирования, Microsoft Project 2000 содержит
несколько других панелей, которые иногда появляются автоматически, когда Вы выполняете
некоторые типы действий. Однако, Вы можете также показывать каждую из этих панелей в любое
время, выбрав Представление(View)  Панель (Toolbars) и выбрать любую необходимую панель
инструментов.
Совет
Эти панели инструментов являются плавающими. Вы легко можете перемещать
плавающие панели по Вашему экрану. Чтобы переместить такую панель Вы должны захватить ее
за строку состояния. Кроме того, Вы можете поставить на якорь любую плавающую панель наверху
вашего экрана около рядом с панелями инструментов, просто отбуксируйте любую плавающую
панель вверх и бросьте на панель инструментов. И наоборот, Вы можете преобразовывать панели
инструментов Стандартная и Форматирования в плавающие панели, отбуксируйте любую из этих
панелей за маркер перемещения в любое место на вашем экране.

Ввод информации в Microsoft Project 2000

Ряд представлений в Microsoft Project 2000, например представление Ганта, используют
знакомый интерфейс электронный таблиц. Информация появляется в колонках и рядах.
Пересечение колонки и ряда - индивидуальная ячейка. Каждая задача в вашем проекте имеет
уникальный номер ID, обозначенный числами. Вы можете входить в информацию или в строку
информации (см. Главу 4) или непосредственно в ячейки. Когда Вы выбираете ввод информации в
ячейке, строка информации показывает информацию в ячейке.
Новая возможность
2000 Проекта использует введение и редактирование информации "в-ячейке".
Если Вы когда-либо использовали Microsoft Excel, Вы уже знаете, как вводить и
редактировать информацию в Microsoft Project 2000. Когда Вы начинаете набирать данные с
клавиатуры, точка вставки появляется в ячейке справа от текста, который Вы вводите. Чтобы
редактировать текст в ячейке, выберете ячейку, и затем нажмите F2, или выполните двойной
щелчок на ячейке, где Вы хотите начать редактировать. Точка вставки появляется на правом краю
текста в ячейке, если Вы нажали F2, если Вы выполнили двойной щелчок, точка вставки
появляется в ячейке в месте двойного щелчка.
Поскольку Вы вводите информацию в ячейке, эта информация также появляется в строке
информации на панели инструментов. Строка информации в Microsoft project 2000 выполняет ту же
роль, что и строка ввода формул в Microsoft Excel. Вы можете напечатать новый текст или
редактировать существующий текст, выполнив щелчок в пределах текста в строке информации.
Две кнопки слева позволяют Вам отменять или принять ввод (см. Рисунок 2-9).

9
Рисунок 2-9: Вы можете вводить или редактировать текст в ячейках или в строке информации.
Ссылка
В Главе 4 детально рассмотрены ввод и редактирование текста.

Смена представлений с помощью панели Представлений

Microsoft Project 2000 предлагает ряд представлений, в которых Вы можете увидеть всю
информацию о проекте. Одно представление возможно не может показать всю информацию, в
которой Вы нуждаетесь о выборе времени, отношениях среди задач, распределении ресурсов, и
контроле выполнения проекта; фактически, каждый тип информации требует специального вида
графического или текстового показа, для более точного их интерпретирования. Думайте о проекте
как о бизнесе. Как в любом бизнесе, разные людях проявляют внимание к различным аспектам
работы. Бухгалтерия думает главным образом о затратах. Директор завода сосредотачивается на
крайних сроках и наличии достаточного количества оборудования, для выполнения заказа. Отдел
кадров думает о людях: их заработной плате, рабочих часах, и так далее. Как руководитель
проекта, Вы должны быть в курсе всех изменений в течении проекта. Для получения
разнообразной информации о Вашем проекте, Вы просто переключаетесь к другому
представлению, чтобы оценить вашу работу с разных точек зрения. Каждое представление
помогает Вам сосредоточиться на различных аспектах проекта. Меню представлений (см. рисунок
2-10) позволяет Вам легко переключаться к разным представлениям.

10
Рисунок 2-10: Панель Представлений предлагает несколько предопределенных
представлений Вашего проекта.
Панель Представлений содержит восемь представлений. Когда Вы передвигаетесь вниз
панели Представлений, в верхней части панели появляется стрелка, направленная вверх, чтобы
Вы могли вернуться к вершине панели Представлений. Вы можете переключится в любое из
представлений, щелкнув на этом пункте в панели Представлений. На дне панели Представлений
имеется кнопка More Views. Щелкнув на этой кнопке, Вы получите доступ к диалогу Представлений,
показанному на рисунке 2-11.

11
Рисунок 2-11: Диалог More Views содержит 24 встроенных Представления и позволяет
добавлять Ваши собственные.
Ссылка
В Главе 6, Вы получите исчерпывающую информацию о применении представлений в
вашем проекте. Вы также можете создавать собственные представления, выбрав пункт New в
диалоговом окне More Views (см. Главу 7).

Новые возможности Microsoft Project 2000

В этой главе будут описаны только часть новых возможностей Microsoft Project 2000. Далее
в этой книге вы должны обратить внимание на сноску Новая возможность, в которых будут
подробно описаны новые возможности Microsoft Project 2000.
Как было упомянуто ранее, Project 2000 не является частью Office 2000, но Project является
частью семейства Office. В связи с этим, переход к Project 2000 целесообразен по тем же
причинам, что и переход к Office 2000. Эти цели и подходы изложены в следующем списке:
 Во-первых. Легкий доступ к информации и коллективная работа в сети Интернет. Исходя из
этого, Вы можете сохранить любой файл Project(или любой документ Office 2000) в
формате HTML так, чтобы Вы могли предоставить доступ к этому файлу любому, кто имеет
Интернет браузер. С помощью команды Сохранить Как (Save As) из меню Файл (File) Вы
можете сохранить файл Microsoft Project 2000 в формате HTML (см. Рисунок 2-12). Кроме
того, Вы можете использовать Microsoft Project 2000 для редактирования HTML-страниц,
созданных в Project, без потери форматирования или функциональных возможностей.
 Во-вторых. Чтобы уменьшать расходы на установку и развертывание, Microsoft создал
Windows Installer, который позволяет легко настроить установку в Вашей организации.
Windows Installer позволяет Вам определить особенности инсталляции, так называемая
"установка по требованию". Команда появляется в меню, но, когда пользователь выбирает
команду, появляется диалог, сообщающий, что данная возможность в настоящее время не
установлена и связана с выбором особенностью установки. Как правило, этот тип
установки исключает шаблоны. Кроме того, можно настроить установку так, чтобы эти
возможности запускались с локального жесткого диска, сервера сети, или терминального
сервера.

12
Рисунок 2-12: Вы легко можете предоставить доступ к Вашему файлу, сохранив его как Web
страницу.
 Чтобы уменьшать административные затраты, Microsoft Project 2000 и Microsoft Office 2000
поддерживают профили пользователей (документы, рабочий стол, приложения) которые
можно перемещать с компьютера на компьютер в общей сети. Но здесь есть одна
особенность: профиль пользователя может перемещать в сети Windows 98 или Windows
NT/2000, но профиль нельзя перемещать с платформы на платформу.
 Чтобы уменьшать затраты на поддержку конечного пользователя, Microsoft Project 2000 и
Microsoft Office 2000 имеют возможность "самовосстановления", то есть они могут
обнаруживать отсутствие необходимых файлов или вхождений регистра, и устанавливать
необходимые файлы или вхождения регистра. Команду Найти и Устранить (Detect and
Repair) Вы найдете в меню Справка (Help) для решения возникших проблем.
 Microsoft Project 2000 установлен новый формат баз данных, который поддерживает SQL 7,
Access 2000, и Oracle 6. Однако, чтобы уменьшить общую стоимость собственности, Вы
можете сохранять файлы Microsoft Project 2000 в формате Project 98. Поэтому, организация
может не устанавливать Project 2000 на всех машинах, но пользователи использующие
Project 2000 могут автоматически сохранять свои файлы в формате Project 98, для того,
чтобы созданные ими фалы были доступны всем пользователям.
 Чтобы увеличивать международную поддержку, Microsoft упростил развертывание, создав
единый выполняемый файл, который может использоваться для Соединенных Штатов,
Европы, Дальнего Востока, и стран, которые используют двунаправленные языки типа
Иврит и Арабского языка.
 В Project 2000 использована и другая особенность Office 2000: адаптивные меню и панели
инструментов. Вы уже видели как эта особенность работает ранее в этой главе. Команды
не появляются в меню, при первом открытии меню; только после короткой задержки или
если Вы щелкните на кнопке с двойной стрелкой в основании меню. Если Вы выбираете
команду, которая не появлялась первоначально, то она будет появляться в следующий раз
при открытии меню.

13
 2. Планування проекту.

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

ресурсы
Мы будем рассматривать наши рекомендации на сквозном примере проекта по
адаптации и внедрению некого программного продукта. Часть I будет посвящена процедуре
запуска проекта. Мы рассмотрим методы планирования, приемы составления бюджета с
использованием человеческих и материальных ресурсов. По ходу дела мы будем совершать
небольшие типовые ошибки, последствия и методы устранения которых мы рассмотрим в
следующей части.
Постановка задачи
Проект должен начинаться с формулировки цели. При этом цель должна быть
зафиксирована письменно в виде измеряемых показателей.
Документ "Постановка задачи" должен отвечать на следующие вопросы:
1) В какие сроки должна быть достигнута цель?
2) Какие условия достижения цели есть в наличии (бюджет, ресурсы,
технология)?
3) Каким способом измерить достижение цели?
4) Как распределены ключевые обязанности в проекте (кто за что отвечает)?
5) Согласен ли спонсор с определением цели и условиями ее достижения?
В нашем примере цель проекта заключается в адаптации и внедрении некой системы
документооборота. В нашем случае задание было письменным, не был определен только
способ измерения того, что цель достигнута; последствия этого мы увидим далее.
Список этапов
Перейдем непосредственно к нашему примеру. Менеджер получил постановку задачи на
адаптацию и внедрение некого продукта Web Work Flow. Менеджер запускает Microsoft Project
2000 и приступает к созданию компьютерной модели проекта. Как видим менеджер приступил
к этому не пройдя полного согласования задач и целей проекта, эта организационная ошибка
приведет к последствиям, которые мы рассмотрим ниже.

14
 После запуска MS Project 2000 менеджер сразу видит список для ввода задач с
графической схемой проекта (Gantt Chart). Слева находятся переключатели видов списков.
В самом начале составления плана менеджер вводит список этапов, соответствующих
технологии внедрения.

Замечание для опытных пользователей. Как можно заметить, внешний вид MS Project
2000 не претерпел значительных изменений по сравнению с MS Project 98. Из новинок можно
отметить новый вид просмотра проекта Network Diagram, который заменил Pert Chart. Новый
вид позволяет просматривать проекты в виде графической схемы, как ранее в PERT-
диаграммах, при этом добавлена возможность работы с иерархическими задачами, как в
диаграммах Gantt.
Совет. Включите Summary Task для того, чтобы видеть обобщенную статистику по
проекту (общая длительность, трудоемкость, стоимость и т.д.).
Список задач
Ориентируясь на письменное задание, менеджер назначил задачи для всех
технологических этапов.

Меня критикуют
Замечание. "Должны быть типовые фрагменты (подпроекты) – корпоративный
стандарт выполнения стандартных этапов. Тестирование вряд ли сильно отличается для
разных задач и нечего менеджеру каждый раз изобретать велосипед."
Могу только согласится. Шаблоны проектов (project patterns) необходимы. Вопрос
насколько они удачно сделаны. Абстрактно или из успешной практики? Выше тоже
применяется шаблон, состоящий в использовании стандартных технологических этапов.

15
Данный шаблон позволит получить единую статистику по этапам всем проектов, но как
увидим дальше страдает недостатком именно из-за отсутствия выделения подпроектов.

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

Замечание для опытных пользователей. В MS Project 2000 появилась возможность

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

17
 Советы и комментарии.
1) Точный срок следует указывать только для задачи "Начало проекта", все
остальные сроки должны быть относительными. Таким образом, вы всегда можете легко
перенести проект на другую дату, все сроки пересчитаются автоматически.
2) Все технологические этапы следует завершать контрольными точками. Дело
в том, что по технологии некий законченный результат может быть получен только в
определенное время, и именно в данный момент следует провести контрольный осмотр
проекта. Жестко и подневно контролировать исполнение отдельных задач часто не имеет
смысла, т.к. исполнителям обычно приходится исполнять задачи не в том порядке, как
указано в плане. Все это не значит, что подневная отчетность не нужна, она нужна в виде
отчетов о затратах рабочего времени, о чем речь пойдет далее.
3) Не используете связи между задачами разного уровня. В этом случае один
технологический этап привязывается к внутренней структуре другого этапа. Это
сковывает свободу модификации планов в рамках отдельных этапов. Если используются
связи только на одном уровне (задача-задача, этап-этап), вы можете без затруднений
изменить состав и последовательность задач внутри некого этапа.
4) Сокращение критического пути проекта за счет преждевременного начала
задач очень рискованно. Сокращайте критический путь за счет подготовительных работ
(обучение, моделирование и т.д.). В нашем случае можно одновременно с постановочными
работами запланировать прототипирование, и за счет этого сократить кодирование и
общую продолжительность проекта. Сокращение критического пути проекта фактически
всегда приводит к увеличению затрат на подготовительные работы. Иными словами,
сокращение длительности проекта, как правило, приводит к повышению его
себестоимости или рисков.

Меня критикуют
Замечание 1. Начало проекта в MS Project нужно отмечать в его свойствах!
Можно и свойством и milestone, последнее мне кажется удобнее, т.к. его можно таскать
мышкой.
Замечание 2. Подневной отчетность может и нужна для некоторых проектов.

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

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

Совет. Если нужно производить учет административных расходов, т.е. затрат на

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

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

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

Советы.
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 многих начинающих пользователей

20
пугает своей "непредсказуемостью". Дадим краткие рекомендации по выравниванию.
Оптимально использовать выравниваение, если у вас более 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 задачи.
План с бюджетом
После назначения расценок на ресурсы менеджер автоматически получил план с
бюджетом.
Из этого документа видны следующие основные параметры проекта:
- Длительность
- Трудоемкость
- Себестоимость
- Сроки
- Исполнители и ответственные лица

21
 Совет. Данные по трудоемкости (Work) и себестоимости можно использовать для
ценообразования проекта. В нашем случае можно умножить трудоемкость на выходную цену
человеко-месяца и получить внешнюю цену проекта. Например, если выходная цена человеко-
месяца $2000, а трудоемкость 2 человеко-месяца, то внешняя цена проекта $4000. Конечно
цена может быть скорректирована из маркетинговых и стратегических соображений.
Меня критикуют
Замечание 1. Чем трудоемкость в вашем примере отличается от длительности?
Так как это понимает MS Project 2000. Если упрощенно Work=Duration*N, где Work -
трудоемкость, Duration - длительность, N - количество занятых ресурсов в задаче.

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

Довольно часто после формальных процедур планирования и получения бюджета

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

В нашем примере сложилась следующая ситуация: не успел проект начаться, как

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

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

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

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

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

Условия: Заказчик требует использования Z-технологии, с которой мы не
Определение
знакомы
риска
Следствие: Кодирование может занять больше времени
Вероятность Работы по кодированию могут занять до 25% больше времени (фактор
продуктивности = 1.25).
Вероятное значение трудоемкости кодирования: 1.25x20=25 человеко-
дней

24
 Вероятное значение длительности кодирования: 1.25x4= 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).

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

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

25
 Следует обратиться к статистике. Нужно посчитать, какие виды рисков вызывают
наибольшее количество проблем. На рисунке приведен график дефектов продукции в
зависимости от видов дефектов.
Видно, что работает правило 80/20. Примерно 20% рисков создают 80% угрозы. Именно
на них следует обращать основные усилия. В технологичных проектах обычно риски
предотвращаются обучением, контролем и поддержанием качества (тестированием и др.
методами).
Совет. Для того, чтобы эффективно бороться с рисками, нужно вести статистический
учет возникающих проблем по видам рисков. В данном качестве может быть использована
система учета дефектов продукции.
Меня критикуют
Замечание 1. Статистики может не быть. Кроме того, у рисков есть обыкновение во
времени меняться.
Что тут сказать? Если нет статистики для принятия решения, то и само решение
будет оставлять желать лучшего. Насчет изменения рисков, нужно делать их отслеживание
как указано выше.
Замечание 2. Риски не только дефекты, а например неправильное определение
последовательности исполнения задач, неточная оценка длительности и т.п.
Для софтверных проектов есть особенность. Фактически любая команда выдающая
продукты хорошего качества имеет систему регистрации дефектов и их отслеживания (Bug
Tracking System). Можно не изобретать велосипед и все рисковые проблемы фиксировать там,
для этого потребуется завести новые категории проблем ("неверное планирование",
"недооценка сроков", "ошибка постановки задачи" и т.д.). В таком случае вы сможете
пользоваться развитой отчетностью по проблемам из системы отслеживания дефектов,
кроме того, вы сможете использовать и механизмы отслеживания проблемы, т.е. на проблему
будет гарантированная реакция ответственного лица.
Согласование и отчет
После утверждения нового плана обучение прошло успешно и в сроки закончилось
необходимой сертификацией. Сотрудник успешно преступил к выполнению первой задачи.
Однако в день ее завершения он сообщил, что "задача готова на 90% и требуется еще 1 день".
На следующий день он ответил то же самое.
На рисунке показан вид просмотра проекта Tracking Gantt, на котором видно отличие
первоначального плана от фактического исполнения.

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

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

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

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

27
 Проблемы и решения
Каковы выходы из сложившейся ситуации?
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. Статистический анализ проектов в малых группах разработки
показал, что можно достаточно точно узнать реальный срок задачи, просто умножив слова
исполнителям на некий коэффициент. Вот ориентировочные значения коэффициента:
x=2 - оптимистичная оценка
x=3 - нормальный проект
x=4-5 - применение нестандартных технологий
3) Схема PERT вычисления реального срока. Часто бывает, что разные оценки дают
разные сроки; в этом случае можно применить метод расчета реального срока по следующей
формуле:
Реальный_Срок=(Оптимистичный_Срок+4*Ожидаемый_Срок+Пессимистичный_Срок)/6

Коэффициенты в данной формуле (4 и 6) получены путем анализа статистики

большого количества проектов. Следует отметить, что схема PERT эффективна только в
том случае, если действительно имеются различные оценки. Если менеджер хочет через PERT
просто убедить себя, что его решение единственно правильно, то подгонка статистики не
даст ничего, кроме положительного ответа. О том, как использовать средства
автоматизации PERT-вычислений в Microsoft Project, речь пойдет ниже.
Важное замечание. Приведенные статические коэффициенты являются лишь
ориентировочными. Необходимо накапливать свою собственную статистику по ведению
проектов для того, чтобы получить специфические для данной технологии и данных
исполнителей калибровочные коэффициенты.
Калибровка сроков
Как это часто и бывает на практике, обсчет реалистичных сроков для проекта
менеджер стал выполнять после его начала. Если проект для менеджера новый, то подобная
ошибка почти неизбежна.
Используя Load Factor, менеджер оценил пессимистичные сроки. В качестве ожидаемых
сроков менеджер взял те, что получились путем согласования через Team Assign с
исполнителями. За оптимистические взял свои первоначальные.

28
 Методом PERT пересчитал ожидаемые сроки. На рисунке в колонке Work Variance видно,
что по сравнению с планом была недооценка трудоемкости в 226 человеко-часов.

Советы.
1) Колонки Variance могут показать вам отличие состояния проекта от
первоначального плана. Вы может добавить эти колонки в любой вид просмотра.
2) Используйте копирование через Clipboard колонок PERT-диаграммы, таким
образом вы сэкономите время. Скопируйте Duration (значения до запуска PERT) в колонки
Optimistic, Expected, Pessimistic. Отредактируйте значения по необходимости.

Мы рассмотрели только часть действий по анализу исполнения и корректирующих

воздействий. Обсужденные данных вопросов мы продолжим в следующей части.

Формальное закрытие проекта. Политические

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

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

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

30
 План и требования должны изменяться совместно
Если проанализировать ситуацию, видно, что фактически происходит изменение
задания (задач) проекта в результате процедуры приемки. На рисунке приведен цикл изменения
плана при корректировке задач по методике PMI.
Если задачи проекта не были документированы или если заказчик проекта настаивает
на новых задачах без коррекции плана, то ситуация неуправляема. Скорее всего, проект пойдет
на самотек, или Исполнитель откажется вести проект себе в убыток.
Требование и план неразрывны, это простое положение не так просто достигается на
практике. Очень часто Заказчик только на сдаче проекта обнаруживает, что требования к
проекту и его ожидания - несколько разные вещи. Часто Заказчик начинает настаивать именно
на выполнении своих ожиданий.
В нашем случае причина в другом. Менеджер предусмотрел в плане работы по
составлению задания и утвердил его у Заказчика. Заказчик был заранее предупрежден, что
многие его ожидания в данном проекте реализованы не будут. Для правильного планирования
необходимо завершить этап постановки задач. Это было сделано. Проблемы заключаются в
другом.

31
 Меня критикуют
Замечание 1. Необходимо изначально ставить измеримые цели, чтобы избежать
субъективизма при оценке, исполнен проект полностью или нет.
С этим не спорю, я намерено пропустил этот шаг в начале своего примера, чтобы
показать последствия данной ошибки и как можно ее постараться исправить по ходу дела.
Замечание 2. Если заказчик начинает настаивать на выполнении своих ожиданий, нужно
их оформить как дополнительное соглашение к Договору.
Если заказчик согласен, то проблем нет. Однако если есть возможность, заказчик
воспользуется своим правом на трактовку неоднозначных описаний в задании. Это еще раз
подтверждает необходимость измеряемых критериев приемки работ, как средство ухода от
различных толкований задания и потенциального конфликта.
Планирование итеративно, следующие стадии предсказуемы
лишь статистически
Итак, в чем заключаются настоящие проблемы данного проекта? Заказчик раздражен
постоянным удорожанием проекта и спорит о толковании пунктов задания. Таким образом,
разделим мотив и формальную причину.
Как мы видели выше, менеджер (исполнитель) сделал много ошибок в процессе
планирования. Однако нельзя сказать, что вся ответственность за это лежит на нем. Дело в
том, что невозможно было точно предсказать сроки задач в конце проекта без завершения
первых задач. Например, выработка требований может изменить оценку трудоемкости
разработки.
Более правильным является разложить этот большой проект на несколько небольших,
но с гарантированным получением результата. Проблема состоит в том, что Заказчик, как
правило, хочет знать сроки и цену на все сразу, т.к. отдельный этап работ представляется
менее ценным, чем весь проект.
Единственное, что может сделать опытный менеджер в данном случае, это четко
спланировать ближайший этап, а остальные определить статистически. Как видно из выше
изложенного, статистика с учетом косвенных работ поражает воображение своей
трудоемкостью на фоне иллюзии простоты.
Заказчик, получив большие статистически оценки, требует составить план работ из
конкретных задач и начинает убирать оттуда "завышенные" и "ненужные" работы.
Если это произошло, проект обречен на потерю контроля.
В нашем случае проблема заключалась в том, что менеджер пытался сделать все в
рамках одного проекта и статистические оценки стал применять только уже по ходу проекта.

Нужны измеряемые критерии завершения проекта

(контрольные тесты)
Поговорим теперь о формальном завершении проекта. Чтобы не спорить о том,
выполнено ли задание или нет, требуется определить измеряемые критерии достижения цели.
В случае ПО это контрольные тесты. Измеряемые критерии позволяют формально
завершить проект, разделив ожидания и требования.
Альтернативой формальному завершению проекта является бесконечное движение в
сторону ожиданий. Рассмотрим, что может получиться в данном случае:
1) Ожидания по своей природе противоречивы, как и человеческие отношения.
Многие желания логически несовместимы. Например, топ-менеджер хочет иметь больше
аналитической статистики, а оператор хочет заполнять меньше аналитических полей.
Удовлетворить оба эти ожидания логически невозможно, поэтому система, развивающаяся
в данном направлении, может оказаться нерабочей из-за дефектов логики
2) Существуют рамки возможностей технологии. Например, ожидания
пользователей по скорости работы программы, может быть невозможно не
удовлетворить с помощью современных технологий.
3) Возможна и обратная ситуация, типичная для внутренних проектов компаний.
Разработчики проекта увлечены технологией и математической логикой, при этом
происходит потеря требований к ключевым ожиданиям заказчика. Результат получается,
но не тот.
Успешное внедрение обычно происходит иначе. Проект обычно решает некий
ограниченный круг согласованных задач. После их достижения формулируются новые задачи и
выполняется новый проект. Таким образом, за несколько проектов все ключевые ожидания
заказчика реализуются. При этом очевидно, что значительная часть ожиданий не будет

32
реализована никогда. Однако заказчик получит не идеальный, но пригодный к эксплуатации
продукт, возможно лучший продукт из возможных в данное время.
Формальное закрытие проекта
Сравним формальное закрытие проекта с проектом "без конца".
Проект с формальным завершением обладает очень высокой предсказуемостью и
управляемостью.
Можно достаточно точно определить бюджет и сроки проекта. Формальный проект
повышает ответственность сторон, все ожидания и соглашения документированы.
Проект без формального ведения обычно мало управляем по срокам и бюджету. Если
формализованный проект подвержен значительному риску на этапе постановки, то
неформальный проект, в силу неопределенности задач, подвержен риску на всем протяжении.
Тем не менее, многие предпочитают неформальное ведение проектов. Этот
объясняется влиянием политических рисков. Формальный проект позволяет установить
ответственность, и эта ответственность часто пугает как исполнителя проекта, так и
заказчика. За неудачу формального проекта несут ответственность в равной степени и
Исполнитель, и Заказчик. Оба подписались под требованиями к проекту и взяли на себя
ответственность, причем эта ответственность носит личный характер.
Обычно ситуация безответственности не устраивает только топ-менеджеров, именно
они и могут своим волевым решением привести ситуацию в норму. Оптимально, если это
происходит до начала проекта, а не по ходу его.
В нашем случае, менеджер на встрече с топ-менежером заказчика добился решения об
измеряемых критериях завершения проекта.

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

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

33
 Анализ статистики
После завершения проекта необходимо вычислить статистические показатели для
последующего прогнозирования сроков: соотношение стадий, типовые длительности,
стоимости и т.д.
Именно поэтому важно разделить план на технологические стадии, состав которых не
зависит от вида проекта.
Для получения сложной статистики (например, по персоналу) можно использовать
связку MS Project и SQL Server. Это встроенная возможность MS Project 2000.
Что показывает статистика?
Приведем типичные статистические показатели Канера-Фолка и прокомментируем их
относительно нашего примера.
Продукт получается в среднем через 8 внутренних и 3 внешних версии. Из этого
следует, что стоит планировать 8 версий, и, скорее всего, потребуется несколько проектов.
Об этом мы уже говорили выше.
Для разработки ПО характерны следующие статистические показатели соотношения
технологических стадий:
Разработка - 37%
Сопровождение - 63%
Этап разработки разделяется на стадии со следующими пропорциями:
Постановка - 34%
Кодирование - 21%
Тестирование - 45%
Если рассмотреть наш пример, то мы увидим, что данная статистика работает.
Однако если мы посмотрим на первоначальный план, то увидим несоответствие
трудоемкости стадий плана средним статистическим показателям.
Совет. Проверяйте план на соответствие статистике!
Внедрение MS Project в масштабах предприятия
Следует отметить, что мы рассмотрели только вопросы управления малой группой.
Для внедрения технологии управления в масштабах предприятия нужно рассмотреть
следующие вопросы:
1) MS Project Central как платформа группового управления
2) Межпроектное управление

34
 3) Конфликты проектов по ресурсам и их предотвращение через Resource Pool
Данные вопросы мы рассмотрим в следующих статьях и специальных семинарах.
Выводы
Управляемость внедрения достигается формализаций и автоматизацией проектной
деятельности.
Для достоверной оценки стоимости и рисков необходимо иметь накопленную
статистику по различным параметрам процесса внедрения. Чтобы накопить такую
статистику, необходимо провести достаточно много проектов и замерить их фактические
параметры. Также следует учесть, что данная статистика специфична и зависит от вида
внедрения, персонала, организационных особенностей.
В качестве эффективного средства автоматизации ведения проектов можно
использовать MS Project 2000. Практика показывает, что Microsoft Project способен вести учет
проектной информации, организовывать проектный документооборот по принятию планов, а
также позволяет получить статистику для принятия решений.

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

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

Меня критикуют
Замечание 1. Большой вопрос по поводу способности MS Project вести полный
проектный учет.
MS Project 2000 и MS Project 2002 Standard это действительно инструмент для
небольших проектов, где не требуется сложное управление ресурсами. MS Project не содержит
средств для управления сложными механизмами затрат, интеграции с бюджетированием и
средств планирования многих внешних критериев проекта (например, для маркетингового
проекта это план и факт продаж). Тем не менее данные ограничения часто не существенны
для небольших проектов, если нужна система hi-end класса, тогда стоит обратить внимание
на MS Project 2002 Professional.
Недостающую функциональность во многих случаях можно легко "допрограммировать"
на Visual Basic и не покупая дорогую систему. Выбор проектной системы определяет
соотношение цена/качество, где необходимый требования к качеству зависят от конкретной
компании.
Замечание 2. Описанная методика соответствует возможностям MS Project, но
нуждается в некоторых коррективах (см. другие замечания). В частности необходимо
планировать риски. Нужно все-таки изначально описывать методику с учетом того, что в
организации это не первый и не единственный проект.
Некоторое планирование рисков мы рассмотрели, возможно оно упрощенное, за полным
вариантом следует обратится к PMBOK. Насчет межпроектного взаимодействия, данной
проблеме будет посвящена отдельная методика, которая базируется на использовании MS
Project Central Server 2000.
Моделирование рисковых сценариев доступно в MS Project 2002 Professional.

Project Risk Analyzer. Профессиональный анализ рисков для

Microsoft Project 2003 на базе BI-решений от Microsoft
В статье рассматривается первый в мире продукт для исследования факторов
влияния на риски для MS Project 2003 на базе технологий Microsoft Data Mining - система
Project Risk Analyzer.
Также в статье рассматривается выдающийся вклад SAS Institute в теорию и
практику профессионального анализа рисков.
Ключевые требования анализу рисков согласно методикам
PMI и их реализация в MS Project
Стандартные средства Microsoft Project для управления рисками, в том числе
новинки MS Project 2003 рассмотрены в обзорах продукта (например, Управление рисками
в MS Project 2003). Данная статья более глубоко рассматривает вопросы анализа рисков и
используемых для этого продуктов.

35
 В стандарте ANSI по управлению проектами (PMBoK) требования по управлению
рисками отражены в следующих разделах
 Планирование управления рисками (PMBoK 11.1)
 Идентификация рисков (PMBoK 11.2)
 Качественный анализ рисков (PMBoK 11.3)
 Количественный анализ рисков (PMBoK 11.4)
 Планирование ответных действий на риски (PMBoK 11.5)
 Отслеживание рисков (PMBoK 11.6)

Основными инструментами для управления рисками в MS Project являются

 Риск-листы (новое в Microsoft Project 2003)
 Резервирование ресурсов на случай возникновения рисков (новое в
Microsoft Project 2003)
 Моделирование поведения портфеля проектов под влияние рисков
(улучшено в Microsoft Project 2003)
 PERT-средства моделирования влияния рисков на сроки и бюджет
Не будем повторять достоинства решения Microsoft, отметим важнейшие
ограничения Microsoft Project в управлении рисками.
 Как отмечает сам Microsoft, хотя базовое средство отслеживания рисков
в виде риск-листов сделано в Microsoft Project 2003, однако система не оборудована
анализом рисков в принципе, хотя именно анализ рисков ключевое требование PMBoK
2000
 Нет встроенных средств для анализа рисков методом Деревьев
Решений, ключевого инструмента согласно PMBoK 11.4.2(3)
 Хотя средства моделирования влияния рисков заявленные PMBoK
11.4.2(4) представлены в Microsoft Project в виде Portfolio Modeler, но нет встроенных
средств для моделирования методом Монте-Карло
Средства моделирования методом Монте-Карло для Microsoft Project можно
приобрести как дополнительную компоненту. Рекомендуем системы @Risk и Risk+.

36
 Еще раз отметим, что системы управления рисками требуют тщательной
методической подготовки и тренингов. Тренинги по управлению рисками на базе
системы Microsoft Project можно заказать по адресу info@microsoftproject.ru
(программы на сайте). Управление рисками самый не интуитивный вид проектного
менеджмента.
Что такое Деревья Решений?
Дерево решений (Decision Tree) - это древовидная структура позволяющая
проанализировать различные варианты воздействий или принятий решений на конечный
результат, например возникновение риска с тяжелыми последствиями.
Простейшее использование анализа методом Деревьев Решений (Decision Tree
Analysis) состоит в создании дерева возможных решений вручную и максимум
полуавтоматический расчет показателей по каждому возможному варианту в дереве.
Профессиональные аналитические системы Microsoft и SAS идут дальше, сама
система разрабатывает дерево решений используя предыдущий опыт ведения проектов.
Хотя для пользователя это выглядит достаточно просто, внутри работает фантастически
сложная аналитическая система, которая ищет корреляции, т.е. закономерности в данных и
по ним конструирует реальную картину принятия решений и воздействий, а не как то
кажется или даже планируется менеджерами.

Типичные задачи которые решают с помощью Деревьев Решений:

 Совокупность каких факторов и решений приводит нас к возникновению
рисков с тяжелыми последствиями?
 Каковы причины возникновения дефектов качества?
 Что влияет на прибыль проектов?
 Каковы последствия принятия комбинации решений с точки зрения
рисковых последствий по финансовым показателям?
Иллюстрация Дерева Решений приведена на рисунке. Данное дерево решений
получено с помощью технологии Microsoft Decision Tree и продукта Project Risk Analyzer.
Приведенный пример показывает, что на возникновение рисков с высокой опасностью

37
наибольшее влияние оказывает персонал. Причем для одного из сотрудников (Сидоров)
есть дополнительные критерии определяющие возникновение опасного риска. В вашем
случае Data Mining может показать, что опасные риски в первую очередь зависят от типа
технологии и т.п. На вашей статистике дерево решений может достигать вложенности в 5-
15 уровней.
Что такое профессиональные аналитические системы?
Поскольку речь в статье будет идти о профессиональном анализе данных, в нашем
случае рисков, сделаем краткий обзор понятия "профессиональная аналитическая
система".
Аналитические системы по уровню своей платформы делятся на профессиональные
и непрофессиональные. Профессиональные системы отвечают следующим основным
критериям:
 Получение ответа на аналитический запрос в виде отчета примерно за
1-2 секунды не зависимо от количества анализируемых операций и документов
 Пользователь может без программиста получить данные в любой
комбинации аналитических разрезов
 Пользователь должен тратить на подготовку и настройку "своей"
версии отчета на более нескольких секунд
 Не смотря на то, что пользователь может делать анализ в
произвольных разрезах, система должна гарантировать защиту информации на уровне
даже отдельных аналитических элементов ("могу видеть столько своих клиентов" и
т.п.)
 Система обладает простым и единообразным интерфейсом для всех
видов отчетов
Фактически 99% профессиональных аналитических систем реализованы на базе
технологии OLAP, из OLAP-систем примерно 50% сделаны в новом поколении MOLAP
(решения Microsoft и Hyperion). Примерно 60% корпоративных пользователей применяют
подобные системы в своей практике. В случае Microsoft это свыше 25 миллионов
пользователей.
В тоже время следует различать инструмент (OLAP) и решение сделанное на его
базе. Профессиональные аналитические системы это именного готовые бизнес решения,
которые часто называют BI-решениями (Business Intelligence Solution)

38
 На рисунке приведен пример использования OLAP-анализа рисков на базе
технологий Microsoft Analysis Services (компонент MS OLAP) и продукта Project Risk
Analyzer. В примере выше анализируется влияние рисков по воздействию на бюджет.
Аналитик смотрит значения финансовых потерь в разрезах ответственных и технологий. В
вашем случае могут и должны быть использованы специфичные для вас критерии анализа.
Управление рисками в проектах: недостатки современных
систем
Рынок средств для управления рисками в проектах чрезвычайно молодой и конечно
имеет болезни роста.
Например, многие системы управления проектами гордятся встроенной
реализацией метода Монте-Карло, но не имеют базовых средств отслеживания рисков,
такие как риск-листы. Другой пример, система может иметь некую статистическую
систему анализа рисков (которая, в прочем может полностью не соответствовать
требованиям PMBoK), но более важные средства рискового моделирования "а что если?"
могут отсутствовать полностью или находится в зачаточном состоянии.
Тем не менее, нельзя не отметить, что некоторые частные решения в управлении
рисками достаточно удачны. Например, различные реализации трендов, для отслеживания
влияния выявленных тенденций в будущем.

Управление рисками: что выбирают профессионалы?

Фактически ни один производитель систем управления проектами (СУП) не
предлагает решений на базе технологии Деревьев Решений требуемых согласно PMBoK
11.4.2(3), хотя это требование идет впереди рекомендации PMBoK 11.4.2(4) по
использованию симуляторов, где только одним из вариантов является метод Монте-Карло.
Все это связано с тем, что все производители СУП сравнительно недавно работают
на рынке управления рисками и они не имеют сложных статистических технологий.

39
Реализация технологии Деревьев Решений требует разработки профессиональной
аналитической системы на базе технологий Data Mining и MOLAP (следующее поколение
OLAP-систем), сложность изготовление такой платформы сравнима со сложностью
изготовления самой СУП, вот почему такие решения и не поставляются, а с ними
приходится интегрироваться.
Признанным грандом на рынке профессиональных средств анализа рисков является
компания SAS, ее решения используют более чем в 37 тыс. предприятий и
правительственных структур по всему миру. Для примера это примерно в 40 раз больше
чем пользователей у крупнейших СУП таких как Primavera, Niku и Artemis. По числу
клиентов SAS уступает разве что Microsoft.
Управление рисками это основа страхового и банковского бизнеса. Не удивительно
наличие большого количества клиентов на продукт SAS® Risk Management в данных
отраслях: Morgan Stanley, Australia and New Zealand Banking Group, Banca Nazionale del
Lavoro Banco Santander, BBL, Mutual & Federal Insurance, NRMA Groupama France,
ChoicePoint, Chubb & Son Insurance, Medical Benefits Fund и многие другие.
Можно сказать, что мировая практика управления рисками и вышла из опыта
банковского и страхового сектора. Однако этот опыт был успешно адаптирован и дополнен
военными и производственниками. Что тоже подтверждается такими клиентами SAS как
U.S. Air Force и U.S. Department of Defense, а также Ford Motor Company, Hyundai Motor
Company, Honda.
Программные продукты и технологии SAS с успехом применяются рядом
крупнейших компаний и государственных структур России. Среди ее заказчиков –
Центральный Банк РФ, Министерство путей сообщения, РАО "Газпром", ФАПСИ,
финансовые организации, в том числе страховая компания РОСНО, Альфа Банк и
компания МТС.
В 1998 году компания Microsoft решила выйти на рынок на котором работал SAS, Hyperion
и Oracle. Удачные технологические решения Microsoft и агрессивная ценовая политика
привели к тому что в мае 2003 года Microsoft удалось фактически разрушить продажи
Oracle на этом рынке и обойти Hyperion в MOLAP решениях (см. анализ рынка на
www.olapreport.com). На текущий момент продажи Microsoft на рынке инструментов для
профессиональной аналитики примерно в 25 раз превосходят SAS. Сейчас простыми и
эффективными инструментами Microsoft пользуются около 25 миллионов человек. Хотя
SAS перестал играть значимую роль на рынке OLAP-инструментов для многомерного
анализа рисков, однако SAS остался признанным лидером в области исследования
закономерностей рисков средствами Data Mining (в том числе для методик Деревьев
Решений). Этот опыт был использован при формировании стандарта для
профессиональных аналитических систем, который был совместно разработан Microsoft,
Hyperion и SAS.

40
 В 2000 году Microsoft представил интегрированную c Microsoft SQL Server
платформу Microsoft Analysis Services, которая включала в себя технологию Деревьев
Решений, а также средства профилирования и выявления типовых обликов (в том числе
рисков). Однако решение являлось только серверной платформой Data Mining, создание
конечных решений Microsoft решил передать третьим компаниям. Microsoft не предложил
даже стандартного рабочего места для аналитика использующего Data Mining-анализ.
Project Risk Analyzer для Microsoft Project 2003
Данный продукт позволяет производить различных анализ рисков по риск-листам
Microsoft Office Project 2003.
Основные возможности Risk Analyzer таковы
 "Know How". Data Mining-клиент к системе Microsoft Analysis Services на
базе Internet Explorer. Иными словами вы можете анализировать Data Mining-модели
рисков и производить OLAP-анализ рисков используя только Internet Explorer.
 OLAP-анализ рисков в произвольной комбинации критериев оценки рисков
(ответственный, категория, приоритет, статус, вид риска и т.д.)
 Анализ стоимостной и временной составляющей рисков
 Построение Деревьев Решений по факторам влияния на риски на базе
технологии Microsoft Decision Tree
 Построение профилей типовых рисков на базе технологии Microsoft
Clustering
Примеры использования продукта с экранами приведены выше (Деревья Решений и
OLAP-анализ). Не рассмотрен только пример профилирования рисков через Microsoft
Clustering. Пример данного анализа на рисунке ниже. Суть анализа в следующем.
Аналитик просит Project Data Analyzer выявить типичные облики рисков, как
совокупность параметров рисков, которые часто встречаются вместе. Затем можно
проанализировать выявленные типовые облики рисков. В нашем примере их три, видно
что центральный облик характеризуется высоким количеством дефектов проектирования.
Можно далее проанализировать ваших клиентов, которые наиболее часто сталкиваются с
внешним проявлением ваших внутренних рисков. Возможен и обратный анализ методом
"корзины покупателя", который наиболее интересен для сервисных компаний. Выявляются
какие типовые пакеты услуг и сопутствующие товары приобретает покупатель, а затем
можно проанализировать какие риски (в том числе дефекты качества) сопровождают
данные покупки.
Стоимость Project Risk Analyzer составляет $700, штатные работы по установке,
настройке и адаптации под систему пользователя составляют $500.
По вопросам демонстрации и приобретения Project Risk Analyzer обращайтесь по
электронной почте info@microsoftproject.ru

41
Звіт з контрольної роботи повинен містити:

1. Титульна сторінка.
2. Мета роботи.
3. Теоретичні відомості із сітьового планування (3-5 стор.).
4. Теоретичні відомості з управління ризиками проекту (3-5
стор.).
5. WBS-структура проекту.
6. Діаграма Ганта с критичним шляхом.
7. Сітьовий графік.
8. Лист ресурсів.
9. Бюджет проекту.
10. PERT-діаграма.
11. Аналіз ризиків проекту.
12. Висновки.

Примітка: п.5-10 роздрукувати із Microsoft Project.

42