Это вторая из двух статей о системном мышлении в разработке программного обеспечения. Как и любое продолжение, в нем будет больше смысла, если вы уже видели часть 1, и, как и любое хорошее продолжение, он пытается разрешить некоторые оставшиеся без ответа вопросы, поставленные его предшественником.

Часть 1 представила 8 системных архетипов, описанных Даной Медоуз в Системном мышлении - Учебник, и описала их, исходя из моей системы взглядов как инженера-программиста. Эти системные архетипы образуют ловушки, которые могут привести к негативным результатам во многих сферах жизни, и программная инженерия или интеллектуальная работа в целом не исключение. Мы рассмотрели управление техническим долгом, коллективное владение кодом, унаследованный код, мотивацию, стимулы, метрики кода, исправление ошибок, продуктивность и Agile и увидели, что их проблемы являются симптомами тех же самых системных паттернов, которые мы видим в глобальных проблемах. от сокращения рыбных запасов до пристрастия к гонке вооружений.

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

Так что, если хочешь, давай зажжем факел и заглянем ...

Ловушка

Перед вами сцена, напоминающая фильм об Индиане Джонсе. Подстерегала целая куча ловушек. Один неверный шаг, поездка, мгновенная потеря концентрации, поспешный выбор - и вы окажетесь на улице прежде, чем сможете сказать: «Я ненавижу змей».

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

Держись за шляпу ...

Политическое сопротивление

Эта ловушка, также известная как «Неудачные исправления», предотвращает изменение системы из-за конфликтующих потребностей нескольких участников в системе.

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

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

Так как же нам обезвредить ловушку политического сопротивления? Начнем с нескольких вопросов: -

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

Можете ли вы посочувствовать этим людям? Что бы случилось, если бы вы это сделали?

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

Что бы произошло, если бы энергия, потраченная на сопротивление, вместо этого была бы направлена ​​на поиск взаимоприемлемых путей для достижения всех целей? Что, если вы поднялись по лестнице и взглянули на систему с более высокого уровня? Может быть, вы могли бы переформулировать цель так, чтобы она отвечала потребностям каждого.

Если нет, то кто?

Если задуматься, система, оптимизированная только для скорости и только скорости, является субоптимизацией, как и система, оптимизированная только для технического совершенства и технического совершенства. Большинство систем требует баланса. В разработке программного обеспечения низкий технический долг часто означает лучшую производительность, что является «беспроигрышным». Если переосмыслить цель на системном уровне, «выиграть-выиграть» превратится просто в «победу». Действительно ли ваша задача - это игра с нулевой суммой?

Так действительно ли забота о нуждах людей - это ответ?

Я мог бы рассмеяться о правиле бойскаутов, TDD или радостях статического анализа, и у вас был бы ответ на тарелке. Было бы это более эффективно удовлетворить ваши потребности?

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

В следующую ловушку…

Трагедия общественного достояния

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

В Части 1 описывается, как индивидуальные стимулы могут привести к истощению общего ресурса, что в конечном итоге приведет к тому, что система просто не сможет поддерживать себя или отдельного человека. Если рыбаков будут мотивировать (обещанием прибыли) выловить как можно больше рыбы, в конечном итоге не будет ни рыбы, ни рыбаков.

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

Так что же делать? Должны ли мы сосредоточиться на долгосрочной ремонтопригодности, а не на скорости разработки? Если бы мы это сделали, подстерегали бы мы другие ловушки?

Ключевым моментом здесь является баланс, борьба между долговременной ремонтопригодностью и скоростью разработки не обязательно должна быть игрой с нулевой суммой. Фактически ремонтопригодность должна повысить скорость разработки. Так почему же наша погоня за скоростью так часто приводит к снижению качества? И как это исправить?

Давайте ответим на это еще одним вопросом (извините, ребята, вы ведь искали ответы, не так ли?): -

Почему моя погоня за пончиками приводит к тому, что я толстею?

Ответ заключается в том, что я чувствую чистую радость в моменты после «пончика», а жирность одного пончика крошечная и не проявляется до тех пор, пока сладость не покинет мои губы. Другими словами, первоначальная обратная связь вознаграждает меня, результаты одного проступка минимальны, а в петле обратной связи между причиной и конечным следствием есть огромная задержка.

Представьте, что вы расстегиваете пуговицу на рубашке каждый раз, когда съедаете пончик. Как это повлияет на ваше потребление Krispy Creme (доступны и другие пончики)?

Представьте себе, если бы будильник срабатывал каждый раз, когда вы использовали глобальную переменную. Как это повлияет на ваше понимание того, как вы истощаете общую базу кода?

Я надеюсь, что вы пришли к собственному выводу о том, как деактивировать трагедию общества. Что вы делаете, чтобы сократить длину цикла обратной связи между вашим кодом и его эффектами?

Сначала вам нужна осведомленность, а затем выберите свое решение: парное программирование, статический анализ, обзоры кода, запросы на вытягивание, TDD, тестирование производительности, наставничество, обучение, коучинг.

Какие инструменты улучшения обратной связи вы используете, чтобы избежать трагедии общества?

Дрейф к низкой производительности

Мы все испытали огромный оптимизм, связанный с новым проектом.

«На этот раз все будет по-другому. Мы будем делать TDD с самого начала, мы будем настолько ПОЛНЫМИ, что сам дядя Боб назовет нас «So SOLID Crew».

Затем кто-то забывает про модульный тест или поспешно создает класс, который придерживается хваленого «принципа единой безответственности». Внезапно изначальный образец совершенства кодирования оказывается запятнанным, и становится легче пропустить следующий модульный тест, в то время как дизайн по контракту начинает напоминать дизайн по катаракте. Это дрейф в сторону низкой производительности.

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

Итак, что делать Инди?

Эта ловушка в основном вызвана измерением текущего состояния системы по сравнению с ее предыдущим состоянием. Когда текущее состояние лишь немного хуже предыдущего, мало причин для паники и мало причин для действий. Вот почему переход к ловушке с низкой производительностью часто называют синдромом вареной лягушки.

Что, если бы вместо этого мы сравнили текущее состояние системы с ее наилучшим состоянием? Как это может повлиять на ваше восприятие последствий еще одного взлома?

Сначала вам понадобится объективная оценка текущего качества и сложности вашего кода. Это необходимо, поскольку мы не можем полагаться на то, что не сосредоточимся больше на плохом, чем на хорошем. Какие инструменты и показатели вы могли бы использовать для этого? Затем вам понадобится соглашение между вашей командой, чтобы эти показатели не опускались ниже определенной отметки.

Можете ли вы использовать подобную технику, чтобы перевернуть эту ловушку с ног на голову, создавая дрейф к высокой производительности?

Те из вас, кто читал часть 1, возможно, сейчас воспылают моим лицемерием. Ищу неправильную цель - кричите вы! Ну да… если бы команду побудили улучшить свои сонарные метрики по сравнению со всем остальным, у вас возникла бы проблема неверного поиска целей. Системы представляют собой хрупкий баланс, и оптимизация одной подсистемы часто вызывает дисбаланс в целом.

Такова жизнь.

Вот почему серебряных пуль не существует.

Поймите это, и мои посты будут стоить того.

Эскалация

В Части 1 ловушка эскалации описывается как гонка вооружений, в которой несколько действующих лиц мотивированы превзойти друг друга в крещендо превосходства одного.

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

Здесь уместна метафора «война». Эскалация конкуренции до тех пор, пока система не сломается или кто-нибудь не пострадает настолько, что не сможет больше продолжать. В вашей организации идет война? для чего это нужно?

Война… Ага… Для чего она нужна?

Часть 1 описывает, как некоторые организации пытаются мотивировать людей посредством конкуренции. Это опасная игра, поскольку она обычно заигрывает не только с ловушкой эскалации, но и с поиском неправильных целей, успехом к успеху и трагедией общества. Вы когда-нибудь работали в организации, которая, например, публикует ежемесячные списки 10 лучших коммиттеров? Десять самых плодовитых авторов модульных тестов? Десять лучших исправителей ошибок? Сравниваются ли команды с совершенно разными задачами друг с другом, как если бы они были яблоками по сравнению с другими яблоками?

Вы говорите, что это безвредно? Какие условия могут потребоваться для этого?

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

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

Успех к успешному

В Части 1 «успех для успешных» описывается как ловушка, ограничивающая возможности и привилегии только тем, кто уже кажется успешным.

Это мнение выражено в общей фразе «успех рождает успех». Очевидное следствие этого состоит в том, что неудача порождает неудачу.

Эта ловушка прячется на видном месте за кажущимися мягкими объятиями «меритократии» - политической философии, которую поддерживают многие компании, которая считает, что власть должна предоставляться отдельным лицам исключительно на основе их продемонстрированных заслуг. Это достойно восхищения, поскольку при определении возможностей не учитываются такие факторы, как привилегии или богатство, и полностью сосредоточивается на индивидуальных заслугах. Идея состоит в том, что метафорический крем поднимается наверх, независимо от описания метафорической коровы, откуда он появился.

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

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

Я пишу свой первый модульный тест и в хорошем старом стиле TDD запускаю его до того, как напишу код реализации. Это не удается. Карьера окончена. Конец.

Конечно, это абсурдно, но это иллюстрирует, как стремление к тесной обратной связи в XP, гибких и бережливых методах работы в основном способствует раннему и частому обнаружению неудач. Это реализовано на всем пути от TDD и парного программирования до MVP и учета инноваций. Как может повлиять на способность организации получать прибыль от гибкости нежелание флиртовать с неудачами?

Итак, ваша организация наказывает неудачи. Что вы можете сделать по этому поводу? На самом деле неудивительно, что многие организации презирают неудачи. Это нормально. Надо быть мазохистом, чтобы встречать каждую неудачу ухмылкой и щелчком каблуков. Однако, как ни странно, ключом к тому, чтобы увидеть положительную сторону неудач, может быть просто делать больше. Больше неудач означает более частые неудачи, а более частые неудачи означают, что стоимость каждого отдельного отказа ниже, а соответствующее обучение позволяет в конечном итоге достичь успеха быстрее.

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

Неудача требует ребрендинга. Есть даже глобальная конференция под названием Failcon, которая специализируется на изучении организационных неудач и извлеченных уроков.

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

Перекладывание бремени на нарушителя

В Части 1 перекладывание бремени на исполнителя описывается как зависимость.

Зависимость возникает, когда зависимость от конкретного решения проблемы подрывает способность системы поддерживать себя. Такие решения часто принимают форму быстрых исправлений. Справиться со стрессом можно, например, самолечением с помощью алкоголя. Это дает временное облегчение, но быстро подрывает способность организма эффективно справляться с дальнейшим стрессом, что приводит к отрицательной спирали. Просто перенос бремени вызван лечением симптомов, а не причины.

От чего зависит ваша организация?

  • Исправление ошибок, а не основных причин?
  • Работать сверхурочно (с большим энтузиазмом!), Чтобы уложиться в сроки, а не работать в стабильном темпе?
  • Нанимать больше сотрудников для повышения эффективности использования ресурсов, а не для повышения эффективности потоков?
  • Использование командования и контроля вместо того, чтобы доверять и воспитывать автономию?

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

Как это остановить?

Исцеление от зависимости сложно. Это больно. Организационные зависимости могут не вызывать в памяти те же самые внутренние образы, связанные с наркотической или алкогольной зависимостью, но я действительно утверждаю, что они по-прежнему разрушают жизни. Первый шаг - признать, что вы зависимы. Второй - понять почему. Только тогда можно заниматься реабилитацией.

«Вмешатель» - это всегда решение проблемы. Алкоголь от стресса, хитрости по срочным производственным вопросам, сверхурочная работа в сжатые сроки. В чем могут заключаться преимущества изучения коренных причин этих проблем вместо того, чтобы искать решения? Какие условия могут потребоваться, чтобы вы могли это сделать?

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

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

Правило избиения

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

В Части 1 описывается, как водители обычно беспорядочно замедляют скорость для камер контроля скорости только для того, чтобы снова ускориться, как только исчезнет угроза их лицензии и банковскому балансу. Правило смотрит на закон так, как будто его соблюдают, но его нарушают. Это можно описать как следование букве, а не духу закона.

Вернувшись в страну разработки программного обеспечения, вы могли быть подвергнуты правилам, требующим длительной подписи для разрешения на начало работы, рассчитанной более чем на x дней. Если это приведет к переизбытку оценок на 1 день, вы станете свидетелем нарушения правил. @Matthewpskelton озорно и гениально предложил после прочтения части 1, что это точное правило можно использовать для поощрения небольших партий. Это могло бы сработать, хотя я полагаю, что организация, которая достаточно осведомлена о системном мышлении, чтобы использовать ложную бюрократию для грязного двойного креста своих сотрудников, могла бы придумать более эффективные способы уменьшить размер партии.

Если говорить о лучших способах, зачем вообще нужны правила? Это потому, что организации не доверяют своим сотрудникам? Причина в том, что потребности организации противоречат потребностям сотрудников, требуя приведения поведения в соответствие с угрозой наказания? Не потому ли, что организациям так сложно описать свои цели и принципы, что единственный способ удовлетворить свои потребности - это угроза наказания?

Этот последний вопрос может содержать вакцину против нарушения правил. Цель и принципы важнее правил любого дня недели. Какова цель вашей команды и по каким принципам вы живете и умираете? Ответьте на этот вопрос, и вам могут не понадобиться правила, и вам определенно не нужно будет держать под столом заостренную палку, чтобы угрожать нарушителям. Полиции предстоит нелегкая работа по повышению безопасности дорожного движения, поскольку им приходится бороться со всем населением. Организациям проще, поскольку они могут выбирать, кто на них работает. Гарантирует ли ваш процесс приема на работу, что люди, за которыми вы ухаживаете, разделяют ваши принципы и согласны с вашей целью? В противном случае вам придется заняться созданием правил.

Ищу неправильную цель

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

Мы рассмотрели легенду о царе Мидасе в части 1, который загадал желание, которое, как он думал, принесет ему богатство, но принесло ему только золото. Как и желания в сказке, цели имеют ужасную тенденцию производить именно то, что вы их просите, поэтому будьте осторожны с тем, к чему вы стремитесь.

Если вы хотите повысить качество кода, но определили свою цель с точки зрения увеличения охвата модульным тестированием, вы увеличите охват модульным тестированием. Можно только гадать, повысится ли при этом качество вашего кода.

Если вы хотите приносить больше пользы своим клиентам, но выражаете эту цель в терминах увеличения скорости, ваша скорость увеличится. Что касается стоимости, кто знает? Добавьте немного нарушения правил, и вы также можете обнаружить, что увеличение скорости - это мираж.

Это, конечно, не означает, что стремление к увеличению тестового покрытия - это плохо. Ни одна из них не нацелена на повышение скорости разработки, соблюдение установленных сроков, повышение гибкости или улучшение показателей findbugs, checkstyle, PMD или lint. Только не ожидайте, что эти цели что-то изменит. Могут, но опять же, вероятно, нет. Такие цели могут быть действительно полезными, даже важными, но они редко бывают целью. Однако их легко измерить: чего нельзя сказать о расплывчатых понятиях, таких как «бизнес-ценность» или степень удовлетворения потребностей пользователей.

А как насчет счастья?

Что насчет любви?

Ого… я только что упомянул слово «L»? Если вы тестировали воду с помощью электронной бомбы, попробуйте L-Bomb на размер и с удовольствием наблюдайте, как крахмал из воротников ваших коллег начинает течь.

Однако невозможность измерения не должна мешать чему-то быть истинной целью. Более того, если прокси-цели используются для управления производительностью, легко увидеть, как истинная цель может быть подорвана желанием достичь прокси-целей.

«Неверно полагать, что если вы не можете его измерить, вы не можете управлять им - дорогостоящий миф» ~ У. Э. Деминг

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

Просто намек: если вы наберетесь смелости задать вопрос, и ответ вернется как «максимизация акционерной стоимости», пожалуйста, не стесняйтесь блевать на весь стол в зале заседаний, прежде чем вежливо извиниться, потому что, откровенно говоря, мы: У всех нас есть дела поважнее, чем это.

Резюме

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

Так прав ли адмирал Акбар? Конечно, он знает ловушку, когда видит ее. Эти ловушки больше не ловушки?

Конечно, они все еще ловушки, но не в этом суть. Дело в том, чтобы распознать ситуации, с которыми мы сталкиваемся, такими, какие они есть, и в способности рассматривать систему в целом, а не просто маленький кусочек, который парит перед нашим носом.

После части 1 несколько читателей выразили потребность в ответах. Я пыталась пройти по канату между покровительственным рецептом и бесполезной неопределенностью.

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

Не могли бы вы поделиться со мной своими мыслями о том, как это помогло - или не помогло вам в поиске ответов?

Дополнительная литература

Следуй за мной в твиттере @smrimell