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

Важнейшая концепция в DDD это единый язык (ubiqutious language). Идея единого языка состоит в том, что при разработке используется язык, используемый предметными экспертами. Таким образом разработчик погружается в предметную область - ему помимо специфических знаний в разработке необходимо разбираться и в предметной области. Причем этот язык используется вплоть до названий переменных или типов. Через общение с предметными экспертами выявляем язык и далее используем этот язык везде в работе. Единый язык помогает сократить расстояние между разработчиком и предметным экспертом и решает известную проблему испорченного телефона, когда задача несколько раз переформулируется и до разработчика доходит в искаженном виде. Также в книге упомянуты аналитики и проговаривается, что аналитики - если они просто берут информацию от заказчика и передают разработчику - не нужны, у них должна быть некая инженерная функция, т.е. они должны принимать решения по продукту и в таком случае получается, что слово “аналитик” вводит в заблуждение, они являются инженерами.

Если домен/предметная область большая, то в ней есть смысл выделить несколько поддоменов. Вводятся три типа поддоменов: общий (generic), поддерживающий (support), основной (core).

Общие поддомены могут быть сложными, но не является ключевым преимуществом бизнеса, его используют все похожие бизнесы, тут можно использовать некий готовый софт или отдавать реализацию на аутсорс. Поддерживающие поддомены - это некоторая простая функциональность. Суть бизнеса заключена в основных поддоменах - именно здесь сосредоточены инновации и сложность. Основные поддомены обязательно должны разрабатываться In-house. Представьте себе, что компания Google отдала на аутсорс алгоритмы ранжирующие выдачу в поиске? Кстати, сложность и инновации основного поддомена могут быть и не завязаны на разработку, а лежать в других областях. В этом плане DDD конечно хорош, что он в первую очередь глядит не на софт, а на бизнес. А в бизнесе софт может играть совсем второстепенную роль, это нормально, а DDD это подсветит.

Подобное разделение на типы поддоменов позволяет сосредоточить внимание на важном и использовать для соответствующих поддоменов необходимые решения.

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

Есть такой закон Конвея, что создаваемый продукт повторяет структуру организации и обратный маневр Конвея, когда структура организации формируется под нужды создаваемого продукт. DDD и Bounded Context позволяют выявить границы продукта и выстроить продукт и организацию правильным образом.

В книге много советов и тактических приемов как выстраивать взаимодействие между частями продукта. Все крутится вокруг идеи единого языка. Разные части продукта будут работать в разных поддоменах и там будут разные языки. В таком случае важен перевод языка. Тут интересный момент - если мы говорим о разработке в рамках одного поддомена, то смена языка это то, с чем мы боремся - разработчик должен разрабатывать продукт и разговаривать с предметным экспертом на одном и том же языке. В то же время если идет взаимодействие двух частей продукта из разных поддоменов, то у них естественным образом два разных языка и с необходимостью требуется перевод с одного языка на другой. Разные тактические приемы предназначены для того, чтобы обеспечивать перевод таким образом, чтобы влияние частей продукта было минимально. Много говорится о слабой связности (loose coupling) частей продукта и про то как обеспечивать подобную связность.

Рассказано о конкретных практиках, которые можно использовать для разработки в стиле DDD. Некоторые практики предназначены для выявления предметной области, а некоторые - это паттерны разработки. Интересной показалась практика EventStorming, предназначенная как раз для того, чтобы выявить как работает предметная область, захотелось попробовать попрактиковать.

По паттернам разработки тоже много интересного. Мне показалось, что DDD более тяготеет к объектно-ориентированному подходу, особенно если смотреть на объекты в стиле BORO-фреймворка, тогда получается хорошо. Тут конечно много интересного и кажется самое важное - умение бегло работать с базовыми паттернами такими как Value Object, Transaction Script, Active Record.

Понял что Clojure как язык не очень сочетается с подходом DDD. В DDD основа это ubiqutios language. Это означает, что мы должны использовать концепты из предметной области и задавать типы. Clojure динамический, т.е. типы играют небольшую роль и проверка типов происходит только в рантайме. Также Clojure функциональный, что означает что основная работа будет происходить с простыми уже заданными структурами.

DDD хорошо согласуется с микросервисной архитектурой, это вопрос выделения Bounded Context, микросервисы должны проходить по границам поддоменов.

Также приведены паттерны для объединения всех частей в единый продукт.

Что хорошо, DDD не является all-or-nothing подходом. Отдельная глава посвящена приемам, позволяющим начать применять приемы DDD в существующих brownfield проектах. Вообще, мне нравится, что сейчас меньше говорят о legacy проектах, а более о brownfield проектах, т.к. концепция brownfield говорит о живущем проекте, а legacy - о проекте, которую в какой-то момент придется заменить. Кажется, что концепция legacy, устаревшего проекта сама уже чутка устарела - понятно, что проект в момент выпуска уже становится несовременным, это норма жизни сегодня.

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

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

Текст опубликован в личном блоге в телеграме https://t.me/burganov

• итеративная разработка
• обратная связь
• инкрементальная разработка
• эмпирицизм
• опора на эксперименты

Борьба со сложностью

• Модульность
• Связность (cohesion)
• Разделение интересов (separation of concerns)
• Сокрытие деталей реализации (information hiding and abstraction)
• Сцепление (coupling)

Магистральной линией с точки зрения конкретных практик в книге является стимулирование использования TDD и Continous Delivery, использование которых поддерживают указанные выше практики.

Про TDD очень интересно. Оказывается ранее я прям неправильно использовал эту технику. Принципиально важно сначала писать тесты и лишь потом код. Если делать в обратном порядке, то вся сила TDD теряется, а вот если сначала писать - то это получается сначала ход на то, как будет код использоваться https://t.me/burganov/65 и лишь потом на создание кода, это очень важно и именно в этом суть TDD. В будущем буду программировать только так. Получается после прочтения этой книги, я поменяю способ с помощью которого программирую. Интересно к какому эффекту это приведет. А сколько еще знаний у меня нет?!

Про Continuous Delivery тоже очень интересно. Вообще автор написал еще несколько книг, где тема непрерывной поставки разобрана более детальна, но и здесь про это немало сказано. Например, автор предлагает релизится несколько раз в день, оптимальная частота по его словам новый релиз каждый час. Также поясняется разница между trunk based development и feature branching development с объяснением почему именно первый хорош.

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

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

Например, предположим стало понятно, что надо поставить полезную привычку, например такую как ежедневную зарядку. Итеративность говорит нам о том, что надо сразу сделать что-то, некий MVP, который может быть кривой и косой, например, пусть это будет 5 отжиманий в день в случайное время. Потом можно будет сделать это не в случайное время, а по утрам.  Инкрементальность и итеративность немножко разные вещи. Итеративность это об изменении системы в целом, например в один момент может стать понятно, что отжимания не очень эффективны и ты меняешь их на подтягивания и добавляешь 10минутную разминку, а инкрементальность о том, чтобы немного улучшить текущую систему, например добавлять 1 отжимание в месяц или улучшить технику чтобы задействовать в отжимании мышцы таза.

Еще один пример. Например хочется научиться хорошо готовить шашлык. Идея купить мангал за 100500 рублей и попытаться приготовить блюдо уровня шеф-повара Мишленовского ресторана не очень здравая. Лучше делать постепенно, улучшая некоторые аспекты, это более надежный вариант. Это выглядит очевидно, но в жизни сплошь и рядом люди пытаются делать всё и сразу.

Итеративность работает на уровне всей системы, например, метод прогрессивного джипега Артемия Лебедева https://www.artlebedev.ru/kovodstvo/sections/167/ ровно об этом. Инкрементальность работает на уровне деталей. Это два разных принципа, использовать надо оба. И оба они про быструю обратную связь.

Понравился автор, также подписался на его youtube-канал Continuous Delivery https://www.youtube.com/@ContinuousDelivery, хорошие и понятные видосы о том, как устроены разные аспекты программирования.

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

Текст опубликован в личном блоге в телеграме https://t.me/burganov

Посоветовали прочитать книжку BORO - Business Objects: Re-Engineering for Re-Use написанную Chris Partridge. http://borosolutions.net/sites/default/files/Business%20Objects%20-%20Re-Engineering%20for%20Re-Use%20%283rd%20Ed%20-%20early%20draft%20-%2020140927%29.pdf Первая версия книги была написана в 1996 году и в следующих переизданиях принципиальных изменений не было.

Книга задает онтологию физического мира - как разные понятия, с которыми мы сталкиваемся в жизни можно формализовать как объекты физического мира. Вопрос не такой простой, как кажется на первый взгляд. Рассмотрим, например, мой телефон на столе. Понятно, что это объект физического мира. А вот если мы перейдем к понятию “мобильный телефон” вообще,  все становится сложнее. К чему реферирует понятие “мобильный телефон”? К чему реферирует понятие, ну, например, “готовка ужина”? Ответы на эти вопросы в терминах элементов, классов и кортежей есть в книге BORO

В курсах ШСМ https://system-school.ru/ прям существенно используются идеи из этой книги. Ссылки и совет прочитать BORO есть в курсе “Моделирование” и как задание ко второй главе в курсе “Системного мышления” Кроме того, мне посоветовал ее прочитать Анатолий Левенчук в комментариях https://systemsworld.club/t/modelirovanie-rezultaty/4528

Я бы советовал пройти [книжку BORO] ... для работы сразу будет полезно, программистам это важно, но отсутствует в их учебных курсах

Необычный совет, если вдуматься. Что такого может дать подобная книга программистам? Впрочем, я недолго размышлял, а прочитал книгу и вот теперь пишу мысли по поводу.

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

Книга достаточно тяжелая, некоторые детали кажутся ненужными, диаграммы со сложным и непонятным UML раздражают. Вообще основы лучше даны в статье http://www.borosolutions.net/boro-foundation-enterprise-ontology

Но все-же и в самой книге есть уникальный материал, в последних главах классные и важные примеры использования этой онтологии. Эти примеры и понимание связанное с ними можно прям сразу использовать в своих проектах.

Базовые типы

Все объекты онтологии делятся на три базовых типа

• элемент - 4D-физический объект с протяженностью в пространстве-времени
• класс - объединение объектов, возможно бесконечное. Объекты могут быть любого типа
• кортеж из двух объектов. Объекты также могут быть любого типа.

Итого, весь физический мир и часть объектов ментального мира можно представить в этой онтологии. Это означает, что можно понять к чему реферирует то или иное понятие. Например понятие “стул” будет реферировать к классу всех стульев. Т.е. представляем разные физические стулья в пространстве-времени и объединяем эти все эти объекты в класс. Тогда понятие “стул” в точности совпадает с этим классом всех физических стульев

С кортежами еще более интересно. Многие отношения между объектами сводится к кортежу. Например отношение часть-целое. Вот например, есть ноутбук, в нем есть клавиатура. Тогда клавиатура физический объект, ноутбук физический объект, Если мы рассмотрим кортеж “клавиатура”, ”ноутбук” то это пример отношения часть-целое. Все подобные кортежи составят класс кортежей и этот класс совпадает с отношением часть-целое. За счет того, что элементы рассматриваются в 4D, многие отношения типа “Аня смотрит в окно”, также можно декомпозировать в отношение часть-целое и в соответствующие кортежи. В этом конкретном случае “Аня смотрит в окно” - это процесс в виде 4D-объекта, частью которого является “Аня”, другой частью “окно”, еще могут быть неуказанные части такие как “пролетающий голубь за окном”, “подоконник на котором сидит Аня” и другие.

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

Все же важно понимать, что покрывается не весь мир, с некоторыми понятиями довольно трудно работать в этой онтологии. Ну, например, понятие “бог” не очень понятно к чему реферирует, или понятие “злость”, или скажем понятие “обязательства продавца перед третьими лицами”. Есть и более тонкие различия. Понятие “яблоко” в онтологии BORO не будет совпадать с понятием “яблоко” в обычной речи. Почему? Потому что яблоко в BORO реферирует ко классу всех реальных яблок бывших и будущих в разных мирах, но яблоко из райского сада в него не попадает, его в онтологии BORO нет - ну по крайней мере непонятно, как его там выразить - кажется, что типы яблок из магазина и райского яблоко будут отличаться. https://youtu.be/2uWqFQBeqmY?t=108

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

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

Моделирование

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

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

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

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

Когда мы говорим о моделировании, то речь идет о том, что создается модель физического мира для некоторых целей. Пример такой модели - это программное средство созданное инженерами-программистами. Но вообще модели это не обязательно про софт. Любой агент создает модель для действий. Да и агент может быть разный: обезьяна, человек, человек со сложным софтом, организация, страна. Таким образом работает любое моделирование, это не специфично для BORO.

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

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

Уровень понимания и операционный уровень

В книге одна из самых полезных и неожиданных концепций - это разделение на уровень понимания и операционный уровень, understanding vs operational level.

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

Рассмотрим сначала как устроено моделирование на операционном уровне, “обычно”. Для этого смотрятся какие понятия нужны для выполнения задачи и какие действия с этими понятиями необходимо выполнить. Оказывается, можно годами размышлять на операционном уровне об объектах, о действиях над ними, не понимая глубоко, как они устроены и к чему реферируют. Причем может казаться, что понимание глубокое, но это иллюзия. Уровень понимания не затрагивается на операционном уровне, чтобы понять устройство объектов, надо специальным образом размышлять о том, как они устроены. Таково странное свойство человеческого разума, это и плюс и минус - очень легко можно размышлять о странных вещах, которые непонятно, что означает. В повседневной жизни это не страшно, потому что к каждому понятию прилагаются какие-то действия, которые можно с этим объектом производить.

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

Другой пример, понятие “дрель”, и различные действия доступные с ним “сверлить”, “положить на полку”.

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

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

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

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

Это принципиальное устройство прописывается в терминах типов: элементов, классов и кортежей.

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

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

Упрощение сложного

Обычно разработка устроена так, что чем более сложная тема, тем более сложно устроена разработка. Есть некие задачи, в соответствии с этими задачами выделяются понятия, потом для этих понятий смотрится какие можно делать действия. Понятия и действия выделяются в соответствии с пониманием системы. С усложнением системы примерно линейно растет и сложность. Вообще сложность растет даже быстрее, т.к. сложные вещи взаимодействуют между собой. Тем не менее, обычно находятся какие-то паттерны, помогающие справиться со сложностью.

Онтология BORO утверждает удивительную штуку - если моделировать, имея ввиду реальный мир, то сложные вещи становятся простыми. Любая новая сложная вещь означает, что появилось некоторое понимание о том как устроен мир. Это понимание выражается в классах, кортежах, элементах. Причем этот процесс отнюдь не бесконечный. Если что-то было разделено в реальном мире на классы, элементы, кортежи - это уже “навсегда”. Никакие действия с этими объектами на разделение не влияют. Разделение может поменяться только если была допущена ошибка, что в общем-то редко происходит. Таким образом при добавлении новой функциональности, в том числе очень сложной, софт не усложняется в разы и даже наоборот, он может упроститься, т.к. добавление новой функциональности подсвечивает более сложную структуру реальности. А чем ближе к реальности построенная модель, тем лучше понимание, тем более точно можно отразить в модели то, что происходит в реальном мире. Таким образом мы моделируем в соответствии с пониманием реальности, какие есть в нем объекты, как эти объекты устроены, какого они типа и только потом думаем как в этих объектах выглядят задачи, которые необходимо решить.

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

В книге несколько примеров приведено: с географическими областями и с названиями. С географическими областями получается прикольно, что там много отношений часть-целое. Итого такие сущности как “Англия” или “Москва, ул. Володарского” или “СССР” оказываются одного типа. Тут важно, что все эти географические области рассматриваются как 4D-объекты. Еще ключевой момент - что 4D объекты могут быть вложены друг в друга. Вообще, по линии BORO очень много отношений оказываются вложением друг в друга, причем многоуровневыми.

С названиями еще более интересно. Для информационной системы логично иметь множество сущностей типа “Название”. В какой-нибудь базе данных может быть сотни столбцов в разных таблицах типа “Название”. Предлагаемая концептуализация без потери гибкости позволяет все названия вынести в одну табличку. Важно, что это не просто решение типа “давайте вынесем все названия в одну табличку”, а вполне объясняется почему это можно сделать с упрощением модели мира, оказывается “название” тоже реферирует к определенному реальному классу. Тут замечу, что конечно нет смысла условно менять базу и убирать все столбцы с “Названиями”, не затрагивая остальных табличек. Более того, названия можно оставить и напоследок, самые интересные и важные эффекты проявляются при работе с объектами близкими к предметной области.

Также интересно смотреть на события. События рассматриваются как мгновенный 3D-срез в 4D-объекте.

Переход от уровня понимания к операционному

На операционном уровне, если смотреть на систему как 4D-объект есть свои специфические проблемы. Они немного другие, нежели при классическом моделировании, когда происходят размышления сразу на операционном уровне без уровня понимания.

Любая система рассматривается как 4D-объект. Но в разработке существенным образом задействуется понятие текущего момента. Например, в CRM системе нас может интересовать какие есть клиенты вот сегодня. Это не вся клиентура во всей ее 4D-полноте, а вот прям срез в текущий момент времени.

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

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

Софт как-то реагирует на входящую информацию, софт также может инициировать действия

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

В то же время исходящая информация - сигнал к действию, к изменению реального мира. Софт инициирует изменения в реальном мире и ожидает ответа от реального мира.

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

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

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

Общее впечатление

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

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

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

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

Но если продраться через все это, материал полезный. Я прям поймал ощущение, когда оказалось, что моя разработка привязана к физическому миру, а не просто существует в компьютерах. Это круто, дает почву под ногами. Хотя, наверное, возможен и другой вариант, когда наоборот становится понятно, что почвы нет и разрабатываемый софт не нужен. Ну тоже хорошо, чем раньше это станет ясно тем лучше.

Использование материала

Мне непосредственно удалось применить материал книги к специфики трейдинга.

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

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

Планирую написать про это статью, есть очень интересные моменты.

Текст опубликован в личном блоге в телеграме https://t.me/burganov

Неспешно ищу работу, прошел несколько собеседований. Текущие проекты не взлетают и пора уже всерьез рассмотреть вариант трудоустройства.

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

Вся эта история кормила меня на протяжении лет, но на данный момент, кажется, она себя исчерпала.

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

В общем, оказалось, что после 20 лет программирования у меня не прям чтобы сильно большой и интересный опыт.

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

Вот с этими вводными я начал поиск работы. Сделал резюме, разместил на hh.ru. Получил какое-то количество откликов, в процессе корректировал резюме и то, на что я претендую. В частности, примерно понял о какой сумме может идти речь.

Претендовал на позицию Senior Developer. Дошел до собеседований в 3 компаниях, но итого не получил ни одного оффера. Пока прекратил активный поиск работы, требуется осмыслить полученную информацию, немного прицелиться и идти дальше.

Собеседования

Те собеседования которые у меня были: два в крупные банки, одно в стартап, разрабатывающий приложение.

Совсем разные компании, но все вместе дало некое общее понимание как устроен рынок найма вот прям сегодня в июле 2023го в России.

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

В разных собеседованиях тестировались разные моменты

• Знание языка. Я не подготавливался к собеседованием, а на Java особо не программирую, основной язык все-таки Clojure. Но руки быстро вспомнили, т.к. в свое время очень много писал на Java, ездил на профильные конференции, даже читал спеку JLS. С каждым собеседованием показываемое мною знание языка улучшалось.
• Ревью кода. Тут получилось довольно смешно. В двух разных собеседованиях дали одну и те же задачку на ревью кода. Похоже это какая-то стандартная задача из запроса в гугле “как собеседовать Java-программиста”. Соответственно второй раз уже было совсем понятно, что отвечать.
• работа с алгоритмами. В двух собеседованиях просили решить две разные задачки на алгоритмы. Справился, более того, кажется, впечатлил интервьюеров своим подходом к решению.
• работа с микросервисами. Не знаком с микросервисами, были вопросы по ним. Понял, что если я претендую на позицию Java-сеньора без знания принципов работы с микросервисами никак, а вообще лучше бы какой-то опыт получить. Помимо указанных трех собеседований еще одно собеседование в банк остановилось на вопросе об опыте работы с микросервисами. В общем, микросервисы - это прям совсем мейнстрим сегодня. Начал читать книжку Sam Newman “Building Microservices”, скучновато, но читаю.
• работа со Spring, базами, другое. Много вопросов специфически энтерпрайзных. Тут сразу говорил, что опыта нет.

Режим работы

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

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

Удаленный режим

• Преимущества: нет необходимости тратить время на дорогу, можно работать в своем ритме, успевая что-то делать дома. Можно работать по всему миру, не привязываясь к офису в Казани
• Недостатки: нет случайного общения, все общение регламентировано, соответственно меньше возможностей проявить себя, возможности карьерного роста ограничены.

Стационарный режим

• Преимущества: единство времени и пространства для работы, ничего не будет отвлекать, можно проявить себя через общение, в том числе неформальное, с коллегами.
• Недостатки: потеря времени на дорогу, меньше времени общаешься с семьей. Работа только по месту жительства, в моем случае Казань, город большой, но все равно 1.3 млн человек в 6000 раз меньше 7.8 миллиардов

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

• работа в офисе в Казани с возможностью удаленки.
• работа на компанию с офисом в Москве или международную компанию с командировками на 1-2 недели

Такие варианты совмещают плюсы удаленного и стационарного режима работы, нивелируя минусы.

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

Резюме и позиция

Я изначально претендовал на позицию Java-программиста, т.к. Clojure-программист редкий зверь в плане вакансий.

Понял что многое зависит от резюме. Я написал какое-то резюме, потом увидел что прямо на hh.ru есть возможность за отдельную плату улучшить резюме, вплоть до того, что карьерные консультанты пишут резюме за тебя. Итого, взял самый дешевый тариф и мне дали рекомендации по улучшению резюме. Рекомендации полезные, но теперь надо переписать резюме в соответствии с ними. Можно заказать, чтобы составили резюме полностью, но пока считаю, что лучше мне сформулировать резюме самостоятельно.

Очень важно четко понимать, на что ты претендуешь. Позиции Senior Developer и Team Lead по факту совершенно различные. Вообще, вижу для себя следующие варианты

• Senior Developer - работа программистом
• Team Lead - руководство командой программистов
• Product Owner - акцент на разработку продукта

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

Еще важно все-таки понимать, что рекрутер хочет. Не стоит рассказывать об опыте не релевантным позиции. Например, у меня много опыта на Clojure, много опыта разных экспериментов с продуктом. К сожалению, в позиции Java-программиста, пусть даже сеньора, этот опыт в основном мимо. Тут надо или искать позицию, которая будет утилизировать указанный опыт или просто не рассказывать о нем, т.к. с точки зрения рекрутера оказывается, что кандидат overqualified в ненужную сторону. Учту на будущее, буду специально иметь ввиду, что требуется рекрутеру.

Также возможно стоит все же искать позицию, где мои знания раскроются максимальным способом. Например, найти позицию Product Owner в международной Clojure-команде занимающейся созданием продукта для трейдеров в крипте.

Знания и опыт

Все эти собеседования подсветили серьезный недостаток знаний и опыта. По поводу знаний, тут у меня конечно в первую очередь задача пройти по траектории ШСМ, “Собранность”  https://teletype.in/@burganov/sobr и “Моделирование” https://teletype.in/@burganov/model пройдены, следующий на очереди курс “Системное мышление”.

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

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

Есть еще интересные мысли, про онтологию BORO, за последнее время получилось довольно интересно отмоделировать трейдинг, получилось интересно, буду писать большую статью на эту тему. Подобная статья помимо всего прочего может оказаться плюсом для трудоустройства в компанию работающую в соответствующей предметной области.

Подготовка к собеседованию

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

• понять на какую роль претендуешь
• понять что рекрутер будет проверять для этой роли
• подготовиться к соответствующим вопросам. Можно поискать эти вопросы в интернете или спросить у gpt-4. Можно воспользоваться услугами карьерных консультантов.

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

Выводы и действия

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

• Выбрать интересную подходящую для себя позицию. Т.к. интересна менеджерская позиция, с максимально возможным влиянием на продукт, то речь будет идти о Product Owner. Остальные позиции менее интересны, хотя тоже возможны.
• Набрать знаний
• Пройти “Системное мышление” и другие курсы по линии ШСМ. Это поможет в любом случае.
• Определить какие знания требуются для интересной мне позиции, составить список вопросов и дисциплин для изучения, изучить их.
• Подкачать английский язык, чтобы была возможность пройти собеседование в международную компанию.
• Сделать соответствующее резюме в соответствии с рекомендациями и начать искать соответствующую работу. Составить резюме на английском и искать работу на международном рынке.
• Устроиться на работу, получать зарплату, решать рабочие задачи, продвигаться в карьере и получать опыт. То, от чего я благополучно увертывался последние 17 лет. Волнительно, но почему бы и нет.
• Также до устройства на работу возможно стоит рассмотреть какие-то проекты во фрилансе, чтобы получить релевантный опыт, ну и возможность заработка конечно.

Контакты

Текст опубликован в личном блоге https://t.me/burganov

Прошел курс “Моделирование” от Школы Системного менеджмента [1]. Рассказано о впечатлениях,  полученных результатах и дальнейших планах.

Третий заход на прохождение курса оказался успешным. Изучены используемые школой мета-мета-мета-модель и частично мета-мета-модель. Созданы онтологии трех предметных областей. Дальше - курс “Системное мышление”.

Почему и как проходил курс.

Это второй текст в серии текстов про прохождение курсов от ШСМ. Курсы рекомендуется проходить в определенной последовательности, именно в этой последовательности я их и прохожу в режиме self-paced. До этого был пройден курс “Собранность” и написан соответствующий текст [2], а теперь пришло время курса “Моделирование”. Курсы в ШСМ меняются быстро и на текущий момент “Моделирование” ушло в архив, а его материалы переместились в “Моделирование и собранность”, впрочем содержание не поменялось.

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

В курсе 7 глав, общая оценка времени на прохождение была 56 часов:

• 1 час создание необходимого для обучения поддерживающего экзокортекса.
• 35 часов на изучение материала и выполнение домашних заданий - каждая глава по 2 часа изучение и 3 часа домашка
• 12 часов моделирование рабочей предметной области
• 8 часов написание этого обзора

Итоговое время прохождения - 44 часа, из которых 9.5 часов моделирование рабочей предметной области. Прошел курс существенно быстрее ожидаемого - во многих местах переоценил требуемое время на прохождение и помогло то, что материал знакомый.

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

В начале, также как и в случае с “Собранностью” на курс тратился 1 час в день, но ближе к концу стало раздражать постоянное переключение между обучением и рабочими задачами, тогда подвинул рабочие задачи, благо деятельность позволяет это сделать и занимался только курсом.

О чем курс

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

Задания курса

Курс был знаком, поэтому новых материалов я не увидел, основная ценность как и в случае “Собранности” была получена при выполнении заданий. Часть заданий было легко выполнить, часть сложно, опишу все по главам.

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

Глава 1

Базовые шаги для разметки предметной области. Была выбрана предметная область, определены роли, выделены объекты. Сложностей никаких не возникло, но был создан довольно большой текст для предметной области.

Глава 2

Рассортировать различные концепты онтологии по плотности концептуального пространства. Тут  также не возникло никаких сложностей.

Глава 3

Типизация. Нужно было всем сущностям присвоить типы: физический объект, класс, кортеж.  Тут получилось интересно и до конца не разобрался, даже к концу курса. Сложности возникли прям с базовыми вещами.

В курсе используется такое понятие как “отношение”, но не до конца проясняется, что это такое. В итоге, я примерно понял как все это устроено, но по-хорошему надо бы прочитать Криса Партриджа про 4D-экстенсиональную онтологию BORO. Курс использует эту онтологию, но не сильно в нее  углубляется, из-за этого лично у меня возникли проблемы и даже простое выражение типа “Ленар - программист” не получилось до конца разбить по типам. Так-то вроде разбил, но определенные сомнения осталось. Хочется, конечно, разобраться более детально, со временем изучу BORO, тем более теперь понятно, для чего это нужно.

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

Глава 4

Тут два задания.

Первое задание была выделить описания в выбранной предметной области. Тут инсайтов особо не было, просто выделял описания. Кстати, модель это тоже описание. Не всякое описание модель, но любая модель это описание, выстроенное по определенным правилам.

Второе задание написать эссе про понимание языков и метаязыков. Сделал. [3]

Глава 5.

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

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

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

Понимание о том, что есть мета-мета-модель мотивирует изучать системный подход дальше. Понимание того, что есть мета-мета-мета-модель мотивирует читать про BORO и возможно другие Foundational онтологии.

Глава 6.

Задание на отслеживание онтологического дребезга, чтобы откалибровать его. Тут довольно странный опыт.

Завел табличку в coda, идентичную представленной в курсе.

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

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

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

Глава 7

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

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

Вторая предметная область была моя непосредственная рабочая деятельность. Интересно подсветились определенные проблемы. Я, как программист, больше отслеживал реализацию, а вот с некоторыми другим аспектами оказалось, что они отслеживались недостаточно глубоко. Были отмоделированы эти аспекты, сделана соответствующая ситуационная мета-модель. После заполнения моделей в соответствии с мета-моделью стало понятно, что требуется внести в реализацию определенные коррективы. Также после подсвечивания мета-У-модели стало ясно что есть много незнакомой литературы, которую можно поизучать. Создание онтологии тут заняло 9.5 часов чистого времени. Времени не жалел, важно для работы.

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

Критика

По содержанию курса критики особо нет, но есть критика по форме.

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

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

Это ключевая информация сжато полностью описывающая курс. Предполагается, что те, кто проходил курс должны прочесть это предложение и понять каждое слово, ну а можно прочесть и не понять, что тогда?

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

По моделированию: явно недостаток примеров по тому, как может быть устроено моделирование. В клубе ШСМ какие-то примеры есть от студентов, но их тоже маловато. (в скобках замечу, как вы можете заметить этот текст тоже не дает примеры, я рассказываю о том что делал домашние задания, но не привожу примеры как я их делал)

Ну и все-таки одна содержательная вещь: с дребезгом у меня сложности, не понимаю почему они возникают и как с ними справляться. Нужно больше практик по работе с дребезгом.

Дальнейшие действия

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

Курс “Системное мышление” планирую проходить сразу полностью не растягивая на месяцы с одновременным применением материалов курса к реальному проекту. Т.е. без мультитаскинга. Прохождение начну через несколько недель, сейчас на повестке дня рабочие задачи, которые были временно отодвинуты.

Ссылки

[1] Школа Системного менеджмента https://system-school.ru/

[2] Курс “Собранность” от ШСМ - результаты https://t.me/burganov/40

[3] Языки и мета-языки https://t.me/burganov/44

[4] Личный блог. https://t.me/burganov

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

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

Иногда мета-язык специально создают, чтобы неспециалист понял описание, созданное на языке специалиста.

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

Мета-язык служит для того, чтобы получить понимание о языке семантического сообщества. Здесь важно сказать пару слов почему вообще у семантических сообществ формируется свой язык. Дело в том, что профессионалы каждый день сталкиваются с концептами, которые для “обычных” людей являются редкими.

Приведу личный пример. Недавно мне надо было поменять трубу в банной печи, для этого посмотрел видос на 15 минут, рассказывающей как монтируется печь. Были упомянуты такие термины как “колосник”, “каменка”, “пламягаситель”, “пазогребневая система сборки” и другие. Специально выписывал, было упомянуто 57 профессиональных терминов! Это нормально, профи в предметной области ежедневно сталкиваются со многими связанными концептами и им необходимо иметь мелкую концептуальную сетку, позволяющую быстро и точно выразить любую задачу, цель или мысль в области интересов. Поэтому в каждой предметной области свой “птичий” язык, освоение которого происходит или исподволь во время практики или осознанно во время обучения. Примером может являться любая профессиональная область: программирование, системный подход, профессиональная математика, интернет-маркетинг, дайвинг и все что угодно.

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

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

Могут быть более сложные цепочки. Например, представим, что есть некоторый эзотерический язык программирования XYZ с необычными концепциями. Семантическое сообщество программистов этого языка довольно мало. Статьи, объясняющие устройство этого языка для других программистов пишутся на мета-языке. Таким образом с помощью мета-языка, объясняющего как устроено программирование на языке XYZ, можно расширить семантическое сообщество пользователей XYZ до всех программистов, которые прочтут описание этого языка. В то же время это описание все еще будет непонятно для обычных людей, не программистов. Для того чтобы обычный человек понял язык на котором общаются программисты, чтобы потом понять XYZ, необходимо изучить как устроены концепты, которые используют программисты в своей работе.

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

Текст опубликован в личном блоге в телеграме https://t.me/burganov

В тексте рассказан личный опыт прохождения курса “Собранность” от Школы системного менеджмента [1]. Отражены впечатления, полученные результаты и дальнейшие планы, но не содержание курса. Используются специфические термины из курса, поэтому что-то может быть непонятным тем, кто не знаком с курсом и материалами школы. Если хочется понять, какую информацию дает курс, лучше обратиться к соответствующей странице на сайте школы.

Почему “Собранность”?

У меня давняя история взаимоотношений с ШСМ. Читаю Левенчука [2] давно, а первый раз был на обучении аж в 2016 году. Тем не менее, до сих пор не интегрировал в себя системный подход, что означает, что у меня проблемы с практическим внедрением материалов. Но есть и плюсы - материалы школы много раз были просмотрены в том или ином виде, а это тоже важно.

В этот раз решил начать с курса “Собранности” [3]. Начал не с Онтологики, а с Собранности, т.к. Онтологику уже проходил какое-то время назад. Впрочем “Собранность” тоже была прочитана, но текущий подход должен был стать серьезным и с выполнением заданий. План был такой: инвестировать в обучение 1 час каждый день и проходить главу за 1 неделю. Таким образом чистое время прохождения должно было составить 70 часов, а календарное время 10 недель

Начал курс 13 февраля с соответствующим планом завершения 23 апреля.

Сегодня 12 мая и этот пост мой последний материал в рамках курса “Собранности”. Я затратил 75 часов чистого времени на прохождение курса плюс отдельно занимался моделированием личных проблем с вниманием 10 часов . План был такой: инвестировать в обучение 1 час каждый день и проходить главу за 1 неделю.

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

Прохождение курса

Есть огромная разница между чтением курса и прохождением. За пару месяцев до текущего захода на обучение курс был прочитан и довольно внимательно. Интересно, что сразу после прочтения курса был какой-то эффект, но через недельку он куда-то исчез. А вот выполнение заданий позволило выйти на совершенно другой уровень. Но времени это заняло намного больше. Вообще есть три уровня работы с курсом: просто прочесть текст, прочесть текст и пройти задания, пройти курс с преподом. Авторы предупреждают, что самый лучший эффект дает именно прохождение курса с преподом, а self-paced прохождение может быть сложным. Просто чтение оно неэффективно и вообще говоря не является обучением. Я настроился на self-paced прохождение, хочется надеяться что оно было эффективно, но я был предварительно хорошо погружен в среду, прошел пропитку, если выражаться терминами курса. Сразу был выделен минимум 1 час в день на работу с материалами курса. Это был важный момент, который сильно помогал в начале.

Уже позже стало понятно, что есть хитрый момент в работе с курсами от ШСМ, что можно тратить на них и рабочее время, если занимаешься рабочими задачами. Об этом много говорилось в одном из видео Лаборатории собранности [4]

В сторону, видео Лаборатории собранности это прям классная пропитка, я их прослушал, наверное, все. Слушаю обычно в машине, когда куда-то еду один. Прям интересно слушать как проходят обсуждения в онтологии системного подхода.

Курс ставит собранность, это что-то вроде GTD согласованное с системным подходом

После курса стали понятны масштабы бедствия.

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

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

Благодаря курсу потихоньку это стало меняться. Такой вот переход от неосознанной некомпетентности к осознанной некомпетентности в плане умения работать. Сейчас ставлю себе цель добиться в среднем 25 часов в неделю deliberate practice к началу осени. Цель для меня достаточно амбициозная, хотя объективно скромная. Вообще, курс здорово поставил меня на место, оказалось что у меня в некоторых областях эффект Даннинга-Крюгера в полный рост. Не то что меня это как-то расстраивает, абсолютно понятно что и как делать дальше. Впереди много интересного.

Мой экзокортекс.

До курса мой экзокортекс: использую Todoist, coda, пишу дневник и иногда в соцсети

После курса: использую Todoist, Focus To Do, coda, пишу дневник и иногда в соцсети

Примерно те же самые инструменты, но использование прежних инструментов улучшилось, появились дополнительные.

Если детально:

• Todoist для GTD
• Focus To Do для отслеживания помидорок
• Coda для записей и моделирования
• Периодические записи в дневник в Coda
• Публичные соцсети

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

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

Интересный момент, что в GTD у меня в основном лежат маленькие задачи, которые важно не забыть. Всегда рядом были крупнейшие задачи, которые занимали львиную долю времени, но в GTD они отражались большими кусками, т.к. это просто “работа”. Получалась диспропорция - в GTD есть задачи, которые выполняются просто звонком за 10 минут в нужное время и те, которые нужно выполнять 5 рабочих дней. Сейчас ситуация немного выровнялась - большие задачи расположились в отдельные таблички в coda,  а в Todoist все тоже что и прежде.

Про дневник скажу отдельно. До курса у меня была практика ежедневного ведения дневника, продолжил эту практику, все также веду дневник, считаю очень полезным. Разница в том, что теперь дневник веду прям каждый день, не прерываясь. Также совмещаю GTD и дневник, делаю в одно и то же время вечером ежедневный разбор задач в GTD и ежедневную запись в дневник. Также делаю еженедельную запись в дневник по аналогии с еженедельным обзором GTD. Причем перед тем как написать еженедельную запись читаю все записи за предыдущие дни. Полезно.

Думскроллинг

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

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

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

Задания курса

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

• глава 1 - создание понятийной базы. Одно из неоднозначных заданий для меня. С одной стороны, оно очень полезное - заполнение понятийной базы по материалу курса позволило хорошо понять материал. С другой стороны, довольно скучно! Вообще, пока что продолжаю создавать понятийные базы при изучении нового материала, т.к. явно понимание улучшается, а как сделать так, чтобы времени тратилось меньше с тем же эффектом по пониманию пока не ясно.
• глава 2, глава 3 - создание и доработка таблицы неудовлетворенности - целевые системы - системы создания. Полезное задание, позволяющее взглянуть на всю свою деятельность с высоту птичьего полета и после - отказаться от ненужного. Хитрость в том, что полезность прямо пропорциональная потраченным усилиям. Мне потребовалось несколько часов, прежде чем польза стала ясна. В начале как-то странно смотреть на деятельность с такой точки зрения. Тут leap of faith стоимостью в несколько часов - стоит поверить, что создатели курса знают, что делают.
• глава 3 - задания на моделирование. Тут интересный момент. С одной стороны, для меня получилось очень полезно, т.к. я взял модель про коммуникации из ранее прочитанного  курса “Онтологики” и начал ее применять постоянно и таким образом решил постоянно возникающую важную и сложную свою проблему. С другой стороны, я даже пройдя курс так и не очень понял, что такое операционная модель и, соответственно, как ее составлять. Соответственно, составляю ее как придется. Ничего страшного, даже логично! Содержание моделирования в рамках системного подхода это следующие курсы
• глава 4 - отказ от мультитаскинга. Отказ от мультитаскинга - т.е. выполнение в момент времени одной работы. Это работает на разных временных масштабах.  Важная практика, т.к. на переключение контекста тратится много времени и ресурса. Пререквизит для практики вывод работ в осознании. Тут интересный момент, что мелкие работы у меня и так были хорошо видны благодаря GTD в Todoist, а вот крупные работы были видны хуже. Для них был создан отдельный экзокортекс в coda, это оказалось удобнее чем использование Todoist. После этого все получилось на масштабе крупных работ. Интересный эффект, что как-то автоматически после этого стал более собран при выполнении работ и на малых временных масштабах. Сейчас легко получается взять необходимую нудную работу на 10-15 минут и доделать ее до конца, чтобы потом к ней не возвращаться, раньше бывало для этого требовалось прилагать усилия. К концу курса пришло понимание, что отказаться от мультитаскинга можно и в плане учебы. Таким образом то самое решение в начале курса, что минимум 1 час в день уделяется обучению ШСМ может оказаться не обязательным костылем. Но тут надо быть осторожным.
• глава 5 - “Ежедневные вопросы”. Это вопросы, благодаря которым периодически наводится внимание на какие-то важные аспекты жизни. Практика хорошо вписалась в GTD и дневниковые записи. Особенно еженедельные вопросы, хорошо писать дневниковую запись, имея предварительно продуманный список вопросов.
• глава 6 - проблемы с наведением и удержанием внимания. Это очень интересное задание, которое я по-настоящему понял и смог сделать лишь под конец курса, уделив ему много времени. Это моя большая проблема, особенно удержание внимания, поэтому специально посвятил ему кучу времени. В общих чертах, получилось следующее: собранность - это мастерство в наведении внимания, удержании внимания и контролем за вниманием. Мастерство ставится на каждом временном масштабе: момент, фокус, день, спринт, привычка, самореализация, жизнь. Для постановки мастерства необходимо отслеживать возникающие проблемы и решать каждую проблему отдельно. Интересно, что проблемы обычно все перемешаны, поэтому их сложно заметить. Разделение по временным масштабам и запись каждой проблемы позволила выделить разные проблемы и выделить повторяющиеся. На данный момент часть проблем удалось решить, часть удалось заметить и начать решать, часть удалось начать замечать. Наверняка что-то важное еще остается вне осознания. Вообще, проблемы с вниманием уровня привычки быстро не решаются, это требует изменения поведения, что может занять несколько месяцев. Но это сдвинулось и это очень сильно воодушевляет, так как итог решенных проблем с вниманием - более собранная личность.
• глава 7 - расчет мощности. Деятельность человека можно условно разделить на техобслуживание, работу и отдых. Наводится внимание на то, сколько и какой деятельностью занимается конкретный человек в разрезе дня. Полезно для понимания сколько времени и на что уходит, что можно успеть, а что нельзя, от чего лучше отказаться. С помощью этого задания хорошо прояснилось, что существенная часть жизни вне осознания. Обычно много думается про рабочие задачи, но хитрость в том, что невозможно хорошо заниматься работой, если не ставишь в осознание отдых и обычную текучку. Отсюда вырастают разные способы прокрастинации, когда вместо восполнения ресурса занимаешься паразитной деятельностью, которая ни уму, ни сердцу.
• глава 8 - автоматизация деятельности и замедление во время отдыха. Что касается автоматизации,  в свою деятельность добавить ее не сумел, а вот замедление отдыха помогло, хотя книжку, которую советуют в курсе, еще так и не прочитал. Тут больше помогла мысль о том, что в роли отдыхающего нужно наводить внимание на отдых и периодическое отслеживание, что во время отдыха, надо и в мыслях быть в отдыхе, а не на работе. Также упомяну недавнюю статью Церена Церенова про профессионального отдыхающего [5]. Очень понравилось. По отдыху также далее отдельно буду думать, как его обустроить. Удивительное дело - более качественная организация отдыха быстро окупается возросшей производительностью в рабочей деятельности.
• глава 9 - выделение MOVE. Это работы связанные с системами. Тут тоже было сложно, опять непривычный взгляд на деятельность, как-то с трудом выделил эти MOVE. Благодаря этому заданию крупные работы стали еще лучше видны и даже стали как-то оцениваться по времени. Это все продолжение истории, что крупные работы были на периферии, а на первом плане малые работы из GTD.
• глава 10 - расчет Work In Progress и т.д. С этим заданием ничего не делал. Наверное оно особенно полезное для команд, но мне нужно было ставить собранность только для себя, а для одного человека внедрение этих метрик требовало много усилий с непонятными перспективами

Критика

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

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

К концу курса стала раздражать фраза “Безошибочность в отличии от бесперебойности не является функцией сознания”. Вроде раз 5 она используется. Если это такой важный концепт, то может лучше переформулировать эту сложную фразу разными другими способами? Лично мне концепт не показался сильно важным, возможно потому что у меня нет особой тяги к перфекционизму.

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

Дальнейшие действия

Итоги курса такие.

Мне понравились результаты, еще раз убедился в необходимости планомерного прохождения всей траектории усиления интеллекта от ШСМ. Продолжаю обучение по предложенной линии в том порядке, которую предлагают создатели. Следующий курс это Моделирование, которое раньше называлась Онтологикой. Этот курс я уже проходил, но проходил давно и кажется не так качественно, как можно было бы. Надеюсь что он займет не очень много времени и далее самое главное - системный подход как он есть в четырех курсах. После “второй год обучения”, но пока рано загадывать не буду, указанных 5 курсов хватит минимум до конца 2023 при лайтовом режиме прохождения. Под лайтовым подразумеваю час в день, включая выходные. Понятно, что можно и ускоряться, но это будет за счет какой-то другой оперативной текучки. Буду решать по ходу дела. Доброй охоты мне.

Ссылки.

[1] Школа системного менеджмента https://system-school.ru/

[2] Анатолий Левенчук, Лабораторный журнал https://t.me/ailev_blog

[3] Курс “Собранность” https://aisystant.system-school.ru/lk/#/course/sobr/

[4] Плейлист с видео “Лаборатории собранности”https://www.youtube.com/playlist?list=PLhPRVGfg1aeM2BmvSPpThM7V6kX1g5Boa

[5] “Профессиональный отдыхающий” https://blog.system-school.ru/2023/04/20/professionalnyj-otdyhayushhij/

[6] Личный блог https://t.me/burganov