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

Форма занятия – лабораторная работа с использованием компьютера.

Продолжительность – четыре академических часа.

3.2.1. Пример планирования работ проекта

Настройка окна проекта

• Запустить Microsoft Project 2007.
• Поместить в рабочем окне системы панель представлений – пункт меню меню Вид/ Панель представлений . Вид окна после настройки изображен на рис. 3.1 .

Сохранение проекта в файл

• Пункт меню Файл/Сохранить .
• Откроется диалог сохранения файла, в котором необходимо выбрать папку для сохранения проекта и указать имя проекта РазработкаПрограммы .
• Нажать кнопку Сохранить .
• Закрыть файл проекта нажав мышкой крестик в верхнем правом углу окна на рис. 3.18 .

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

Рис. 3.18.

Открытие созданного файла проекта

• Выбрать пункт меню Файл/Открыть .
• В появившемся диалоге открытия файла найти папку, в которой расположен проект.
• Среди проектов, сохраненных в выбранной папке, найти нужный файл (РазработкаПрограммы.mpp ), выделить его и нажать кнопку Открыть (тот же результат достигается двойным щелчком мыши по имени файла).

Настройка календаря

• Открыть окно изменения рабочего времени – Сервис/Изменить рабочее время .
• Для календаря Стандартный (открывается по умолчанию) выбрать вкладку Исключения .
• В поле Название первой пустой строки таблицы ввести День согласия и примирения .
• Щелчок мышью в поле Начало этой же строки – в этом поле появится кнопка выбора.
• Нажать эту кнопку выбора – откроется календарик.
• Выбрать в календарике ноябрь 2009г и дважды щелкнуть мышью по дате 4 ноября – установится выбранная дата начала исключения. По умолчанию устанавливается такая же дата окончания исключения и исключение считается нерабочими днями.
• Аналогично добавить исключение Новогодние праздники, начинающееся 31.12.09 и заканчивающееся 10.01.10. Итоговый вид окна после всех преобразований изображен на рис. 3.19.

Ввод перечня задач проекта

• Составить список задач проекта, содержащий вехи, фазы и обычные задачи. Расположить задачи таким образом, чтобы их порядок соответствовал последовательности выполнения, а после каждой фазы должны быть перечислены входящие в нее вехи и задачи. Для создаваемого проекта РазработкаПрограммы список задач приведен в табл.3.3 .
• Открыть файл проекта. Щелчком мыши выбрать на панели представлений Диаграмма Ганта .
• В столбец Название задачи последовательно ввести названия задач из табл.3.3 . По умолчанию все введенные задачи являются обычными задачами длительностью 1 день. На диаграмме Ганта они изображены отрезками синего цвета. Знак вопроса в столбце Длительность означает, что она не была задана пользователем и является предварительной.
• В столбце Длительность установить для вех длительность в 0 дней. Результат – на диаграмме Ганта эти задачи изображены ромбиками. Результат ввода задач проекта изображен на рис. 3.20 .

Преобразование задачи в фазу

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

• Удерживая нажатой левую кнопку мыши в области номеров задач, выделить строки задач с номерами 3 – 8.
• Нажать кнопку (на уровень ниже) на панели инструментов Форматирование . Результат – выделенные задачи становятся подзадачами, входящими в Программирование , а само Программирование – фазой, т.е. составной задачей. На диаграмме Ганта фаза изображается отрезком в виде горизонтальной скобки.
• Выделить задачи с номерами 10 – 13.
• Нажать кнопку. Отладка становится фазой, а выделенные задачи – ее подзадачами. Результат совпадает с изображением на рис. 3.20 .

Создание связи при помощи мыши

• Навести мышь на ромбик вехи Начало проекта .
• Удерживая нажатой левую кнопку мыши переместить указатель на отрезок задачи Постановка задачи .
• Отпустить левую кнопку. Результат – между задачами создается связь, которая указывает что задача Постановка задачи следует за вехой Начало проекта . Эта связь изображается на диаграмме Ганта в виде стрелки.

Создание связи в окне сведений о задаче

Создание связи при помощи столбца Предшественники

Создание остальных связей проекта Разработка Программы

Используя рассмотренные выше методы создать остальные связи проекта в соответствии с табл.3.5 .

Таблица 3.5.

№	Название	Предшественники	Длительность
1	Начало реализации проекта		-
2	Программирование		-
3	Постановка задачи	1	10
4	Разработка интерфейса	3	5
5	Разработка модулей обработки данных	4	7
6	Разработка структуры базы данных	3	6
7	Заполнение базы данных	6	8
8	Программирование завершено	5;7	-
9	Отладка		-
10	Отладка программного комплекса	8	5
11	Тестирование и исправление ошибок	10	10
12	Составление программной документации	10	5
13	Отладка завершена	11;12	-
14	Конец проекта	13	-

Типы связей, задержки, опережения и ограничения

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

хорошую работу на сайт">

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

• Введение
• 1. Организация проекта
• 1.3 Создание графика работ
• Заключение

Введение

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

За короткий срок информационные системы прошли развитие от вычислительных систем, применяемых в научных исследованиях и АСУ крупных предприятий до комплексных автоматизированных информационных систем, позволяющих реализовать весь спектр не только обработки, накопления информации, но и управления компаниями, организациями на всех уровнях.

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

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

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

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

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

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

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

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

1. Организация проекта

1.1 Создание проекта в программе Microsoft Project

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

Рисунок 1 - Создание нового проекта

Теперь можно выбрать способ создания нового проекта:

ѕ выбрать "Новый проект" и нажать команду "Создать": проект будет создан на основе шаблона Global. mpt;

ѕ создать новый проект из существующего документа - проекта, книги Excel или списка задач SharePoint;

ѕ создать на основе шаблона. Шаблон можно выбрать из имеющихся на компьютере или на сайте Office.com (при наличии подключения к интернету).

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

Рисунок 2 - Сохранение файла проекта

Microsoft Project 2016 поддерживает экспорт в формат PDF и XPS.

Portable Document Format (PDF) - это электронный формат с постоянной разметкой, который сохраняет форматирование документа и допускает совместное использование файла. Формат PDF гарантирует, что при просмотре файла в интерактивном режиме и при его печати будет сохранен исходный формат и данные файла нельзя будет легко изменить. Формат PDF также полезен при печати документов в типографии.

XML Paper Specification (XPS). XPS является электронным форматом файла, сохраняющим форматирование документов и обеспечивающим совместную работу с файлом. Формат XPS гарантирует, что при просмотре файла в интерактивном режиме и при его печати будет сохранен исходный формат и данные файла нельзя будет легко изменить.

1.2 Создание календаря проекта в программе Microsoft Project

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

Microsoft Project использует три типа календарей:

1. календарь проекта определяет рабочее время по умолчанию для всего проекта (для всех ресурсов и задач проекта);

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

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

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

В качестве календарей проекта и задач, а также в качестве основы календарей ресурсов используются базовые календари. Microsoft Project имеет три базовых календаря:

1. Стандартный: рабочее время с понедельника по пятницу (с 9: 00 до 13: 00 и с 14: 00 до 18: 00). Этот календарь используется по умолчанию при создании нового проекта;

2. 24 часа: нерабочее время отсутствует;

3. Ночная смена: ночная смена с ночи понедельника по утро субботы (с 23: 00 до 8: 00 с часовым перерывом).

Microsoft Project поддерживает создание своих базовых календарей, если имеющиеся календари не соответствуют требованиям проекта.

Рисунок 3 - Создание календаря

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

Рисунок 4 - Назначение созданного базового календаря

1.3 Создание графика работ

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

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

Порядок выполнения работы:

1) Редактирование начальных параметров проекта.

Для редактирования начальных параметров проекта, нужно перейти на вкладку "Проект" и нажать кнопку "Сведения о проекте", и в открывшемся окне определите дату начала работ (Вт 05.04.16).

Рисунок 5 - Дата начала работ

2) Создание перечня задач проекта и их продолжительность

Определение целей разработки ПО - 2дн.

Планирование разработки - 4дн.

Назначение кода темы - 3дн.

Выбор принципов разработки ПО - 24дн.

Выяснение основных требований к ПО - 20дн.

Формирование проекта ТЗ - 7дн.

Согласование проекта ТЗ с заказчиком ПО - 5дн.

Формирование структурной модели - 7дн.

Формирование объектно-ориентированной модели - 30дн.

Определение принципов построения экранного интерфейса - 35дн.

Разработка основных модулей - 50дн.

Разработка базы данных - 48дн.

Интеграция всех модулей - 35дн.

Проведение отладки - 5дн.

Выпуск бета-версии - 2дн.

Сбор сведений о результатах тестирования - 5дн.

Доработка модулей и БД - 7дн.

Выпуск финальной версии - 5дн.

Формирование необходимой для сертификации документации - 5дн.

Внутренний аудит процесса создания ПО - 2дн.

Заключение договора на сертификацию - 2дн.

Проведение сертификации ПО - 2дн.

3) Создание перечня ресурсов

- 1чел.

Программист - 5чел.

Экономист - 1чел.

Аудитор ПО - 1чел.

4) Создание назначений (связей)

Зависимость задач и ресурсов приведем в таблице.

Таблица 1 - Зависимость задач

Название задачи	Длительность		Окончание	Предшественники	Названия ресурсов
Разработка программного средства
Организация работ
Определение целей разработки ПО					Начальник отдела разработки ПО
Планирование разработки					Начальник отдела разработки ПО
Назначение кода темы					Экономист
Выбор принципов разработки ПО					Начальник отдела разработки ПО
Разработка ТЗ
Выяснение основных требований к ПО					Начальник отдела разработки ПО ; Программист 1
Формирование проекта ТЗ					Программист 2
Согласование проекта ТЗ с заказчиком ПО					Начальник отдела разработки ПО; Программист 2
Разработка ПО
Формирование структурной модели					Программист 3; Программист 4
Формирование объектно-ориентированной модели					Программист 1 ; Программист 4 ; Программист 5
Определение принципов построения экранного интерфейса					Начальник отдела разработки ПО; Программист 4
Разработка основных модулей					Программист 1 ; Программист 2 ; Программист 3 ; Программист 4 ; Программист 5
Разработка базы данных					Программист 1
Интеграция всех модулей					Программист 2 ; Программист 3 ; Программист 4
Отладка и испытания
Проведение отладки					Программист 3; Программист 4; Программист 5
Выпуск бета-версии					Программист 1
Сбор сведений о результатах тестирования					Программист 2; Программист 3
Доработка модулей и БД					Программист 2; Программист 4; Программист 5
Выпуск финальной версии					Программист 1
Сертификация
Формирование необходимой для сертификации документации					Программист 4; Программист 5; Программист 1
Внутренний аудит процесса создания ПО					Аудитор ПО
Заключение договора на сертификацию					Начальник отдела разработки ПО
Проведение сертификации ПО					Начальник отдела разработки ПО

При помощи видов связей (назначений) создадим диаграмму Гантта в соответствии с таблицей 1.

Рисунок 6 - Диаграмма Гантта

1.2 Формирование структуры графика работ

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

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

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

Сгруппируем работы по этапам и введём названия этих этапов.

ѕ Для создания группы (этапа) нажмём правой клавишей мыши на первой строке таблицы и из контекстного меню выберем "Вставить задачу";

ѕ Называем её "Организация работ";

ѕ Выделим работы: "Определение целей разработки ПО", "Планирование разработки", "Назначение кода темы" и "Выбор принципов разработки ПО" и сгруппируем их, нажав на кнопку "Понизить уровень задачи".

Аналогичным способом нужно сгруппировать все последующие задачи, для создания следующих этапов: "Разработка ТЗ", "Разработка ПО", "Отладка и испытания", "Сертификация".

Завершающим этапом будет создание группы "Разработка программного средства", которая сгруппирует все выше созданные этапы.

Рисунок 7 - Иерархическая структура проекта

Так же данную задачу можно решить нисходящим методом.

В нисходящем методе планирования проекта сначала определяются основные этапы, которые затем разбиваются на отдельные задачи.

2. Назначения ресурсов проектов

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

Для назначения ресурсов непосредственно при описании задачи необходимо:

ѕ Открыть окно "Сведения о задаче" для этого необходимо два раза нажать на названии задачи или выделить задачу и нажать на кнопку "Сведения" на закладке "Задача";

ѕ В открывшемся окне "Сведения о задаче" перейти на закладку "Ресурсы";

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

ѕ В поле "Владелец" выводится имя пользователя владельца ресурса, которому будет отправляться согласование использования данного ресурса. Для всех локальных и универсальных ресурсов это поле пустое;

ѕ В поле "Единицы" ввести объем необходимого ресурса. Если ресурс трудовой необходимо указать процент времени ресурса, которое он будет тратить на реализации данной задачи. Если материальный ресурс ввести его количество в размерности указанной в представлении "Лист ресурсов". Если затратный ресурс ничего не вводить;

ѕ В поле "Затраты" будет выведено стоимость использования данного ресурса. Для трудовых и материальных ресурсов данное значение будет подсчитано автоматически при нажатии кнопки "ОК". Для затратных ресурсов необходимо указать сумму которую планируете потратить на реализацию данной задачи этим ресурсом.

Рисунок 8 - Назначение ресурсов при описании задачи

Назначение ресурса задаче:

ѕ Перейти в представление диаграмма Гантта и перейти на страницу "Ресурсы";

ѕ Выберите задачу, которой нужно создать назначение ресурса;

ѕ Нажать на кнопку "Назначить ресурсы". Появится соответствующее диалоговое окно;

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

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

Результат выполнения показан на рисунке 8.

3. Отслеживание хода выполнения проекта

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

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

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

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

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

Чтобы отследить ход выполнения работ, нужно создать отметку о прохождении этапа "Определение целей разработки ПО". Для этого на диаграмме Гантта подведём указатель мыши к левой части графика (указатель поменяет свой вид на знак процента со стрелкой вправо). После чего нужно нажать левую клавишу мыши и не отпуская её потянуть указатель мыши вправо.

Рисунок 9 - Отметка о прохождении этапа "Определение целей разработки ПО"

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

Рисунок 10 - Отметка о прохождении этапа "Планирование разработки"

Слева таблицы диаграммы Гантта появится отметка о завершении этапа, а на самой диаграмме появится темно-синяя полоса, которая показывает процент завершения этапа работ. Если работа выполнена на 100%, то полоса будет от начала до конца блока работ.

Рисунок 11 - Пример выполнения работ на 70%

На рисунке 11 показан пример не полного выполнения работ, на котором видно, что на диаграмме Гантта темно-синяя полоса не до конца блока работ (правый нижний угол). Всё что было проделано до этого было бы бесполезно, если в программе Microsoft Project не было возможности сформировать отчеты. "Обзор проекта" - отчет показывающий процентное завершение проекта. Для его формирования нужно зайти на вкладку "Отчет", нажать на кнопку "Панели мониторинга" и выбрать "Обзор проекта".

Рисунок 12 - Обзор проекта

"Обзор затрат" - более полный отчет показывающий и процентное завершение работ, и денежные затраты (как уже потраченные, так и оставшиеся затраты).

Рисунок 13 - Обзор затрат

"Критические задачи" - отчет представляющий пользователю возможность увидеть оставшиеся критические задачи. Критические задачи - задачи от выполнения которых зависит весь проект.

Рисунок 14 - Критические задачи

Заключение

Microsoft Project является наиболее популярным инструментом управления проектами, предоставленным компанией Microsoft. Приложение разработано для предоставления помощи руководителям проектов при разработке планов, назначении ресурсов для выполнения задач, управления бюджетов и анализа загруженности.

Microsoft Project может помочь в создании плана на основе критического пути. Графики также могут быть применены для равномерного распределения запросов на ресурс. Критический путь представлен в виде диаграммы Гантта (Gantt chart).

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

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

Microsoft Project создает бюджеты на основе показателей ресурсов и назначаемой работы. Поскольку ресурсы назначаются заданиям, и эта работа оценивается, Microsoft Project подсчитывает затраты, которые равны работе помноженной на показатели. Это все подсчитывается в общий уровень задания, затем к общим затратам на задания и в конце к общим подсчетам проекта.

проект программа управленческое решение

Список использованных источников

Размещено на Allbest.ru

1. Беляева С.А. Роль планирования в процессе управления инновационными проектами // Организатор производства. - 2010

2. Бетанова И. Роль HR в управлении проектами // Справочник по управлению персоналом. - 2011.

3. Бетанова И. Роль HR в управлении проектами // Справочник по управлению персоналом. - 2011.

4. Ганчин В.В. Роль проектного управления в инновационном развитии электроэнергетики в Российской Федерации // Экономика и управление: рос. науч. журн. - 2011.

5. Гончаренко С. Управление проектами // Управление качеством. - 2011.

6. Емельянов Ю. Управление инновационными проектами в компании // Проблемы теории и практики управления. - 2011.

7. Ивасенко А.Г. Управление проектами: учебное пособие для студентов. - Ростов н/Д.: Феникс, 2009.

8. Конференции ПМСОФТ по управлению проектами // Проблемы теории и практики управления. - 2011.

9. Кузнецов А.А. Процессное управление проектами на предприятии // Менеджмент сегодня. - 2011.

10. Куперштейн В. Microsoft Project 2010 в управлении проектами. - СПб: БХВ-Петербург, 2011.

11. Лапыгин Ю.Н. Оценка эффективности проектного управления // Экономический анализ: теория и практика. - 2011.

12. Мазур И.И. Управление инвестиционно-строительными проектами: международный подход. - М.: Омега-Л, 2011.

13. Матвеева Л.Г. Управление проектами: учебник. - Ростов н/Д.: Феникс, 2009.

14. Мыльников Л.А. Микроэкономические проблемы управления инновационными проектами // Проблемы управления. - 2011.

Подобные документы

Составление плана проекта создания нового предприятия по производству автомобилей. Создание базы данных по ресурсам в программе Project Expert. Применение методики PERT для анализа проекта. Контроль выполнения задач проекта по срокам и трудозатратам.

курсовая работа , добавлен 11.10.2014


Методы управления сложными проектами. Редактирование свойств проекта. Настройка календаря проекта. Создание задач в Microsoft Project и изменение их свойств. Выбор свободных ресурсов и их использование. Составление сводки по проекту и отчета о бюджете.

лабораторная работа , добавлен 01.03.2015


Настройка параметров программы Microsoft Project. Таблицы как основные средства хранения данных в MS Project. Подготовка к составлению плана и отслеживание хода работ по нему. Форматирование диаграмм Ганта. Набор функций для работы с сетевым графиком.

практическая работа , добавлен 25.12.2010


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

контрольная работа , добавлен 02.06.2010


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

курсовая работа , добавлен 23.01.2011


Использование MS Project для определения критического пути проекта. Задачи транспортной логистики. Разработка модели формирования затрат и доходов проекта. Расчет затрат, связанных с внедрением базы данных. Создание оптимальных условий труда оператора.

курсовая работа , добавлен 21.04.2013


Выбор структуры, обзор различных вариантов создания нового проекта. Управление поведением MS Project 2007 при запуске. Создание нового проекта на основе шаблона. Список стандартных шаблонов. Установка общих параметров проекта, параметров планирования.

презентация , добавлен 15.03.2014


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

презентация , добавлен 15.03.2014


Назначение, создание современной информационно-аналитической системы. Формирование рабочей документации в среде Microsoft Project. Расчет длительности проекта методом Монте-Карло. Моделирование типов связи. Проектирование интерфейсов пользователя.

курсовая работа , добавлен 16.12.2014


Оценка стоимости проекта с помощью функции Microsoft Project на примере создания технорабочего проекта комплекса задач "Управление качеством продукции и услуг". Назначение и условия применения программы, ее характеристика и руководство пользователя.

• Tutorial

Небольшое введение

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

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

Перед началом проекта

Перед началом проекта от руководителя проекта обычно требуется ответить на два вопроса:

1. сколько проект займет времени
2. сколько проект будет стоить

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

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

В процессе выполнения проекта

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

При завершении проекта

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

Что умеет MS Project

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

Разберем вкратце свойства сущностей.

Задача имеет длительность, объем, назначенный ресурс и еще чертову уйму различных свойств. Если встроенных свойств не хватает, можно добавить свои - этим мы потом воспользуемся. Задачи могут быть связаны между собой различными отношениями (предшественники, последователи и т.п.).

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

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

Как это использовать

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

Подготовка плана

Итак, перед нами лежит техническое задание, и требуется дать ответ на три вопроса:

1. Сколько времени займет этот проект?
2. Сколько (и каких) специалистов для этого потребуется?
3. Какие примерно трудозатраты ожидаются по этому проекту?

Для этого мы готовим прикидочный план выполнения проекта в MS Project. Т.е. просто последовательно выписываем задачи, которые необходимо выполнить. Методика превращения техзадания в набор задач - это отдельная история, я не буду на ней сейчас останавливаться.
Подготовка плана выполняется в несколько этапов:

1. Готовим список задач
2. Выставляем зависимости между задачами
   (результат какой задачи необходим для перехода к следующей?).
3. Назначаем исполнителей задач
4. Выравниваем загрузку ресурсов
5. Балансируем то, что получилось

При подготовке плана придерживаемся следующих рекомендаций:

1. Не используем суммарные задачи для декомпозиции.
   Все задачи помещаем в один линейный список. Сначала это может показаться неудобным,
   но зато избавляет от многих проблем в дальнейшем. Для управления структурой задач
   используем настраиваемые поля (см.ниже).
2. Очень часто для управления зависимостями задач используют Drag&Drop. Когда задач много это быстро становится неудобно. Я рекомендую в этом случае не использовать перетаскивание, а явное указывать номера задач-предшественников. для этого можно добавить в таблицу столбец «предшественники» и вписывать номера задач вручную.
3. Срок каждой задачи не должен превышать двух недель.
   Если срок задачи превышает неделю - это уже повод задуматься о её декомпозиции. Я придерживался очень простой методики оценки: примитивная задача - 2 дня, средней
   сложности - 1 неделя, сложная задача - 2 недели. При этом сложных задач не должно быть много. Такой подход дает возможность подготовить оценочный план довольно быстро.
   С одной стороны, полученная оценка, конечно, не будет точной, но, с другой стороны - а какая из них точная? По опытку практического применения могу сказать, что на
   больших проектах погрешности оценок отдельных задач обычно нивелируются, а на малых часто можно (и нужно!) использовать и более точные оценки.
4. Всеми силами избегаем задач, у которых несколько исполнителей. Для каждой задачи должен быть назначен только один исполнитель. Двух исполнителей имеет смысл назначать
   только если они действительно работают вдвоем (например, вы практикуете парное программирование). В прочих случаях лучше декомпозировать задачу.
5. При назначении исполнителей руководствуемся их профессией и квалификацией, пока не беспокоясь о равномерности загрузки.
6. Используем суммарные задачи для разделения задач на этапы. Ставим зависимости между этапами, чтобы они шли последовательно. Разделение на этапы пока достаточно приблизительное.

Балансировка проекта

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

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

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

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

1. Сменить исполнителя задачи.

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

2. Перенести задачу в другой этап.

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

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

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

Учет рисков

Теперь - последний штрих: учет рисков. Честно признаюсь, я не занимался серьезным управлением рисками, но учитываю возможность возникновения определенных форсмажоров (таких как болезни исполнителей, забытые работы и т.п.). Для этого я добавляю в каждый этап фиктивную задачу с минимальным приоритетом, под названием «прочие работы» для каждого ресурса. После выравнивания ресурсов эти задачи оказываются в конце этапа. Длительность этих задач зависит от вероятности возникновения и степени вляния рисков, она зависит от способа определения оценок длительностей задач, здоровья членов команды и степени паранойи руководителя проекта. Обычно я выставлял длительность «прочих работ» примерно от трети до четверти длины этапа.

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

С этим планом мы можем:

1. Назвать сроки выполнения проекта и его этапов. Аргументированно и с высокой степенью
   достоверности.
2. Оценить примерные трудозатраты по проекту

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

Работа с планом

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

1. Выдавать задания исполнителями
2. Отмечать выполненные задания в плане
3. Корректировать план в случае значительных отклонений

Выдача заданий исполнителями может выполняться по разному. Можно разбить выполнение на короткие итерации, формировать пул задач на итерацию и по окончании итерации отмечать результаты. Можно сразу озвучить лнителям набор задач на этап, выдать каждому по экземпляру диаграммы Ганта и периодически опрашивать о прогрессе. Можно использовать интеграцию MS Project и TFS и загрузить проект непосредственно в TFS. Суть не в средствах. Главное - это регулярное обновление плана . Я делаю это примерно раз-два в неделю. Это дает возможность достаточно быстро увидеть проблемные участки.
Для определения проблемного участка удобно использовать различные группировки - по исполнителями, по компонентам и др. Часто может оказаться, что проект в целом идет даже с опережением, но в определенном разрезе наблюдается отставание, например один из разработчиков неожиданно уткнулся в серьезную системную проблему, которая привела к отклонениями. Использование только средней метрики не покажет этой проблемы - она всплывет только в конце этапа, когда что либо делать будет уже поздно.

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

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

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

Я категорически рекомендую не использовать суммарные задачи в MS Project для функциональной декомпозиции или категоризации задач. Дело в том, что иерархия задач в MS Project сильно завязана на их последовательность. А часто хочется посмотреть на задачи в разной последовательности, при этом вся структура «рассыпается». Для управления структурой задач я рекомендую использовать Пользовательские поля . MS Project имеет предопределенный набор полей с неопределенным заранее поведением, которые мы можем использовать так, как нам удобно. Например, для разбивки задач по компонентам нужно на основе текстового поля Текст1 создать поле Компонент и задать для него список значений, соответствующий компонентам системы.

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

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

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

Завершение проекта

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

Заключение

Я попытался обобщить свой опыт использования MS Project для практического решения задач, которые возникали передо мной, когда я руководил проектами по разработке ПО. Описанная методика не претендует не универсальность, но она, как мне кажется, достаточно проста и логична, при этом позволяет решать практические задачи руководителя проекта.
Использование этого подхода позволило мне успешно и в срок завершить не один проект.
Правда, случались и сбои. Это происходило, как правило, тогда, когда плохо была проведена подготовительная часть проекта, а именно - постановка задачи. Т.е. в результате проекта получалось не совсем то, что требовалось, а понимание этого приходило слишком поздно.

Наверняка я что-то упустил, не стесняйтесь задавать вопросы.

• Tutorial

Небольшое введение

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

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

Перед началом проекта

Перед началом проекта от руководителя проекта обычно требуется ответить на два вопроса:

1. сколько проект займет времени
2. сколько проект будет стоить

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

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

В процессе выполнения проекта

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

При завершении проекта

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

Что умеет MS Project

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

Разберем вкратце свойства сущностей.

Задача имеет длительность, объем, назначенный ресурс и еще чертову уйму различных свойств. Если встроенных свойств не хватает, можно добавить свои - этим мы потом воспользуемся. Задачи могут быть связаны между собой различными отношениями (предшественники, последователи и т.п.).

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

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

Как это использовать

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

Подготовка плана

Итак, перед нами лежит техническое задание, и требуется дать ответ на три вопроса:

1. Сколько времени займет этот проект?
2. Сколько (и каких) специалистов для этого потребуется?
3. Какие примерно трудозатраты ожидаются по этому проекту?

Для этого мы готовим прикидочный план выполнения проекта в MS Project. Т.е. просто последовательно выписываем задачи, которые необходимо выполнить. Методика превращения техзадания в набор задач - это отдельная история, я не буду на ней сейчас останавливаться.
Подготовка плана выполняется в несколько этапов:

1. Готовим список задач
2. Выставляем зависимости между задачами
   (результат какой задачи необходим для перехода к следующей?).
3. Назначаем исполнителей задач
4. Выравниваем загрузку ресурсов
5. Балансируем то, что получилось

При подготовке плана придерживаемся следующих рекомендаций:

1. Не используем суммарные задачи для декомпозиции.
   Все задачи помещаем в один линейный список. Сначала это может показаться неудобным,
   но зато избавляет от многих проблем в дальнейшем. Для управления структурой задач
   используем настраиваемые поля (см.ниже).
2. Очень часто для управления зависимостями задач используют Drag&Drop. Когда задач много это быстро становится неудобно. Я рекомендую в этом случае не использовать перетаскивание, а явное указывать номера задач-предшественников. для этого можно добавить в таблицу столбец «предшественники» и вписывать номера задач вручную.
3. Срок каждой задачи не должен превышать двух недель.
   Если срок задачи превышает неделю - это уже повод задуматься о её декомпозиции. Я придерживался очень простой методики оценки: примитивная задача - 2 дня, средней
   сложности - 1 неделя, сложная задача - 2 недели. При этом сложных задач не должно быть много. Такой подход дает возможность подготовить оценочный план довольно быстро.
   С одной стороны, полученная оценка, конечно, не будет точной, но, с другой стороны - а какая из них точная? По опытку практического применения могу сказать, что на
   больших проектах погрешности оценок отдельных задач обычно нивелируются, а на малых часто можно (и нужно!) использовать и более точные оценки.
4. Всеми силами избегаем задач, у которых несколько исполнителей. Для каждой задачи должен быть назначен только один исполнитель. Двух исполнителей имеет смысл назначать
   только если они действительно работают вдвоем (например, вы практикуете парное программирование). В прочих случаях лучше декомпозировать задачу.
5. При назначении исполнителей руководствуемся их профессией и квалификацией, пока не беспокоясь о равномерности загрузки.
6. Используем суммарные задачи для разделения задач на этапы. Ставим зависимости между этапами, чтобы они шли последовательно. Разделение на этапы пока достаточно приблизительное.

Балансировка проекта

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

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

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

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

1. Сменить исполнителя задачи.

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

2. Перенести задачу в другой этап.

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

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

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

Учет рисков

Теперь - последний штрих: учет рисков. Честно признаюсь, я не занимался серьезным управлением рисками, но учитываю возможность возникновения определенных форсмажоров (таких как болезни исполнителей, забытые работы и т.п.). Для этого я добавляю в каждый этап фиктивную задачу с минимальным приоритетом, под названием «прочие работы» для каждого ресурса. После выравнивания ресурсов эти задачи оказываются в конце этапа. Длительность этих задач зависит от вероятности возникновения и степени вляния рисков, она зависит от способа определения оценок длительностей задач, здоровья членов команды и степени паранойи руководителя проекта. Обычно я выставлял длительность «прочих работ» примерно от трети до четверти длины этапа.

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

С этим планом мы можем:

1. Назвать сроки выполнения проекта и его этапов. Аргументированно и с высокой степенью
   достоверности.
2. Оценить примерные трудозатраты по проекту

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

Работа с планом

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

1. Выдавать задания исполнителями
2. Отмечать выполненные задания в плане
3. Корректировать план в случае значительных отклонений

Выдача заданий исполнителями может выполняться по разному. Можно разбить выполнение на короткие итерации, формировать пул задач на итерацию и по окончании итерации отмечать результаты. Можно сразу озвучить лнителям набор задач на этап, выдать каждому по экземпляру диаграммы Ганта и периодически опрашивать о прогрессе. Можно использовать интеграцию MS Project и TFS и загрузить проект непосредственно в TFS. Суть не в средствах. Главное - это регулярное обновление плана . Я делаю это примерно раз-два в неделю. Это дает возможность достаточно быстро увидеть проблемные участки.
Для определения проблемного участка удобно использовать различные группировки - по исполнителями, по компонентам и др. Часто может оказаться, что проект в целом идет даже с опережением, но в определенном разрезе наблюдается отставание, например один из разработчиков неожиданно уткнулся в серьезную системную проблему, которая привела к отклонениями. Использование только средней метрики не покажет этой проблемы - она всплывет только в конце этапа, когда что либо делать будет уже поздно.

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

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

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

Я категорически рекомендую не использовать суммарные задачи в MS Project для функциональной декомпозиции или категоризации задач. Дело в том, что иерархия задач в MS Project сильно завязана на их последовательность. А часто хочется посмотреть на задачи в разной последовательности, при этом вся структура «рассыпается». Для управления структурой задач я рекомендую использовать Пользовательские поля . MS Project имеет предопределенный набор полей с неопределенным заранее поведением, которые мы можем использовать так, как нам удобно. Например, для разбивки задач по компонентам нужно на основе текстового поля Текст1 создать поле Компонент и задать для него список значений, соответствующий компонентам системы.

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

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

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

Завершение проекта

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

Заключение

Я попытался обобщить свой опыт использования MS Project для практического решения задач, которые возникали передо мной, когда я руководил проектами по разработке ПО. Описанная методика не претендует не универсальность, но она, как мне кажется, достаточно проста и логична, при этом позволяет решать практические задачи руководителя проекта.
Использование этого подхода позволило мне успешно и в срок завершить не один проект.
Правда, случались и сбои. Это происходило, как правило, тогда, когда плохо была проведена подготовительная часть проекта, а именно - постановка задачи. Т.е. в результате проекта получалось не совсем то, что требовалось, а понимание этого приходило слишком поздно.

Наверняка я что-то упустил, не стесняйтесь задавать вопросы.

Статья Алексея Просницкого, РМР, MVP (Компания Leo Consulting), первоначально опубликованная .

Данная статья посвящена рабочим процессам планирования и исполнения работ по проектам в проектных институтах и инструментам для автоматизации этих процессов (Microsoft Project Server / Microsoft Project Pro + PlanBridge).

Рабочий процесс планирования работ по проекту в проектной организации выглядит примерно так, как показано на Рисунке 1 .

Рисунок 1. Возможный рабочий процесс планирования проекта в проектной организации*

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

Примечание 2 - Конечно, в каждой проектной организации схема взаимодействия может быть отличной от приведенной. Например, длительность разработки одного раздела, определяется за 1 раз, если это только не суперсложный проект, которых в общем объеме очень мало.

Как видно из Рисунка 1 , планирование проекта может происходить не одним человеком, а несколькими.

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

На Рисунке 2 изображен возможный рабочий процесс отчетности и отслеживания проекта.

Рисунок 2. Рабочий процесс отслеживания проекта

Сейчас мы рассмотрим, можно ли в Microsoft Project Professional и Microsoft Project Server/Online планировать и отслеживать проекты согласно вышеприведенным бизнес-процессам в проектных организациях.

Microsoft Project Professional

«Голый» Microsoft Project Professional или как его задумал Microsoft

В Microsoft Project Professional, в том виде, в каком он представлен на рынке, нет возможности ни одновременного планирования (детализации) работ (см. Рисунок 1 ), ни возможности автоматизировать рассылку и сбор отчетности об исполнении от исполнителей (Рисунок 2 ). Т.е. работать с план-графиком проекта будет только один человек, и он самостоятельно будет собирать отчетность от исполнителей и заносить ее в проект.

Что делать?

Microsoft Project Professional + PlanBridge