Как грамотно собрать бизнес-архитектуру для системы управления проектами

В статье «Зачем вам автоматизировать проектное управление?» я уже говорил о том, как важно при внедрении информационной системы управления проектами (далее — ИСУП) соблюсти баланс между пользой, которую она приносит заказчикам, и усилиями, необходимыми для ее функционирования.

И одно из первых препятствий при внедрении ИСУП — разработка требований к системе.

Многие из тех, кто сталкивался с внедрением ИСУП, знают, сколько нужно приложить усилий для формирования требований. Подробное, «выстраданное» техническое задание зачастую готовится месяцами (мой личный рекорд — девять месяцев), и все равно в итоге оказывается неполным. Это может привести к тому, что внедренная система сильно разочарует заказчиков.

Готовое решение имеет четкую архитектуру, и большинство новых «хочу» требует привлечения IT-разработчиков. При этом быстро добавить ранее упущенное, как правило, не получается (если это в принципе реально в выбранной ИСУП). Поэтому уже внедренная система может какое-то время простаивать, ее невозможно использовать.

С No-Code- / Low-Code-инструментами (например, Coda, Fibery, Airtable, Jira) ситуация обратная. Полноценные требования к такой ИСУП часто вовсе не формируются, а разработка ведется с помощью итеративного прототипирования решения. Но, как я говорил в статье «NoCode-инструменты для управления проектами: преимущества и недостатки», хаотичное добавление объектов, полей, атрибутов может привести к потере взаимосвязи между данными. Из-за этого пользователям будет сложно получить цельную картину, например, сформировать отчетность по проекту или портфелю.

Ключом к решению данных проблем может стать построение модели ИСУП до начала или в самом начале ее внедрения.

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

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

Давайте рассмотрим основные этапы объектного моделирования.

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

В стандартах проектного менеджмента, например, в PMBoK, аспекты называют предметными областями, а в PRINCE2 — темами.

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

1. Структурирование деятельности компании в виде проектов всегда имеет какие-то цели: достижение определенного эффекта, применение результатов в процессах компании.

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

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

Классификации аспектов можно найти в любом стандарте по управлению проектами. Я в своей практике выделяю двенадцать основных аспектов:

• «сроки»,
• «содержание и качество»,
• «финансы»,
• «команда»,
• «выгоды»,
• «риски и открытые вопросы»,
• «заинтересованные стороны»,
• «коммуникации»,
• «знания»,
• «документооборот»,
• «приживаемость»,
• «закупки».

Вы можете использовать этот список аспектов либо сформировать свой.

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

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

Кроме того, одно и то же явление можно отнести к разным аспектам. Например, регулярные встречи команды можно отнести как к аспекту «команда», так и к аспекту «коммуникации», а можно и к аспекту «заинтересованные стороны», если ключевым для вас в этих встречах является именно согласование ожиданий от проекта с заинтересованными сторонами.

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

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

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

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

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

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

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

Чем больше объектов вы выделите в рамках аспектов, тем сложнее, но одновременно и полнее будет ваша модель проектного управления.

Выделение объекта в системе проектного управления и дальнейшее управление им с помощью ИСУП позволят вам:

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

Мы видим, что объект может не быть уникальным для какого-либо аспекта. Например, такой объект, как «работа», будет присутствовать и в аспекте «сроки» для контроля сроков исполнения, и в аспекте «содержание и качество» для определения состава работ. А возможно, и в аспекте «финансы», если вы контролируете затраты на выполнение конкретной работы.

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

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

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

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

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

Я выделяю две группы свойств объектов ИСУП:

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

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

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

Самым распространенным способом описания состояний являются статусы. Например, в процессе исполнения работ можно использовать такие статусы, как:

• «к исполнению» — все плановые параметры работы определены, и исполнитель может приступать к ее выполнению;
• «в работе» — исполнитель выполняет работу;
• «приемка» — исполнитель закончил выполнение работы, и ответственное лицо должно оценить качество ее результатов и принять решение о завершении;
• «завершено» — деятельность по работе закончена, а ее результаты признаны достаточно качественными.

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

Кроме таких «процессных» состояний, вы можете использовать состояния-«флажки», например: наличие отклонений («значительное отклонение», «отсутствие отклонений») или уровень риска («высокий риск», «средний риск», «низкий риск») и тому подобные. Чаще всего такие состояния рассчитываются ИСУП автоматически.

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

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

Несмотря на некоторую сложность определения, а скорее даже сложность согласования состояний при использовании ИСУП, они значительно упрощают подготовку и восприятие управленческой отчётности.

Заключительный этап формирования объектной модели — определение взаимосвязей между ее элементами. Это наиболее сложный этап, так как вам необходимо проверить наличие взаимозависимостей между каждой парой объектов. Например: «цель — проект», «проект — задача», «цель — метрика». Также взаимосвязи могут быть выстроены и между объектами одного типа.

Определенные в рамках ИСУП взаимосвязи позволяют:

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

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

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

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

Для решений No-Code / Low-Code объектная модель становится каркасом, позволяющим избежать дублирования данных и не связанных ни с чем данных («повисших в воздухе»). При этом большинство No-Code- / Low-Code-решений (например, Coda, Jira) позволяет создать иерархию объектов любой сложности, настроить изменения их свойств, в том числе автоматизированный переход по фазам жизненного цикла объекта, и задать взаимосвязи между ними.

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

#проджектменеджмент