March 13th, 2013

2021 год

Мастер метод менеджмент

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

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

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

Фишка в том, что есть ещё и абстрактные сущности, которые существуют независимо от конкретных дел и их моделей -- все эти "требования", "стейкхолдеры", и даже та самая "технология". Ну, и деятельности типа "исследовать возможности" (explore possibilities). Этот набор абстрактных сущностей тоже описывает некий "абстрактный" (не привязанный к конкретной технологии, т.е. конкретным используемым инструментам и продуктам работы и выполняемым с этими инструментами делам по изменению продуктов работы) метод, "неситуативный метод", "обобщённый метод". Вот понимание этих абстрактных сущностей и есть образование. Образование сохраняется при смене инструментов и рабочих продуктов -- это те акценты внимания, которые у вас будут при любых используемых инструментах и рабочих продуктах. Если вы усвоили важность работы с "требованиями", то хоть формальные модели требований на SysML, хоть use cases, хоть user stories, хоть использование GRN -- вы не забудете про нужность работы с требованиями, а уж конкретным премудростям вас обучат на месте. Если не понимаете про абстрактную сущность "требования" -- то вам, необразованному, никакое повышение квалификации в конкретном методе работы с требованиями не поможет.

Итого:
-- софт для образования каким-то образом должен в себе описание набора сущностей (kernel какой-то дисциплины с расширениями для поддисциплин) метода, а для обучения ещё и описание практик (дел и продуктов работы, связанных с используемой технологией).
-- я думаю, что люди из мира учебного софта (образовательного, который "для университетов" и который покупают ректораты и деканаты, и обучающего, который покупают HR-службы предприятий) вообще о ситуационной инженерии методов не слышали. Они сегодня все думают в терминах scorm-пакетов (думайте в этом месте об использовании интерактивного-PowerPoint-на-стероидах, в котором никаких знаний о самом учебном предмете нет, а есть только знание об учебной форме).
-- про архитектуру предприятия (которая должна быть озабочена, чтобы все эти методы работы стыковались с бизнес-архитектурой, то бишь содействовали бизнесу, а также с архитектурой IT-решения, то бишь поддерживались софтом и инструментами) я тут вообще молчу.

Так что какая-нибудь "утренняя продувка" будет вышита крестиком минимум четырежды:
-- в архитектуре предприятия, чтобы понимать, какие софты её поддерживают (и это будет счастье, если кусок "бизнес-процессов" и регламентов работы не оторвут от этой архитектуры в какую нибудь "службу качества"),
-- в описании метода работы (ибо в какой-то момент менеджеры среднего звена вдруг начинают понимать, что им нужны для людей совсем не те описания, которые им предлагают делать на всяких изводах BPMN или даже ArchiMate люди из архитекторов, а документы "службы качества" хороши только для отчётности о взятых у работников интервью сотрудниками этой службы).
-- этих самых scorm-пакетах образовательных продуктов, которые будут жить где-то в районе HR-службы. Ибо людей-то учить нужно!
-- а теперь, когда всё описано, развёрнуто и обучено, мы со всем этим раздраем попытаемся метод исполнить: опишем его для этого, например, в трекере/планировщике системы adaptive case management (ну, или в виде шаблона проектного управления, или процесса в BPMS -- это уж кому как понравится).

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

Это и есть современное состояние корпоративных информационных технологий, сегодняшние "лучшие практики".

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

Возможные сценарии развития событий:
-- описание деятельности (текущая конфигурация деятельности) содержится где-то в одном месте, остальные софты его пользуют из этого одного места. Хорошего ничего не будет, ибо всем этим софтам нужно про деятельность знать совершенно разное.
-- софт business intelligence научится заглядывать в знания (то бишь повторно где-то используемую информацию) одной системы и другой системы, и предъявлять нестыковки в виде списка issue. Что-то типа сегодняшней системной инженерии, в которой модели склеиваются друг с другом исключительно для целей раннего (в компьютере, а не в жизни) обнаружения ошибок.
-- описание деятельности будет переползать из системы в систему, попутно обогащаясь содержанием и меняя формы: generative organization engineering, оно же model-based organization engineering. То есть одни модели деятельности, менее детальные, будут порождать (с использованием справочных данных и данных конфигурации) более детальные модели деятельности.

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

Так что ждём-с появления управления конфигурацией не только оборудования, не только проектируемых и эксплуатируемых систем, но и управления конфигурацией методов работы. Мастер метод менеджмент, инженерия справочных методов и так далее, по всему списку.
2021 год

ISO 15288 и OMG Essence

Сначала нужно похвалить: ISO 15288:2008 очень хорош, ибо чётко прописал те деятельности, которыми занимаются системные инженеры, предложил какую-то классификацию этих деятельностей, и даже намекнул на те сущности, с которыми приходится иметь дело системным инженерам. Кроме этого, стандарт представил не только собственно системноинженерные деятельности (технические), но и деятельности системно-инженерного менеджмента (проектные, обеспечивающие проекты, и связанные с контрактацией). Стандарт примерно соответствует тому, что проходят в курсе "Введение в системную инженерию": рассказывает, чем занимаются системные инженеры по мере прохождения жизненного цикла. В своей нормативной части стандарт подразумевает какое-то подобие чеклиста: если какими-то деятельностями, описанными в стандарте, люди предприятия не занимаются, то это значит, что они не занимаются системной инженерией. Ну, и стандарт предлагает какую-то консистентную терминологию, чтобы обо всём этом разговаривать. И к нему прилагаются технические отчёты с разъяснениями. А ещё это международный стандарт, и никому не нужно объяснять, почему вдруг именно его нужно класть в основу регламентов предприятия.

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

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

Как я советовал бы использовать OMG Essence в проектах системной инженерии? Очень просто: выкидывать слово software из словосочетания software system -- и использовать "из коробки", даже без расширения начального набора сущностей. Это сразу будет очень и очень полезно, я это пробовал делать на нескольких проектах.

Дальше правильно было бы специализировать (расширить) начальный набор сущностей до традиционного, находящегося во внимании системных инженеров. Для этого я бы рекомендовал брать ISO 15288 как краткое хоть как-то структурированное описание деятельностей системной инженерии (сравните, например, абсолютно бесструткруное описание вида "чего бывает в цирке" из BKCASE/SEBoK), и перекладывать его в формат Основ. Какие при этом возникают проблемы? Вот очень краткий списочек (и нужно понимать, что аналогичные проблемы будут возникать при перекладывании в этот универсальный язык описания методов многих других подобных стандартов -- всех этих CMMI, PMBoK, ITIL и т.д. и т.п.):

1. Основная структура описания деятельности системных инженеров в ISO 15288 структурирована по требованиям ISO 24774 (не путать с ISO 24744) -- process-activities-tasks. Выше -- группы, выделенные по принципу перехода от рассмотрения целевой системы к рассмотрению обеспечивающей системы. Она принципиально не совпадает с принятой структурой описания деятельностей и дел (activity spaces, activities, activities approaches и т.д.) в Основах. Я предлагаю не зацикливаться на собственно деятельностях-глаголах, ибо их сложнее всего распознавать, отделять друг от друга, описывать и обсуждать. Нет проблем иметь хоть два, хоть три, хоть пять классификаций видов деятельности. Пусть будут обе классификации, нет проблемы.

2. ISO 15288 не отделяет важное от неважного. Конечно, там говорится что-то типа "работайте с требованиями" и "договорись о методе разработки" (звучит это в нём как требование выбрать вид жизненного цикла"). Но внимание читателя сконцентрировано главным образом на видах необходимых работ, а не на альфах и рабочих продуктах. Так что первым делом нужно вытащить из ISO 15288 альфы и подальфы. Вот, например (http://ailev.livejournal.com/706776.html):
а) источники потребности заинтересованных сторон (sources of stakeholder need). Говорится, что время жизненного цикла системы идет -- и потребности заинтересованных сторон могут поменяться. Поэтому нужно поддерживать отнесение требований заинтересованных сторон к источникам их потребностей, чтобы не прозевать момент изменений этих потребностей и соответствующий пересмотр записанных требований.

б) требования заинтересованных сторон (stakeholder requirements) -- включая все вопросы их формулирования, полноты выявления, устранения в них противоречий, выкидывания нереализуемых или непрактичных требований.

Это все практика определения требований заинтересованных сторон (Stakeholder Requirements Definition Process). Один из пяти результатов выполнения этой практики -- "выявлены требования заинтересованных сторон для валидации".

в) системные требования. Цитата: "Назначение практики анализа требований – переработать основанную на требованиях заинтересованных сторон группу описаний желательных функций в техническую группу описаний требуемого продукта, который может предоставить эти функции. В ходе данной практики строится представление удовлетворяющей требованиям заинтересованных лиц будущей системы, и которое, насколько то позволяют ограничения, не предполагает никакой определенной реализации. Практика приводит к измеримым системным требованиям, которые с точки зрения поставщика специфицируют, какими характеристиками и в какой степени должна обладать [система], чтобы отвечать требованиям заинтересованных сторон".

Это уже практика анализа требований (Requirements Analysis Process). Один из четырех результатов выполнения этой практики -- "определена основа для верификации соблюдения требований к системе".

Поддержка и регулярная демонстрация соотнесения (tracability) всех элементов слоев этого блинчатого пирога: заинтересованные лица <--> их потребности <--> их требования <--> системные требования <--> проект-design <--> система. Для этого используется правильное хранилище данных (data repository).
Обратите внимание, что высказываемые в ISO 15288 соображения по требованиям по-другому рассортировываются -- ибо речь идёт о разных областях интересов (клиентской, решения, предпринятия). Но самое интересное наступает потом:

3. Оформить найденные альфы: отличить "настоящие альфы" (которые присутствуют во всех проектах системной инженерии) как сущности, которые проходят свои состояния, от несущностных конкретных/практических повышающих свою детализацию рабочих продуктов , через которые эти альфы проявляются. А затем определить наборы состояний для этих альф. Тут эвристика: поскольку изменения состояний альф будут определять границы стадий жизненного цикла, то изменения состояний альф -- это часто будет изменение "cognitive framework" (помним, что ISO 24744 определял стадии жизненного цикла как то, что различается своим cognitive framework -- чем забита голова у работников на этой стадии). То есть поменяли предмет размышлений -- поменялось состояние альфы. А затем нужно создать список контрольных вопросов, подтверждающий состояние этих альф.

4. Явно выделить отсутствующие в ISO 15288 компетенции системного инженера и системноинженерного менеджера (systems engineering management), отсортировав их от общих инженерных компетенций -- помним, что OMG Essence говорит о всей работе по созданию системы, как системно-инженерной части "удержания целого", так и всей работе инженерных специальностей, плюс всей работе менеджеров.

Конечно, это только основные вопросы. Я даже не касаюсь, например, вопроса об использовании паттернов OMG Essence для выражения всех понятий из ISO 15288 -- до этого момента нужно ещё провести огромное количество работы.

Я бы сейчас предложил после разбирательства с этими основными проблемами не столько выполнить проект по конвертированию полного содержания ISO 15288 в формат OMG Essence (получив "суженный расширенный" его вариант -- суженный за счёт ограничения только сущностями и абстрагируясь от упоминания конкретных практик, а расширенный за счёт явного доформулирования состояний и списков контрольных вопросов к этим состояниям), сколько озаботиться о том, как эти описания потом будут использованы в ходе реальных крупных инженерных проектов. Ибо все примеры использования OMG Essence пока игрушечны, и авторы не скрывают, что они сами хотели бы работать с отдельными небольшими командами проектов. Для системной инженерии тренд резкого снижения числа непосредственных участников одного проекта также есть, но всё-таки он не так выражен пока, как в софтовых проектах. Так что для системноинженерного использования ISO 15288 в формате OMG Essence нужно:
-- предложить корпоративные процедуры method enactment
-- внимательно подумать над тем, как (в каком виде, по каким процедурам, когда и почему) эти описания того, что должны делать системные инженеры попадут к разным другим людям, связанным с организацией работы и управлением технологиями работы (это я рассматриваю в посте http://ailev.livejournal.com/1067676.html).