Технологии управления проектами

Программный продукт «MS Project»

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

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

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

· сколько проект займет времени;

· сколько проект будет стоить.

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

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

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

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

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

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

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

· Сколько времени займет этот проект?

· Сколько (и каких) специалистов для этого потребуется?

· Какие примерно трудозатраты ожидаются по этому проекту?

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

Подготовка плана выполняется в несколько этапов:

1. Готовим список задач.

2. Выставляем зависимости между задачами (результат какой задачи необходим для перехода к следующей? ).

3. Назначаем исполнителей задач.

4. Выравниваем загрузку ресурсов.

5. Балансируем то, что получилось.

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

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

2. Очень часто для управления зависимостями задач используют Drag& Drop. Когда задач много это быстро становится неудобно. Я рекомендую в этом случае не использовать перетаскивание, а явное указывать номера задач-предшественников. для этого можно добавить в таблицу столбец «предшественники» и вписывать номера задач вручную.

3. Срок каждой задачи не должен превышать двух недель.

Если срок задачи превышает неделю — это уже повод задуматься о её декомпозиции. Я придерживался очень простой методики оценки: примитивная задача — 2 дня, средней сложности — 1 неделя, сложная задача — 2 недели. При этом сложных задач не должно быть много. Такой подход дает возможность подготовить оценочный план довольно быстро.

С одной стороны, полученная оценка, конечно, не будет точной, но, с другой стороны — а какая из них точная? По опытку практического применения можно сказать, что на больших проектах погрешности оценок отдельных задач обычно нивелируются, а на малых часто можно (и нужно! ) использовать и более точные оценки.

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

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

6. Используем суммарные задачи для разделения задач на этапы. Ставим зависимости между этапами, чтобы они шли последовательно. Разделение на этапы пока достаточно приблизительное.

Рис.58. Список задач, разделенный на этапы

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

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

Рис.59. Группировка задач по исполнителям

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

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

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

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

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

Последний штрих - учет рисков.

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

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

· Оценить примерные трудозатраты по проекту.

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

· Выдавать задания исполнителями.

· Отмечать выполненные задания в плане.

· Корректировать план в случае значительных отклонений.

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

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

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

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

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

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

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

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

В конце проекта мы получаем план, в котором все задачи выполнены.

Технологии бюджетирования

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

Бюджетирование — процесс сложный и для его реализации используются специализированные программные продукты. На различных предприятиях существуют свои требования к созданию бюджета. Эти особенности учитываются создателями программных продуктов. Наиболее известные и распространенные программные продукты сферы бюджетирования: «Hyperion Pillar», «Corporate Planner», «Adaytum Planning», «Нефрит» и «Красный директор».

Hyperion Pillar

Рис.60. Форма приложения Hyperion Pillar

Hyperion Pillar - одна из самых ранних, хорошо известных и широко распространенных систем бюджетирования в мире. Наиболее успешно может быть применена в комплексе с остальными программными продуктами Hyperion Solutions Corporation. Система может рассматриваться как инструментальное средство для реализации на ее основе различных методик бюджетирования.

Состав и свойства информационных объектов

Измерения бюджетных планов статей

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

Основные измерения, необходимые для ведения бюджета, реализованы следующим образом:

· Организационно-штатная и финансовая структура. Идеология системы основана на классическом принципе разделения центров учета при бюджетировании: центры финансовой ответственности (ЦФО), центры затрат (ЦЗ), центры прибыли (ЦП). Предусмотрено три уровня организационной структуры - " администратор бюджета", " начальник филиала или подразделения", " бюджетный специалист - планировщик".

· Валюты, курсы. Предусмотрено ведение справочника валют и установка одного вида курса валют. Курсы устанавливаются по датам.

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

· Клиенты, потребители и поставщики. Присутствуют плоские справочники - предприятия, страны.

Бюджетные планы статей

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

Основные свойства статей бюджетных планов:

· Хранение значений во временных периодах. Период планирования в системе жестко определен - на 5 лет по месяцам, или на 15 лет по кварталам.

· Иерархия статей бюджета. Иерархия статей имеет 2 уровня: тип, номер.

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

· Возможность учета значений статьи в разных валютах и натуральном измерении.

Первичная информация

· Бюджетные строки и бюджетные документы. Вся первичная информация в системе представлена бюджетными строками предопределенной структуры.

· Объекты поддержки финансовой логики. Эта задача обеспечивается другим программным продуктом - Hyperion Enterprise (решение для финансовой консолидации в управленческих и отчетных целях).

Функциональность и алгоритмы системы бюджетирования

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

Алгоритмы планирования

· Расчет значений статей по временному горизонту планирования. С успехом настраивается с применением шаблонов.

· Расчет значений статей по ЦФО. В шаблоне возможно указание кода ЦФО.

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

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

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

· Обеспечение процесса планирования " от достигнутого". Применяется режим процентного изменения и " пошагового увеличения/уменьшения".

· Моделирование " что если" присутствует в виде штатного средства, основанного на шаблонах.

· Реализация технологии " скользящего бюджета". Возможно ее моделирование посредством корректировки шаблонов.

Алгоритмы учета исполнения бюджета

· Учет факта на основании данных бухучета. Весьма нетривиальная задача для системы. Для ее реализации необходимы внешние средства для преобразования данных бухгалтерского учета к структуре управленческого учета.

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

Агрегация, консолидация бюджетных данных

· Агрегация выполняется по запросу " планировщика".

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

Аллокации и трансферты

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

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

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

Алгоритмы расчета финансовых результатов

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

Организация работы пользователей с системой

Автоматизация коллективной работы с бюджетом

Требуется отдельный сотрудник - " администратор бюджета" для дистрибуции и консолидации бюджетов подразделений и филиалов.

Организация взаимодействия с удаленными филиалами

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

Удобства в работе с системой

· Лимиты, защищенные статьи. Возможна эмуляция этой технологии посредством выдачи прав доступа (на просмотр и запрет редактирования).

· Утверждение статей и планов. Возможно на уровне утверждения версии плана.

· Примечания к статье. Предусмотрен ввод комментариев на уровне бюджетных строк.

· Визуализация расхождений. Для контроля исполнения бюджета в системе необходимо создавать отдельные бюджетные файлы и следить за соответствием структур бюджета в файлах планов и файлах исполнения бюджета.

· Версионность планов реализована в системе очень удобно.

· Средства анализа бюджета. Для OLAP-анализа необходимо применять Hyperion Essbase.

⇐ Предыдущая 23 24 25 26 272829 30 31 32 Следующая ⇒