Зачем моделировать систему и вообще что такое моделирование?

Модель — это абстрагированная часть реальной системы, которая уже существует или может существовать в будущем. Модель является таким объектом, который описывает часть свойств, присущих реальной системе, или же сам обладает рядом таких свойств. То, насколько “карта” будет “соответствовать” территории, или то, насколько модель будет обладать свойствами и функциями реального объекта, зависит, в том числе, от целей моделирования.

Среди множества возможных целей моделирования выделю следующие (при этом по тому, что находится в скобочках, можно увидеть некоторую относительность разницы между “описательными” и “проектировочными” целями или возможности для их синтеза):

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

Можем различить моделирование системы в статике и моделирование системы в динамике. И это — разные цели, разные функции моделей, и немного разные способности, которые нужны для моделирования. В некоторых случаях сначала строится статическая модель, и затем уже переводится в динамику. В некоторых случаях строится динамическая модель, и затем переводится в статику. Не буду вдаваться в подробности в этой статье, отмечу лишь, что запрос людей на то, чтоб система начала “вращаться” обычно касается, как ни странно, и статических, и динамических моделей (опять таки, по моему опыту общения с людьми). В основном это значит, что человек хочет моделью пользоваться и получать результаты, то есть осуществлять управление (как самой системой, так и другими системами с помощью этой, так и жизнью на основе систем).

И теперь возвращаясь к теме практических навыков, или что делать, чтобы модель/система “вращалась” или “двигалась”)

Какими инструментами я пользуюсь

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

• Воображение. А именно — моделирование в воображении. В этом способности развиваются — раньше было легко представить несколько деталей, которые взаимодействуют, сейчас получается представить системы с n-количеством элементов, которые взаимосвязаны между собой и функционируют, а в некоторых моделях получается разложить систему на слои: где-то подсистемы, где-то разные уровни функций, где-то системы прямых и обратных связей, а где-то — смысловые уровни, периодика, развитие в пространстве и времени и т.д.
• Инструменты в физическом мире. Начиная с листика и ручки, продолжая чертежными инструментами, а в электронном виде — начиная со схем, диаграмм, таблиц, майндмэпов, заканчивая 3D моделированием с разной степенью детализации. Это помогает также развивать быстрее воображение (особенно, если закладывать намерение и держать внимание двунаправленным), а воображение является отличным подготовительным этапом к моделированию на физическом плане, делая его более быстрым, с меньшим количеством “проб и ошибок”, иногда сразу более точным и компактным. Поэтому я бы рекомендовала попробовать “зациклить” эти процессы, если в ваш вектор целей (понятие из ДОТУ)* входит развитие этих навыков. Кстати, понравилось когда-то делать модели для первичного обзора в VR-очках, там есть программы для 3D рисования, комната, в которую можно “зайти” и творить модели (на счет движения элементов не помню, но обозреть систему со всех сторон может тоже быть одним из этапов).
• Анализ. Перед тем, как приступать к моделированию путем воображения или в физической реальности, для начала хорошо бы выделить иерархию значимости элементов, процессов того, что вы хотите создать. Я стараюсь идти от общего к частному, от существенного к менее существенному, от наиболее функционально (жизненно) важного до того, что можно детализировать позже. Если задача стоит именно в том, чтобы моделируемая система пришла в движение и начала выполнять свою основную функцию в модели, начала “вращаться”, “оживать”, то можно для начала попробовать определить для себя необходимый и достаточный минимум: подсистем/элементов, функций, процессов, взаимосвязей на их основе и т.д. Если этого будет недостаточно, можно добавлять и смотреть в какой момент система таки начнет работать: это тоже процесс обучения тому, что такое системы и как с ними можно обращаться.
• Из подручных материалов. Это похоже на расстановочные техники — на полу, на столе можно выложить небольшими (или большими) предметами модель системы, использовать пластилин для лепки, скрепки, нитки, лего, да что угодно, чтобы пройти какой-то этап первичного обозревания системы в объеме. Мне помогает как промежуточный этап при моделировании, либо когда мне нужно смоделировать в воображении изменения системы во времени, но мощностей воображения не хватает. Так я сначала смотрю поэтапно, и моделирую сами изменения, и легче потом это сделать уже с помощью других инструментов.
• Тестирование. Создаю модель, тестирую на практике, дорабатываю, тестирую. Если результат удовлетворяет, модель работает и выполняет свои функции — совершенствую, усложняю, достраиваю. Если не работает, не дает результата в применении к жизни — анализирую, дополняю, перестраиваю. Тестирую. То есть, этот инструмент я бы назвала — практическое применение моделей, желательно разумно и с учетом техники безопасности. Ведь если вспомнить, то одно из назначений модели — проводить эксперименты без вреда для реальных объектов-процессов, на основании которых создана модель.

Возможные ошибки и способы их прохождения

Из тех ошибок, с которыми я сталкивалась, и которые тормозили меня на пути моделирования были:

• Попытка взять сразу много элементов без способности связать их между собой. Итог — система сыпется, из внимания выпадают то одни, то другие элементы.

Возможные решения. Здесь можно решить тем, чтобы сначала моделировать отдельные подсистемы, модули, и когда они будут более устойчивы, соединять их с другими. Тогда внимание будет удерживать уже не элементы, а подсистемы с включенными в них элементами, что будет восприниматься как одна единица, а не как множество. Из недостатков такого способа — собранные подсистемы могут быть собраны неправильно, и не будут “стыковаться” с другими подсистемами, придется пересобирать. С развитием навыков и приобретением опыта можно найти свою “золотую середину” или скорее динамический баланс в том, сколько элементов удерживать, а сколько объединять в модули для дальнейшей работы.

• Добирание все большего и большего количества элементов, изучение материала, детализация разных частей системы без пауз (во время которых подсознание может все это хоть как-то структурировать само), без самоактивной направленной деятельности по объединению, сопоставлению, синтезу, выстраиванию взаимосвязей между ними (на что тоже нужно время и внимание), без применения на практике того, что было “загружено” или даже “усвоено”. Для аналогии — что будет, если организм будет потреблять пищу, усваивать элементы, а потом накапливать их и не использовать по назначению? Скорее всего, переизбыток тех или иных элементов. Почему это происходит — как в организме, так и в других сферах, в том числе со знанием — отдельная тема.

Возможные решения. Решения думаю вполне очевидны, но все же — взять паузу, уменьшить/замедлить процесс дальнейшего “потребления”, проявить больше активности или улучшить качество внимания, направляемое на систематизацию уже изученного и т.д. В долгосрочной перспективе параллельно можно прокачивать навыки обработки и синтеза, расширять «депо» (если это целесообразно), или переходить на более «сложные углеводы». (Если здесь кто-то разбирается и аналогия не совсем корректна, дайте знать).

• Недостаточный добор элементов — прерывание изучения, попытка составить систему и сделать ее подвижной без необходимых элементов. В основном эта ошибка связана с тем, что изучение происходит не от общего к частному, когда сначала появляется общий эскиз и затем его детализация, а когда система изучается кусочно, и нет видения сколько и каких элементов не хватает для того, чтобы начать качественное моделирование.

Возможные решения. Решаться может разными способами — обратиться к тем, кто уже освоил систему, если они обладают педагогическими способностями и готовы показать общую картину, через аналогии попробовать проанализировать каких-то на самом деле может не хватать элементов (если есть понимание общих закономерностей систем, их видов и т.д.) и другие.

• Непосильные задачи или попытка прыгнуть выше головы. Это когда вместо того чтобы взять детский конструктор мы пытаемся построить космический корабль. Утрирую, конечно) Но трезвая оценка своих способностей в моделировании систем — хорошее начало, так как позволяет оценить почему возникают трудности.

Возможные решения. Чтобы происходило развитие, для освоения можно брать системы “на вырост”, там придется прилагать усилия, будут развиваться навыки и способности, возможно не все будет получаться сразу и с первого раза. Но будет сохраняться интерес, энтузиазм, желание разобраться, “лестница прогресса” будет проходиться ступенька за ступенькой. Поэтому первое — постараться оценить не только себя, но и систему, и примериться — соразмерно ли, сильно на вырост или уже перерос, или в самый раз для освоения ближайший зоны. Иногда понимание приходит уже в процессе освоения, мы приобретаем опыт распознавания на будущее, и это тоже нормально. Дальше зависит от каждого что с этим делать — оставлять систему до лучших времен, осваивать постепенно, параллельно с освоением более простых систем и т.д., делаем выборы, принимаем решения.

• Пока не “завращалась” и фрустрация. Это когда я выделяла недостаточно времени, то есть в моем прогнозировании была ошибка по таймингам: модель этой системы уже должна работать! Но не работает. Ожидания и реальность.

Возможные решения. Тут можно развернуться с попытки все-таки что-то сделать с моделью системы, применить еще какие-то инструменты, добавить детали и т.д., и перенаправить этот энтузиазм на улучшение алгоритмов прогнозирования таймингов. Как вариант) Когда у меня происходило признание, что на некоторые модели понадобится не год, а десять — фрустрация проходила, начиналась работа и планирование.

Пока думаю достаточно, если что-то еще вспомню — дополню. Успехов в тренировках и развитии, благодарю за внимание!

*“Образно говоря, вектор целей — это список, перечень того, чего желаем, с номерами, назначенными в порядке, обратном порядку вынужденного отказа от осуществления каждого из этих желаний”. Цитата из “Достаточно общая теория управления (в кратком изложении)”, ВП СССР

Сообщение Чтобы система начала “вращаться”, или Развитие навыков моделирования появились сначала на iris-space.club.

Предположим, что крайности “безумие и отвага” + “потом разберемся” и “сначала просчитаем каждый шаг” + желание “проконтролировать каждую деталь” уже пройдены и мы находимся в поисках золотой середины или оптимального варианта для развития: своего, команды и проекта. Здесь я предложу свой список, а вы можете дополнить его в комментариях, если будет желание. Возможно что-то из ваших списков я в дальнейшем добавлю в статью с пометкой “из списка читателей”. Итак:

• Цели и ценности проекта. Это фундамент. Сюда же может относиться миссия, видение и т.д., смотря по какой модели строите. Можно прописать ценности для каждого участника, а также для разных отделов, подразделений в проекте, направлений, но хорошо, если базовые ценности будут едиными для всего проекта и все участники будут готовы их реализовывать во всей деятельности. Это базовый “манифест”, к которому можно возвращаться в случае конфликтов. Из своего опыта — недостаточно сойтись на одном и том же слове, важно понять насколько содержимое совпадает. Например, два сооснователя в ценность “свобода” могут вкладывать противоположные значения)) Хорошо потрудитесь на старте — заложите более прочный фундамент, на основании которого разрешение недопониманий будет проходить легче. Бывает и так, что именно на этом этапе люди могут понять, что лучше пока вместе проект не создавать и в близкие взаимоотношения не заходить, так как ценности разные, либо понимание целей сильно расходится.
• Финансовая составляющая. Здесь речь пойдет и о финансовой модели самого проекта (как получается доход, как он распределяется, какая часть дохода идет в реинвест, создается ли фонд и для чего, на каких основаниях принимаются решения о покупках, о сотрудничестве со специалистами и т.д. Кстати, многое из этого тесно связано и базируется на предыдущем пункте, именно поэтому он стоит в моем списке первым. Потому что не зная своих целей и ценностей, мы не знаем на чем мы будем базироваться при принятии решений касаемо финансов в проекте. Сюда же входят условия входа и выхода из проекта для каждого из участников, это действительно желательно обсудить “на берегу”, и периодически пересматривать эти пункты и обновлять данные.
• Взаимоотношения в команде. Базовое, с чем можно определиться на начальном этапе — иерархия. Есть ли она, как работает, кто за что отвечает, зоны ответственности и точки контроля. Конечно же, когда речь идет о начальной стадии, когда стартап только формируется, и особенно если у участников еще не было подобного опыта с другими проектами, большая часть таких договоренностей возможно будет предварительной и весьма условной. Тут важно понимать, что это все равно будет — структура, зоны ответственности, определенные договоренности в команде, другой вопрос — насколько это будет видимо, осознаваемо и прозрачно. Действительно важно признать, что если есть зона, то кто-то берет в ней ответственность (даже если она распределяется между участниками, то все равно в каких-то пропорциях). Пока это не видится, то будто все работает само собой, и в это можно не смотреть только в одном случае — если оно устойчиво, эффективно и долгосрочно показывает высокий уровень качества. В ином случае — стоит учиться делать это видимым и управляемым.

Пока оставим эти базовые сферы, хотя можно детализировать и дополнять. Скажу по своему опять таки опыту — если команда глубоко и внимательно подходит к этим трем пунктам, то скорее всего об остальном они уже захотят вместе договариваться, это будет интересно, в этом будет ощущаться и видеться реальная польза и ценность.

Чувства и договоренности

А если я нехочунебуду договариваться? Или “ну мы же уже договорились, что там непонятного”? Или я вроде и хочу об этом всем, но есть сопротивление?

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

Как это определить? Я это определяю в основном так: когда у меня все ровно, то дальше дело в том, чтобы оптимально договориться и прояснить детали. Я могу не знать как это сделать наилучшим образом, я могу не сразу понимать о чем и с кем договариваться в данном конкретном проекте, но меня не стопорит это делать. Я могу пробовать, давать время, обдумывать, общаться, создавать временные договоренности, тестировать гипотезы, заходить в эксперименты и т.д. Я ищу возможности для того, чтобы это решить. Это основной для меня показатель. Если я избегаю или саботирую прояснение — скорее всего дело не в проекте и не команде, а во мне. Осознанно отложить решение вопроса — это ответственность, это другое)

Поэтому — сначала разбираюсь с собой, иду во взрослую позицию, потому иду договариваться с проектом (или сообщаю о том, что договоренности не будет, если принимаю такое решение).

Пишу от своего имени, однако в консультировании проектов мягко делаю примерно то же самое в отношении сторон — рекомендую сначала к психотерапевту, коучу или другому помогающему специалисту, а затем уже возвращаться к вопросам, касающимся проекта.

P.S. Что делать, когда не договорились “на берегу” и приходится разбираться с последствиями, — тема для отдельной статьи. Но если говорить вкратце, то как один из инструментов можно попробовать следующее: представить, что вы собираетесь зайти в новый проект уже с тем опытом, знаниями и гипотезами, которые у вас есть. Как бы вы хотели заходить, что хотели бы обсудить с будущими партнерами, что для вас по-настоящему важно, а в чем вы готовы быть гибкими и обучаться по ходу дела? Составить такую карту хотя бы для самого себя уже может быть помощью в том, чтобы увидеть ситуацию в текущем проекте более ясно и понять, какие именно зоны не устраивают и нуждаются в изменениях.

Сообщение “На берегу”, или О чем договариваться сразу появились сначала на iris-space.club.