Пятый день 21 потока "Системного менеджмента и стратегирования 2021"
Вчера прошёл пятый день тренинга "Системный менеджмент и стратегирование 2021" для 21 потока.
Традиция повышений выпускников до директора по развитию прямо по ходу курса СМС продолжилась: можно поздравлять ещё одного студента с прыжком из "инженеров" в главного по развитию своей фирмы (как называется должность -- это совсем другой вопрос. Ну, и власть обычно берут, а не дают). Пятый день обсуждений был посвящён разбору нескольких типовых ситуаций:
-- сначала смотрим на целевую систему, затем на обеспечение. И оно в 10-100 раз сложнее, чем целевая система в части проектирования и изготовления! Производство сложно, но оно находится в тени, о нём редко говорят. Пример разговора на эту тему -- свежее интервью с Elon Musk, https://everydayastronaut.com/starbase-tour-and-interview-with-elon-musk/
-- если фирма занята какими-то мелкими объектами (деревьями), то обычно совокупность этих объектов (лес) никак не осознаётся, никак не называется, поэтому нельзя обсуждать эмерджентные свойства этой совокупности. Если тягач, то флот тягачей, если вагон, то пул вагонов (и слова даже разные), если клиент, то клиентела/клиентура, и т.д.. Это важно, ибо для целевой системы разворачивается её кейс, её жизненный цикл. Если у вас нет клиентелы, а есть только клиент, вы не можете её развивать как целое (скажем, наращивать число клиентов). Если у вас "узлы", то не можете обсуждать "покрытие узлами", ибо оно только у "сети узлов", другой объект.
-- как быстро можно развернуть архитектурное моделирование на productivity tools? Очередной заход через "конспектирование": берём кейс сотрудника, разбираем его по альфам, выделяем подальфы (ручка-бумажка). Затем берём какую-нибудь coda.io (потому как всего много и связность написанного на бумаге уже трудно контролировать) и выделяем состояния подальф и их контрольные вопросы. Дальше связываем с issue tracker в github, чтобы переходы состояний запускали какие-то задачи по продвижению кейса (контроль конфигурации работ). Затраты времени: 4 часа на освоение coda.io, 2 часа на беседы с сотрудиком и моделирование (у сотрудника модель и понимание мета-модели, кодирование мета-модели в coda.io и помнимание мета-мета-модели у нашего студента), 2 часа на колдовство с автомагизацией coda.io и issue tracker в github. Всё, очередное "приложение low code/adaptive case management/actionable_architecture/archictecture-as-a-code" готово, равно как есть обученный работой с этим приложением сотрудник. Можно удивляться успеху и переходить к следующему кейсу. Ждём теперь доклада на эту тему. Что послужило триггером к этой "пробе пера"? После изучения материала курса стали понятны доклады И.Падабеда и Ю.Геронимуса, и была сделана попытка повторить что-то подобное. Новация: был проведён поиск адекватного productivity tool для этой работы среди 15-20 софтов. Победитель конкурса -- coda.io. С архитектурой предприятия в какой-то момент неизбежен вопрос: "а что, так можно было?!". Да. Но только после довольно большого числа часов предобучения трансдисциплинам, разбирательства с мета-мета-моделью и пониманием как устроена вся цепочка до модели.
-- схематизация и рендеринг: программисты, "аналитеги" и т.д. все настроены на обобщение, схематизацию. Найти закономерность, обобщить её, дать сверхобщее имя -- и вуаля, дело сделано. Но схематизация подразумевает и возможность рендеринга: найти в окружающем мире (или разработать и воплотить!) ситуацию, попадающую под весь стек мета-моделирования. Слова там звучат экземпляров и их типов, а не типов из мета-мета-модели. Наш студент говорит на языке прикладного специалиста (рендеринг до описаний экземпляров, до модели!), порождает мета-модель (мышление! прикладные понятия как материал для мышления, мета-мета-модель как схема для её рендеринга в прикладной предметной области). Прикладной спец не говорит на системном и онтологическом языке, он поставляет рассуждения в прикладной области. На системном, онтологическом языке говорит наш выпускник/архитектор предприятия/методолог/мастер мышления. Мета-мета-модель библиотечна (например, из курса ШСМ). Это даёт ответ на вопрос: как работать с сотрудниками, которые не проходили курсов ШСМ, и работать прямо сейчас, а не когда-нибудь потом. Всё работает немедленно, если вы понимаете, что делаете! А "развернуть технологию"? Начальная технология -- ручка-бумажка, а потом можно и до coda.io добраться, через пару дней (а не пару лет!).
-- "дырка" инженерии требований между собственником с его бесконечными идеями и архитекторами в разработке. Иногда на этом месте есть какие-то "аналитики", но чаще таких нет. А если и есть, то они об инженерии требований не знают и просто превращают "идеи собственника в ТЗ для разработчиков", что совсем другое. Что делать? Брать productivity tool (экзокортекс!) и строить инженерию требований (что-то такое и было продемонстрировано в докладе И.Падабеда в той части, где он писал про аналитиков, работающих в coda.io).
-- ещё раз проговорили, "с чего начать": управление конфигурацией (версии продуктов, затем конфигурация работ -- убрать помойку из issue tracker и навести дисциплину его использования). Это убирает rework за счёт конфигурационных коллизий, суммарное время работ становится меньше за счёт качественной инженерии. Затем operation management -- kanban, то есть удавливание мультитаскинга (и стратегирование на каждом ходе: что именно является главнейшей задачей, что на критической цепи! И развитие, и совершенствование должны быть прицельны!). Время работ ещё поджимается за счёт оптимального планирования. Дальше пожары вдруг потухают, люди спокойно сами справляются с операционной работой, и можно заняться стратегированим и резким ростом (штатная работа с архитектурой предприятия через кейс-менеджмент и productivity tools -- запуск новых продуктных линий, переход на новые поколения технологий и другое интересное), или рапортовать, что "в лавке всё спокойно, сотрудники обойдутся без меня, мне скучно, пошёл искать сложные проекты в других местах".
-- в очередной раз обсуждали, что "распределённому PLM" в какой-то момент быть, ибо git окончательно победил всё централизованное в разработке. Варианты "централизованной распределённости" на blockchain не проходят, ибо цена на килобайт хранения запретительна (сейчас десяток центов), или ждём следующего поколения технологий распределённого хранения/репозиториев с автоматизацией клонирования. Но это не светлое настоящее с готовыми продуктами, а туманное будущее: PLM как протокол, по которому создаётся сеть узлов хранения версии продукта и версии проекта (аналог git/mercury и аналог issue tracker), прописаны финансовые механизмы (какие-нибудь токены, меняемые на реальные деньги по текущему курсу). Обсуждение было весьма заинтересованным: в студентах есть люди и из блокчейн-бизнеса, и из PLM-бизнеса, и эти бизнесы немаленьких размеров.
-- ... вот такого у нас на каждом дне тренинга (а это 7 астрономических часов разговоров) обсуждается довольно много, и даже в каждом потоке разные акценты.
ОдО переписано ровно наполовину, 189 вордовых страниц -- и они ушли сегодня в качестве учебного материала текущему двадцать первому потоку тренинга "Системного менеджмента и стратегирования 2021", там ведь первая глава про стратегирование, как раз тема следующего дня тренинга. Содержательных изменений более чем достаточно:
-- "исполнитель проектной/деятельностной/орг роли" -- агент (и там, конечно, тоже возможно деление на части). Общество, сообщество -- не исполнители ролей, и не агенты. Они не могут договориться о целях, это другой системный уровень, там другие дисциплины, не менеджмент. А вот компании вполне могут выступать как агенты, и в них поэтому есть менеджмент. И в компьютере тоже могут появиться агенты.
-- интеллект и мыслительное мастерство (из версии 2021 года) оказались синонимами, ролевое мастерство перестало выделяться как отдельный таксон (хотя над этим можно ещё подумать)
-- вписан новый с иголочки интеллект-стек. Ведущие практики его уровней: понятизация, собранность (mind and body control), онтология, логика, физика, информатика, познание, обучение, методология, праксиология, системное мышление, деятельностные кругозоры (инженерия, включая системную информатику и системное образование, менеджмент, включая инженерию предприятия, предпринимательство).
Вот одна из новых картинок про прикладное мастерство, интеллекта и агента, исполняющего роль:
Следующий (двадцать второй) поток шестидневного тренинга "Системный менеджмент и стратегирование 2021" начинается 19 сентября 2021, https://system-school.ru/sms
Традиция повышений выпускников до директора по развитию прямо по ходу курса СМС продолжилась: можно поздравлять ещё одного студента с прыжком из "инженеров" в главного по развитию своей фирмы (как называется должность -- это совсем другой вопрос. Ну, и власть обычно берут, а не дают). Пятый день обсуждений был посвящён разбору нескольких типовых ситуаций:
-- сначала смотрим на целевую систему, затем на обеспечение. И оно в 10-100 раз сложнее, чем целевая система в части проектирования и изготовления! Производство сложно, но оно находится в тени, о нём редко говорят. Пример разговора на эту тему -- свежее интервью с Elon Musk, https://everydayastronaut.com/starbase-tour-and-interview-with-elon-musk/
-- если фирма занята какими-то мелкими объектами (деревьями), то обычно совокупность этих объектов (лес) никак не осознаётся, никак не называется, поэтому нельзя обсуждать эмерджентные свойства этой совокупности. Если тягач, то флот тягачей, если вагон, то пул вагонов (и слова даже разные), если клиент, то клиентела/клиентура, и т.д.. Это важно, ибо для целевой системы разворачивается её кейс, её жизненный цикл. Если у вас нет клиентелы, а есть только клиент, вы не можете её развивать как целое (скажем, наращивать число клиентов). Если у вас "узлы", то не можете обсуждать "покрытие узлами", ибо оно только у "сети узлов", другой объект.
-- как быстро можно развернуть архитектурное моделирование на productivity tools? Очередной заход через "конспектирование": берём кейс сотрудника, разбираем его по альфам, выделяем подальфы (ручка-бумажка). Затем берём какую-нибудь coda.io (потому как всего много и связность написанного на бумаге уже трудно контролировать) и выделяем состояния подальф и их контрольные вопросы. Дальше связываем с issue tracker в github, чтобы переходы состояний запускали какие-то задачи по продвижению кейса (контроль конфигурации работ). Затраты времени: 4 часа на освоение coda.io, 2 часа на беседы с сотрудиком и моделирование (у сотрудника модель и понимание мета-модели, кодирование мета-модели в coda.io и помнимание мета-мета-модели у нашего студента), 2 часа на колдовство с автомагизацией coda.io и issue tracker в github. Всё, очередное "приложение low code/adaptive case management/actionable_architecture/archictecture-as-a-code" готово, равно как есть обученный работой с этим приложением сотрудник. Можно удивляться успеху и переходить к следующему кейсу. Ждём теперь доклада на эту тему. Что послужило триггером к этой "пробе пера"? После изучения материала курса стали понятны доклады И.Падабеда и Ю.Геронимуса, и была сделана попытка повторить что-то подобное. Новация: был проведён поиск адекватного productivity tool для этой работы среди 15-20 софтов. Победитель конкурса -- coda.io. С архитектурой предприятия в какой-то момент неизбежен вопрос: "а что, так можно было?!". Да. Но только после довольно большого числа часов предобучения трансдисциплинам, разбирательства с мета-мета-моделью и пониманием как устроена вся цепочка до модели.
-- схематизация и рендеринг: программисты, "аналитеги" и т.д. все настроены на обобщение, схематизацию. Найти закономерность, обобщить её, дать сверхобщее имя -- и вуаля, дело сделано. Но схематизация подразумевает и возможность рендеринга: найти в окружающем мире (или разработать и воплотить!) ситуацию, попадающую под весь стек мета-моделирования. Слова там звучат экземпляров и их типов, а не типов из мета-мета-модели. Наш студент говорит на языке прикладного специалиста (рендеринг до описаний экземпляров, до модели!), порождает мета-модель (мышление! прикладные понятия как материал для мышления, мета-мета-модель как схема для её рендеринга в прикладной предметной области). Прикладной спец не говорит на системном и онтологическом языке, он поставляет рассуждения в прикладной области. На системном, онтологическом языке говорит наш выпускник/архитектор предприятия/методолог/мастер мышления. Мета-мета-модель библиотечна (например, из курса ШСМ). Это даёт ответ на вопрос: как работать с сотрудниками, которые не проходили курсов ШСМ, и работать прямо сейчас, а не когда-нибудь потом. Всё работает немедленно, если вы понимаете, что делаете! А "развернуть технологию"? Начальная технология -- ручка-бумажка, а потом можно и до coda.io добраться, через пару дней (а не пару лет!).
-- "дырка" инженерии требований между собственником с его бесконечными идеями и архитекторами в разработке. Иногда на этом месте есть какие-то "аналитики", но чаще таких нет. А если и есть, то они об инженерии требований не знают и просто превращают "идеи собственника в ТЗ для разработчиков", что совсем другое. Что делать? Брать productivity tool (экзокортекс!) и строить инженерию требований (что-то такое и было продемонстрировано в докладе И.Падабеда в той части, где он писал про аналитиков, работающих в coda.io).
-- ещё раз проговорили, "с чего начать": управление конфигурацией (версии продуктов, затем конфигурация работ -- убрать помойку из issue tracker и навести дисциплину его использования). Это убирает rework за счёт конфигурационных коллизий, суммарное время работ становится меньше за счёт качественной инженерии. Затем operation management -- kanban, то есть удавливание мультитаскинга (и стратегирование на каждом ходе: что именно является главнейшей задачей, что на критической цепи! И развитие, и совершенствование должны быть прицельны!). Время работ ещё поджимается за счёт оптимального планирования. Дальше пожары вдруг потухают, люди спокойно сами справляются с операционной работой, и можно заняться стратегированим и резким ростом (штатная работа с архитектурой предприятия через кейс-менеджмент и productivity tools -- запуск новых продуктных линий, переход на новые поколения технологий и другое интересное), или рапортовать, что "в лавке всё спокойно, сотрудники обойдутся без меня, мне скучно, пошёл искать сложные проекты в других местах".
-- в очередной раз обсуждали, что "распределённому PLM" в какой-то момент быть, ибо git окончательно победил всё централизованное в разработке. Варианты "централизованной распределённости" на blockchain не проходят, ибо цена на килобайт хранения запретительна (сейчас десяток центов), или ждём следующего поколения технологий распределённого хранения/репозиториев с автоматизацией клонирования. Но это не светлое настоящее с готовыми продуктами, а туманное будущее: PLM как протокол, по которому создаётся сеть узлов хранения версии продукта и версии проекта (аналог git/mercury и аналог issue tracker), прописаны финансовые механизмы (какие-нибудь токены, меняемые на реальные деньги по текущему курсу). Обсуждение было весьма заинтересованным: в студентах есть люди и из блокчейн-бизнеса, и из PLM-бизнеса, и эти бизнесы немаленьких размеров.
-- ... вот такого у нас на каждом дне тренинга (а это 7 астрономических часов разговоров) обсуждается довольно много, и даже в каждом потоке разные акценты.
ОдО переписано ровно наполовину, 189 вордовых страниц -- и они ушли сегодня в качестве учебного материала текущему двадцать первому потоку тренинга "Системного менеджмента и стратегирования 2021", там ведь первая глава про стратегирование, как раз тема следующего дня тренинга. Содержательных изменений более чем достаточно:
-- "исполнитель проектной/деятельностной/орг роли" -- агент (и там, конечно, тоже возможно деление на части). Общество, сообщество -- не исполнители ролей, и не агенты. Они не могут договориться о целях, это другой системный уровень, там другие дисциплины, не менеджмент. А вот компании вполне могут выступать как агенты, и в них поэтому есть менеджмент. И в компьютере тоже могут появиться агенты.
-- интеллект и мыслительное мастерство (из версии 2021 года) оказались синонимами, ролевое мастерство перестало выделяться как отдельный таксон (хотя над этим можно ещё подумать)
-- вписан новый с иголочки интеллект-стек. Ведущие практики его уровней: понятизация, собранность (mind and body control), онтология, логика, физика, информатика, познание, обучение, методология, праксиология, системное мышление, деятельностные кругозоры (инженерия, включая системную информатику и системное образование, менеджмент, включая инженерию предприятия, предпринимательство).
Вот одна из новых картинок про прикладное мастерство, интеллекта и агента, исполняющего роль:
Следующий (двадцать второй) поток шестидневного тренинга "Системный менеджмент и стратегирование 2021" начинается 19 сентября 2021, https://system-school.ru/sms