В статье «Зачем вам автоматизировать проектное управление?» я уже говорил о том, как важно при внедрении информационной системы управления проектами (далее — ИСУП) соблюсти баланс между пользой, которую она приносит заказчикам, и усилиями, необходимыми для ее функционирования.
И одно из первых препятствий при внедрении ИСУП — разработка требований к системе.
Еще больше актуальной информации про полезные методы и инструменты проектного менеджмента, внедрения организационных изменений и ИТ-решений ищите в нашем Телеграм-канале: Уж&Ёж. Управление проектами. PMLogix
Многие из тех, кто сталкивался с внедрением ИСУП, знают, сколько нужно приложить усилий для формирования требований. Подробное, «выстраданное» техническое задание зачастую готовится месяцами (мой личный рекорд — девять месяцев), и все равно в итоге оказывается неполным. Это может привести к тому, что внедренная система сильно разочарует заказчиков.
Готовое решение имеет четкую архитектуру, и большинство новых «хочу» требует привлечения IT-разработчиков. При этом быстро добавить ранее упущенное, как правило, не получается (если это в принципе реально в выбранной ИСУП). Поэтому уже внедренная система может какое-то время простаивать, ее невозможно использовать.
С No-Code- / Low-Code-инструментами (например, Coda, Fibery, Airtable, Jira) ситуация обратная. Полноценные требования к такой ИСУП часто вовсе не формируются, а разработка ведется с помощью итеративного прототипирования решения. Но, как я говорил в статье «NoCode-инструменты для управления проектами: преимущества и недостатки», хаотичное добавление объектов, полей, атрибутов может привести к потере взаимосвязи между данными. Из-за этого пользователям будет сложно получить цельную картину, например, сформировать отчетность по проекту или портфелю.
Ключом к решению данных проблем может стать построение модели ИСУП до начала или в самом начале ее внедрения.
Существует множество подходов к созданию целостного представления о будущей ИСУП. Можно описывать ее на основе процессов проектного управления, можно строить структуру данных на основании требующейся управленческой отчетности. Но я предлагаю использовать метод объектного моделирования.
Построение объектной модели очень близко к построению информационной архитектуры, поэтому, как правило, модель легко переносится на выбранное IT-решение. При этом объектное моделирование не требует специфических технических знаний и базируется на элементарной бизнес-логике.
Давайте рассмотрим основные этапы объектного моделирования.
Этап 1. Выделение аспектов
В первую очередь вам необходимо определить для себя, чему следует уделять особенное внимание при реализации проектов в вашей компании. Эти условные области внимания будем называть аспектами. Примеры аспектов: сроки, эффекты, риски и т. д.
Аспект проектной деятельности — область внимания в проекте, на которой фокусируется руководство организации и/или руководитель проекта, так как она несет выгоды организации, позволяет соблюсти ограничения или решает наиболее острые проблемы в управлении.
В стандартах проектного менеджмента, например, в PMBoK, аспекты называют предметными областями, а в PRINCE2 — темами.
В каждой компании аспекты могут немного отличаться, в зависимости от специфики бизнеса, зрелости процессов проектного управления, наиболее часто встречающихся проблем с проектами. Ниже я кратко перечислю моменты, о которых стоит задуматься, выбирая аспекты. Все они важны, хотя и будут отличаться от компании к компании.
1. Структурирование деятельности компании в виде проектов всегда имеет какие-то цели: достижение определенного эффекта, применение результатов в процессах компании.
2. Проекты реализуются в рамках важных для бизнеса ограничений. Для кого-то важна реализация в срок, для кого-то — минимальный расход ресурсов.
3. Нужно определить области источников наиболее частых проблем. Это могут быть проблемы с качеством, с укомплектованностью команды, с потерянными требованиями (такими, которые не были корректно зафиксированы и всплыли в конце проекта).
Классификации аспектов можно найти в любом стандарте по управлению проектами. Я в своей практике выделяю двенадцать основных аспектов.
- «сроки»,
- «содержание и качество»,
- «финансы»,
- «команда»,
- «выгоды»,
- «риски и открытые вопросы»,
- «заинтересованные стороны»,
- «коммуникации»,
- «знания»,
- «документооборот»,
- «приживаемость»,
- «закупки».
Вы можете использовать этот список аспектов либо сформировать свой.
Важно определить не только наименование аспекта, но и расшифровать его суть, поскольку в различных компаниях она может различаться. Так, в одной организации аспект «команда», например, будет рассматривать исключительно обеспеченность команды ресурсами, а в другой может дополнительно включать оценку членов команды, развитие проектных компетенций и т. п.
Поэтому, когда вы определили аспекты вашей проектной деятельности, потратьте еще немного времени на то, чтобы письменно зафиксировать их содержание. Это очень поможет вам в дальнейшем.
Кроме того, одно и то же явление можно отнести к разным аспектам. Например, регулярные встречи команды можно отнести как к аспекту «команда», так и к аспекту «коммуникации», а можно и к аспекту «заинтересованные стороны», если ключевым для вас в этих встречах является именно согласование ожиданий от проекта с заинтересованными сторонами.
Также при описании аспектов желательно, чтобы содержание их не дублировалось. То есть нужно определить, в рамках какого аспекта чаще всего рассматривается явление на практике.
Если вы не включите какое-то явление ни в один из выбранных вами аспектов, то есть риск, что вы будете работать с ним не систематически, а лишь по ситуации, интуитивно.
Конечно же, список аспектов или их определения всегда можно уточнить. Но в целом для большинства проектов характерен набор универсальных аспектов, которые понадобятся почти в любом проекте. Их я называю обязательными. Для меня это, например, «сроки», «содержание и качество», «команда», «финансы», «риски и открытые вопросы».
Этап 2: Определение объектов
После того как вы определитесь с аспектами, необходимо понять, с помощью каких элементов вы будете управлять каждым из них, то есть осуществлять планирование и контроль. И здесь вам помогут описания аспектов, которые вы составили на предыдущем этапе.
Допустим, вы выбрали аспект «сроки», так как для вас важно завершение проектов в срок. В этом случае мы воспользуемся объектом «проект» и зададим для него даты сроков окончания.
Если вам хочется видеть, соответствует ли процесс работы над проектом графику «внутри» этих сроков, то у вас появляется еще один объект — «работа», и у него тоже есть сроки начала и окончания.
А может быть, вы захотите быть уверены в том, что в проекте успешно и в запланированный срок произойдет какое-то важное событие, например, заключение контракта. В этом случае вы можете добавить объект «событие», который традиционно называют вехой или контрольной точкой.
Объект — это элемент проектной деятельности, с помощью которого можно управлять процессами в рамках аспекта, т. е. осуществлять планирование и контроль.
Чем больше объектов вы выделите в рамках аспектов, тем сложнее, но одновременно и полнее будет ваша модель проектного управления.
Выделение объекта в системе проектного управления и дальнейшее управление им с помощью ИСУП позволят вам:
- планировать параметры проекта — сроки, бюджеты и т. д.;
- оперативно контролировать динамику состояний и параметров объекта и своевременно принимать управленческие решения;
- формировать единое понимание текущего состояния и параметров объекта у всех участников проекта, исключая возможности для субъективного толкования, фиксировать все договоренности на общедоступной платформе;
- формировать у всех участников проектной деятельности четкое и единообразное представление о процедурах управления проектами в рамках каждого из аспектов.
Мы видим, что объект может не быть уникальным для какого-либо аспекта. Например, такой объект, как «работа», будет присутствовать и в аспекте «сроки» для контроля сроков исполнения, и в аспекте «содержание и качество» для определения состава работ. А возможно, и в аспекте «финансы», если вы контролируете затраты на выполнение конкретной работы.
То есть не обязательно увеличивать количество объектов, вы можете просто задать необходимые свойства (см. 3-й этап).
Этап 3: Определение свойств объектов
Объектная модель представляет собой иерархическую структуру из связанных друг с другом объектов и их параметров, на основе которой формируется система управления проектами вашей организации.
Поэтому после определения объектов мы переходим к определению их свойств. Напомню, что аспекты мы определяем для того, чтобы не упустить в нашей системе ничего важного, объекты становятся «кирпичиками» системы, создают ее структуру. А свойства объектов представляют собой виды данных, которые вы хотите контролировать по каждому объекту. По сути, это будущие «поля» для форм ввода данных и отчетов.
Свойство — это параметр объекта, его характеристика.
При определении свойств я рекомендую вам по-прежнему отталкиваться от аспектов, а не от объектов, которые могут относиться к нескольким аспектам. Такой подход поможет, с одной стороны, ничего не упустить, а с другой — избежать дублирования.
На этапе формирования объектной модели инвентаризировать все свойства (поля) необязательно, их список можно уточнить, когда будет конфигурироваться проектная отчетность.
Я выделяю две группы свойств объектов ИСУП:
- Параметры, которые вы планируете контролировать. Например, у объекта «работа» в аспекте «срок» вам важны плановые и фактические даты начала и окончания работы, ее длительность, имеющийся у работы резерв. Возможно, вы захотите оценивать прогнозную дату окончания работы и риск отклонения плановых дат и длительности от фактических или прогнозных. У того же объекта «работа» в аспекте «содержание и качество» вас, к примеру, будут интересовать результаты работы, критерии оценки качества ее исполнения, состав исполнителей и ответственных, перечень входящих в работу задач и пошаговые взаимосвязи в системе между всеми процессами.
При определении параметров объекта важно соблюдать принципы необходимости и достаточности, то есть отбирать те параметры, которыми вы реально пользуетесь, включаете в отчетность. В противном случае использование ИСУП может стать очень трудоемким для исполнителей, вносящих данные, и в дальнейшем даже привести к отказу от нее.
2. Состояния. Состояние объекта — это набор принятых в организации обозначений происходящих с объектом процессов или их шагов. Изменение состояния объекта может сигнализировать о необходимости проведения каких-либо мероприятий, например по началу выполнения определенного этапа работ или по снижению тех или иных рисков.
Самым распространенным способом описания состояний являются статусы. Например, в процессе исполнения работ можно использовать такие статусы, как:
- «к исполнению» — все плановые параметры работы определены, и исполнитель может приступать к ее выполнению;
- «в работе» — исполнитель выполняет работу;
- «приемка» — исполнитель закончил выполнение работы, и ответственное лицо должно оценить качество ее результатов и принять решение о завершении;
- «завершено» — деятельность по работе закончена, а ее результаты признаны достаточно качественными.
Свойства-состояния часто используются для таких объектов, как «проект», «работа», «результат», «риск», так как содержание действий, связанных с ними, может значительно отличаться в различные моменты.
Кроме таких «процессных» состояний, вы можете использовать состояния-«флажки», например: наличие отклонений («значительное отклонение», «отсутствие отклонений») или уровень риска («высокий риск», «средний риск», «низкий риск») и тому подобные. Чаще всего такие состояния рассчитываются ИСУП автоматически.
При описании состояний объекта необходимо сформировать полный перечень состояний с описанием их смысла и условий переходов между ними.
Если переход между состояниями осуществляется исключительно последовательно, то вы определяете так называемый жизненный цикл объекта (по сути, это бизнес-процесс). Например, жизненный цикл проекта состоит из последовательно меняющихся состояний-фаз: «инициирование», «планирование», «реализация», «завершение».
Несмотря на некоторую сложность определения, а скорее даже сложность согласования состояний при использовании ИСУП, они значительно упрощают подготовку и восприятие управленческой отчётности.
Этап 4: Определение взаимосвязей между объектами и свойствами
Заключительный этап формирования объектной модели — определение взаимосвязей между ее элементами. Это наиболее сложный этап, так как вам необходимо проверить наличие взаимозависимостей между каждой парой объектов. Например: «цель — проект», «проект — задача», «цель — метрика». Также взаимосвязи могут быть выстроены и между объектами одного типа.
Определенные в рамках ИСУП взаимосвязи позволяют:
- использовать иерархию и/или логическую связь при отображении объектов, например, работы, как составные части конкретного проекта, и последовательность выполнения работ;
- формировать обобщенную отчетность, например, рассчитывать занятость сотрудника во всех проектах, в которых он участвует, на основании трудоемкости выполнения задач или суммирование в программе значений аналогичных показателей всех входящих в нее проектов, допустим, значений фактического бюджета;
- автоматизировать заполнение отдельных свойств. Это могут быть свойства из выпадающих списков других объектов — например, ответственный за работу выбирается из общего списка участников проектной деятельности. А могут быть и расчетные формулы: скажем, при заданных датах начала и окончания работы длительность рассчитывается автоматически.
Корректно определенные взаимосвязи позволят проверять информацию в ИСУП на ее целостность и непротиворечивость. Допустим, наличие связей между проектами и стратегическими целями позволяет оперативно узнать, какие проекты не привязаны к стратегическим целям и какие стратегические цели остались без проектов.
Таким образом, объектная модель формирует смысловой скелет ИСУП, обеспечивает полноту и достаточность требований к системе.
Для готовых решений ИСУП сравнение с разработанной на основе требований объектной моделью дает вам возможность максимально оперативно оценить наличие в системе необходимых элементов и возможность реализации их взаимодействия в необходимой вам бизнес-логике, а также комплексно определить объем и содержание необходимых доработок.
Для решений No-Code / Low-Code объектная модель становится каркасом, позволяющим избежать дублирования данных и не связанных ни с чем данных («повисших в воздухе»). При этом большинство No-Code- / Low-Code-решений (например, Coda, Jira) позволяет создать иерархию объектов любой сложности, настроить изменения их свойств, в том числе автоматизированный переход по фазам жизненного цикла объекта, и задать взаимосвязи между ними.
Однако важно помнить, что объектная модель, как и сама ИСУП, является вспомогательным инструментом для повышения качества управления, и если у вас в организации не будут налажены сами процессы проектной деятельности, с применением ИСУП эффективность проектов вряд ли вырастет.
Еще больше актуальной информации про полезные методы и инструменты проектного менеджмента, внедрения организационных изменений и ИТ-решений ищите в нашем Телеграм-канале: Уж&Ёж. Управление проектами. PMLogix
