рабочих продуктов уровень детальности определяется по любому из вопросов, т.е. через "или" ("да" в ответе хотя бы на один вопрос). Состояния альф и уровни детальности рабочего продукта не связаны между собой, они про разное. Так, для согласованных со стейкхолдерами требований спецификация может быть в виде краткого резюме, более-менее подробна, в виде формальной модели. С другой стороны, могут быть детальнейшие требования, которые совсем не согласованы со стейкхолдерами, и эти требования могут быть противоречивы между собой. Так что уровни детальности — это просто уровни гранулярности и объёма информации, который мы можем почерпнуть о той или иной альфе, а уж какое состояние этой альфы — это другой вопрос. Заметим, что работа прежде всего продвигает состояние альф — а уж будет ли продвинуто состояние альфы, если вложиться в работы по повышению детальности рабочего продукта, это большой вопрос. Повышение детальности рабочих продуктов, конечно, как-то связано с общим состоянием работ в проекте, но не впрямую.

Метонимия и схемы

Метонимия — это когда в речи один элемент схемы обзывается другим “по смежности” отношения в схеме (в то время как метафора — это про “похожесть” структур разных схем). Подробней: http://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D1%82%D0%BE%D0%BD%D0%B8 %D0%BC%D0%B8%D1%8F

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

Без метонимии нельзя разговаривать, речь ведь должна быть живой. Но нужно быть крайне внимательным, когда живую речь мы переводим в формальные диаграммы. Читаем схемы мы обычно с использованием метонимии. Писать схемы нужно, устраняя метонимию (это специальная работа онтологического моделирования). Понимать речь нужно, зная о метонимии и не попадаясь в её ловушку перескока с одного элемента схемы на другой по отношениям “род-вид” (специализации), “часть-целое” (композиции), “функционального объекта-конструктивного объекта”

(установки, installed_as).

Методологическая действительность: дисциплины, практики, методы

Дисциплины/области интереса

Основная схема включает указание на три основные предметные области/области интереса/дисциплины (area of concern), они выделены на диаграмме зелёным, жёлтым и голубым цветами:

●Технологический менеджмент, упор на маркетинг/стратегирование: как сотрудничать со стейкхолдерами, которые дают возможности для самых разных проектов (“предпринятий” — от “предпринять что-то”) и соединять их

с возможностями, которые даёт команда. Если возможности стейкхолдеров и команды совпали, то проекту быть! На диаграмме эта предметная область/дисциплина отмечено, как относящееся к “клиенту” (client). Системная инженерия всегда кого-то обслуживает! Инженеры не разрабатывают системы сами для себя!”

●инженерию: как придумать/определить и сделать/воплотить успешную систему. На диаграмме это область “инженерного решения” (solution, не путайте с decision!).

●Инженерный менеджмент, упор на операционный менеджмент и лидерство: как собрать и сплотить компетентную команду, оснастить её всеми необходимыми технологиями и организовать работы по проекту. На диаграмме это область “предпринятия” (от “предпринять” что-то, но слово “предприятие” не подходит, речь тут идёт не о юридическом лице — это может быть и большой холдинг, и какая-нибудь “рабочая группа проекта”. В OMG Essence это “Endeavor”, ибо стандарт писали в США главным образом. В Англии было бы “более по-французски” — Endeavour).

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

Каждая из основных дисциплин состоит из своих поддисциплин. Например, инженерия включает в себя поддисциплины:

●инженерия требований (требования — это часть определения системы)

●инженерию системной архитектуры (системная архитектура — это часть определения системы)

●системный дизайн (3D-модель — это часть определения системы)

●проверки и приёмка (соответствия определения и воплощения системы, воплощения системы и возможностей стейкхолдеров)

●управление конфигурацией (поддержка целостности определения системы и его соответствия воплощению системы)

●специальные инженерии (электрика, теплотехника, программная инженерия,

...), работающие со своими особыми частями определения и воплощения системы.

●... (этот список далеко не полный).

Это, конечно, очень упрощённое представление о предпринятиии. Так, есть особенности для предпринятия как нового инвест-проекта и предпринятия для проекта разработки в уже давно состоявшемся предприятии. Технологиями обычно занимаются CTO (chief technical officer) и CIO (chief information officer), их часто

относят к технологическому менеджменту, а не инженерному менеджменту. Но тут важно понять идею: выделять отдельные области интересов и обсуждать их по отдельности (мыслительно «разделять и властвовать», принцип separation of concerns), не валить всё в кучу, предполагать какое-то разделение труда, наличие разных дисциплин.

Практики

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

Тем самым в простейшем варианте (пока мы не обращаем внимания на дела, процедуры, операции и т.д.):

●Дисциплина = набор альф, уровень учебника (”дисциплина грузится в голову”).

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

●Практика = дисциплины + технология.

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

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

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

Практика также имеет указание на единицы измерения, оценивающие результаты (performance) практики и меру достижения её цели. Измерения проводятся и документируются в ходе выполнения практики.

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

Практики объединяются (composition) в другие практики, чтобы охватить больше аспектов. Когда результат такого объединения практик охватывает все аспекты

проекта, тогда это уже метод.

По-русски чаще всего описание практики оформляют в виде “методических рекомендаций”, “методики”.

Метод

Метод — это сочетание дисциплины и набора практик для достижения какой-то цели. В инженерии бывают методы разработки, методы сопровождения, методы интеграции систем, методы проведения испытаний, в операционном менеджменте бывают методы управления проектами, методы обеспечения цепочки поставок и т.д.

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

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

Практики, которые составляют (articulate, make up, contained in) метод, должны удовлетворять свойствам:

●однородности (coherency): достижение цели каждой практики даёт вклад в достижение цели всего метода.

●связности (consistency): каждый вход (entry) и результат (result) взаимосвязаны и используются.

●полноты (completeness): достижение целей всех практик означает достижение цели метода и достигает ожидаемого результата.

Эти свойства в начале создания (authoring) метода почти никогда не присутствуют, любой проект начинает набирать практики своего метода по мере понимания ситуации.

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

Методов десятки тысяч, но практик в них много меньше. Практики как слова, из которых можно составить множество методов-предложений. Каждый проект должен получить свой метод, ни один метод не работает для разных проектов. Так, если проект небольшой, то работа с требованиями может проходить с использованием практики user story, если проект большой, то необходимо уже использовать практику Use Case. Если нужно вести какие-то списки, то “в ворде” можно справиться с текстовым списком не более чем на 400 элементов, а если элементов списка больше, то для его ведения нужно уже использовать какие-то другие практики — другие технологии (базу данных, например), хотя дисциплина ведения списка может остаться той же самой. В зависимости от природы системы, наличия специалистов и доступности технологий используемые даже в похожих проектах методы могут разительно различаться из-за вариации в использованных практиках.

В зарубежной практике слова method, methodology обычно считаются синонимами. По-русски описание метода иногда называется “методология” (не путать с “методикой”, которая только часть методологии и означает обычно описание практики).