Я часто вижу среди рекомендаций по системному анализу книгу Донеллы Медоуз "Азбука системного мышления" ('Thinking in Systems. A Primer'). Тут у меня дошли руки прочитать её.

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

Ну да, это известная проблема с одинаковыми названиями двух совершенно разных дисциплин: системного анализа и системного анализа. Первый — кусок из кибернетики/теории управления, с математическим моделированием, теорией оптимизации и принятия решений, исследованием операций и всяким таким. Второй — набор практик для выявления требований и проектирования ИТ-систем. Вот "Азбука системного мышления" из первой области. Более того — это "системное мышление" применительно к управлению социальными системами, а технические если и упоминаются, то лишь в качестве иллюстрации.

Какие тезисы внутри:
🔸 Системы состоят из элементов, связанных потоками информации. Пока вроде всё ок.
🔹Поведение системы может быть адаптивным, целеустремленным, ориентированным на самосохранение и иногда на эволюцию. Очевидно, мало какие ИТ-системы обладают такими свойствами. Скорее наоборот — сами по себе они практически не адаптивны, не ориентированы на самосохранение или эволюцию.
🔸Цель системы, как правило, не выражена явно. Всё наоборот, да?
🔹Главное в системах — запасы, то, что накапливается. Ну, в каком-то смысле можно рассматривать накопление информации, но тут есть ловушка: обычно в ИТ-системах накапливается информация, но только эта "информация" обычно не имеет смысла для системы: система никак не меняется под действием этой информации. Это отличается от понятия "информация" из физики, где поступление медленнее, чем изменение объемов входящих и исходящих потоков. То есть, у системы есть инерция, и она меняется под внешним воздействием не так быстро, как мы ожидаем. Это с одной стороны может демпфировать резкие скачки потока, не давая системе сломаться, с другой — затягивает требуемые изменения. Даже не знаю, как это применить к ИТ-системам, разве что к проектированию нагрузки и эластичности.
🔹Наличие запасов позволяет исходящим потокам не зависеть от входящих.
🔸Система управляет собой через обратные связи. Но в ИТ-системах ничего подобного нет! Они не эволюционируют сами по себе, не содержат петель обратной связи и у них нет запаздывания реакции.

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

В общем, это всё очень интересно с точки зрения внедрения изменений в организациях и обществе, но к ИТ-системам имеет отдаленное отношение. Для ИТ-систем это всё начинает работать, только если мы включаем в рассмотрение команду поддержки и разработки системы — тех, кто как раз получает обратную связь о работе системы и может её менять. Если рассмотреть всё вместе: ИТ-систему, технические средства и команду разработки, а ещё лучше — управленческую и политическую обвязку — то принципы Медоуз начнут работать. Именно в управленческом или лидерском аспекте. Может быть также полезно посмотреть с этих позиций, если вас интересует — как изменится деятельность организации после внедрения какой-нибудь системы. Это уже для правильных бизнес-аналитиков и продактов.

А для задач сбора требований и проектирования программных систем книга практически ничего не дает.