Открыть Электронные книги
Категории
Открыть Аудиокниги
Категории
Открыть Журналы
Категории
Открыть Документы
Категории
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.
3
Эти две временных шкалы помогают Вам видеть сразу два уровня выбора временных отрезков,
например день и час или неделя и день.
Примечание
Вы можете настраивать вашу шкалу времени самым необычным образом. На Рисунке 2-3,
шкала времени настроена для показа недель. Для того чтобы открыть диалоговое окно управления
показом времени на временной шкале, сделайте непосредственно на ней двойной щелчок. Также
обратите внимание, что не выполнено назначение количества часов в рабочем дне, рабочих дней
в неделе, и так далее. Чтобы настроить эти назначения, чтобы показать или скрыть нерабочие дни,
Вы можете использовать назначения нерабочего времени в диалоговом окне временной шкалы. В
Главе 3, подробно рассматривается вопрос изменения календарей, которые управляют проектом.
4
Рисунок 2-4: Типовой проект в представлении Ганта. Табличная часть с деталями задач и
диаграмма Ганта.
Одна из сильных сторон Microsoft Project 2000, это то, что Вы можете легко переключится
из представления Ганта в другие представления. После небольших экспериментов по
переключению представлений, Вы сможете видеть информацию о выборе времени, бюджете, или
назначениях ресурсов более подробно, или выбрать общую картину Вашего проекта. Вы можете
также настраивать любые из представлений в зависимости от того, какую информацию Вы хотите
получить. Например, Вы можете использовать разделитель, который находится между таблицей
Ганта и диаграммой Ганта, чтобы отрегулировать размер окон. Перемещение этого разделителя
вправо показывает большее количество колонок данных о вашем проекте в таблице Ганта.
Перемещение разделителя влево увеличивает представляемую диаграмму Ганта.
В дополнение, так же легко как Вы можете изменить пропорции отображения графической
и табличной частей представления, Вы можете изменить масштаб отображаемых данных. Вы
можете увеличить масштаб отображения времени в диаграмме Ганта с помощью кнопки Увеличить
(Zoom In) или уменьшить масштаб отображения времени с помощью кнопки Уменьшить (Zoom
Out). Даже большие многолетние проекты Вы можете настроить для отображения ежедневных
задач, и так же легко перейти к ежемесячному или ежеквартальному отображению данных.
Обратите внимание, что каждый из окон представления Ганта имеет собственную полосу
прокрутки, поэтому Вы должны использовать соответствующую полосу прокрутки для выбора в
соответствующем окне.
5
Новая возможность
Настраивающиеся меню является новой особенностью Microsoft Project 2000.
Вы можете изменить это поведение подобно меню предыдущих версий Project, в которых
все команды появились в меню одновременно после открытия. Чтобы изменить поведение меню
воспользуйтесь диалогом Customize в меню Tools.
Ссылка
Диалог Customize описан подробно в Главе 18.
Некоторые команды и меню Microsoft Project 2000 в верхней части экрана Вам знакомы,
например, Save (Сохранить), Print (Печать) и некоторые другие. Другие команды и меню на панели
инструментов являются специфическими инструментами, характерными только для Project.
6
Рисунок 2-6: После паузы или щелчка на кнопке с двойными стрелками, меню раскрывается
полностью.
В таблице 2-1 переведены и описаны функции каждого меню.
Таблица 2-1
7
Project Просмотр информации о задаче или проекте, просмотр примечаний,
Проект использование команд фильтр и сортировка. Изменение структуры задач в
проекте.
Последние два меню, Окно и Справка, содержат команды для расположения окон и
доступа к справке, соответственно.
Ссылка
См. Главу 3 для получения большей информации об эффективном использовании Справки
в Microsoft Project 2000.
Как Вы видите на Рисунке 2-7, в меню одновременно располагаются иконка, название
команды и сочетание клавиш, для быстрого вызова данной команды с помощью клавиатуры. Этот
способ помогает Вам изучить различные способы выбора команд в Microsoft Project 2000.
Обратите внимание на наличие дополнительного меню, которое иногда называется –
дополнительное меню или каскадное меню. Черный треугольник направленный вправо от команды
указывает на присутствие дополнительного меню.
Панели инструментов
Вероятно, Вы уже знакомы с инструментами в программах Windows и порядок их
расположения на панели инструментов. Когда Вы открываете Microsoft Project 2000, Вы видите две
панели инструментов: Стандартная и Форматирования, как показано на рисунке 2-8.
8
реагируют на щелчок мыши. Это зависит от действий, которые Вы выполняете в данный момент
при работе Microsoft Project 2000.
Примечание
Если Вы производите вставку объекта из другого приложения, например, Excel или
PowerPoint в Ваш проект Вы можете обратить внимание на появление инструментов из этого
приложения при Вы выборе этого объекта. Поэтому, Вы можете использовать инструменты другой
программы, чтобы изменить объект без необходимости выхода из Microsoft Project 2000. Как только
Вы перейдете к работе над проектом, вновь происходит восстановление меню Microsoft Project
2000. Для этого Вы должны произвести щелчок мыши в любом месте Вашего проекта, с тем, чтобы
снять выделение с внедренного объекта.
В дополнение к панели Стандартная и Форматирования, Microsoft Project 2000 содержит
несколько других панелей, которые иногда появляются автоматически, когда Вы выполняете
некоторые типы действий. Однако, Вы можете также показывать каждую из этих панелей в любое
время, выбрав Представление(View) Панель (Toolbars) и выбрать любую необходимую панель
инструментов.
Совет
Эти панели инструментов являются плавающими. Вы легко можете перемещать
плавающие панели по Вашему экрану. Чтобы переместить такую панель Вы должны захватить ее
за строку состояния. Кроме того, Вы можете поставить на якорь любую плавающую панель наверху
вашего экрана около рядом с панелями инструментов, просто отбуксируйте любую плавающую
панель вверх и бросьте на панель инструментов. И наоборот, Вы можете преобразовывать панели
инструментов Стандартная и Форматирования в плавающие панели, отбуксируйте любую из этих
панелей за маркер перемещения в любое место на вашем экране.
9
Рисунок 2-9: Вы можете вводить или редактировать текст в ячейках или в строке информации.
Ссылка
В Главе 4 детально рассмотрены ввод и редактирование текста.
10
Рисунок 2-10: Панель Представлений предлагает несколько предопределенных
представлений Вашего проекта.
Панель Представлений содержит восемь представлений. Когда Вы передвигаетесь вниз
панели Представлений, в верхней части панели появляется стрелка, направленная вверх, чтобы
Вы могли вернуться к вершине панели Представлений. Вы можете переключится в любое из
представлений, щелкнув на этом пункте в панели Представлений. На дне панели Представлений
имеется кнопка More Views. Щелкнув на этой кнопке, Вы получите доступ к диалогу Представлений,
показанному на рисунке 2-11.
11
Рисунок 2-11: Диалог More Views содержит 24 встроенных Представления и позволяет
добавлять Ваши собственные.
Ссылка
В Главе 6, Вы получите исчерпывающую информацию о применении представлений в
вашем проекте. Вы также можете создавать собственные представления, выбрав пункт New в
диалоговом окне More Views (см. Главу 7).
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. Планування проекту.
14
После запуска MS Project 2000 менеджер сразу видит список для ввода задач с
графической схемой проекта (Gantt Chart). Слева находятся переключатели видов списков.
В самом начале составления плана менеджер вводит список этапов, соответствующих
технологии внедрения.
Замечание для опытных пользователей. Как можно заметить, внешний вид MS Project
2000 не претерпел значительных изменений по сравнению с MS Project 98. Из новинок можно
отметить новый вид просмотра проекта Network Diagram, который заменил Pert Chart. Новый
вид позволяет просматривать проекты в виде графической схемы, как ранее в PERT-
диаграммах, при этом добавлена возможность работы с иерархическими задачами, как в
диаграммах Gantt.
Совет. Включите Summary Task для того, чтобы видеть обобщенную статистику по
проекту (общая длительность, трудоемкость, стоимость и т.д.).
Список задач
Ориентируясь на письменное задание, менеджер назначил задачи для всех
технологических этапов.
Меня критикуют
Замечание. "Должны быть типовые фрагменты (подпроекты) – корпоративный
стандарт выполнения стандартных этапов. Тестирование вряд ли сильно отличается для
разных задач и нечего менеджеру каждый раз изобретать велосипед."
Могу только согласится. Шаблоны проектов (project patterns) необходимы. Вопрос
насколько они удачно сделаны. Абстрактно или из успешной практики? Выше тоже
применяется шаблон, состоящий в использовании стандартных технологических этапов.
15
Данный шаблон позволит получить единую статистику по этапам всем проектов, но как
увидим дальше страдает недостатком именно из-за отсутствия выделения подпроектов.
16
Длительность задач
Проанализировав задание, менеджер составил свое представление об их трудоемкости
и ввел эту информацию. При этом менеджер не исходил не столько из квалификации и
количества исполнителей, сколько из своих интуитивных представлений о длительности
этапов. Подобный подход встречается у тех менеджеров, которые не берут на себя заботу об
управлении ресурсами их скорее волнует просто расписание этапов. Последствия такого
подхода мы увидим ниже.
17
Советы и комментарии.
1) Точный срок следует указывать только для задачи "Начало проекта", все
остальные сроки должны быть относительными. Таким образом, вы всегда можете легко
перенести проект на другую дату, все сроки пересчитаются автоматически.
2) Все технологические этапы следует завершать контрольными точками. Дело
в том, что по технологии некий законченный результат может быть получен только в
определенное время, и именно в данный момент следует провести контрольный осмотр
проекта. Жестко и подневно контролировать исполнение отдельных задач часто не имеет
смысла, т.к. исполнителям обычно приходится исполнять задачи не в том порядке, как
указано в плане. Все это не значит, что подневная отчетность не нужна, она нужна в виде
отчетов о затратах рабочего времени, о чем речь пойдет далее.
3) Не используете связи между задачами разного уровня. В этом случае один
технологический этап привязывается к внутренней структуре другого этапа. Это
сковывает свободу модификации планов в рамках отдельных этапов. Если используются
связи только на одном уровне (задача-задача, этап-этап), вы можете без затруднений
изменить состав и последовательность задач внутри некого этапа.
4) Сокращение критического пути проекта за счет преждевременного начала
задач очень рискованно. Сокращайте критический путь за счет подготовительных работ
(обучение, моделирование и т.д.). В нашем случае можно одновременно с постановочными
работами запланировать прототипирование, и за счет этого сократить кодирование и
общую продолжительность проекта. Сокращение критического пути проекта фактически
всегда приводит к увеличению затрат на подготовительные работы. Иными словами,
сокращение длительности проекта, как правило, приводит к повышению его
себестоимости или рисков.
Меня критикуют
Замечание 1. Начало проекта в MS Project нужно отмечать в его свойствах!
Можно и свойством и milestone, последнее мне кажется удобнее, т.к. его можно таскать
мышкой.
Замечание 2. Подневной отчетность может и нужна для некоторых проектов.
18
Все верно, конкретный характер подневной отчетности определяется спецификой
проекта. Для небольших софтверных проектов, подневной отчетности обычно достаточно
как отчет о фактических затратах рабочего времени.
Замечание 3. Связь задач по PMBOK должна быть на нижнем уровне, а вы рекомендуете
делать их на уровне этапов проектов.
PMBOK тут не однозначен, там есть две рекомендации в зависимости от условий.
Связь действительно рекомендуется на нижнем уровне, в тоже время рекомендует разбивать
большой проект на модули и делать связи между модулями.
Ресурсы
После определения состава задач и их сроков менеджер назначает ресурсы для каждой
задачи.
В результате после указания ресурсов менеджер автоматически получает график
работ.
Меня критикуют
Замечание. Неверно – ресурсы определяют сроки, а не наоборот!
Это так, но как я отмечал выше многие менеджеры небольших проектов управляют
сроками, но не берут на себя ресурсный менеджмент. Отдавая дань этому, поставил этап
определения сроков до этапа определения ресурсов. Кроме того, следует учесть, что мы
разбираем пример ведения проекта, недостатки ресурсного менеджмента в данном проекте
будут видны далее.
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. Отслеживание проекта. Управление рисками. Модификация
плана по ходу проекта.
23
Управление рисками
Рассмотрим теорию управления рисками.
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, на котором видно отличие
первоначального плана от фактического исполнения.
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
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. Если заказчик начинает настаивать на выполнении своих ожиданий, нужно
их оформить как дополнительное соглашение к Договору.
Если заказчик согласен, то проблем нет. Однако если есть возможность, заказчик
воспользуется своим правом на трактовку неоднозначных описаний в задании. Это еще раз
подтверждает необходимость измеряемых критериев приемки работ, как средство ухода от
различных толкований задания и потенциального конфликта.
Планирование итеративно, следующие стадии предсказуемы
лишь статистически
Итак, в чем заключаются настоящие проблемы данного проекта? Заказчик раздражен
постоянным удорожанием проекта и спорит о толковании пунктов задания. Таким образом,
разделим мотив и формальную причину.
Как мы видели выше, менеджер (исполнитель) сделал много ошибок в процессе
планирования. Однако нельзя сказать, что вся ответственность за это лежит на нем. Дело в
том, что невозможно было точно предсказать сроки задач в конце проекта без завершения
первых задач. Например, выработка требований может изменить оценку трудоемкости
разработки.
Более правильным является разложить этот большой проект на несколько небольших,
но с гарантированным получением результата. Проблема состоит в том, что Заказчик, как
правило, хочет знать сроки и цену на все сразу, т.к. отдельный этап работ представляется
менее ценным, чем весь проект.
Единственное, что может сделать опытный менеджер в данном случае, это четко
спланировать ближайший этап, а остальные определить статистически. Как видно из выше
изложенного, статистика с учетом косвенных работ поражает воображение своей
трудоемкостью на фоне иллюзии простоты.
Заказчик, получив большие статистически оценки, требует составить план работ из
конкретных задач и начинает убирать оттуда "завышенные" и "ненужные" работы.
Если это произошло, проект обречен на потерю контроля.
В нашем случае проблема заключалась в том, что менеджер пытался сделать все в
рамках одного проекта и статистические оценки стал применять только уже по ходу проекта.
32
реализована никогда. Однако заказчик получит не идеальный, но пригодный к эксплуатации
продукт, возможно лучший продукт из возможных в данное время.
Формальное закрытие проекта
Сравним формальное закрытие проекта с проектом "без конца".
Проект с формальным завершением обладает очень высокой предсказуемостью и
управляемостью.
Можно достаточно точно определить бюджет и сроки проекта. Формальный проект
повышает ответственность сторон, все ожидания и соглашения документированы.
Проект без формального ведения обычно мало управляем по срокам и бюджету. Если
формализованный проект подвержен значительному риску на этапе постановки, то
неформальный проект, в силу неопределенности задач, подвержен риску на всем протяжении.
Тем не менее, многие предпочитают неформальное ведение проектов. Этот
объясняется влиянием политических рисков. Формальный проект позволяет установить
ответственность, и эта ответственность часто пугает как исполнителя проекта, так и
заказчика. За неудачу формального проекта несут ответственность в равной степени и
Исполнитель, и Заказчик. Оба подписались под требованиями к проекту и взяли на себя
ответственность, причем эта ответственность носит личный характер.
Обычно ситуация безответственности не устраивает только топ-менеджеров, именно
они и могут своим волевым решением привести ситуацию в норму. Оптимально, если это
происходит до начала проекта, а не по ходу его.
В нашем случае, менеджер на встрече с топ-менежером заказчика добился решения об
измеряемых критериях завершения проекта.
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.
35
В стандарте ANSI по управлению проектами (PMBoK) требования по управлению
рисками отражены в следующих разделах
Планирование управления рисками (PMBoK 11.1)
Идентификация рисков (PMBoK 11.2)
Качественный анализ рисков (PMBoK 11.3)
Количественный анализ рисков (PMBoK 11.4)
Планирование ответных действий на риски (PMBoK 11.5)
Отслеживание рисков (PMBoK 11.6)
36
Еще раз отметим, что системы управления рисками требуют тщательной
методической подготовки и тренингов. Тренинги по управлению рисками на базе
системы Microsoft Project можно заказать по адресу info@microsoftproject.ru
(программы на сайте). Управление рисками самый не интуитивный вид проектного
менеджмента.
Что такое Деревья Решений?
Дерево решений (Decision Tree) - это древовидная структура позволяющая
проанализировать различные варианты воздействий или принятий решений на конечный
результат, например возникновение риска с тяжелыми последствиями.
Простейшее использование анализа методом Деревьев Решений (Decision Tree
Analysis) состоит в создании дерева возможных решений вручную и максимум
полуавтоматический расчет показателей по каждому возможному варианту в дереве.
Профессиональные аналитические системы Microsoft и SAS идут дальше, сама
система разрабатывает дерево решений используя предыдущий опыт ведения проектов.
Хотя для пользователя это выглядит достаточно просто, внутри работает фантастически
сложная аналитическая система, которая ищет корреляции, т.е. закономерности в данных и
по ним конструирует реальную картину принятия решений и воздействий, а не как то
кажется или даже планируется менеджерами.
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), но более важные средства рискового моделирования "а что если?"
могут отсутствовать полностью или находится в зачаточном состоянии.
Тем не менее, нельзя не отметить, что некоторые частные решения в управлении
рисками достаточно удачны. Например, различные реализации трендов, для отслеживания
влияния выявленных тенденций в будущем.
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. Висновки.
42