Адаптация Microsoft Project Server 2010 под специфику системы управления проектами компании

Мы хотим поделиться своим опытом доработки Microsoft Project Server 2010 под специфические требования заказчика.

Данная статья может быть интересна как бизнес-пользователям, которые могут узнать о новых возможностях платформы применительно к собственной компании, так и техническим специалистам, которые могут подчерпнуть из статьи новые знания о методах доработки Microsoft Project Server 2010.

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

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

Информационная система управления проектной деятельностью в идеальном случае должна обеспечивать следующий функционал (далеко не полный, но, в общем, достаточный):

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

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

Одним из вариантов, рассматриваемых компаниями, как базис для построения корпоративной системы управления проектами, является Microsoft Project Server 2010 (2013). Но возможно ли использование его под запросы компании практически «из коробки» или с минимальными доработками и насколько это возможно и удобно – вопрос открытый.

Если с функционалом календарно-сетевого планирования и управления ресурсами проекта вопросов не возникает, то с функциональностью рабочей области проекта, предоставляемой Microsoft Project Server 2010 (2013) по умолчанию все не так радужно.

Постановка задачи

Приведем пример реального проекта.

Проект организован по классической методологии и содержит стадии: Инициирование, Планирование, Выполнение, Мониторинг и Контроль, Закрытие.

Остановимся на стадиях инициирования и планирования проекта. Что мы хотим от системы (в идеале) – создание проекта по стандартам компании и механизм (функционал) для коллективной работы по оценке и планированию проекта, включая:

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

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

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

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

Обзор решение «из коробки»

Что мы можем получить при использовании Microsoft Project Server 2010 с настройками «по умолчанию» и как это будет соответствовать нашим ожиданиям?

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

Все расширенные атрибуты проекта мы можем получить, используя механизм сustom fields, главным преимуществом которых является автоматическое попадание в отчетные базы и возможность строить аналитику поверх них.

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

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

Здесь все не так радужно: при использовании Microsoft Project Server 2010 (2013) с минимальными настройками мы можем получить только стандартную рабочую область проекта содержащую:

1. Документы;
2. Риски;
3. Вопросы.

Стандартная рабочая область проекта (чтобы увеличить, картинки открывать в новой вкладке)

Таким образом, предварительный итог следующий – Microsoft Project Server 2010 (2013) без существенных доработок отлично справляется с коллективной работой управления проектами с точки зрения календарно-сетевого планирования и управление ресурсами, вопросами и рисками, но слабо приспособлен для комфортной работы с формированием паспортных показателей проекта, финансового планирования проекта, договорной работы и проектного документооборота в целом.

Возможно ли найти компромисс и «малой кровью» расширить и модифицировать базовый функционал Microsoft Project Server 2010?

Ответ: «Да» и об этом ниже.

Доработка Microsoft Project Server. Технические аспекты

Итак, что можно сделать, чтобы достичь желаемого результата?

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

С технической точки зрения, в организации используется идентификация проектов с помощью кодов, определяемых при создании проекта. Т.е. задача при создании проекта необходимо сгенерировать для него кода в следующем формате PRJ[спецификатор типа проекта][деятельности][номера в рамках выбранного типа и направления]. Для этого вполне подходит механизм MS Project называемый project event handlers. Т.е. на событие создание проекта необходимо повесить обработчик, который сгенерирует требуемый код. Как записать нужное значение поля?

Для работы непосредственно с полем потребуется proxy-сборка для Project Server Web Api, называемого PSI, ProjectServerServices.dll. Надо отметить, что работа с PSI весьма специфична, т.к. все действия делаются с помощью специализированных DataSet, и информация о ней несколько разрознена. Id искомого поля можно получить например при помощи этой статьи http://msdn.microsoft.com/en-us/library/office/ms453399(v=office.15).aspx, далее:

//read project information
var projectDS = ProjectSvc.ReadProject(ProjectUID, SvcProject.DataStoreEnum.WorkingStore);

foreach (ProjectDataSet.ProjectCustomFieldsRow cfRow in projectDS.ProjectCustomFields)
            {
                //if field exists, just update it
                if (cfRow.MD_PROP_UID.ToString() == id.ToString())
                {
                    //update the value
                    cfRow.TEXT_VALUE = code;
                    customFieldFound = true;
                }
            }

После чего проект необходимо вернуть.

//create a new job id
            jobId = Guid.NewGuid();

            //checkin the updated project
            bool force = false;
            string sessionDescription = "updated custom fields";
            ProjectSvc.QueueCheckInProject(jobId, ProjectUID,
                force, sessionId, sessionDescription);

И опубликовать.

//create a new job id
            jobId = Guid.NewGuid();

            bool fullPublish = false;
            ProjectSvc.QueuePublish(jobId, ProjectUID,
                fullPublish, EndpointAddressProjectSvc.Uri.ToString())

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

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

Первый вопрос как создать site definition, который можно использовать в качестве шаблона рабочей области MS SharePoint. Существует два пути:

1. Создать Sandboxed solution, который на основе стандартной рабочей области PWS.
2. Создать farm solution site definition.

Рассмотрим, оба варианта:

Sandboxed solution или Site-Definitions представляет из себя настойку уже существующей рабочей области. Преимущество его в том, что созданная рабочая область уже сразу же появится в интерфейсе администрирования. Однако ограничения sandboxed solutions довольно сильны. Например, нельзя обращаться к базам данных, а мы ведь именно этого и хотим. Чтобы отображать различные соединения данных непосредственно Microsoft Project и рабочей области.

Farm Solution. Преимущество очевидно, мы имеем полный доступ к OM SharePoint, можем вызвать данные из различных источников. Однако как же заставить на Project считать Site-Definition допустимым для использования в качестве шаблона рабочей области? Гугл не смог нам помочь в свое время. Итак, вооружаемся IL-Spy либо Reflector и в путь:

Начать лучше всего со странички “Enterprise Project Type Details” (PWAADMINEnterpriseProjectTypeDetails.aspx) откуда после серии вызовов мы придем к Microsoft.Office.Project.Server.dll и методу ReadWssInstalledLanguagesAndWebTempalates(…) класса
Microsoft.Office.Project.Server.BusinessLayer.Admin что же мы там увидим…

 foreach (SPWebTemplate sPWebTemplate in sPWebTemplateCollection)
	{
		if (sPWebTemplate.ID >= 6000 && sPWebTemplate.ID <= 6220)
		{
			dataRow = webTemplatesTable.NewRow();
			dataRow["LanguageId"] = sPLanguage.LCID;
			dataRow["TemplateName"] = sPWebTemplate.Name;
			dataRow["TemplateTitle"] = sPWebTemplate.Title;
			dataRow["TemplateId"] = sPWebTemplate.ID;
			webTemplatesTable.Rows.Add(dataRow);
		}
	}

Вот так все просто: ID – а это тот самый ID, который задается в webtemp_***.xml – должен быть в промежутке от 6000 до 6220. Однако это еще не все: если сделать SiteDefinition с нужным ID, он действительно появится на страничке “Enterprise Project Type Details”. Однако создание такого сайта будет падать. Почему?

Ответ: в методе AddOrChangeProjectWorkspaceAddress(…) класса Microsoft.Office.Project.Server.BusinessLayer.Project. Если внимательно проанализировать код, то можно увидеть, что он полагается на существования листов PWSIssues, PWSRisk, и PWSDocLibs. Можно добавить соответствующие Feature в наш SiteDefinition, а можно просто добавить Feature PWS в onet.xml, которая добавит все что нужно.

<!--Activate PWS Feature -->
        <Feature ID="90014905-433F-4a06-8A61-FD153A27A2B5">
          <Properties xmlns="http://schemas.microsoft.com/sharepoint/">
            <Property Key="InheritGlobalNavigation" Value="false"/>
            <Property Key="OnQuickLaunch" Value="false"/>
            <Property Key="InheritCurrentNavigation" Value="false"/>
            <Property Key="IncludeSubSites" Value="false"/>
            <Property Key="IncludePages" Value="False"/>
          </Properties>
        </Feature>

Что собственно неудивительно, ведь стандартный Site Definition PWS представляет из себя сайт с активированной этой Feature.
Важно!!! Создание рабочей области, происходит в службе “Microsoft Project Server Queue Service 2010”, поэтому необходимо перезапускать ее при изменениях в SiteDefinition.

Что же будет представлять собой наша рабочая область? Это будет набор списков со специфическими данными. И набор страниц, которые отображают различные срезы из этих списков, а также базы данных ProjectServer_Reporting.

Здесь встает 2 вопроса:

1. Как сделать соединение данных, используя минимальное количество кода?
2. Как отобрать данные, которые относятся к текущему проекту?

Пункт 1. Для соединения хорошо подходит DataFormWebPart и его AggregateDataSourcse. Краткая суть тут в следующем: мы выбираем данные из всех источников, а потом делаем соединение на уровне xsl. Пример:

<cc1:AggregateDataSource runat="server" RowsName="" SeparateRoot="true" RootName="" IsSynchronous="">
      <Sources>
        <cc1:SPSqlDataSource runat="server" AllowIntegratedSecurity="False" ConnectionString=""
          <%$ connectionStrings:.._ConnectionString %>" SelectCommand="SELECT TOP 1000 [Результат] as WorkResults, [TaskIndex], [TaskOutlineNumber],  [TaskUID],cast(cast(TaskWork as decimal(9,2)) AS FLOAT) as TaskWork,[TaskName] FROM [ProjectServer_Reporting].[dbo].[MSP_EpmTask_UserView] TV INNER JOIN [ProjectServer_Reporting].[dbo].[MSP_EpmProject] PR ON  TV.ProjectUID = PR.ProjectUID  WHERE PR.ProjectUID = @ProjUid " ID="SqlDataSource1">
          <SelectParameters>
            <asp:controlparameter name="ProjUid" controlid="PlaceHolderMain$wspp" propertyname="ProjUid"/>
          </SelectParameters>
        </cc1:SPSqlDataSource>
        <cc1:SPDataSource runat="server" DataSourceMode="List" SelectCommand="..."/>
        <cc1:SPDataSource runat="server" DataSourceMode="List" SelectCommand="..."/>
        <cc1:SPDataSource runat="server" DataSourceMode="List" SelectCommand="..."/>
      </Sources>
      <Aggregate>
        <concat name="data source">
        <concat name="data source">
          <datasource name="TasksInfo" id="0"  />
          <datasource name="ProjectPhases" id="1" />
          <datasource name="ProjectWorkSteps" id="2" />
          <datasource name="Contracts" id="3"  />
        </concat>
      </Aggregate>
</cc1:AggregateDataSource>

Посмотрев на этот код, легко понять, увидеть набор SPSqlDataSource для обращения к БД и SPDataSource для обращения к спискам. Все, что остается сделать, это написать .xsl, который отобразит их в нужном виде.

Пункт 2. И здесь встает вторая проблема. Как выбрать данные, в данном случае Tasks, которые относятся непосредственно к текущему проекту, а не к другим? Здесь есть два варианта:

a. Ориентироваться на URL рабочей области. А уже в запросе вычислить ProjUid по табличке MSP_EpmProject.
b. Однако, есть второй вариант: ProjUid для рабочих областей MS Sharepoint записан в свойствах SPWeb, в поле MSPWAPROJUID, таким образом можно написать простейший контрол, который его возвращает:

 public class WSProjectProperties : WebControl
    {
        public String ProjUid
        {
            get
            {
                if (SPContext.Current == null)
                    return null;
                if (SPContext.Current.Web == null)
                    return null;

                return SPContext.Current.Web.AllProperties[“MSPWAPROJUID”] as string;
            }
        }
    }

А его значение уже передавать в DataSource, что и показано в предыдущем примере.

Что мы получаем в итоге?

Доработка Microsoft Project Server. Результаты.

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

• классификация проектов и их автоматическое кодирование согласно нашим требованиям:

• рабочая область с необходимым нам функционалом, максимально адаптированная под удобство работы пользователей:

• формирование основных целевых показателей проекта:

• организационная структура проекта, включая управление несколькими проектными группами:

• определение объемов и рамок проекта и подходов к его реализации:

• формирование финансового плана проекта с детализацией по этапам работ и планирование договорных отношений на основе этапов календарного плана-графика, сформированного в Microsoft Project 2010:

• и списка работ, входящих в него на основе этапов календарного плана-графика:

• планирование договорных отношений с соотнесением работ по статьям затрат и временным интервалам:

• автоматическая генерация на основе плановых данных по проекту твердых копий документов (паспорт проекта):

• оперативные панели управления проектом на основе ключевых показателей (Резюме проекта):

* красным отмечены показатели, автоматически формирующиеся на основе фактических данных из календарного плана-графика Microsoft Project 2010 или финансовых систем компании.

• контроль выполнение работ по этапам, основываясь на плановых и фактических сроках работ и достижения вех проекта, включая визуальную индикацию нарушения сроков и выполнения работ:

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

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

Заключение.

На данном примере, основанном на реальном проекте, мы показали, что задачи, связанные с адаптацией Microsoft Project Server 2010 под специфику деятельности компании и улучшение эргономики работы с системой, возможны и достижимы.

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

Аналогичным образом, помимо коллективной работы, связанной с планированием проекта, могут быть решены задачи работы с оперативными данными по проекту, в частности:

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

Автор: eastbanctech

Источник