Признаки целевой системы
Целевая система выявляется/discover ситуативно, о ней договариваются командно, нет никакого алгоритма или «типовых ситуаций». Тем не менее, есть эвристики (правила, которые срабатывают часто, но не всегда[1]), которые помогают найти целевую систему какого-то коллективного проекта среди многочисленных самых разных систем в самых разных вариантах системных разбиений. Да, в системном мире царит вроде как хаос из совокупности самых разных субъективных мнений, но человек склонен упорядочивать и хаос, находить в нём паттерны — символ хаоса совсем не случайно выглядит весьма структурированно:
Надёжного алгоритма выявления целевой системы нет, вы просто будете делать много догадок и затем критиковать их, чтобы принять всерьёз ту догадку, которая пережила критику. Принять всерьёз — это действовать так, как будто эта догадка и есть верная. И так действовать, пока не появится догадка получше — тогда быстро бросать старую догадку и переходить на новую, действовать в реальном мире, опираясь на эту новую догадку. Есть множество приёмов мышления, которые помогут быстрее формулировать, а затем оценивать догадки по поводу того, что же в вашем проекте будет целевой системой.
Слово «выявление**»** (discovery) тут использовано не случайно: считается, что целевая система есть, она задана типом мета-мета-модели «целевая система»::система и её нужно только найти/выявить своим вниманием, определить её границы — возможно, поговорив при этом с большим количеством самых разных исполнителей самых разных ролей. Нас тут не смущает, что речь идёт о будущем — в пространстве-времени эта система уже существует, только в будущем отрезке времени, не прямо сейчас, это не мешает описывать целевую систему и её роль в надсистеме уже сегодня. Не смущает и то, что «поговорить со всеми» — это необязательно узнать их мнение, можно и наоборот — договориться с ними, что они согласны с вашим мнением о целевой системе. Вообще, неважно, кто именно высказал хорошую догадку о том, какова целевая система в вашем проекте. Это можете быть вы, это может быть какой-то AI, это может быть какой-то участник проекта. Главное, чтобы догадка была высказана, а потом она пережила критику.
Концепция использования как описание функциональности «чёрного ящика» системы в надсистеме — её не «выдумывают», не «разрабатывают», её как раз выявляют, договариваются по поводу того, что там будет с функциональностью системы, причём обязательно это документируют. Неправильно использовать вместо «документируют» термин «фиксируют», т.е. закрепляют описание. Концепция использования — это догадка, она будет уточняться и корректироваться до самого конца проекта, в модели системы как «чёрного ящика» всё время будут вноситься изменения, ничего «фиксированного» нет!
Договориться по поводу целевой системы, чтобы потом по отношению к ней договариваться обо всех других важных системах, в том числе о «нашей системе» — это подготовить концепцию использования, в которой описать целевую систему как вписанный в надсистему «чёрный ящик», удовлетворяющий интересы внешних проектных ролей. Основное в концепции использования — это сценарии использования, то есть поведение целевой системы в разных ситуациях, которые предъявляет ей окружение. А уж как целевая система будет устроена — это потом, это будет уже концепция системы. В концепции использования становится понятным, что в мире относится к целевой системе, а что попадает в её окружение в момент использования. Решения о том, как будет устроена система (концепция системы) и как будет устроено её создание и развитие (решения по составу и структуре графа создателей) логически принимаются потом, хотя обычно все они разрабатываются параллельно: концепция использования учитывает пределы возможного (чтобы не оказалось, что это концепция какой-нибудь скатерти-самобранки или ковра-самолёта, которые непонятно как сделать и непонятно кто будет изготавливать), но всё-таки вопрос ставится как «сначала опишем, что система должна делать, то есть какие объекты в окружающем мире в какое состояние приводить, а затем — из чего её делать и как она должна быть устроена, затем — какими методами её делать, и только затем — у кого есть мастерство и инструменты для поддержки таких методов, которыми систему можно сделать».
Например, вы хотите поручить каким-то другим людям-подрядчикам создать какую-то систему в вашем проекте (инструмент создателя в вашем графе создателей целевой системы или просто подсистему целевой системы), чтобы не делать её самостоятельно, то есть хотите купить уже готовую систему или попросить разработать и сделать систему «под заказ». Вы формулируете и документируете, что именно хотите купить у подрядчика, это и есть формулируете концепции использования этой заказываемой системы (раньше на основании этой концепции делались требования, в них часто отфильтровывалась и искажалась информация концепции использования — тот самый «испорченный телефон»). Для вас это будет система-инструмент создателя в графе создателей вашей целевой системы или просто подсистема целевой системы (или даже всё это не целевой системы, а вашей системы), а вот для подрядчика — это будет его целевая система! И он должен будет разобраться не в «изготавливаемой им системе» (время изготовления), а в «используемой вами системе» (время использования, и ровно это вы в своей концепции использования системы для подрядчика и прописываете).
На основании концепции использования вы делаете закупку. Сегодня обычно это не разовая и окончательная закупка, но предполагающая сопровождение — постоянные улучшения системы после момента её создания, продажи и начала эксплуатации. То есть предполагается, что вы не продукт покупаете, а работы сервиса по улучшению продукта, мир становится не продукт-ориентированным, как раньше, а сервис-ориентированным.
Целевая система находится в физическом мире, это точно не какое-то описание — хотя если вы типография или художественная мастерская, то вашей целевой системой вполне может книга или картина, но вас тогда не будет волновать описанное в книге или картине (документированное описание), но только «документ», а уж что там за описание — это проблемы авторов и читателей, не ваши. Но если вы не типография, и вас интересуют работы с содержанием информации (о чём документ: книга, картина), а не носителем информации (из какой бумаги), то сразу смотрите на содержание, а не на носитель информации — систему надо искать в том, что описано, система не ваше описание! Если вы говорите «моя система — проектная документация», то вы курьер, или владелец принтера. Если вы инженер, который занят проектной документацией — то первый же кандидат в рассмотрение будет та система, которая описана в документации.
Если вы делаете какие-то информационные модели, пишете тексты, создаёте базы данных (например, разрабатываете софт), рисуете схемы или чертежи, то это вы обычно делаете только описание системы, воплощённое в физическом мире как документация системы/системная документация, но не как сама система! Описание, даже документированное — не целевая система! Задайте себе вопрос: а что описано в документе, в базе данных, в информационных моделях, отражено на графиках и диаграммах, описано в текстах? Возможно, там описано другое какое-то описание (текст, таблица, диаграмма, описывающие другие тексты, таблицы, диаграммы — объекты ментального/понятийного мира, имеем дело с «описанием описания»), но, возможно, там будет описана ваша целевая система, или хотя бы её подсистема, или создатель из их графа (всё это — системы физического мира).
Уберите внимание к носител****ю информации (компьютер с софтом, сам софт), обратите внимание на данные этого софта: там наверняка будут подсказки, где искать целевую систему в физическом мире**, эти данные описывают какие-то системы****.** Если данные софта описывают процесс сборки самолёта, то это описание поведения самолётного завода (время создания, описаны операции создателя — сборка::метод самолёта::«предмет метода»), но если у вас самолётный завод, то вы обязательно вспомните о самолёте (это же будет «предмет метода» для сборки) — и дальше вы просто задаёте вопрос о времени использования самолёта: понимаете, что его место не на заводе самолётов, а в небе, чтобы лететь куда-то с грузом и пассажирами. Ради этого «самолёт, который летит с грузом и пассажирами» всё это и делается: завод самолётов, а для завода делается описание процесса/метода сборки самолёта. Целевая система самолёт, завод — создатель в графе создателей самолёта, платят люди-потребители не за завод, а за сервис со стороны авиакомпании, самолёт — инструмент авиакомпании как провайдера сервиса, а для завода — это целевая система (он выпускает инструментарий авиакомпаний, ему платят за это).
Если вы говорите, что «система находится в физическом мире» — и показываете на носитель информации, то вам поверят только, если вы производите сам носитель, а не содержательно занимаетесь информацией на нём! Целевая система «книжка как документ» не у писателя, а у типографии или интернет-магазина электронных книг. А у писателя? Если это инженерный проект, то это было бы воплощение фрагмента мира, описанного в книге. Форма книги тут была бы не важна, а вот принятые по устройству этого фрагмента мира решения — важны. Если это образовательный проект, то можно было бы говорить о том, что создаётся при помощи книги участок мозга ученика (специализированная «мокрая нейронная сеть») как исполнитель какого-то метода работы. Этот участок мозга потом будет проявляться как провайдер сервиса мышления (или выполнения какого-то другого метода работы, с учётом задействования не только вычислителя как части мозга, но и тела, и даже инструментов как датчиков и эффекторов) в какой-то ситуации, для которой и было обучение этой части мозга — и целевая система тут не просто «участок мозга», но «участок мозга в момент его задействования для выполнения метода». Этот участок мозга в его функциональной роли вычислителя для выполнения метода работы мы и назовём «мастерство». А если брать всё мастерство агента, выполняющее все методы, которыми владеет этот агент? Это будет личность агента (и кроме личности там будет ещё и организм/тело). Если у нас в руках учебный курс или руководство, то мы смотрим прежде всего не на их носитель (компьютер датацентра, мозг преподавателя/наставника, книжка), но на содержание курса/руководства/регламента — знания/теории/объяснения/алгоритмы, которые описывают какую-то предметную область. И там два кандидата в системы, которые мы ищем:
- Мастерство, для создания которого этот учебный курс и был создан
- Предмет метода, описанного в курсе (скажем, если курс/руководство/регламент по выращиванию клюквы — то это клюква), а курс мы рассматриваем как справочник по предмету метода — системе. Не все методы работают с системами, часть работает и с описаниями систем или даже описаниями описаний, но часть предметов метода — это таки системы.
Такой мыслительный приём/метод уподобляет проекты по изменению поведения людей через изменение «мозгового софта» проектам по разработке компьютерного софта (можно было бы назвать это «нейролингвистическим программированием», но этот термин уже был занят в середине 70-х годов прошлого века конкретным методом такого программирования, описанным Джоном Гриндером и Ричардом Бэндлером, и тем самым оказался недоступным для общего пользования[2]. И да, Джон Гриндер и Ричард Бэндлер использовали системный подход первого поколения, им в этом помогал один из видных системных мыслителей этого поколения системного подхода — Грегори Бейтсон[3]). Этот приём/метод нередок при моделировании изменений, проходящих с людьми (образовательные проекты, продвижение каких-то продуктов и сервисов, психотерапия и т.д.). И помним, что целевая система определяется на момент её эксплуатации: то есть на тот момент, когда мастерство как соответствующая функциональная часть мозга (реализуемая на сегодня малопонятными конструктивными частями, но вполне материальная!) будет задействовано в выполнении работы с тем методом, которому мозг был научен в ходе обучения/терапии/программирования/кодирования (да, использовалось и слово «кодирование»!) и т.д. Мы уже неоднократно упоминали в нашем руководстве, как думать о системах, которые не изготавливаются из отдельных деталей, а обучаются. Более подробно об этом будет рассказано в руководстве по инженерии личности, а учитывая то, что организация тоже учится работать новыми методами (хотя она условно «собирается» из отдельных людей, AI и их инструментов, но всё равно люди и AI в ней потом научаются работать по новым методам), то и в руководстве по системному менеджменту.
Что будет целевой системой в детском садике Монтессори[4]. Ребёнок? А родители тогда что делают/изготавливают (создают и развивают), его же, ребёнка? Детский сад сервис, который выполняет какой метод работы над ребёнком, который не выполняют его родители? Садик — склад для ребёнка, где его хранят в то время, когда родители работают? Эвристика: в детском садике Монтессори идёт учебный процесс, ребёнка учат. Это значит, что целевой системой скорее всего будет какое-то мастерство: функциональная часть мозга, которая будет включаться в определённых жизненных ситуациях, уже за пределами садика. А детский садик будет только провайдером сервиса обучения. Эксплуатация мастерства как вычислителя/части мозга — за пределами садика.
Скажем, ребёнка должны там научить вести себя по методу разумной осторожности (не прятаться всё время за родителей, но и не лезть на рожон в любое доступное ему пекло), читать стихи, не теряться в незнакомой обстановке, быть собранным и не терять внимания. Это означает, что мастерство (то есть подготовленный таким образом вычислитель как часть мозга) должно не просто на выпускном утреннике в знакомой обстановке актового зала учебного заведения выдать чтение стишка с табуретки, но уверенное чтение стишка на каком-нибудь фестивале, где ребёнка поставят на железную бочку, фотовспышки будут со всех сторон, родителей оттеснят куда-нибудь в сторону, но обученный в садике кусочек мозга включится, даст спокойствие, уверенность и прочтение того самого стишка. Это и есть мастерство как результат обучения, вполне материальный объект (реализованный конструктивными частями мозга). И это будет через год после выпуска, мастерство должно быть изготовлено (инженерная терминология! Она позволяет говорить более точно!) так, чтобы через год умение не терялось. Весь персонал детского садика Монтессори должен вот это всё понимать: что результаты их работы надо будет смотреть не в самом детском садике, а за его пределами, возможно, через год. Впрочем, примерно то же относится и к школе, и даже к вузу, хотя в вузе даётся прикладное образование и поэтому можно задавать вопросы о ситуациях, где применяется мастерство, полученное в вузе. Но вот со школой и детским садиком такое рассуждение сложнее: ответ обычно «мы готовим к экзаменам», а экзамены как раз можно рассматривать как часть учебного процесса, а не использование мастерства в жизни (если научили не тому, что надо, то и экзамен можно организовать по тому, что не надо — мастерства в методе, которому учили, не будет, но будет мастерство сдавать экзамены).
Зачем так подробно это расписывать? Теперь вы знаете, какая целевая система в вашем учебном проекте (выполнили творческую/исследовательскую/предпринимательскую работу, ответили на вопрос «чему учить», какому мастерству учить — и ответ более-менее детальный, с перечислением того, что именно должен будет уметь делать выпускник), и только после этого вы должны задавать вопросы к системе создания: какие методы могут создать/изготовить (в нашем случае — обучить) такую функциональную часть мозга? Как должно быть устроено обучение для того метода, которому выбрано учить? Учить ведь математике, выращиванию морковки и рассказыванию стихов на фестивалях нужно разными методами — и только после того, как выяснится, что учить нужно именно этому (например, что детей надо учить именно рассказывать стихи, тратить время их детства именно на это умение)!
И дальше обсуждать уже методы обучения и ситуации этого обучения, каждый раз задаваясь вопросом о том, как это влияет на результат: мастерство, которое будет проявлено вне ситуации обучения. И если школа говорит, что «мы учим детей сдавать ЕГЭ», то можно усомниться, что «мастерство сдачи ЕГЭ» является именно тем мастерством, которому должна учить школа. А после обсуждения вопроса о том, какое же это должно быть мастерство, можно обсуждать методы изготовления этого мастерства: методы изготовления мастерства сдачи ЕГЭ при этом могут оказаться совсем другими, нежели методы изготовления жизненного мастерства как какого-то набора прикладных видов мастерства и фундаментального мастерства мышления, которые могла бы изготавливать школа.
Вот этот ход на то, что целевая система должна рассматриваться не в тот момент, когда она создаётся, а в тот момент, когда она эксплуатируется — он крайне важен и часто тут делаются ошибки. Причёска рассматривается в ситуации, когда идёт встреча с женихом, а не любая причёска на момент нахождения владельца волос в парикмахерской, когда там идёт стрижка и укладка и наблюдаются какие-то промежуточные состояния причёски. Шлиф рассматривается в момент его использования (то есть уже после шлифования и даже не в момент отдачи шлифа клиенту, а в тот момент, когда клиент уже установил деталь со шлифом в свою систему, и она работает). Все методы шлифования подбираются так, чтобы с этим использованием шлифа было всё в порядке. То же самое верно и для обучения людей, и для любых других проектных ситуаций. Вы должны дотянуться мыслью до ситуации использования/эксплуатации целевой системы, а когда договариваетесь про целевую систему со всеми остальными участниками проекта, то надо, чтобы и они признали целевую систему на момент использования, а не на момент её создания или продажи, или даже наладки. Нет, целевая система должна быть представлена в момент её эксплуатации/работы/функционирования/использования.
Целевую систему всегда придётся выявлять в ситуации недостаточной информации и разнообразия мнений на этот счёт. В каждом проекте она будет уникальна, справочника «типовых решений» и магического алгоритма её выявления тут нет, можно только давать примеры — в надежде, что эти примеры не будут восприняты как «делайте именно так», но нейронная сетка всё-таки заметит какие-то паттерны в этих примерах.
Системное мышление задаёт лишь набор типов**,** для которых надо найти в проекте объекты, чтобы обязательно подумать об этих объектах. Оно просто управляет вниманием в проекте, оно не указывает, как и о чём думать (указывает о чём думать в мета-мета-модели, но чтобы подумать хотя бы об объектах мета-модели, надо отождествить эти объекты с типами мета-мета-модели: выполнить выявление систем, разобраться с отношениями систем. Например, в учебном проекте понять, какое мастерство будет целевой системой**—** и дальше всех договорить по поводу этого мастерства)****. Если вам трудно принять решение по поводу целевой системы**—** это означает, что вы что-то плохо понимаете про ваш проект, и лучше бы вам подумать ещё**,** а также собрать больше информации, поговорить с исполнителями разных других ролей в проекте.
Документация (бумажная или электронная) — не целевая система, даже если речь идёт о толстой пачке проектной документации для высотного здания или даже если речь идёт об исходном коде компьютерной программы, или даже если речь идёт о каком-то сценарии городского праздника, или даже если речь идёт о какой-то компетентности в чьей-то голове. Возможно, целевая система — это то, что вы описываете на этом носителе. Возможно, вы описываете даже не целевую систему, а систему в окружении целевой системы, или подсистему целевой системы, или систему создания где-то глубоко в графе создателей. Главное тут — не путать системы и описания (даже если описания даны нам как документация). Целевая система**—** это не описание**! Целевая система чаще всего****—** воплощение того, что описано!
Целевая система — это обычно то, что делает (то есть полномочно меняет сама, а не «влияет на то, что кто-то другой поменяет») команда проекта. Если завод выпускает конфеты, то конфеты — это и есть целевая система (при этом не эшелон конфет в момент заключения контракта, не ящик конфет в момент отгрузки магазину, не упаковка конфет в момент продажи, а вот прямо одна конфета, причём в момент её поедания и переваривания).
Если команда делает описание, по которому потом сделают систему — это непосредственное стратегирование (описываем методы/функции), а затем и планирование (кладём метод на ресурсы, превращаем в работу) изменения физического мира. Это не уговоры кого-то, чтобы он изменил свою систему, не «рекомендации аналитика», который обычно не имеет полномочий реализовать свои рекомендации даже для системы, которой занимается его команда. У команды есть какие-то полномочия по отношению к её системе, а также в силу участия в проекте целевой системы — по отношению к целевой системе. В отношении других систем (систем окружения, в том числе надсистемы, систем в графе создателей) полномочия команды сильно ограничены, влияние много меньше.
Целевая система — это очень часто то, за что команде в конечном итоге (после того, как система окончательно изготовлена и начинает успешно эксплуатироваться) платят деньги. Если команда делает информационную модель велосипеда, то в конечном итоге заплатит деньги потребитель за велосипед. Вот целевой системой тут и будет велосипед, деньги именно за это — информационная модель велосипеда тут просто описание велосипеда (даже если это документ, то есть описание на носителе). Но если команда делает алюминиевую раму велосипеда, и эта рама продаётся только в составе велосипеда (то есть продаётся велосипед, а не отдельно рама), то и рама не будет хорошо выбранной целевой системой. Она будет подсистемой целевой системы. Вместе с тем двигатель самолёта — хороший кандидат в целевые системы. Двигатель обычно (с небольшими модификациями) может поставляться для включения в состав разных моделей самолётов, двигателестроители работают в составе независимых более-менее автономных предприятий, поэтому двигатель — хороший кандидат. Но Роллс-Ройс продаёт авиастроителям не авиадвигатели, а часы работы двигателя, так что и тут возможны варианты: двигатель тут неразрывно связан с системами его обслуживания, и двигатель тут может быть только подсистемой.
Целевая система-продукт часто пересекает границу предприятия, идёт её «поставка» (delivery, при этом обычно в delivery включают и ввод в эксплуатацию, а не просто «логистику доставки на место»). Подсистемы обычно границу предприятия сами по себе не пересекают, сами по себе не разворачиваются и не вводятся в эксплуатацию, это с ними происходит только в составе целевой системы.
У разных компаний/групп/команд проекта могут быть разные представления о том, что такое целевая система, каковы её границы, какой её уровень в системном разбиении, и даже какое там вообще системное разбиение. У поставщика авиадвигателей целевой системой является двигатель. Но у завода авиалайнеров авиадвигатель — это заказная подсистема.
Если вы обнаружили, что целевой системой у вас является какой-то процесс/метод, то подумайте дважды или трижды, какая система осуществляет это поведение. Если отдых, то вашей целевой системой, скорее всего будет отдыхающий (причём созданный, то есть отдохнувший). Если жизнь — то живой агент, её проживший и не жалеющий о процессе жизни. Если танец (помним о многозначности слова! Тут это — перформанс, танцевание), то зритель, который воспринял этот танец, а иногда и сам агент-танцор, который «зритель себя», это ведь всё ролевые рассмотрения, один агент может играть в ходе перформанса две роли — и танцора, и зрителя. Мероприятие (фестиваль, перформанс, совещание — какие-то события с некоторой протяжённостью во времени и понятным составом участников) ещё можно представить системой, там можно ткнуть пальцем в составляющие этого мероприятия, собрать их в одном месте и одном времени — и затем использовать. А вот метод — это не мероприятие, а чистой воды поведение, его не надо делать системой, вы не сможете ни с кем договориться, вас не будут понимать, вы не сможете «изготовить метод». Хотя разработать описание метода — почему бы и нет, но дальше изготавливать по этому описанию вы сможете только мастерство агента и инструментарий этого агента, а потом агент встанет в роль и задействует метод в своих работах. А вот «изготовить мероприятие» — сможете, участники проекта будут вас как-то понимать.
Если у вас какой-то «рабочий процесс» (сервис/метод), то скорее всего интересует результат, предмет метода. Часто этим предметом метода будет система, «наша» или даже «целевая». Следите за типами: целевая система не стрижка::процесс/метод, а причёска (стрижка — один из процессов получения причёски, другой — укладка), не шлифовка::процесс, а шлиф (физический объект, на который легко указать в пространстве-времени, причём на момент его работы, а не изготовления), не доставка::процесс, а доставка как коробочка в руках клиента в месте назначения. У танцевания нельзя просто показать его материальный результат как достижение ожидаемых состояний предметов этого метода (хотя зритель в состоянии «доволен» или «заинтересован» и танцор в состоянии «без травм» — это вполне себе может быть результат), а вот у «рабочего процесса» или чего-то подобного результат (предмет какого-то метода в каком-то заранее оговорённом состоянии) обычно можно указать, вот и опишите этот результат в материальном мире — это более вероятный кандидат на целевую систему.
Целевая система — точно не процесс, но она наверняка как-то себя ведёт в ходе функционирования/работы, то есть меняет состояния чего-то вовне себя. Если нашли какой-то глагол, важный для описания результатов (приведения каких-то объектов в ожидаемые состояния — самолёт летает, компьютер вычисляет, мастер задействует своё мастерство), задайте вопросы по этому глаголу: 1. кто себя так ведёт? и 2. для какого результата, какой объект будет приведён в какое состояние? Получите сразу двух кандидатов в целевую систему.
Ответы хорошо бы получить «в ролях»/функциональных объектах, а если речь идёт об агентах, то одним агентом могут выполняться множество ролей. Один агент может сыграть роль многих систем. Все эти рассмотрения множества ролей агентов — первый шаг к рассмотрению возможности разделения труда, что важно для инженерии систем создания. Но для начала нам надо не столько заниматься ролями, методами этих ролей, разделением труда, сколько искать целевую систему. Если я причёсываю себя, то я в роли парикмахера и клиента одновременно. Но можно и разделить труд: отдать роль парикмахера агенту, который умеет причёсывать меня лучше, чем я сам. А результат? Причёска, целевая система! С неё и надо начинать.
Если договориться о результате проекта (какая система в каком состоянии должна оказаться)****, то тогда можно говорить и о разных рабочих процессах, к этому результату ведущих, разных сервисах разных создателей**, которые помогут этот результат (целевую систему) получить.**
Что происходило с нейролингвистическим программированием и подобными подходами можно посмотреть по ссылкам в тексте «психопрактики движения по шкале формальности мышления», https://ailev.livejournal.com/1461939.html ↩︎
https://www.livingmontessori.com/montessori-kindergarten-vs-traditional-kindergarten/ ↩︎