В ноябре я закончил прохождение курса “Системное мышление”. Мне постоянно приходится погружаться в работу систем, работу которых я плохо себе представляю из-за большого количества деталей, удержать в голове которые бывает очень сложно. Я делаю это во многом “по наитию” и сложилось ощущение, что многое упускаю из вида и должен существовать лучший способ работы со сложными системами.

Упоминание этого курса в неоднократно встречал в интернете (с ходу смог найти упоминание у Всеволода Устинова и Ивана Евтуховича) именно в контексте работы со сложными системами. Автор курса — Анатолий Игоревич Левенчук тоже был немного знаком по текстам из его блога, так что я решил пройти этот курс.

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

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

Конспект материалов

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

Системный подход

Системное мышление (systems thinking) — это мышление с использованием основных положений и приёмов системного подхода (system approach). Нет единого понимания того, чем именно должен быть системный подход.

Материалы этого курса основаны на системной инженерии (systems engineering). Самое современное определение системной инженерии дано в Guide to the Systems Engineering Body of Knowledge.

Главная цель системной инженерии: воплощение успешных систем.

Системы и стейкхолдеры

Система должна нести во внешний мир какую-то функцию, т.е. она существует для выполнения этой функции.

Запомнить:

При разговоре о новой системе типичной ошибкой является рассказ об устройстве (из чего она состоит) до того, как будет рассказано о функции (зачем она нужна). Чтобы подтолкнуть к рассказу о функции можно использовать “любимый” вопрос: “А какую проблему это всё решает?”

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

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

Отсюда вытекает и следствие: если новый элемент не даёт системе какого-то нового свойства или изменения в её функции, то возможно он не нужен в этой системе.

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

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

Успешность системы определяется по тому, как она соответствует ожиданиям стейкхолдеров.

Системная холархия

Системы взаимодействуют друг с другом. Чаще всего они относятся друг к другу как “часть — целое”, т.е. системы состоят из других более мелких систем.

С этой точки зрения система является холоном (состоит из частей сам и входит в состав другого холона в качестве части), а сама иерархия систем холархией.

Возможные виды систем по отношению друг к другу:

  • целевая система (system-of-interest) — система, над которой мы работаем, (на неё направлен основной интерес);
  • использующая чистема (using system) — система, в состав которой непосредственно входит целевая (как часть);
  • подсистема — часть целевой системы;
  • система в операционном окружении (operation environment) — система, взаимодействующая с целевой, которая влияет на использующую;
  • поддерживающая система (enabling system) — даёт возможность существовать целевой системе (люди и инструменты).

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

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

Целевая и использующая системы

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

Нет правил, по которым можно найти свою целевую систему, но есть признаки такой системы:

  • она есть в физическом мире;
  • это то, над чем работает твоя команда;
  • это то, что выходит наружу за пределы команды;
  • у неё есть требования, архитектура, проверки и приёмки.

Основные ошибки в определении системы:

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

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

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

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

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

Определение и описание системы

Стандарт IEC 81346 выделяет три аспекта устройста системы:

  • Компоненты (components, “функциональные объекты”, “альфы”) — из каких логических частей состоит система и как они связаны друг с другом (отвечает на вопрос “как оно работает?”)
  • Модули (modules, “конструктивные объекты”) — из чего сделана система (“из чего оно состоит?” / “как это сделать?”)
  • Размещения (locations) — место установки модулей (“где оно находится?”)

Разные стейкхолдеры могут интересоваться разными аспектами.

При создании системы сначала нужно сделать функциональную декомпзицию системы, а потом собрать её из модулей, которые выполняют конкретные функции на конкретных местах системы. Соотношение между модулями и компонентами не обязана быть 1:1.

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

Способы борьбы со сложностью в мышлении:

  • разделение интересов (по одному за раз)
  • разделение описаний по уровням холархии и частным описаниям каждого холона

Проверка и приёмка:

Проверка (verification) — проверка целевой системы на соответствие системным требованиям (system requirements)

Приёмка (validation) — проверка работы использующей системы на соответствие ожиданиям стейкхолдеров (stakeholder needs).

Архитектура:

Неформальное определение:

Архитектура — это обо всём важном, что бы это ни было

Отражает последовательность принятых важных решений. Решение важное, если при его изменении нужно переделывать всю систему. Должна содержать все три аспекта (компоненты + модули + размещения).

Жизненный цикл системы

Жизненный цикл — это про работы над целевой системой, которые осуществляются “силами” обеспечивающей системы.

В жизненном цикле любой системы есть следующие стадии:

  1. замысел
  2. проектирование (system definition)
  3. изготовление (system realization)
  4. эксплуатация (system operation)
  5. вывод из эксплуатации

Для визуализации удобно использовать V-диаграмму:

V-диаграма

Источник: А.И. Левенчук “Системное мышление”

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

Есть разные модели жизненных циклов: водопадная (каскадная), спиральная, итерационная. На их принципиальных схемах важно смотреть на связи между отдельными стадиями.

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

Практики

Практика — это функциональный элемент обеспечивающих систем (“как деятельности”, activity).

Практика состоит из дисциплины и технологии, поддерживающей эту дисциплину:

Дисциплина Технология
“Теоретическая часть” Практическая часть: конкретные материалы, инструменты и т.д.
“Загружается в голову” “Разворачивается на местности”
Меняется редко Меняется часто

Методологии состоят из набора практик. Брать из них только нужные — это нормальная “практика”.

Системная схема проекта

“она будет подсказывать, за чем вам следить в ваших проектах, чтобы они приводили к созданию успешных систем” (описание курса)

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

Системная схема проекта по стандарту OMG Essense

Источник: https://ailev.livejournal.com/1351873.html

Эти альфы разбиты на три основных области интереса (area of concerns):

  • Клиентская (customer) — относится к использующей системе;
  • инженерное решение (solution) — относится к целевой системе;
  • организационная (“предпринятие”) — относится к обеспечивающей системе.

Следить нужно за всеми альфами на протяжении всего проекта.

Если состояние какой-то из альф неясно, то нужно разбивать её на подальфы. Единых правил разбиения нет, главный критерий — изменение состояния подальфы должно вести хотя бы к небольшому изменению состояния альфы, которую она представляет. Пример: рассматривать каждый интерес стейкхолдера по отдельности.

Дополнительные материалы: