Эссе о разработке игр, мышлении и книгах

О книге «Системное мышление 2019»

Обложка книги «Системное мышление 2019»

Автор книги — Анатолий Левенчук — широко известный в узких кругах евангелист системной инженерии. Блогер, научный руководитель Школы системного менеджмента, пишет учебники, до одного из которых у меня наконец дошли руки.

Книга оставила о себе двоякое впечатление.

С одной стороны, по содержанию она вполне похожа на учебник системной инженерии. Информация в «системном мышлении» подана хоть и не лучшим образом, но вполне понятно. Желающий разобраться — разберётся. Тем более, автор сам предупреждает в начале учебника, что тот плохо подходит для самообразования — писался под школу.

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

Выбирать «Системное мышление 2019 » первой книгой по системной инженерии не стоит. Если вы хотите познакомиться с предметом, лучше возьмите Путешествие по системному ландшафту Гарольда Лоусона. В ней представлена хорошая ретроспектива системной инженерии, равно как и описание основных практик. Потом уже, по желанию, можно читать «Системное мышление»  или ещё что-нибудь.

Далее расскажу как в книге подаётся материал, чем она хороша и какие у меня к ней претензии.

Подача

Вы сразу / с первых строк уловите уникальный стиль автора. Характеризовать его можно обильным использованием синонимов / аналогий / терминов из смежных областей, равно как и английской терминологии, для более точной передачи мысли.

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

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

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

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

Хорошие стороны

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

Особенно понравился взгляд на требования к системе и ограничения:

  • Требования — описание системы как чёрного ящика.
  • Ограничения — описание системы как белого ящика.

Или вот ещё пара интересных мемов:

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

Из больших вопросов интереснее всего раскрыты:

  • Выработка общего языка участников проекта и организация общения.
  • Роль времени в определении границ системы (как одного из измерений).
  • Логика определения целевой системы проекта.

Претензии

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

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

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

Ракетостроение как раз является примером области с заметными эволюционными процессами (как и любая другая R&D область). Необходимым для запуска ракеты стандартам, процессам — идеям неоткуда взяться, кроме как появиться в результате её самоорганизации, — их нет во вне системы (почти нет).

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

«Платоновская» философия

Напомню, в философии Платона существует два «мира»: мир идей, с образами идеальных объектов и мир вещей — неидеальных копий идей.

Местами складывается впечатление, что автор придерживается некоей модификации этого античного мировоззрения.

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

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

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

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

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

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

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

Следствие игнорирования эволюционных процессов

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

Пропуск важных вопросов

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

Поверхностные примеры

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

Претензии к софтостроению представлены крайне однобоко, как будто перед разработчиками стоит задача оптимизации только одного критерия — «правильности» системы. Это обоснованная претензия с точки зрения платоновской философии, но не с точки зрения эволюции реального мира.

На каждую организацию оказывает давление множество факторов. Её развитие и поведение определяется их совместным эволюционным давлением. В первую очередь это касается процессов, обеспечивающих выполнение основных функций организации. Распространять утверждения о «некачественном организации процессов» на всю отрасль, только потому что со стороны они выглядят не оптимальными, как минимум, не вежливо.

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

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

Игнорирование сложности в сравнениях

Примечательна демонстрации оптимизации цены связи компонент системы через стандартизацию интерфейсов.

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

Более грубую аналогию мне и придумать сложно.

Во-первых. Идёт сравнение системы разработанной для выполнения чётко заданной цели с системой таковой цели не имеющей. Между тем, стоимость поддержки системы можно оценивать только в контексте её целенаправленной деятельности.

Во-вторых. Левенчук опускает вопрос привнесённой сложности. То есть сложности, добавленной в систему вследствие ошибок при её развитии. Вся электроника на текущий момент развивается от силы лет 70, что не идёт ни в какое сравнение с миллиардами лет эволюции. Фактически, он сравнивает не «качество» систем, а срок их жизни. При этом мы уже, например, видели ошибки в процессорах, подпадающие под определение привнесённой сложности.

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

Переусложнённое описание альф

Заметная часть книги посвящена «альфам».

Альфа — ALPHA — abstract-level progress health attribute.

Есть вариант, что я так и не понял, что в точности под ними понимает автор. Но если я понял правильно, то это ключевые элементы абстрактной модели системы, которые нужно уметь переносить на объекты (четырёхмерные) реального мира, чтобы по состоянию реальных объектов оценивать состояние системы.

  1. Держим в голове абстрактную (высокоуровневую) модель системы в 4D.
  2. Выделяем в ней ключевые части.
  3. Соотносим их ожидаемое состояние с реальным состоянием системы.
  4. На основе этого делаем какие-то выводы, производим какие-то действия.

То есть вся суть альф в синхронизации ментальной модели с реальностью.

Рассказывается же о них как о некоей пафосной сверхсложной штуке. И название мне не нравится :-)

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

Книга не про системное мышление

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

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

Что я хотел бы видеть в книге про системное мышление (часть этого есть в учебнике, но в неявном виде):

  • Глубокий разбор разделения на внутреннюю и внешнюю среды системы, определение их границы и особенности её работы.
  • Анализ и синтез систем.
  • Глубокий разбор понятия «сложность» и её видов.
  • Анализ эволюции систем, их изменений, распространения изменений по подсистемам.
  • Рассмотрение фенотипа системы, как артефакта её деятельности.
  • Рассмотрение базовых принципов организации систем: ортогональность, дублирование, нормализация/денормализация, инварианты.
  • Рассмотрение базовых явлений в системах: появление и накопление ошибок, обратная связь.
  • Концепции управления системой / контроля системы.

Ещё один мемплекс

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

По видимости такой эмерджентности нет. Не в том смысле, что при следовании практикам системной инженерии не будет эмерджентного эффекта, а в том, что аналогичные эффекты можно получать следуя и другим наборам практик, или следуя набору практик частично.

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

Большинство атомарных практик системной инженерии не являются её прерогативой, а скорее являются универсальными эвристиками.

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

В будущем я откажусь от соотнесения какой-либо своей активности именно к системной инженерией.

Поскольку мышление и системы остаются мне интересными, придётся придумать свой термин, чтобы не пересекаться по терминологии. Пусть это будет «мышление системами».

Кстати, мой пост на хабре О системном мышлении, похоже, как раз о мышлении системами.

P.S. Из-за подачи методологий через совокупность практик, а не через базис, вроде мышления системами, у многих методологий (ТРИЗ, Системная инженерия) складывается репутация карго-культов. Я бы на месте их апологетов постарался с этим что сделать.