О системах и эпистемах о них (описаниях, моделях)
У вещей как физических объектов и особого класса вещей – систем – есть описания. Но ещё точнее говорить, что существуют кусочки знания, или эпистемы/представления о вещах, их свойствах, действиях с ними – да вообще о чём угодно. Эпистемы/представления – это именно кусочки знания, содержание знания. Кусочек знания обычно зафиксирован на некотором носителе – например, в ваших мозгах, на листочке бумаги, на сервере, в памяти компьютера и так далее. Описания же – это такие специальные эпистемы, которые явно указывают на описываемый(е) объект(ы) (described_entity в FPF), контекст, в котором эти объекты описываются (bounded context в FPF), с какой точки зрения/способа смотреть на мир/viewpoint эти объекты описываются. Если вы имеете дело с описанием, значит, вы можете ответить на следующие вопросы:
- о чём это (о каких объектах речь, described_entity)?
- в каком контексте описываем/bounded context?
- с какой точки зрения/viewpoint?
- где проверяем, что описание соответствует описываемым объектам?
- когда, при каких условиях описание соответствует описываемым объектам?
- чем докажем, что описание соответствует?
Обычно являются эпистемами, но не описаниями различные «хотелки» и замыслы: от «хочу мороженого» до «планируем увеличить выручку на 20%». По формулировкам этих хотелок мы не можем понять, есть ли у вас мороженое, которое вы хотите, каким именно способом планируете увеличить выручку, есть ли у вас на это ресурсы, не можем проверить выполнение хотелки. Правило «записывать все задачи в таск-трекер» является и эпистемой, и описанием нормы (как надо делать). Утверждение «в нашей команде все записывают задачи в таск-трекер» является описанием реальности – при условии, что оно подкреплено цифрами и фактами (а если нет, то предположением/гипотезой).
Здесь и далее мы будем называть эпистемой/представлением любой кусочек/единицу знания о мире. Более правильный термин из двух – это эпистема, U.Episteme в FPF. Но для вас он может быть непривычен. Кроме того, вам как-то надо разговаривать с окружающими, которые не владеют «птичьим языком», на котором пишется FPF и формулируются нулевые принципы мышления. Поэтому пока будем употреблять слова «эпистема» и «представление» как взаимозаменяемые. В будущем, когда вы привыкнете, предлагаем вам оставить только термин «эпистема».
Итак, есть эпистемы/представления/кусочки знания о вещах. Но в работе вы чаще будете сталкиваться не просто с эпистемами/представлениями, а с разнообразными описаниями вещей и конкретно систем. Например, есть договорка между банком, выдавшим кредит (кредитором), и человеком, который взял кредит (должник), в котором должник обязуется отдавать часть своих будущих доходов в погашение долга (для уплаты кредита)[1]. Но вот наступает ситуация банкротства, и договорка уничтожается, обязательство платить кредит погашается. Мы можем описать эту договорку, перечислив участников, договорившихся о чём-либо, и смену их состояний, как и сделано выше. Но мы также можем описать эту договорённость, составив юридически обязывающий договор. Мы можем описать эту ситуацию со стороны кредитора (и там будет много разных описаний), можем – со стороны должника, или со стороны регулятора (суда), который будет решать, возможно ли погашение обязательств в данном конкретном случае.
Описания обычно размещаются на физических носителях и не совпадают с описываемым объектом ни в какой момент времени. «Предварительный план размещения трубопровода» в памяти вашего компьютера, на сервере или распечатанный на бумаге ни в какой момент времени не превращается в сам трубопровод. Описание на носителе со всеми его молекулами не становится физически частью трубопровода, молекулы сервера не встраиваются в трубопровод[2]. Проектное решение «заменить материал для шумоизоляции в проекте строительства жилого дома» – это решение заменить минеральную вату на звукоизоляционные панели с песком, которое должно быть воплощено в реальности. Иными словами, если вы приезжаете на стройку и видите там установленные панели, то это решение воплощено. Если вы видите, что закуплены панели вместо минеральной ваты, то решение воплощается (и будет воплощено когда-то в будущем). Но когда мы просто говорим об этом решении, не проверяя, начало ли оно воплощаться в реальности – мы почти наверняка говорим об описании решения, а не о самом решении.
Как проверять, имеете ли вы дело с системой или с её эпистемой/представлением (описанием, моделью):
- попробуйте потрогать/увидеть объект или измерить следы его существования. Если это сделать нельзя – то это точно не система, поскольку не вещь (не физический объект);
- если потрогать можно, то проверьте, не пытаетесь ли вы назвать «системой» носитель описания, например, «документацию на 300 страниц». Проверка простая: нужен ли объект сам по себе, без информации на носителе – или информация важнее, а носитель можно заменить?
Поясним эти пункты подробнее.
Во-первых, система – вещь, физический объект, то есть, мы должны уметь выделить вниманием не информацию, а именно нечто, по чему можно постучать. Обычно это более-менее легко: мы обычно не называем «правило», «норму», «информацию о посещаемости сайта» вещью. Вещью может быть разве что носитель перечисленных эпистем/представлений. «Пакет документов» вполне себе вещь, «документация на 300 страниц» тоже – мы можем пощупать носители этих эпистем, передать их другим как готовые артефакты, поэтому первому критерию они соответствуют. Но вот системами эти вещи, как правило, не являются.
Во-вторых, система не просто вещь, а вещь, которая выполняет некоторую функцию в среде/окружении. Система нужна сама по себе, а не как носитель знания/carrier. Часто «системой» пытаются назвать какое-либо описание. Например, ваша компания может составлять документацию для создания испытательных стендов, на которых будут тестироваться опытные образцы топливной системы самолёта. Документация для создания испытательных стендов (пакет документов) – вещь, потому что у неё есть носитель/carrier, который и передаётся создателям испытательных стендов. Но документация не является системой. Документация лишь описывает систему – испытательный стенд. Как вычислить, что вы имеете дело с такой ситуацией? Допустим, вы выделили вниманием некую вещь, проверили её на вещность. Теперь нужно задать вопрос: эта штука нужна как носитель знания/carrier, то есть, её используют для того, чтобы что-то сделать (но сама она работать не будет), или она сама будет работать/функционировать и приносить пользу окружающим?
Если вещь – носитель эпистемы/carrier, то сам носитель описания не так важен, как записанная на нём информация. Чтобы проверить, так ли это, проведите мысленный эксперимент: замените содержание/информацию на носителе. Была «документация на испытательный стенд на 300 страниц», стала «документация по разработанному ПО на 300 страниц». Нужен ли вашему заказчику носитель с такой информацией? Если нет, то носитель эпистемы/представления – вещь, но не система. Эта штука нужна из-за содержащейся на ней информации, она не выполняет работу сама. Документацию берут, чтобы узнать, как изготовить правильный стенд для тестирования топливной системы самолёта. С тем же успехом вместо пакета документов можно было бы переслать электронный файл с описанием, рассказать устно и так далее. Главное – что нужная информация получена.
Бывает, что объект, используемый как носитель представлений/carrier, нужен сам по себе. Например, ваша компания предоставляет сервера для хранения и обработки банковских документов. В таком случае вам как провайдеру серверов действительно безразлично содержание документов, которые на них лежат, вам нужно предоставить инфраструктуру для банка. И именно в таком случае вы действительно разрабатываете систему, которая сама выполняет функцию в окружении: хранит нужные документы и даёт к ним доступ авторизованным пользователям. Другой пример: вы можете разрабатывать «электронного почтальона», который доставляет электронные письма внутри организации вовремя и без задержек. Именно эта функция «доставки писем до адресата» востребована теми, кто будет эксплуатировать систему, поэтому электронный почтальон, выполняющий эту функцию – вполне себе система, нужная сама по себе, она будет работать сама и приносить пользу. При этом неважно, какие именно по содержанию письма доставляются, главное – что вовремя, без провалов, без задержек. Но такие ситуации будут встречаться достаточно редко. Большинство тех, кто участвует в составлении различных документаций, работают над описанием, но не непосредственно над системой.
Если вы (или даже ваша компания целиком) составляет документации (то есть, описания/эпистемы на носителях), нужные из-за содержащейся в них информации, вам надо продолжать искать системы. Чтобы найти системы, которые нужны сами по себе, вам надо задать себе вопрос: что за информация содержится на носителе/carrier? Что именно она описывает, к чему отсылает? Какую будущую систему можно будет создать благодаря вашему описанию на носителе?
Да, система может быть на данный момент не воплощена в физическом мире. Но если она будет воплощена в некоторый момент, то мы можем считать её будущей физической системой, которая в какой-то момент воплотится в мире. Например, ваша компания создаёт ЗД модели сложных мостов[3]. В таком случае 3Д модель моста – это описание на носителе, которая нужна для того, чтобы в будущем построить мост. Ваша система – это мост, который в какой-то момент начнёт существовать; 3Д модель лишь описывает этот будущий мост. Будущая система описывается вашей эпистемой/описанием. Вам надо думать об этой будущей системе так, как будто она уже воплощена, и представлять, как она будет эксплуатироваться, чтобы составить качественную 3Д модель. «Система смотрит на эпистему, эпистема соответствует системе».
Часто в этот момент инженеры-менеджеры начинают говорить: «Ну, этот мост строим не мы, так что мост меня не интересует, я на его создание непосредственно не влияю, меня интересует лишь модель». Это неправильное представление, из-за которого у вас формируется неверное понимание собственной работы. 3Д модель моста нужна для того, чтобы в будущем в нужном месте появился мост. Если вы строите какие-то оторванные от жизни модели, которые затем не используются в строительстве, не удивляйтесь, что ваши модели станут ненужными, ваша компания разорится, а вас уволят. Никто не хочет платить за ненужную, бесполезную работу, и ваши заказчики не исключение. И если такая компания разорится как можно быстрее, это будет очень хороший результат: в таком случае высвободившиеся ресурсы можно будет перенаправить на составление других, полезных эпистем, которые будут задействоваться при создании систем.
Такой способ смотреть на мир/точка зрения/viewpoint сложнее, чем «я просто маленький человек, который выполняет свою работу на своём месте и больше ни о чём не беспокоится». Вам придётся выделять систему, в создании которой участвуете не просто вы, а ваше предприятие, которое может вообще не соприкасаться непосредственно с создаваемой системой, как не соприкасается с ней конструкторское бюро. Придётся и игнорировать границы полномочий и ответственности, учиться смотреть на систему с точки зрения менеджеров, которые управляют предприятием. Только тогда вы сможете говорить с ними содержательно. Вам не придётся угадывать, чего они хотят – вы будете это знать, сможете вычислить. Менеджеры хотят ускорять выпуск систем и увеличивать прибыль – если вы сможете показать, как ваши предложения ускоряют выпуск и увеличивают прибыль, вы договоритесь с ними об организационных изменениях, вам выделят ресурсы. Начинаем учиться думать как менеджеры и смотреть на системы «снаружи» и «сверху».
Пример с 3Д моделями мостов относительно простой. У вас может быть более сложный случай, когда вы составляете описание, при помощи которого создаются другие описания, пока наконец не появляется описание системы и созданная по нему система. Например, ваша компания может выдавать заключения о безопасности проектных решений, представленных в документации (проектной, сметной, исходно-разрешительной) объекта капитального строительства (ОКС). Ваша компания готовит описания (заключения), которые другое описание (документацию ОКС). Значит, вам нужно дотягиваться вниманием дальше – как минимум до объекта капитального строительства (ОКС), который будет строиться по документации. Все кипы бумаг нужны для того, чтобы этот объект начал строиться (=воплощаться в реальности)!
Но лучше бы протянуть рассуждение дальше. Если вы прогуглите, что такое «объект капитального строительства» (как мы всегда рекомендуем делать, когда вы подозреваете, что имеете дело с терминами из профессионального (не бытового) языка), то узнаете, что это «здание, строение, сооружение, объекты, строительство которых не завершено (далее - объекты незавершенного строительства), за исключением некапитальных строений, сооружений и неотделимых улучшений земельного участка (замощение, покрытие и другие)»[4]. Обратите внимание: ОКС в данном случае – это «объект незавершённого строительства», то есть, «строительная незавершёнка». Воплощенная в реальности штука будет называться не «объект капитального строительства», а как-то иначе, например, в приведённом случае – «общежитие для студентов»[5]. И вам нужно дотянуться вниманием в конкретном проекте до этого общежития (или общежитий), потому что заказчики строительства общежития (одним из которых будет выступать конкретный университет) могут начать давить на строительные и проектные организации (то есть, создателей в графе создателей) для того, чтобы получить общежитие поскорее – к новому учебному году. В результате компанию, выдающую заключения о безопасности проектных решений, могут заставить одобрить сомнительное строительное решение, например, решение начать строить общежитие слишком близко к другому дому. И если вы не будете следить за происходящим, произойдёт это внезапно, без предупреждения, вы не успеете подготовиться и поменять ситуацию, вас могут продавить. И если в дальнейшем из-за продавленного решения возникнут проблемы на стройке или после начала эксплуатации, то у вас будут проблемы, и никого не будут интересовать оправдания, что на вас надавили. Чтобы найти способ оптимально разрешить этот конфликт, вам придётся учитывать интересы самых разных создателей в цепочке/графе (интересы заказчиков, интересы проектировщиков, интересы строителей, интересы надзорных органов и так далее) и предлагать приемлемые решения, которые позволяют с учётом ограниченных ресурсов максимально учесть интересы всех сторон.
Итого: эпистемы (описания) на носителях глобально нужны для того, чтобы что-то изменить в физическом мире: создать новые физические объекты, изменить состояния текущих физических объектов, прекратить существование физических объектов, например, ликвидировать полигон твёрдых бытовых отходов. Описания сами по себе, в отрыве от описываемых объектов, мы не считаем полезными/ценными. Описания лишь отражают или реконструируют какой-то объект – причём обычно не во всей его полноте и сложности. Например, заключение о безопасности проектного решения отражает только мнение безопасника о том, насколько будет безопасно экплуатировать здание, в котором это решение реализовано. Но для того, чтобы обосновать это решение экономически, то потребуется ещё одно описание. Кроме того, потребуется ещё архитектурное описание, и ещё ряд других.
https://systemsworld.club/t/rr-25-zadanie-9-1-iz-rukovodstva-1-raczionalnaya-rabota/31937/6 ↩︎
Все примеры в разделах про «работу» – это реальные примеры наших инженеров-менеджеров. Часть обсуждений, например, вещи и графа создателей вещи, можно найти в клубе МИМ, часть обсуждений проходила во время резидентур и на отдельных семинарах ↩︎
Градостроительный кодекс Российской Федерации (ГрК РФ), статья 1, п. 10: https://www.consultant.ru/document/cons_doc_LAW_51040/cdec16ec747f11f3a7a39c7303d03373e0ef91c4/ ↩︎
https://systemsworld.club/t/zadanie-9-3-iz-rukovodstva-1-raczionalnaya-rabota/25994 ↩︎