Использование MS Project для управления проектами по разработке ПО

• Tutorial

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

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

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

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

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

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

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

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

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

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

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

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

Что умеет MS Project

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

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

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

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

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

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

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

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

Общие рекомендации

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

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

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

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

Самым главным в методике является именно балансировка. Цель этого процесса — подготовить план, в котором работы достаточно равномерно разделены между исполнителями на всем протяжении. После первичной подготовки плана обычно получается полное безобразие, а не проект. Поэтому начинаем приводить его в порядок. Приведение в порядок заключается в ручной балансировке назначений исполнителей и разделений на этапы. Для этого используем группировку задач по исполнителям, чтобы увидеть как разложились задачи. Для удобства просмотра рекомендую сортировать задачи по дате начала. Группировка задач по исполнителямПримечание. Теоретически, для оценки загрузки полагается использовать графики загрузки пользователей. Эти графики хороши (наверное) для начальства, когда они оценивают готовый проект. Но они непригодны на этапе создания плана, так как показывают что все плохо, но совершенно не дают информации почему это так и что можно сделать. Дальше начинается магия балансировки. Требуется минимизировать сроки выполнения каждого этапа путем обеспечения более-менее равномерной нагрузки на всех участников проекта. Для этого мы выполняем следующие действия: Делать все это, к сожалению, приходится вручную, выполняя выравнивание загрузки ресурсов после каждого изменения. Несмотря на кажущуюся сложность, этот процесс обычно занимает конечное время. Проект на год из 8 участников, разбитый на 4 этапа я приводил в порядок менее чем за час. Теперь еще раз внимательно смотрим на проект, убеждаемся, что связи между задачами расставлены правильно, что ничего не забыто, а назначения исполнителей соответствуют их специальностям и квалификации.

Учет рисков

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

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

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

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

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

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 для практического решения задач, которые возникали передо мной, когда я руководил проектами по разработке ПО. Описанная методика не претендует не универсальность, но она, как мне кажется, достаточно проста и логична, при этом позволяет решать практические задачи руководителя проекта. Использование этого подхода позволило мне успешно и в срок завершить не один проект. Правда, случались и сбои. Это происходило, как правило, тогда, когда плохо была проведена подготовительная часть проекта, а именно — постановка задачи. Т.е. в результате проекта получалось не совсем то, что требовалось, а понимание этого приходило слишком поздно. Наверняка я что-то упустил, не стесняйтесь задавать вопросы.

Настраиваемые поля

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

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

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

Создание настраиваемых полей

Во «внутренние» таблицы MS Project включен набор полей, которые пользователь может настроить по своему усмотрению и размещать в них свои данные. Эти поля могут относиться либо к ресурсам, либо к задачам и различаются по типам данных, которые в них можно хранить. Работа с настраиваемыми полями осуществляется в диалоговом окне Customize Fields (Настройка полей), вызываемом либо из контекстного меню заголовка таблицы, либо с помощью команды меню Tools › Customize › Fields (Сервис › Настройка › Поля).

Диалоговое окно настройки полей состоит из двух вкладок. На первой вкладке, Custom Fields (Настраиваемые поля), и осуществляется работа с настраиваемыми полями (рис. 13.16, файл 15.mpp).

Прежде чем настраивать поле, нужно решить, к задачам или к ресурсам, относится его содержимое, и, соответственно, выбрать переключатель Task (Задач) или Resource (Ресурсов). Затем в раскрывающемся списке Type (Тип) нужно определить тип данных (табл. 13.1) этого поля.

Таблица 13.1. Типы настраиваемых полей в MS Project.

Рис. 13.16. Диалоговое окно настройки полей

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

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

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

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

Как сделать такое поле в Project Professional?

• В Project Professional перейти на вкладку ленты Формат и щелкнуть кнопку Настраиваемые поля.

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

• Дать название вашему индикатору, переименовав ближайшее свободное поле, и щелкнуть ОК.

• В группе команд Настраиваемые атрибуты нажать кнопку Формула.

• Щелкнуть кнопку Поле в группе команд Вставка и выбрать поле, к которому приравниваем, из списка. В моем примере – Поле – Число — % завершения. Имя поля также можно написать вручную в квадратных скобках. После составления формулы щелкнуть ОК.

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

• И, наконец, щелкнуть кнопку Графические индикаторы.

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

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

• Щелкнуть ОК, затем еще раз ОК.
• Далее в нужные представления добавить настроенное поле:

Используемые источники:

• https://habr.com/post/151593/
• http://samoychiteli.ru/document18785.html
• http://projectplanet.ru/tag/настройка-project/