У вас тут чуток перемешана программная инженерия и computer science, но больше всего путаница в описываемой деятельности. Очень похоже на разницу в programming-in-the-large (реально групповой рабочий контекст в крупной разработке, “исполняется код, собираемый от многих”) и programming-in-the-small (скажем, олимпиадное программирование: один человек крепко думает на пару часов, результат – полсотни строк сложного кода, выполняется только этот кусок, результаты видны мгновенно).
Эта проблема “в большом” и “в малом” – всеобщая. Я раньше много раз её касался, вот текст 2019 года “Умненькие дебилы: умны в деле-в-малом, дебилы в деле-в-большом”, Умненькие дебилы: умны в деле-в-малом, дебилы в деле-в-большом: ailev — ЖЖ, и там в четвёртом абзаце ещё несколько ссылок и много замечаний (скажем, “проекты-в-малом – рукоделия, проекты-в-большом – коллективная проектная работа. Личные проекты – рукоделия”, или T-люди это про умение делать и проекты-в-малом, и проекты-в-большом). Новые заметки:
– “в малом” – это на одном системном уровне (или одном уровне разложения метода, если это алгоритмика) и обычно вопрос одной роли. Но если есть затыки, то ходы делаются внутрь системы (если затык в программном коде, то ход делается на аппаратуру. Если затык в танцевании – ход делается на телесную работу, если в телесной работе – в физиологию). “В большом” – это много системных уровней, а при проблемах первый шаг ожидается от границы твоего уровня наверх, классическое системное мышление.
– в реальных проектах нужно и мышление-в-малом (“изобретение”, концепция системы – и детали реализации, собранность команды над “нашей системой”), и мышление-в-большом (концепция использования нашей и понимание причинно-следственной цепочки к скорости выпуска целевой). Эту фразу можно раскрывать бесконечно.
– один из грехов мировоззрения – это невидимость проекта-в-большом (проекта целевой системы, часто там ведь ещё и много организаций, и нетривиальные инвестирования, и дикое разнообразие ролей, и неопределённость самого проекта – ибо supply chain можно всегда обсуждать чуть ли не “от руды”. Скажем, давайте обсуждать создание суперкомпьютера для AI, потихоньку приближаясь к главной проблеме: где брать песок для кремния, из которого будут сделаны чипы. Или ювелирку будем обсуждать, начиная с того, откуда в земной коре взялось золото и где его искать) для людей, которые заняты проектом-в-малом, “нашей системой”. Просветление в том, что для реальной приложимости в мире мало обсуждать при помощи системной мантры одну систему (“нашу”, другую-то не видно!), надо обсуждать в минимальном виде две мантры – для нашей и целевой системы, а если ты с кем-то взаимодействуешь: три мантры (целевая, наша и его система с их нетривиальными взаимосвязями, которые надо объяснять, то есть приводить причинно-следственные связи). Одна мантра – “не могу договориться”. Две мантры – “стал быстрее договариваться” (ибо показываешь, как ты работаешь на общую цель, первый же, с кем договариваешься – ты сам! Коммуникация с собой тоже требует перехода от мычания к языку). Три мантры – “я со всеми договорился”, системное мышление на множестве мантр, “проект-в-большом” – “договорил всех”.
– всё это отягощается динамикой. Так, важны не системы, а скорости выпуска систем, и причинно-следственные связи надо тянуть на производные выпуска во времени (скорости, ускорения и рывки).
– когда мы занимаемся проектами-в-малом, всё довольно просто: идём по системным уровням к “простой физической системе”, а в графах создания – к одному человеку, а там к одному мастерству. Как только мы пошли вверх – там драконы: от чего-то небольшого технического быстро выходим на всякие “техносферы”, а в графах создания – через организации немедленно выходим на сообщества людей. Внятного разговора на уровне техносферы не получается (там сразу прыжок в техноэволюцию), про сообщества – то же самое, ибо культурная эволюция.
– в программировании ходы вверх, на программирование-в-большом крайне трудны, этот “верх” для инженеров невидим – нет языка для обсуждения того, что выше “моего изобретения”. А, например, в социальных танцах – наоборот, хорошо видно всё, что там выше – уровень организации обычно пропущен (там “организация” с её ролями – это “вечеринка”), и вместо перетирания косточек менеджеров и смежников-инженеров обсуждаются сразу проблемы сообщества, начиная с пресловутого ННННД (никто никому ничего не должен). Языка нет, но обсуждение-то есть! Но вот “вниз” там – тоже “драконы”, ибо языка для обсуждения особенностей собственного танцевания нет (начиная с того, что “танцевание” это метод, а с методами проблемы – там как чеширский кот, сразу надо обсуждать разложение метода, а это невозможно без декомпозиции ролей, в “Методологии” прямо в первом разделе указано, почему так трудно).
– в-большом там может быть расщепление уровней (тоже шкала, вряд ли дихотомия): организация и сообщество. Вот эти ходы на клиентуру, на инвестуру всё-таки тоже – ходы на в-большом, только в-очень-большом. То есть какие-то существенные черты этого “в большом” отличаются на разных уровнях, вопрос дико недоисследован.
– я планировал писать “инженерию сообществ” вот прямо сразу после “Методологии”. Сейчас я склоняюсь к тому, чтобы заняться прикладной методологией систем AI (ожидаю курс Григория Сапунова) и прикладной методологией социального мультиданса. В первом случае придётся выходить на методологию сообществ на высоких уровнях тамошнего стека, при этом там “сообществами агентов” называют и организации тоже, где понятно кто за что в организации ответственен и у кого какие полномочия. А во втором случае то же самое – сразу придётся промахивать уровень организации и говорить о “тусовках”. Собственно, системная инженерия, инженерия личности, системный менеджмент как инженерия организаций – это тоже “прикладные методологии”, но достаточно обобщённые. Вот для сообществ это надо делать – и, похоже, подняться до обобщения “на примерах” можно легче и надёжней, чем бороться сразу “социологически”. Шанс прорваться с “подходом” (отработать хоть что-то на более заземлённых/grounding примерах, а потом обобщить) выше, чем что-то там абстрактное сформулировать, а потом поприкладывать успешно к прикладным областям. Скажем, предложение разложения танцевальной культуры в спектр в танцах (раньше это был стек) было прорывным шагом, а потом на этой базе с разной степени успешности мы это применяли для других практик – тот же интеллект-стек был сделал “о образу и подобию”. Возможно, надо этот ход повторить для уровня сообществ. В танцах там много удобных примеров: есть сообщества, которые “народные, но есть звёзды”, а есть сообщества, которые “авторские”, удобно обсуждать “роль личности в истории” и идеи эволюции. И это не тусовки вокруг брендов, хотя тут тоже всё очень и очень похоже. Тут ещё интересно, что мы хорошо проработали нижние уровни разложения танцевальной культуры в спектр (и даже есть курсы по этим нижним уровням), а верхние уровни – нет, только наметили их существование. Вот и надо будет понять, что и как мыслить на этих уровнях, в каком языке – и насколько этот язык приложим к агентам AI (и наоборот). Снизу вверх, так победим.
– контрольная точка тут у меня – 1-8 сентября 2024, я должен буду рассказывать про мультиданс на Q-fest в Витязево под Анапой, я там лектор. Вот и попробую собрать мысли в кучку, это будет аккурат после окончания переписки “Методологии”. Возможно, надо будет подумать уже и о курсе “для своих” (ибо это прикладной курс, его надо предлагать после основной программы). Все проблемы там известны, например, надо будет решать проблемы ритмики где-то на очень низких уровнях шкалы методов, проблемы мычания на уровнях сообщества – но главное, там ведь более-менее полноценное функциональное разложение (разложение культуры социальных танцев, разложение метода), и можно потренироваться на более-менее всем понятном примере.
Пробежитесь там по ссылкам и ссылкам в текстах по ссылкам, много будет интересного. В том числе ключевой вопрос оригинальной статьи: почему таки работе-в-большом не учат, ей учатся только исподволь. А учат только работе-в-малом, как вы и пишете в своём посте.