Практически во всех современных инженерных софтах управления жизненным циклом (PLM-системах, product life-cycle managmenet) находятся именно issue trackers, называемые обычно “системами управления изменениями”. Каждое issue/задача/проблема/вопрос/изменение понимается как запрос на изменение (Engineering Change Request). После обсуждения того, что и кто должен изменять, этот запрос на изменение превращается в поручение (Engineering Change Order), а после выполнения работы — извещение о том, что запрос удовлетворён, начальная проблема закрыта (Engineering Change Notice).

Вот простейший вид issue tracker в виде стикеров на ватмане:

Обратите внимание, как команда проекта меняла состояния, через которые проходит issue: сначала состояние было названо Done, но потом команда поняла, что “сделать” это ещё не “принять сделанное” (помним про трансакции DEMO) — и переименовала колонку.

Не слишком похоже на диаграммы Гантта и прочие рабочие продукты управления проектом? Да, это совсем другое view на работы.

Управление проектами и управление жизненным циклом

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

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

Оценки разработчиков OMG Essence таковы, что одна альфа свидетельствуется часто десятком рабочих продуктов — да ещё эти продукты часто разные для разных состояний альфы. Рассуждения в ходе разработки ведутся содержательные, концептуальные, инженерные, "в терминах альф". Рабочие продукты только

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

Инженеры говорят содержательно, в терминах альф: "архитектура готова", "пользователи удовлетворены". Менеджерам всё равно, что там с содержанием, поэтому они предпочитают говорить в терминах рабочих продуктов: их наличие или отсутствие легко проверить, а факт содержательности тоже легко проверить путём получения подписи на них какого-то эксперта ("архитектурное эссе согласовано, но ещё не подписано", "подписи заказчика на акте приёмки-сдачи уже получены"). Менеджерам трудно проверить “архитектура готова”, но легко проверить “файл с принципиальной схемой опубликован”. С точки зрения инженеров три месяца идёт работа над архитектурой, а потом три дня она оформляется в виде рабочих продуктов. С точки зрения менеджеров три месяца ничего не происходит, а потом бац — “архитектурные рабочие продукты готовы”.

Менеджеры предпочитают структуру проекта-design в системах управления конфигурацией (PLM-системах) делать “по томам документации”, это облегчает контроль готовности и передачу заказчику всех запланированных рабочих продуктов. Инженеры предпочитают хранить “по сборкам” (т.е. не в соответствии с разбиением по документации, а в соответствии со структурой системы — компонентной и модульной декомпозиции), что не помогает для контроля готовности и передачи заказчику, но хорошо помогает при собственно разработке.

Управление жизненным циклом признаёт тесную взаимосвязанность и параллельное (одновременное) практикование самых разных дисциплин в ходе инженерного проекта. Контрольные вопросы — это вопросы прежде всего к самому важному, т.е. очень небольшому числу аспектов инженерного проекта. Контрольные вопросы ни в коем случае не являются полными для контроля проекта! Они просто напоминалки, попытки обратить внимание на отдельные важнейшие моменты! Они не заменяют собой детальных планов, в которых учтены все требуемые рабочие продукты, не заменяют собой все наборы требований, каждое из которых требует проверки, не заменяют собой всех других вопросов, которые задаст в те или иные моменты работы команда инженерного проекта.

Ответы на контрольные вопросы приводят к формулированю дел (issues/tasks/cases) — постановке проблем, заданию задач, задавания вопросами. Эти отдельные дела обычно не учитываются ни в одном из планов, но тем не менее, их нужно выполнять. Все дела формулируются по возможности в содержательной форме (альф), а не в форме оформления рабочих продуктов (хотя и могут быть отдельные дела, связанные именно с недостатками оформления).

У "управленцев проектами" в голове план выпуска рабочих продуктов, как проходящих по “трубе предпринятия” (метафора потока, хода работ) — то, что легко проконтролировать по форме при прохождении работ и передаче их от одного исполнителя к другому. И вот во что превращается Essence с его контрольными вопросами при попытках его изменить с моделью “проектного управления” в голове:

●по стандарту Essence детализация на подальфы требуется только там, где "команда не понимает" или "команде трудно дать однозначный ответ". Но после перехода к бюрократическому контролю детализация на подальфы потребуется везде, просто как ещё одно средство детализации контроля. Из механизма дебюрократизации (уменьшение объема необходимых рабочих

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

●поскольку содержательные ответы команды бессмысленны и плохо проверяемы (а часто инженеры нагло и необоснованно врут друг другу и менеджерам, а менеджеры тоже врут друг другу и инженерам, когда дают положительные ответы на контрольные вопросы и закрывают глаза как раз на те риски, которые призваны вскрыть контрольные вопросы), то делается попытка немедленно привязать альфы к рабочим продуктам и вопросы задавать уже про рабочие продукты. Это недопустимо! Разговор про “требования” — это не разговор про “техническое задание” или “опросный лист”, а разговор про “архитектуру” — это не разговор про “четвёртый лист схемы автоматизации”! В итоге получаем тьму довольно бессодержательных вопросов про готовность рабочих продуктов к сдаче, а не вопросов про проработанность решений для перехода к следующим состояниям альф.

●набор карточек для вопросов к рабочим продуктам, развёрнутый по линии времени становится просто планом из PRINCE2 (названия задач представляют собой названия готовых рабочих продуктов), WBS верхнего уровня которого наследует рубрикацию рабочих продуктов, оставленную в наследство от альф Essence.

Проектное управление и ведение дел: не “или”, а “и”.

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

Перед выполнением проекта (в ходе инженерии предпринятия):

●Определения практик (в виде регламентов, при определении формы жизненного цикла, методик проектирования, ГОСТов и т.д.)

●Процессы (служба качества)

Изредка — шаблоны проектов В ходе работы предпринятия:

●Задачи в переписке (как в электронной почте, так и в официальной переписке). Часто говорят о “поручениях”.

●Дела в протоколах совещаний и других бумажных документах

●дела в issue trackers, в том числе выявленные при работе с карточками

Essence

●Планы проектов (то, что удалось спланировать up front) в системе проектного управления.

Конечно, это далеко не полный список.

Это риторический вопрос, будут ли все эти списки дел/работ согласованы между собой по названиям, датам, ресурсам, ответственности и т.д. — и какие из этих явных (в случае проектного управления) или неявных (в виде списков дел в issue tracker) планов будут актуализовываться и мониториться в выполнении. Очевидно,

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

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

По какому плану будет вестись проект инженерами? Конечно, будет работать ведение дел (issue tracking) в содержательных терминах (альфы), а не управление проектами: крупные пункты плана проектами ("директивный график" — задаваемый соглашением со стейкхолдерами “политически” и основанный на экспертных оценках, игнорирующих потом выявляемые проблемы) представляются для управления делами крупными целями, но более мелкие задачи формулируются "с голоса" по ходу проекта и попадают в самые разные распорядительные документы и даже проходят мимо документов — поручения "в рабочем порядке", пункты протоколов совещаний, пункты отдельных приказов, и issue в каком-нибудь issue tracker. Конечно, инженер предпринятия должен по возможности минимизировать число систем, в которых ведётся учёт дел (а часто и минимизировать число планов проекта: в крупных проектах легко найти пять разных планов проекта, не совпадающих друг с другом!).

Но в момент прохождения гейтов (принятия решений “Go — No Go” между стадиями жизненного цикла) все эти планы проверяются на соответствие — понимание рисков инженерами и менеджерами согласовываются. Это хорошо понимают разработчики систем ведения дел (”управления задачами”). В этих системах стремительно появляются возможности систем проектного управления (например, показать диаграмму Гантта для имеющихся в системе задач).

Управление мероприятиями

Управление мероприятиями (Event management is the co-ordination, running and planning of all the people, teams and features that come together to create every kind of event, http://www.eventbusinessacademy.com/why-events/what-is-event- management, часто переводят как “событийный менеджмент”) предназначено главным образом для управления проведением какими-то собраниями людей: Олимпийских игр, концертов, конференций, фестивалей. Тут мы приводим в пример “управление мероприятиями” просто для того, чтобы показать огромное разнообразие деятельностей по производству разного типа целевых систем и сервисов, которое требует создания самых разных видов обеспечивающих (enabling) предпринятий.

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