Плохо выделенная система, лучше чем никакая

Пост по мотивам 8-ой главы учебника ССВСМ.

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

  • Целевая система - роль junior node.js разработчика
        - Список требований к роли взял из сети.
  • Надсистема - роль fullstack разработчика
  • Системы обеспечения
        - курс по node.js
        - тематические youtube каналы
        - чаты в телеграме
        - инструменты: редактор кода, утилиты, онлайн сервисы
  • Системы окружения
        - API других сервисов
        - облачные хранилища
        - библиотеки методов
  • Подсистемы
        - владение практиками создания API, подключение БД, деплой приложения

При выделении системы пользовался подсказкой из учебника:

В личных системах целевой системой часто является "обладающий мастерством играть новые роли человек"

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

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

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

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

Артур, спасибо за пост!
Хорошо, что попробовали провести системное разбиение. Пока в нем есть что исправлять)
Немного вопросов “на подумать”:

  • Может ли в названии роли быть слово "старший/младший"? Почему?
  • точно ли ваша система – вот эта штука, обозванная ролью, или какое-то мастерство? что это за мастерство и из каких практик состоит?
  • когда описываете систему обеспечения, надо помнить, что система обеспечения буквально создает целевую. Как курс сам по себе изготавливает вашу ЦС?
  • чем не устраивает применение СМ для личных проектов? а как ничего не забыть в проекте – личном ли, рабочем ли? я использую системную схему проекта как чеклист "а ничего ли я не забыла" и чтобы выяснить, почему мой проект не двигается или двигается небыстро.

Спасибо за вопросы, Анна!

  • "старший/младший" может указывать на уровень владения ролью, название самой роли может быть и без этого уточнения
  • Специально привёл цитату из учебника про человека обладающего мастерством играть новые роли и не увидел разницы как назвать систему. Теперь перечитываю и вижу различие между абстрактной "ролью" и конкретным "человеком обладающим мастерством". Практики ещё предстоит описать.
  • Конечно, курс сам по себе не является системой обеспечения. Это стало яснее после 9-ой главы. Сейчас такое описание возникло для системы обеспечения - это я, выполняющий по составленному графику задания курса.
  • Применение СМ для личных проектов - устраивает и подталкивает к тому, чтобы проекты были сложными и интересными. Самим понятием "проект" пользоваться начал недавно и сейчас переопределяю, что считать проектом, а что чем-то иным. Вот для иного - какой-то простой деятельности, СМ может быть избыточно.