Как мы путаем вещи (системы) и описания вещей (систем)
Первая типовая ошибка – путать систему как физический объект/вещь и её описания. Например, вы называете «системой» денежную транзакцию, отображённую в интерфейсе банковской системы[1]. На самом деле это лишь учётная запись, которая отображает, кому из контрагентов в реальной сделке перешли деньги («кучка золота» в упрощённом варианте[2] в реальном мире. О чём вы должны думать на самом деле: что поменялось в физическом мире, что именно отображает эта запись в интерфейсе? Какие реальные агенты/контрагенты задействованы в сделке? Кому и от кого перешла «кучка золота»?
Что получил совершивший платёж контрагент в обмен на переведённую им кучку золота? Запись в интерфейсе – это кучка золота или её отображение? Саму кучку золота, сменившую владельца, мы можем потенциально называть «системой» – но точно не запись о том, что смена владельца произошла!
Можно также путать физические объекты «вообще» и их описания. Например, инженер-менеджер путает задачу как описание реальной работы, которую потребуется выполнить, с самой выполняемой работой/физическим действием. Например, есть задача «выпустить релиз продукта». Описание задачи в вашем корпоративном планировщике/таск-трекере не следует путать с действиями, которые реально выполняют члены команды для того, чтобы пользователи получили релиз: разработчики совместно с тестировщиками готовят сборку, релиз-менеджер описывает релиз/составляет release notes и грузит сборку в App Store, Google Play, RuStore. Действия не равны их описаниям в таск-трекере. Это очень распространённая ошибка, которую вы в будущем будем называть «проблемы с отношением «описываемый объект – описание». Почему мы совершаем эту ошибку, будет рассказано в руководствах по моделированию и системному мышлению.
Пока вы не знакомы с соответствующими объяснениями, достаточно просто запомнить, что эта ошибка часто встречается – и вы наверняка допускали её сами (а ещё могли видеть, как эту ошибку совершают другие, например, ваши коллеги). Чтобы исправить ошибку, уже сейчас, до соответствующих объяснений, её нужно начать замечать, выделять вниманием. Для этого можно пользоваться следующим приёмом: пробовать представить себе конкретных агентов, которые что-то делают (физически меняют мир, а не пишут бумажки), результаты их действий, какие могли бы быть последствия в реальном мире от сделанного (и вы сможете убедиться в том, что преобразование совершено, где-то в будущем). Что по сути произойдет (или должно произойти)? Например, рассматриваем платёж как переход кучки золота от контрагента А к контрагенту Б. Что в результате должны получить оба контрагента? Что они смогут сделать после того, как платёж совершён?
Если вы подписали заключение о безопасности строительных решений, принятых при строительстве общежития для студентов, то вы в первую очередь должны подумать не о бумажках, а о принятом строительном решении, например, решении заменить материал реальных водопроводных труб – и оценить, насколько это реально будет безопасно при эксплуатации. Лишь после этого можно писать заключение (бумажку) о том, что решение, описанное в проектной документации (другая бумажка), хорошее (или не очень). Бумажка лишь отражает принятое проектное решение и мнение реального безопасника о безопасности этого решения.
Следующая ошибка – путать носитель описания/сarrier и его содержание (информацию, смысл). Например, менеджер выделяет вниманием «лист бумаги» как носитель регламента постановки задач и дальше начинает обсуждать содержание: что именно надо записать в регламент, чтобы задачи команде ставились правильно. При этом менеджер искренне считает, что обсуждает физический объект – хотя на деле он обсуждает содержание описания[3]. Другой случай: вы выделяете «сервер» как носитель информации и говорите, что у вас там лежит код (информация) – и сразу переключаете внимание на обсуждение, как именно этот код будет исполняться в приложении, чтобы заработала новая фича (это вообще третий объект, не носитель и не его содержание!). Эту ошибку часто совершают менеджеры: менеджерам приходится много работать с описаниями, и они нещадно путают содержание информации на носителе с самим носителем (и заодно с объектами, которые описываются). Но эту же ошибку любят совершать инженеры, которые работают с софтом (им тоже приходится часто сталкиваться с описаниями). Объяснение, как именно вы совершаете эту ошибку, вы сможете получить в ходе следующих резидентур. Пока попробуйте думать так: назовите носитель, выделите вниманием информацию на носителе; подумайте, что описывает эта информация, к каким объектам за пределами описания отсылает.
Когда вы пытаетесь выделить вниманием систему как физический объект, вы можете провести длинное рассуждение и начать с выделения носителя – но тогда сразу должны сказать, что это носитель информации. Вы выделяете вниманием «заключение о безопасности строительных решений в трехсотстраничной документации», но сразу уточняете, что «документация на 300 страниц с подписями» – это носитель*,* который содержит информацию. Далее вам требуется порассуждать, что именно за информация содержится на носителе: что описывается в информации? Что должно (не) случиться в физическом мир**е, если носитель с содержащейся на нём информацией будет использоваться/эксплуатироваться? Какие последствия (или цепочка последствий) возможна в физическом мире? В дальнейшем мы уточним эти вопросы и переформулируем их поточнее. Но пока вам надо запомнить одно: мы всегда стремимся дотащить рассуждение до того, что происходит в физическом мире.
В конечном итоге нас интересуют объекты физического мира и происходящие с ними изменения[4]. Когда мы будем обсуждать, какую систему вы создаёте; где ваше место на предприятии как производственной цепочке (или в команде как производственной цепочке); что вы делаете и для чего – мы всегда будем исходить из прагматической предпосылки: агенты что-то делают для того, чтобы поменять физический мир – и объекты физического мира, а не описания. Все описания, в итоге, должны приводить – непосредственно или опосредованно – к изменениям в физическом мире. Поэтому основной вопрос, который вы должны себе задавать, звучит так: «Что должно измениться в физическом мире, когда мы сделаем это?». И в первую очередь вы должны думать о том, что произойдет (или может произойти) в реальном мире – это и есть суть операции «заземления». Если вы регулярно/систематически не выполняете эту операцию, рано или поздно вы обнаружите, что занимаетесь симпатической магией: тыкаете иголкой в куклу вуду – и ждёте изменений. Например, вы выкладываете во внутреннюю информационную систему регламент с описанием нового способа постановки задач и ожидаете, что сотрудники сразу начнут им пользоваться, в результате чего будут формулировать задачи точнее и выполнять их с первого раза правильно, что уменьшит количество ресурсов на переделки/исправления/rework[5]. Нет, сам факт появления описания на носителе ещё ничего не меняет для команды. Чтобы изменение произошло, надо убедить команду использовать этот регламент, следить за тем, как регламент применяется при постановке задач, отмечать, уменьшились ли траты ресурсов предприятия на ненужные работы или нет. Иными словами, вам всё время придётся искать объекты, которые вы хотите изменить в реальном физическом мире – и начинать с них, выделять их вниманием и обсуждать изменения/преобразования, которые должны произойти с этими объектами, а потом думать, как их описать.
Альтернативно можно думать так: «давайте представим себе, что мы сделали это. Что изменилось в физическом мире?». Ответ может быть не таким уж и простым: на предприятиях инженеры-менеджеры часто составляют описания, которые описывают другие описания, и лишь через несколько тактов разбирательств можно наконец найти объекты физического мира. Например, вы составляете описание способа/метода постановки задач (создаёте соответствующий регламент). Думаем дальше: как это описание будет использоваться? Постановщики задач должны будут воспользоваться предложенным в регламенте способом описать задачу в трекере (и, возможно, донести исполнителю нюансы, которые по разным причинам нельзя описать в трекере). Получаем другое описание – уже не метода постановки задач, а описание задачи/task, составленное предложенным методом. При этом сама работа/work/исполнение метода по задаче ещё не начала выполняться, мы только получили описание. Когда реальная работа начнёт исполняться реальным агентом, например, кладовщиком Васей, вот тогда мы сможем сказать, что наконец-то добрались до реального физического объекта: конкретный Вася в конкретный день тратит ресурсы (силы, человекочасы и так далее), чтобы товары на складе были разложены по местам и правильно учтены в складской системе. То есть, если вы описываете метод постановки задач, вы должны добраться до того, что будет делать физический Вася-кладовщик в конкретный день – а ещё Петя-логист и Ангелина-финансист (они все, по замыслу, ставят или исполняют задачи, описанные предложенным способом). И вы должны будете подумать, понятно ли будет кладовщику Васе, логисту Пете и финансисту Ангелине то, что вы напишете. Потому что кладовщик Вася, логист Петя и финансист Ангелина, получив описание задач, сделанное новым методом, должны будут быстрее и правильнее сообразить, что от них требуется, и быстрее сделать нужное, не потратив лишние ресурсы. И если это не происходит, то это повод проверить всю цепочку, чтобы найти проблему (почему новый супер-регламент не помог сократить количество реальных ресурсов, тратящихся впустую?).
Именно поэтому тема «Различать системы и представления о них (эпистемы) и заземляться» стоит первой: вам требуется, как иногда говорят, «сменить парадигму» и начать думать о том, что изменится в физическом мире после ваших или чужих действий. При этом, когда вы так рассуждаете, вам нужно игнорировать границы полномочий и ответственности. Нельзя думать «мне задали задачу просто написать регламент постановки задач, вот и напишу как-нибудь, зачем заземляться и думать о кладовщике, логисте и финансисте, которые будут им пользоваться». Такие рассуждения – одна из причин, почему вы много ресурсов тратите впустую: вы просто сделаете не то, после чего ваше руководство заставит вас переделывать (позитивный сценарий), или все сделают вид, что всё хорошо, и не будут пользоваться вашим описанием (реалистичный сценарий), или кто-то попытается воспользоваться, в результате накосячит, и всё вскроется после скандала (негативный сценарий). Лучший вариант – вообще не допускать таких сценариев (или по крайней мере быть к ними готовым) за счёт того, что вы продумываете, что должно измениться в физическом мире. В первую очередь всегда ищем и выделяем вниманием объекты физического мира (заземляемся), потом объединяем их в категории/классы (абстрагируемся). Вы будете учиться делать это на протяжении всей резидентуры.
Конечно, в этом разделе перечислены не все способы спутать вещи (и в частности, системы) и их описания. Некоторые ошибки вы сможете обнаружить позже, после изучения соответствующих разделов по моделированию. Пока вам требуется начать выделять объекты физического мира и думать о том, какие изменения в физическом мире нужны (а не в бумажках). Начните ловить выделенные типы ошибок в вашей речи и речи окружающих.
https://systemsworld.club/t/popytka-1-projti-mantru-sistemnogo-myshleniya/20379/4 ↩︎
Если вы хотите говорить о деньгах более точно, придётся разобраться с обязательственными правами и моментами переходов этих прав между контрагентами в реальном мире. Для этого можно воспользоваться книгой Хесуса Уэрто де Сото «Деньги, банковские кредиты и экономические циклы» ↩︎
Понятие объекта будет введено позже в разделах по моделированию. Пока пользуемся интуитивным пониманием, что такое «объект», которое уже сложилось у вас как развивающегося агента ↩︎
Об изменениях подробнее поговорим в ходе следующих резидентур ↩︎