Текст книги "Методология 2023"

Эксплуатация как выделенная стадия жизненного цикла

Эксплуатация/использование/operations/функционирование/задействование – это особая стадия жизненного цикла, поскольку именно на этой стадии у нас с описанием и воплощением целевой системы имеют дело не создатели, а системы в операционном окружении. Создатели при этом могут быть операторами, ремонтниками, модернизаторами, но их работу относим по большей части ко времени создания. Спорным тут может быть пункт про операторов, но есть тенденция заменять операторов на автоматы, начиная с центробежного регулятора Уатта для паровых машин, заканчивая автоматизацией работы логиста в сети поставок/supply chain и операционного менеджера на предприятии. Это общий тренд: первые ламповые телевизоры имели по шесть рукояток настроек с каждого бока, чтобы зрители могли подстраивать плывущие параметры аналоговых схем, а современные телевизоры никаких «настроек» вообще не имеют (хотя можно залезть глубоко в меню и настроить один раз приятную для какого-то зрителя цветность, но это не требует выделенного оператора). А уж сколько менеджеров среднего звена заменил софт issue tracker, так и сказать нельзя. Очень часто оператор именно что налаживает работу целевой, а не собственно «работает на» – он из соседней системы, создателя (ну, или создателя создателя, если речь идёт о цепочке создания). Так, на поверку кто-то на должности операционного менеджера (должность с названием таким же, как роль!) чаще всего выполняет не столько эту роль «оператора созданной уже организации», то есть роль операционного менеджера, сколько роль менеджера по развитию (то есть занимается орг-проектированием и лидерством).

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

Вот схематически это показано на примере сверхсложной системы – человека.

Сам человек тут показан как система, которую делают (а не которая сама растёт-развивается). В отличие от биологических жизненных циклов тут показан не жизненный, и не цикл – ибо не рассматривается цикл биологической жизни человека, биологическая жизнь входит в предлагаемый метод описания (viewpoint) только как часть важных событий, а акцент делается на практики/деятельность/методы/труд систем создания и их роли.

Человека рожают (показана семья как система создания, выполняющая практику рождения), учат (школа/учительница как система обучения, «система создания, выполняющая практику обучения»), и в этот момент, когда он ещё не вырос, и недоучен, он не является полностью дееспособным. Но даже в этот момент человек-агент уже может иметь в себе две части: одна часть будет учиться и тем самым целевой, а вторая часть будет учителем::создатель). На схеме это вроде как не отображено, но не факт: это ролевая картинка. И какой-нибудь Теодор в десятилетнем возрасте может вдруг стать не только Теодором-учеником, но и одновременно Теодором-учителем (и перед этим Теодором-тьютором, чтобы подобрать для себя то, чему он хочет научиться), и пойти по какому-нибудь самоучителю (что вряд ли), или даже тихо пытаться научиться нарисованным на экране мечом бить нарисованных на экране монстров в видеоигре (что очень вероятно). Затем человек эксплуатирует сам себя, ибо у него появляется самопринадлежность (и тут могут возникнуть трудности, если этот человек не может встроиться в какую-то надсистему: так, мало кому нужны люди, умеющие нарисованным мечом бить нарисованных монстров, а уж люди, тупящие в социальных сетях на просмотре мемасиков и подавно ни в каких надсистемах как создатели чего бы то ни было не нужны). В ходе эксплуатации мы находим множество систем в его операционном/эксплуатационном/системном окружении. В это же время нарастающее время уходит на практики ремонтов (врачи как системы создания) и «модернизации» (учёба, физподготовка), но чаще всего это в процессах разработки/моделях жизненного цикла не отражается. А затем доктора его главным образом лечат (эксплуатация закончена, человек больше не работает – выведен из эксплуатации), а потом микробы прекращают существование тела (практика ликвидации. Альтернативная реализация практики ликвидации в данном случае – кремация, там без микробов). А как же развитие? Тут несколько вариантов: или мы рассматриваем «биологический жизненный цикл» с деторождением (и пытаемся сделать детей этого человека умней и здоровей, чем он сам), или считаем, что живёт дальше не сам человек, а порождённые им в ходе «эксплуатации» мемы – реплицируются, добавляя что-то в развитие коллективов, обществ, сообществ, человечества. Одна из форм – создание этим человеком книг, курсов. Другая форма – создание учеников, которые будут реплицировать новое знание, порождённое в ходе жизни нашим «человеком с картинки». То есть ход на развитие – это ход в эволюцию, преодоление ограничений одного экземпляра системы, даже если система эта – человек. Считаем по факту человека не целевой системой, а станком-создателем в цепочке создания. Всё это сложней, ибо человек может учить сам себя, быть станком для самого себя, и развитие будет и у него тоже, но он может и учить других людей, учить компьютеры, оставлять знание в форме, удобной дальше для обучения, а также может это делать абсолютно впустую – эволюция бездушна, и именно эта линия репликации новых мемов человека может оказаться неудачной, «жил впустую», как вроде как впустую жили динозавры и саблезубые тигры – и потом вымерли. Но не факт, что они жили «впустую», ибо существенно влияли на выживание других видов. Так и люди, чьи идеи/мемы потом «вымерли» в их книгах, или детях, или рабочих продуктах, вполне могли самим наличием этих идей в их времени и их месте существенно повлиять на судьбу тех идей, которые смогли отреплицироваться.

Где же тут «жизненный цикл человека», «процесс разработки», «создание и развитие»? А вот это и есть «метод создания и развития человека»: все выполняемые практики всех систем создания (родителей, учителей, самого человека в «работе над собой», докторов и даже микробов), реализованные/воплощённые в работах/сервисах по «замысливанию», «проектированию», «производству» и «выводу из эксплуатации» человека, плюс практики работы операционного окружения с целевой системой, реализованные соответствующими работами в ходе стадии эксплуатации (практики контрактации, лидерства, оплаты труда и т.д.). Системное мышление обращает внимание тут на типы объектов: целевую систему, системы в окружении, системы (возможно, в цепочках) создания, практики/труд/методы и работы. В рассуждениях про жизнь человека («жизненный цикл человека») должны быть учтены они все, все оставаться во внимании при мышлении о проекте «человек»! Если вы о чём-то из этого списка не подумали, то в проекте вас ждут сюрпризы, и не все из них будут приятными.

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

Есть два разных понимания эксплуатации/использования в части представления ремонтов (обслуживания, maintenance – конструкция и функциональность остаются прежними) и модернизации (modernization, частичное изменение функциональности и конструкции, при этом «непрерывное всё» по факту означает непрерывную модернизацию, развитие/эволюция – это непрекращающаяся модернизация, даже если она происходит с разными экземплярами системы):

• Эксплуатация как стадия::работа включает в себя все эти подстадии::работы. Главные проектные роли – операторы и различные виды пользователей. Ремонтники и инженеры по модернизации отдельно не учитываются, создатели сделали своё дело и можно о них забыть.

• Техобслуживание и ремонты, равно как и модернизация считаются отдельными стадиями жизненного цикла, при этом модернизация разделяет несколько разных (первую, вторую и т.д.) стадий эксплуатации, а «техобслуживание и ремонты (TОиР)» считается стадией, которая протекает в одно и то же время («перекрытие стадий жизненного цикла») с эксплуатацией, понимаемой как «рабочее функционирование» (operations). То есть техобслуживание и ремонты не считаются «короткими стадиями», а считаются длинной стадией, которая длится всё то же самое время, которое длится сама стадия эксплуатации – и это неважно, что сами работы по обслуживанию и ремонтам составляют не слишком большое время от этой стадии. Важно, что в мышлении разделяются работы разных людей, эти работы (во время, когда система работает/эксплуатируется, и во время, когда система не работает, а над ней трудятся системы создания) в обсуждениях не смешиваются друг с другом.

Это лишний раз подчёркивает условность отнесения работ к разным стадиям и необходимость упора на обсуждение метода/практик/способа работы. Практики – это способы выполнения работ, которые вы должны делать с системой, чтобы она была успешной. А уж сами работы по этим практикам вы будете выполнять в самых причудливых конфигурациях: последовательно, параллельно, сжато или растянуто во времени в зависимости от ресурсов, одним мультиспециалистом или сотней «узких спецов», это будет зависеть от конкретной проектной ситуации. Но если в проекте нужно разрабатывать архитектуру (практика), то вам придётся предусмотреть эти работы и найти оргвозможность – сама архитектура себя не разработает и не задокументирует, не объяснит себя разработчикам и не проверит, придерживаются ли её разработчики в своей работе, а потом ещё и сама себя не изменит, когда выяснится (кем?), что текущая архитектура неадекватна и её надо срочно менять.

Цепочки создания

Нужно всегда понимать, о какой системе (целевой, в окружении, или создающей) вы говорите в каждый конкретный момент – ибо речь идёт о вашем осознанном внимании к разным объектам, да ещё и разным временам. Например, когда вы просто упоминаете «топор», то непонятно – вы делаете топор (топор – целевая система), вы используете топор для колки дров (целевая система – дрова, топор – «один из создателей»/«одна из систем создания», необходимая для подготовки целевой системы-дров к эксплуатации – сгоранию в печке) или топор для вас одна из систем в окружении целевой для вас колоды, совместно с которой топор должен колоть дрова и свойства которого вы выясняете для того, чтобы спроектировать и изготовить правильную колоду4040
  http://forum.rmnt.ru/threads/koloda-dlja-kolki-drov-nou-xau.102202/


[Закрыть].

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

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

На таких диаграммах (её рисовать несколько секунд!) удобно рассказывать истории про цепочки создания типа «мы организуем стартап, который создаст САПР, при помощи которого мы затем спроектируем топор, при помощи которого мы потом будем колоть дрова, при помощи которых потом мы приготовим обед» – и для каждой системы в цепочке создания в такой диаграмме понятно, что она проходит довольно долгий период собственного изготовления перед тем, как быть использованной/проэксплуатированной. Недостаток такой картинки – она по факту про физическое время, хотя и предельно абстрактно нарисованное (одно из ранних пониманий жизненного цикла как «водопада» стадий::работ, а не практик), но главное – системы не просто разово вводятся в эксплуатацию, они продолжают модифицироваться в ходе эксплуатации, то есть после ввода в эксплуатацию продолжается стратегирование новых возможностей/фич, их проектирование, изготовление, инженерное обоснование успешности системы с этими фичами, интеграция в уже работающие системы.

Давайте вспомним об альфах, они вводились в курсе «Практическое системное мышление». Перейдём к языку не работ, а практик: альфы – это объекты отслеживания в проекте, ибо по ходу создания систем альфы меняют свои состояния, поскольку для смены состояний альф проводятся работы по каким-то практикам.

Давайте представим какие-то области интересов по именам типовых систем, которыми занимается какое-то предприятие/фирма:

• Целевая система: система, которую делает фирма

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

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

• Создатель команд фирмы (который будет создавать команду инженеров и команду создателя агентуры, то есть команда менеджеров фирмы, занимающихся её развитием)

• Создатель создателя команд фирмы, который создаёт инвестуру – группу инвесторов, которые дают фирме необходимый для развития капитал (то есть команда основателей фирмы, которая проводит соответствующие переговоры с инвесторами, оформляет инвестиционные сделки и организует/создаёт и развивает команду менеджеров)

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

• Создатель клиентуры (агентура, то есть группа агентов, которая будет вербовать клиентов)

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

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

Когда мы рассматриваем системы попарно: создатель::система «создаёт и развивает»::деятельность «свою систему»::система, то если «своя система»::создатель, эту цепочку можно продолжить. А ещё один создатель может создавать несколько систем, и цепочки в этот момент оказываются графом.

Исключительно для иллюстративных целей приведём диаграмму графа создания как набора цепочек создания (в жизни вы будете создавать и заполнять списки и/или таблички, а не диаграммы, ибо замучаетесь вносить постоянные изменения в диаграмму, но про таблички расскажем чуть позже)4141
  Картинка высокого разрешения – https://ic.pics.livejournal.com/ailev/696279/215914/215914_original.png


[Закрыть]:

Все цепочки создания в графе создания так или иначе ведут к целевой системе, но при желании можно показать, что целевая система тоже что-то создаёт, она вполне может быть не последняя в цепочке (это легко может оказаться станком, который купил у вас клиент). Цвета областей интереса взяты по мотивам стандарта OMG Essence: относящиеся к целевой системе альфы даются на жёлтом фоне, надсистеме – на салатном фоне (клиентура как внешние проектные роли имеет потребность каких-то характеристик надсистемы, которые может дать целевая система в составе надсистемы, так что клиентура тоже попадает на салатный фон), а вот команды-создатели в их цепочках даны на голубом фоне. По большому счёту, мышление про все эти показанные системы в их цепочках одинаково, так что цвет в рассуждениях оказывается не так важен. Но можно его учитывать. Так, жёлтое – это начало всех начал, целевая система, и поэтому все рассуждения должны как-то приводить к её созданию и улучшению, зелёное – это системы и команды (внешние проектные роли) вовне фирмы, а голубое – это и есть сама фирма, внутренние проектные роли. Это альфы, так что разговор про огроли, а оргзвенья тут будут с точки зрения OMG Essence рабочими продуктами, по которым мы будем определять состояние альф. И помним, что в OMG Essence онтология кривовата (об этом предупреждалось ещё в курсе «Практическое системное мышление»), поэтому любителям строгости и формализмов приходится туго, но мы не будем тут что-то сочинять своё, а будем задействовать язык/language/дисциплину этого стандарта – OMG Essence как раз предназначен для описания методов/процессов/практик разработки, вот мы и будем использовать его понятия для этих целей, разве что не советуем использовать предлагаемую этим стандартом нотацию (как текстовую, так и диаграммную) и предложенный в нём набор областей интереса и альф (в языке стандарта это kernel, «основные альфы»). Не нужно копировать эту диаграмму, не нужно даже её рисовать свою, адаптированную. Нужно будет прописывать ваши варианты цепочек создания для вашего проекта, а также описывать состояния альф из этих цепочек создания в табличках в каком-то универсальном моделере. Как это делать, будет рассказано дальше.

Мы (кто мы? Команда, коллектив команд, предприятие? Владельцы, менеджеры, инвесторы?) создаём софтверную компанию, которая разработает софт ведения общей модели данных в ходе строительства моста, проектный институт предусмотрит этот софт при проектировании стройки, а стройка будет эксплуатировать этот софт, когда будет строить мост. А целевая система? Мост (как провайдер «транспортного потока», эту цепочку создания можно продолжать!). И придётся тщательно проработать всю эту цепочку создания (она тут ещё и не вся прописана! Создателей в самых разных цепочках, и даже не столько цепочках, сколько графах создания тут много больше). Если вы не научитесь моделировать и документировать такие цепочки, каждый раз доводя их до целевой системы, то вы будете вынуждены находиться в клубке бесконечных обсуждений того, чем же вы занимаетесь в рамках какой-то невнятно «тусующейся» толпы самых разных людей из самых разных служб самых разных компаний со всеми важными и неважными деталями описания. Плохо будет понятно, чем из всего обсуждаемого нужно заниматься, и нужно ли вообще этим заниматься. Если вы моделируете и документируете цепочку создания, то вы очень быстро говорите, зачем и почему нужен ваш проект (обычно он где-то в середине какой-то из цепочек создания в графе создания), как он приведёт к успеху целевой системы (ну, или понимаете, что проект не влияет на успех целевой системы, поэтом никому кроме вас не нужен, и закрываете этот бесперспективный проект).

Чем дальше по цепочке создания вы находитесь от целевой системы, тем больше внимания вам нужно ей уделять: от вашего мышления потребуются усилия, чтобы удерживать её во внимании. Системное мышление требует собранности: найти целевую систему, а после этого спроектировать и обосновать всю цепочку создания до «вашей» системы, не пропуская ни одной системы в этой цепочке и удерживая во внимании пользу всего проекта для целевой системы. Без собранности у вас не получится не терять из виду целевой системы. Совет тут обычный для усиления внимания: документируйте описание/модель цепочки создания! Это поможет удержать внимание к целевой системе.