Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Облегчённые основы (Essence light)

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

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

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

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

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

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

Когда мы обсуждаем деятельность, дисциплины, практики -- это обсуждение "вообще", не относимое к конкретному проекту, начинанию (предпринятию). Говорят о "методологической реальности", в которой идёт это "обсуждение вообще". В "реальности предпринятия" обсуждаются уже конкретные объекты и дела. Достижение каждого состояния альф соответствующей дисциплины в конкретном предпринятии должно быть проведено так, чтобы были положительные ответы на контрольные вопросы.

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

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

* * *

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

Вот набор облегчений, о котором я сейчас думаю:
-- kernel это Основы, далее они бьются на набор дисциплин. "Области интереса" (клиентская, инженерного решения, предпринятия) я бы переименовывал по наименованию входящих в основы дисциплин (маркетинг/стратегирование, инженерия, менеджмент).
-- из основ выкидываем "процессный подход" (activity spaces), сосредотачиваемся на дисциплинах, как знаниях о смене состояний альф и связанных с ними рисках (отражаемых в контрольных вопросах по смене этих состояний).
-- положительные ответы на контрольные вопросы требуют практических доказательств (т.е. предъявления рабочих продуктов). Т.е. контрольные вопросы всегда к практике, хотя и могут задаваться в терминах дисциплины.
-- отрицательные ответы (или непонимание того, как обстоят дела) на контрольные вопросы требуют реальных дел (заведения тикета/issue/task -- опустим пока связанные с этим нюансы), выполнение этих дел требует компетенций. "Реальные дела" -- это подчёркивание того, что они в endeavour realm, а не в methodology realm. Дела привязываются к тем альфам и их состояниям (возможно, нескольким сразу), в methodology realm, неответы на контрольные вопросы которых их породили. Никаких activity, activity spaces: завязываем с "процессным подходом". Это case management, issue tracking (а процессное и проектное управление рассматриваем только по сопричастности, когда разбираемся с устройством дисциплин для смены состояний альфы "работа". По-разному выделяем подальфы, получаем разные дисциплины).
-- компетенции переформулируем как профессиональное знание дисциплины и владение технологиями, т.е. компетенции -- это прежде всего компетенции в делах по изменению альф так, чтобы контрольные вопросы были отвечены (т.е. не допускались основные ошибки в работе -- это профессионализм по определению Нильса Бора).

Поддисциплины -- это то, что было extended kernel, в нашем случае это добавленные альфы с их состояниями. Тем самым поддисциплины (и связанные с ними практики, получаемые добавлением к поддисциплинам инструментов и рабочих продуктов) автоматически дадут набор компетенций для членов команды.

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

Уфф, стало легче! Попробуем поговорить теперь на этом языке облегчённых основ (Essence Light). То, что написано в этом посте -- это разворачивание основной (pun intended) диаграммы деятельности. Я долго думал, диаграмма чего это:
-- не инженерного проекта (ибо там куча всяких разных проектов: маркетинговый, инженерный, менеджерский, развития и прочих)
-- не системы, ибо речь идёт не столько о самой системе, сколько о том, как эту систему сделать. Разговор не столько про саму систему (хотя и про неё тоже), а про деятельность в её общем виде (человеческая деятельность, которая меняет мир -- альфы).
-- не жизненного цикла системы, хотя он в скрытом виде он там есть. Хотя мне очень хочется сохранить "управление жизненным циклом" в названии, чтобы отличать всё обсуждение от традиционного обсуждения "управления проектами" или "процессного подхода и цикла совершенствования процессов". Но "диаграмма управления жизненным циклом системы" опять же тут не самый лучший выбор, вид жизненного цикла разработки лучше обсуждать на другой диаграмме (с ленточками состояний альф, но эта "другая диаграмма" уже глубоко индивидуальна для разных проектов -- синхронизация состояний альф может сильно различаться).
-- не дисциплины, ибо там три базовых дисциплины, но все вместе они составляют основы (essence, kernel) деятельности как таковой. Деятельностный подход и системный подход в одном флаконе, "системная деятельность".

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

Ну, и мы будем активно использовать 4D extensionalism: деятельность это 4D индивид, в который отдельные меняющиеся объекты входят как части. Сведение огромного числа отношений к отношениям часть-целое существенно облегчает понимание. Хотя нужно особо отметить, что OMG Essence и ISO 15926 не слишком дружат. Нужно ещё много попотеть, чтобы их подружить.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 7 comments