Системный подход. Личный опыт и проблемы

Этот пост опять не очень складный, но нужно уже что-то выложить. Так за 1,5 недели и не могу собрать мысли на тему лекции в кучу.

Система, системное мышление, роли, требования..

Вот так вот рассуждая теоретически, это звучит хорошо, понятно и логично. Но на практике пока не складывается пазл.

Хочется поделиться своим опытом и ощущениями, надеюсь, промежуточными.

На курсе «введение в системное мышление» мы учимся делать систему из себя, ну или просто относиться к себе через призму системного мышления. Конечно, многие концепции были знакомы ранее и перед глазами много примеров личностей, которые успешно их применяют. И ты такой «да-да всё понятно, наверное, я тоже могу, если правильно подойди к вопросу». Найдя обучение по СМ тебе кажется, что вот он "тот самый ключик", который поможет тебе открыть нужную дверь.

Я понимаю, что я в самом начале пути и иду не самым прямым путем, но все же.

Опишу свои проблемы, если у кого-то что-то подобное было, может быть он подумает, что он не один и может быть это даже нормально.

Ситуация: рабочий проект.

Проблемы:

  1. Не учитываешь множество соседних систем в общей надсистеме.
  2. Роли. Забыл не просто одну роль, а много ролей. Или даже не забыл, а просто не хочешь их включать в рабочий процесс, потому что кажется, что тогда он усложнится. Но часто бывало наоборот, если бы сразу включила их в процесс, то он пошел бы проще и быстрее.
  3. Роли нашел, они вроде даже заинтересованы, да не так как тебе надо. В их системе приоритетов твоя система на отличном от твоего уровне. И тебе понятно, почему так и сделать ты с этим ничего не можешь потому что проблема на n-уровней выше.
  4. Не можешь определить части системы. Ощущаешь, что их намного больше, записываешь мысли, задаешь вопросы, фиксируешь ответы, но пазл все равно не складывается, и ты не понимаешь почему. Проходит одна неделя, вторая, ты как-то продвигаешь проект, медленно, но, главное пазл так и не складывается. Пытаешься нарисовать одну схему, другую, меняешь подходы к анализу проблемы, на середине понимаешь, что выбранный путь тупиковый. А потом случайно извне приходит какая-то мысль, которая складывает твой пазл как надо. А этот процесс получения мыслей извне не всегда управляемый.

На сегодняшний день для меня самое сложное — это соединить весь этот логичный, структурированный подход к самоорганизации/к решению проектов через системный подход и движение по наитию, «случайные» озарения.

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

На моем опыте бывало, что удача/случай или просто потоковое увлечение помогали не просто решать какие-то части проекта, а в целом проект, хоть и не всегда в том виде, что был изначально запланирован. А лишь целеустремленность и старание сделать по схемам наоборот ничего не давали и главное, в этих старательных ситуациях я себе не нравлюсь, как будто я не я. Хотя вижу, как у других получается.

Мария, спасибо, что поделились затруднениями! Все они абсолютно нормальны и случаются почти у всех в ходе освоения и попыток применения системного мышления. 

Что тут можно сделать:

  • Как обсуждали в ходе лекции 10, сначала попробовать построить цепочку "целевая система – надсистема – системы обеспечения (+ желательно системы в окружении)" и только потом в этой цепочке искать "свою" систему. Это поможет четче определить, за что в данном проекте платят деньги в конечном итоге, и не путать "целевую систему" и "нашу систему". Подробнее об этом можно прочитать в новом учебнике системного мышления СМ2020, глава 4 "Системное разбиение" (особенно раздел "Наша система" . Ссылка на бесплатную версию учебника закреплена в верхнем собщении Телеграм-чата "Системное мышление": https://t.me/systemsthinking_course&nbsp

  • Выделять роли после того, как проведено системное разбиение и выделена "целевая" и "наша" система. Каждый раз при этом вы выделяете роли с какой-то целью ("разобраться, о чем проект и что надо делать, чтобы он был успешным", "договориться" и тп. Цель выделения нужно держать в уме.

<li>Пробовать тренироваться на более простых проектах. Рассматривать системное разбиение сразу для всей большой фирмы, которая занимается очень многими проектами &ndash; сложно. Попробуйте для начала потренироваться на наиболее легком проекте, и только потом разбирать сложные.

  • Роли надо выписывать все. Можно не сразу со всеми ролями что-то делать, например, не договариваться сразу, но понимать, какие роли есть и когда и где они могут застопорить рабочий процесс или начать активно отстаивать свои интересы – это важно.

  • <li>У разных ролей будут разные описания (viewpoints) системы, это нормально. Чтобы лучше договариваться, нужно попробовать описать систему из их ролей (&quot;натянуть шкуру&quot; другой роли) и попробовать дальше объяснить свои ролевые интересы людям в других ролях так, чтобы им было понятно, о чем речь (разговаривать на их языке), и также понятно, как проблемы на вашем системном уровне отразятся на их работе и их ролевых интересах. Если те роли, которые на n уровней выше, и после этого не готовы решать проблему и разговаривать, значит, надо идти на уровень n+1 выше. Идти к начальнику (по должности) человека в той роли, которая для вас важна, и доносить до него важность проблемы &ndash; и тут опять нужно понимать ролевые интересы этого начальника и говорить с ним на его языке. Объяснять проблему при этом лучше в терминах ролей (&quot;инженер должен выбрать новый строительный материал, потому что старый слишком дорог и неэффективен для строительства&quot;) и только потом уже добавлять должность и имя человека в роли, которая отказывается с вами договариваться. Те объяснить, что человек не исполняет в данный момент свою роль. Дальше нужно предложить вариант решения в терминах ролей. Если человек-в-роли по-прежнему не хочет договариваться, только тогда уже рассматривать варианты смены исполнителя роли в данном проекте. При этом, если у вас нет полномочий на это, нужна будет пропитка тех, у кого полномочия есть &ndash; и это опять-таки обсуждение ролевых конфликтов по примерному алгоритму, написанному выше, только не один раз, а регулярно. Можно без должностей и имен, но обязательно в ролях.</li><br />
    
    <li>Проблемы с частями системы часто возникают в ИТ-проектах, когда айтишники занимаются небольшой подсистемой системы обеспечения (AIsystant / MS Teams для ШСМ из примера на лекции 10). Возможно, станет понятнее, почему проблема (и на вашем ли она уровне), когда будет простроена вся цепочка от целевой системы и надсистемы до системы обеспечения и находящейся в ней вашей системы. Если проблемы на несколько уровней выше, то надо поднимать этот вопрос с руководителями, которые в своих ролях заинтересованы в решении проблемы, и пробовать поднимать выше по уровням. С первого раза это скорее всего не получится, требуется пропитка: донести важность проблемы, предложить способы решения, понимать уровень иерархии и тп.</li>
    

    Что касается "работы по схемам": системное мышление дает объекты внимания, те на что нужно обращать внимание в проекте, чтобы проект был успешным, но не дает единого для всех свода правил. Те это не правила ПДД вроде "подойди к переходу, убедись, что горит зеленый свет, посмотри направо, посмотри налево, и если нет машин, то переходи". Нет, у каждого проекта свой "рецепт успеха", бездумно копировать схемы не получится. Более того, успешные проекты в конце действительно частенько отличаются от изначально запланированных действий – как обсуждали в лекции 10, это связано с несовершенством доступной информации: на старте у вас никогда не будет 100% всей нужной информации для успешного завершения проекта, в ходе реализации может многое поменяться. Успешный не тот проект, который соответствует начальному плану, но тот, в результате которого интересы внешних (и внутренних!) проектных ролей удовлетворены. Поэтому придется меняться, и иногда меняться часто и сильно. И нередко озарения и удача будут играть в успешности проекта немалую роль – это норма. Системное мышление отвечает за повышение шанса проекта на успех, но даже с ним не всякий проект будет успешен, увы.

    Мария, благодарю за пост!

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

    На данный момент у меня у самого мозг "артачится", когда начинаю накладывать полученные знания на свою реальность, частично из-за немного рваного ритма задачи из чек-листов копятся и единая структура изучаемого материала складывается с большим трудом…

    Я думаю дорогу осилит идущий )

    Добрый день.

    Часть этих проблем ощущаю в своих проектах тоже. Проект это вообще довольно сложная громоздкая и трудно прогнозируемая, на дальнюю перспективу, штука. Так что раз за разом, шаг за шагом и у вас будет получаться всё лучше и лучше. Главное не забывайте периодически оглядываться назад и смотреть, что было хорошо и можно оставить, а что лучше изменить в своих практиках :slight_smile: