SMART-UP: методология унификации автоматизированного управления проектной и операционной деятельностью

Основной замысел

Методология SMART-UP состоит из трех основных элементов:

1. Единые правила построения информационной модели проектной или операционной деятельности на основе унификации учета задач для проектов JIRA различной направленности.

2. Унифицированные дашборды для отображения текущего состояния проектов JIRA и системы единых показателей для оценки этого состояния.

3. Совокупность подходов к оценке результатов проектной (операционной) деятельности и ее текущего состояния, а также формирования на основе этой оценки рекомендаций по управлению сотрудниками проектных команд (подразделений).

В настоящее время инструменты SMART-UP представляют собой надстройку над JIRA. Поскольку, с одной стороны, JIRA может использоваться как для управления проектами, так и для управления операционной деятельностью, а с другой стороны регистрация сведений об этой деятельности JIRA осуществляется в форме проектов. Проект в системе JIRA представляет собой набор задач (запросов), сгруппированных по определенному направлению работ, определяемых в соответствии с требованиями вашей организации. Поэтому в дальнейшем для описания основного субъекта управления мы будем применять термин проект, как для проектной, так и для операционной деятельности.

Применение подходов и инструментов SMART-UP позволяет:

• повысить объективность и целенаправленность управленческих решений;

• обеспечивает превентивное выявление скрытых причин срыва сроков выполнения задач;

• проводить в реальном масштабе времени оценку рентабельности/результативности деятельности как отдельных сотрудников, так и проектных команд;

• снизить трудозатраты на формирование проектной документации;

• выявить организационные ограничения на проектах;

• оценить качество управления на разных проектах;

• проводить оценку степени соответствия сотрудника занимаемой должности;

• проводить оптимизацию штатной структуры подразделений в соответствии с проводимыми работами.

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

При создании SMART-UP в основу замысла были взяты подходы, применяемые, с одной стороны, для управления войсками при ведении боевых действий, а с другой - при организации проведения научных исследований.

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

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

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

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

Общие понятия

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

• проекты по разработке программного обеспечения;

• проекты по сопровождению программного обеспечения;

• научно-исследовательская работа (НИР);

• предпродажная подготовка;

• кадровая деятельность;

• бухгалтерская деятельность;

• консалтинг;

• юридические услуги.

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

• Период оказания услуг - период рабочего времени в рамках суток (рабочего дня) в течении которого оказываются услуги согласно договора с заказчиком.

• Срок выполнения задачи – крайняя дата, до истечения которой задача должна быть решена, т.е. переведена из статуса «назначена» в статус «контроль» (в терминологии БД JIRA - DUEDATE) . Под статусом «контроль» подразумевается состояние задачи, когда с точки зрения исполнителя все работы по ней полностью завершены и фиксируется готовность к сдаче/приемке результатов этой задачи заказчиком (результат отгружен на склад готовой продукции).

• Календарная продолжительность реализации требования – продолжительность календарного времени между моментом регистрации и моментом решения требования.

• Проектная продолжительность реализации требования (время в работе в рамках договора) – продолжительность рабочего времени по проектному договору между моментом регистрации и моментом решения требования.

• Календарная продолжительность выполнения работы – продолжительность календарного времени нахождения задачи-работы в статусе <назначено>.

• Проектная продолжительность выполнения работы – продолжительность нахождения задачи-работы в статусе <назначено> в рамках рабочего времени по договору.

• Табельная продолжительность выполнения работы - продолжительность нахождения задачи-работы в статусе <назначено> в рамках периодов рабочего времени сотрудника.

• Трудоемкость задачи – объем рабочего времени, запланированный из бюджета рабочего времени сотрудника для выполнения работы (решения задачи-работы) в полном объеме (в терминологии БД JIRA - TIMEORIGINALESTIMATE). Очень хорошо, на мой взгляд, разницу между трудоемкостью и продолжительностью выполнения задачи объяснил Егор Бугаенко в одном из своих выступлений.

• Трудоемкость, необходимая для завершения задачи – рабочее время, необходимое по оценке ответственного сотрудника для завершения задачи с учетом ранее выполненных работ (в терминологии БД JIRA - TIMEESTIMATE).

• Трудозатраты – фактическое рабочее время, потраченное сотрудником для решения задачи (в терминологии БД JIRA - TIMESPENT).

• Бюджет рабочего времени сотрудника – объем рабочего времени сотрудника в рамках заданного периода.

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

В основе построения унифицированной модели учета лежит разделение задач JIRA на два основных класса:

задачи-требования - цели, которые предполагается достичь;

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

Каждая задача-работа должна быть связана с требованием, в интересах реализации которого она запланирована. В результате формируется модель проекта, измеряя текущее состояние которой можно оценить “здоровье” проекта (степень достижения поставленных целей проекта, выявить текущие риски, маржинальность).

В рамках модели для всех типов задач были унифицированы ряд пользовательских атрибутов и рабочий процесс (workflow).

Жизненный цикл и бизнес-процесс

При организации выполнения задач (работ) разделены понятия жизненного цикла работы и бизнес - процесса.

Бизнес- процесс ( business process ) – согласно концепции BPM - это совокупность взаимосвязанных мероприятий или работ, направленных на создание определенного продукта или услуги для потребителей. Как правило, бизнес-процесс изображается в форме графа ( сетевого графика ), где узлами графа являются работы или мероприятия, а с помощью ребер этого графа отражается последовательность выполнения этих работ.

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

Рабочий процесс задачи JIRA (workflow) - в рамках применения данной модели предназначен для регистрации возможных статусов и переходов, которые проходит задача в течении всего своего жизненного цикла.

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

• оценка;

• в работе (назначено);

• контроль;

• закрыто;

• ожидание.

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

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

Предлагаемая модель учета позволяет обеспечить контроль за следующими видами основных проектных бизнес-процессов:

• процесс выполнения задачи;

• процесс реализации группы требований (от одного требования до всех требований проекта);

• процесс реализации программы проектов;

• процесс реализации портфеля проектов.

Кроме этого, эта модель учета позволяет обеспечить контроль за обеспечивающими бизнес-процессами проекта (на основании анализа по задачам определенного типа) и мониторинг качества управления.

Визуализация и контроль основных бизнес-процессов осуществляется на основании матрицы трассировки требований (RTM).

Распределение ответственности

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

• автор задачи;

• исполнитель.

Если рассматривать задачу с позиции BPM, роль автора задачи аналогична роли владельца этого процесса .

Автор задачи - это сотрудник, который отвечает за постановку задачи и контроль ее выполнения. Статусы задачи, которые находятся в зоне ответственности автора задачи.

• оценка;

• контроль;

• закрыто;

• ожидание.

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

Автор задачи-работы отвечает за организацию работ в рамках подзадач и результат реализации задачи в целом.

Автор задачи-требования отвечает за организацию работ в рамках бизнес-процесса реализации требования и получения подтверждения о решении этого требования от заказчика .

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

Только ответственный исполнитель может перевести задачу из статуса <назначено> в статус <контроль>.

За качество выполнения отдельной задачи отвечает только один ответственный исполнитель (при выполнении задачи не предполагается смена исполнителя). Однако, если в процессе выполнения задачи исполнитель был переназначен - ответственность за качество решения задачи несет исполнитель, переведший задачу в статус <контроль>.

Для всех типов задач (как требований так и работ) устанавливается один рабочий процесс. Для подзадач принимается упрощенный рабочий процесс, состоящий из тех же статусов, что и для задач, за исключением статуса <контроль>.

Единая система классификации

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

Фундаментом для построения любой модели является классификация объектов, которые используются для формирования этой модели. Единая классификация дает возможность увидеть и оценить систему в разрозненном наборе фактов и событий.

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

• классификатор проектных требований;

• классификатор оснований (источников) требования;

• классификатор требований операционной деятельности;

• номенклатура видов работ (предоставляемых услуг);

• классификатор уровней приоритета;

• классификатор стадий жизненного цикла продукта (оказываемого сервиса);

• единая номенклатура штатных должностей/ проектных ролей/ уровней квалификации сотрудника, необходимой для выполнения работ.

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

• номенклатуру форм пользовательского интерфейса (UI);

• перечень сервисов API;

• номенклатуру печатных отчетов;

• номенклатуру проектной документации;

• номенклатуру основных подсистем (автоматизируемых бизнес-процессов);

• перечень таблиц БД;

• перечень основных элементов инфраструктуры (сервера, стенды и т.п.);

• перечень вспомогательных подсистем (JIRA, GIT и т.п.)

Так же к классификаторам продукта относятся классификатор стадий жизненного цикла продукта (оказываемого сервиса). Данный классификатор должен применяться для классификации всех однотипных продуктов.

Общие правила регистрации задач

При регистрации всех задач предполагается учет следующих основных атрибутов:

• автор;

• исполнитель;

• тема (резюме);

• описание задачи;

• приоритет;

• планируемый срок исполнения.

• затрагиваемые компоненты.

Кроме этого в ходе решения задач при необходимости уточняются следующие сведения:

• ежедневные трудозатраты на решение задачи;

• оставшееся время необходимое для окончательного решения задачи;

• в случае изменения срока решения задачи указывается причина перепланирования;

• в случае перевода задачи в статус <ожидание> необходимо указать тип причины ожидания и описать эту причину;

При решении задачи регистрируется описание решения и уточняются затронутые компоненты.

При закрытии задачи задачи регистрируется:

• причина закрытия;

• описание основания для закрытия задачи (при необходимости).

Особенности регистрации требований

Требования в рамках деятельности команд (подразделений) можно разделить на две части:

1. Требования которые нацелены на реализацию запланированных проектов (в рамках заключенных контрактов или внутренних проектов).

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

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

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

1. Каждое требование заказчика должно регистрироваться как отдельная задача в JIRA. Другими словами, в рамках каждой задачи JIRA регистрируется одно нормализованное (логически неделимое) требование. И если приходит письмо об инциденте, в котором описаны три разных ошибки программного обеспечения, то в JIRA регистрируется три разных требования-задачи.

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

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

При регистрации задач-требований предполагается учет следующих дополнительных атрибутов:

• тип требования;

• тип договора (не рекомендуется использовать - для каждого договора необходимо формировать собственный проект);

• квалификация ответственного исполнителя (проектная роль), необходимая для организации решения данного требования;

• стадия жизненного цикла продукта (пресейл, промышленная эксплуатация, опытная эксплуатация и т.п. );

• реквизиты основания для регистрации требования:

• вид основания

• номер, дата и раздел документа

• атрибуты заказчика (ФИО, подразделение и должность).

• компоненты, которые затрагивает требование

• номер версии продукта для которой заявлено требование (при необходимости);

• номер версии продукта для которой реализовано требование (при необходимости);

Как и любая задача, требование в JIRA имеет атрибуты, позволяющие зафиксировать планируемую трудоемкость (original estimate) и фактические трудозатраты (time spent). В нашем случае важно понимать, что эти значения описывают не общее время на все работы, связанные с реализацией требования, а только время ответственного сотрудника, связанное с уяснением и уточнением требования.

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

Особенности регистрации работ

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

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

Подзадача рассматривается как работа определенного типа, которая может быть выполнена одним сотрудником от начала до завершения. При этом подзадача не имеет смысла без реализации всей задачи целиком. Например, проверка качества кода (code review) не имеет смысла, если в конце концов автоматизированная функция не будет использована в программе.

На проектах по созданию программного обеспечения предлагается применять следующие базовые типы задач для учета выполняемых работ:

• «анализ» – тип задачи для регистрации проводимых совещаний по согласованию требований, проведение занятий по обучению пользователей, материалов информационных обследований (пользовательских историй) и описаний постановок задач (проектных решений) по связанным требованиям;

• «разработка» – работы по созданию или модификации программного обеспечения;

• «тестирование» – работы, связанные с тестированием готового ПО (направленные на составление описания тестовых заданий, подготовку тестовых данных, создание автотестов, проведение тестирования разработанного ПО);

• «документирование» – работы по формированию и доработке установленной проектной документации (одна задача характеризует работу только над одним документом);

• «внедрение» – работы, направленные на внедрение разработанного ПО в деятельность заказчика (проведение испытаний, демонстраций, выпуск релиза/патча/datafix, развертывание программного обеспечения на серверах заказчика и т.д.).

При регистрации задач-требований предполагается учет следующих дополнительных атрибутов:

• квалификация ответственного исполнителя (проектная роль), требуемая для выполнения данной работы;

• компоненты, которые затрагивает работа;

• версия ПО (при необходимости).

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

Для прозрачности распределения ответственности при автоматизации управления проектом был реализован принцип «1 задача – 1 исполнитель». Т.е. процесс выполнения задачи не предполагает ее передачу другим исполнителям. Этот принцип позволил применить одинаковый рабочий процесс (workflow) ко всем типам задач, поскольку статус выполнения работы определялся с точки зрения автора этой задачи.

Инструменты для визуализации и оценки состояния проекта

В случае, если проекты JIRA организованы в соответствии с приведенными выше правилами, то для таких проектов подготовлены унифицированные инструменты для визуализации и оценки проектной (операционной) деятельности.

Эти инструменты включают в себя нижеперечисленные дашборды:

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

• оценка текущей степени реализации группы требований;

• диаграмма накопления требований;

• тетрис М.Дорофеева (по сотрудникам, по видам задач, по проектным ролям);

• распределение времени обработки требований;

• текущий план работ по реализации требований;

• оценка стоимости и рентабельности выполнения работ.

• актуальный план индивидуальной работы сотрудника с визуализацией основных рисков;

• отчет сотрудника по выполненным работам за заданный период с оценкой результативности и рентабельности.