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

Интересно, что в опросе в канале ЛАФа 61% ответов — "пущено на самотек". Видимо, разная аудитория у нас всё же.

А можете чуть подробнее рассказать — что ваша компания делает? Есть инструменты с ИИ, типа Cursor или Copilot? Какие KPI введены? Что требуют от сотрудников? Как проверяют владение инструментами ИИ на собеседованиях? Как обеспечивают безопасность?

Как изменилась ваша работа, как аналитика, с этими нововведениями? Напишите в комментах, ужасно интересно!

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

Вообще, можно найти довольно много статей под заголовком "Null considered harmful", Гугл сходу выдает штук 10. Страниц выдачи.

Сам Чарльз Энтони Ричард Хоар, изобретатель null reference, говорит, что это его "ошибка на миллиард долларов". Говорит, невозможно было удержаться, но "this has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years".

В чем проблема с Null? Основная проблема в том, что это семантическая черная дыра. Что конкретно означает Null каждый раз, когда он появляется, непонятно. То ли это ошибка, то ли это пропущенное значение (например, при объединении двух таблиц), то ли пустое значение, то ли элемента нет в списке, то ли есть элемент с пустым значением, и т.д.

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

Это приводит к защитному стилю программирования — каждый раз нам нужно проверять значение на Null. В некоторых языках ещё и на пустое значение, потому что они разные. Получаются конструкции типа string.IsNullOrEmpty(str). Пустое или Null. Бинарная логика становится тернарной: True, False и Null. Или даже 4-арной (я не знаю, как это читается): True, False, Null и Empty (Undefined).

Во многих случаях нам нужно это различать: аватар пользователя Null потому, что мы не можем его прямо сейчас извлечь из хранилища/кэша, или пользователь его не установил (Empty) и нужно показать дефолтный?

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

В XML никаких Null'ов нет, зато есть вариант с пустым тегом (<avatar/>) или просто исключение тега, когда его нет в документе. Что какая семантика означает — решать вам! Будет пустой тег пустой строкой или Null'ом? Когда как. Я видел дичь, когда <string></string> дает пустую строку, а <string/> — Empty.

Впрочем, у пустого тега можно ещё поставить атрибут xsi:nil="true", но некоторые парсеры на этом ломаются.

В JSON всё ещё хуже: есть отдельное значение null, и получается 6 вариантов: null, "", 0, [], {}, пропущенное значение. Все они разные и не равны друг другу.

Зато в Protobuf вообще нет Null! Вот я понимаю — концептуальная целостность! Выкручивайтесь как хотите. Зато там есть значения по умолчанию для типов (0, "", false), и механизм для явного указания пропущенных полей. Помним, что protobuf бинарный и стремится к уменьшению размера сообщения, а для передачи null нужно было бы накручивать дополнительную семантику. А вот в Avro есть отдельный тип null, который ни с каким другим типом не совместим, так что нужно его в схеме явно указывать: это поле может иметь два типа — int и null.

Зато в GraphQL Null'ы резвятся вовсю: все типы по умолчанию nullable, и нужно специально указывать, если вы хотите это отключить. Null в GraphQL — в первую очередь признак ошибки (значение этого поля по какой-то причине не удалось предоставить). Потому что GraphQL пытается отправить хоть какую-то информацию, пусть даже неполную. Это же позволяет гибко управлять доступом (вернем null в тех полях, которые недоступны этому клиенту) и допускает эволюцию схемы без изменения старых клиентов (мы выкинули какое-то поле, а клиент его запрашивает? Ну просто вернем ему null!).

Кстати, вопрос про эволюцию схемы данных можно смело задавать на собеседовании, ещё один в копилочку :) Ну а про null'ы — если нужно зачем-то кандидата засыпать 🥴

Вы ещё не забыли про конкурс постов от Systems.Education?

Там есть очень интересные! Искать по тегу #продолжи_мысль_SE

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

https://news.1rj.ru/str/cool_analyst , посты про промпты для аналитика. Полезная польза!

https://news.1rj.ru/str/parawriter , канал технического писателя, пост про типографическую раскладку. Люблю хорошо оформленные тексты! Правда, говорят, теперь это считается признаком ИИ-генерации и нужно наоборот делать максимально неряшливо: никаких кавычек-ёлочек, длинных тире и прочей красоты. Да ну их всех, не буду отказываться от эстетического удовольствия.

https://news.1rj.ru/str/vne_efira , пост про кофе и подход к критике продукта, но и вообще канал интересный и поднимающий неочевидные темы.

https://news.1rj.ru/str/kozlovaabout , пост про требования к UI. Очень правильные мысли! Вообще вижу, что аналитикам зачастую сложно формулировать требования к интерфейсам, а уж проектировать хорошие совсем сложно. Не знаю, почему так — вроде вполне системно и почти формально можно к этому подойти, а не получается.

https://news.1rj.ru/str/system_analysis_max , пост про транзакции и их откат. Скажу честно — точное попадание в тематику: понятное объяснение сложной темы.

https://news.1rj.ru/str/analyticagain , пост про харденинг. Узнал новое слово!

https://news.1rj.ru/str/analitics_way , пост про транзакции. Дались вам эти транзакции! Но авторы находят разные ракурсы, и это интересно.

https://news.1rj.ru/str/business_analysis_team , пост о SWOT-анализе, а также его родственниках и знакомых. Не люблю карточки, но может вам зайдет.

А также совершенно неожиданные находки! Как вам ментор по системному анализу с 13-летним опытом работы в МВД? (https://news.1rj.ru/str/solo_teach) Не говорите теперь, что в ИТ сложно перейти. У меня, кстати, был сотрудник, долго работавший судебным экспертом и перешедший в аналитики. Вот у кого не было никаких проблем с написанием документов и логикой изложения!

Вот такие у нас участники, все очень классные. Если кого-то не упомянул, простите. Смотрите больше каналов по тегу!

Зацепила статья про Human Centered Design от Дона Нормана (автора книги "Дизайн привычных вещей" и, собственно, изобретателя термина UX, "пользовательский опыт").

Это статья из серии "considered harmful", в данном случае — это самый человеко-ориентированный дизайн должен быть признан небезопасным. Почему? Тем более что у нас есть целый стандарт ISO 9241-210 (и ГОСТ Р ИСО 9241-210-2016 "Человеко-ориентированное проектирование интерактивных систем"). И что он предлагает взамен?

В статье я увидел четыре концепции:

1) Не всегда нужно ориентироваться на человека. Расписывать его портрет, персону и социально-демографические характеристики. Это не очень помогает спроектировать интерфейс. Не так важно — кто именно пользуется вашим продуктом, гораздо важнее — что они делают, какая деятельность происходит в этом продукте. Тут Норман излагает в нескольких фразах теорию деятельности Леонтьева (не называя его, он говорит просто об early Russian research): у человека есть цели и задачи, им соответствует деятельность, действия и операции. И анализировать нужно именно деятельность и действия, а не личность человека. От HCD нужно перейти к ACD — Activity Centered Design.

2) Не всегда стоит игнорировать инструмент. Подход HCD говорит, что лучший интерфейс — это отсутствие интерфейса. Но есть много примеров, когда интерфейс имеет значение и никуда не исчезает: часы, автомобили, музыкальные инструменты, да даже письменность. Это не концепция исчезновения интерфейса, а концепция взаимной адаптации человека и интерфейса. Где-то интерфейс поменяется, а где-то человек привыкнет. Поэтому часто смена интерфейса на более модный и вроде бы удобный ломает работу пользователей, привыкших к старым интерфейсам (впервые я столкнулся с таким, когда нужно было перевести старых банковский софт под DOS на Windows: например, оказалось что плотность и различимость текста в интерфейсах типа Нортон-коммандера самая лучшая — в GUI элементы тоньше, пространства больше, а информации вмешается меньше). Тут сразу вспоминаются работы В.Ф.Венды по взаимоадаптации человека и машины, но их Норман видимо уже не читал. Идея в том, что адаптация взаимна — человек, в конце концов, очень хорошо учится, и на это можно рассчитывать.

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

4) Почти всегда нужен авторитарный дизайнер. HCD рекомендует слушать пользователей и делать, как они говорят. Но великие продукты создавались яркими авторами, типа Джони Айва. Я тут уже писал, что это математически обусловлено.

И всё это дает фору аналитикам при проектировании интерфейсов! Мы же умеем (должны уметь!) выявлять и моделировать деятельность людей — через бизнес-процессы или сценарии. Вот и нужно на этом фокусироваться.

Какая деятельность выполняется? (процессы/сценарии)
Из каких действий она состоит? (шаги сценария/частные сценарии)
Какие операции может выполнить пользователь? (Это уже уровень отдельных компонент интерфейса, можем выбрать по табличке).

Фокус на деятельности отражен даже в способе записи требований: job stories против user stories. Ну или их объединение — User Story Map. Правда, кажется, зачастую анализ деятельности пропускают — сразу перепрыгивают от бизнес-процессов к отдельным операциям. Но тогда целостный сценарий из действий не соберется.

Вопросы дизайна и проектирования сильнее связаны с проектированием API, чем мы привыкли думать.

В конце концов, и то, и другое — это интерфейсы и взаимодействие.

Проектировщик интерфейсов строит диаграмму переходов между экранами, и, как правило, на одном экране есть какое-то главное действие (+ несколько второстепенных). Изменение экранов, их состояний, переходы с одного экрана на другой — это и есть смена тех самых состояний, которые упоминаются в принципе stateless. Less — это из на сервере нет, а на клиенте они как раз есть, от них всё и проектируется. Изменяется экран — изменяется и состояние. Каждый переход — вызов API. Один и тот же артефакт служит основой и для работы дизайнера, и для работы проектировщика API.

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

Такое же "предложение" справедливо и для API. И — вы не поверите — называется HATEOAS, о котором писал Рой Филдинг! Почему-то на русском практически не встречается статей на эту тему, а для англоязычной аудитории это почти что общее место.

Аффордансы в API — это предложения следующих действий с предоставленным ресурсом: следующий шаг в процессе, изменение свойств и состояний, удаление, в конце концов. Майк Амундсен называет проектирование вокруг аффордансов высшей точкой зрелости API. Ну а что они такое, конкретно? Да это же ссылки на действия с ресурсом из HATEOAS!

Как это может выглядеть в коде:

{
  "user_id": "12345",
  "username": "johndoe",
  "email": "john.doe@example.com",
  "_links": {
    "self": {
      "href": "/users/12345",
      "methods": ["GET", "PUT", "DELETE"]
    },
    "update_profile": {
      "href": "/users/12345/profile",
      "methods": ["PUT"],
      "expected_fields": ["first_name", "last_name", "address"]
    },
    "change_password": {
      "href": "/users/12345/password",
      "methods": ["PUT"],
      "expected_fields": ["old_password", "new_password"]
    }
  }
} 

Так мы можем работать практически без документации! Идея пришла из простого следования HTML: там же сразу есть гиперссылки, и человек может нажимать на них, не запрашивая дополнительной информации и не обращаясь к документации. Вот бы и в API так делать! Ничего не вышло, т.к. c API работает программа, которую создает программист, и ей не требуются все эти ссылки, она сама не принимает решения ходить по ним. Это должен сделать программист. А дополнительный трафик они жрут порядочно.

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

На Flow в этом году какой-то нереальный конкурс — ПК приходится отказывать даже очень классным (с моей точки зрения) докладам! Потому что есть ещё более классные. ИИ, архитектура и немного софт-скиллов — всё для развития аналитика.

Но у JUG Ru Group осенью будет ещё несколько отличных конференций. (У Джугов вообще все конференции отличные, но в основном для программистов, для меня слишком глубоко). А вот на какие две я лично собираюсь, кроме Flow:

InBetween — про оперативное управление. У нас не так много конференций для менеджеров, а искусству управлять толком нигде не учат и мало где обсуждают. Каждый учится на практике, набивая себе шишки и пересчитывая новые седые волосы. Поэтому новая конференция про управление давно уже напрашивалась, как площадка для обсуждений. Очень рассчитываю на умение JUG Ru собирать классных спикеров и поднимать актуальные темы!

Кстати, онлайн-часть уже прошла и можно посмотреть доклады в записи (после регистрации). Уровень дискуссий повыше, чем в среднем на обычных конференциях! Ну и моё почтение за выбор названия — это же явная отсылка к австралийскому сериалу Mr. Inbetween, да?.. да?.. На русский его перевели как "Решала". Про эксперта в оперативном и тактическом управлении, так сказать.

BiasConf — я, можно сказать, джва* года ждал такой конференции. Про философско-методологические и научные основы исследований в бизнесе — ну вы знаете, на что меня можно поймать. Вы, вероятно, заметили, что философские основания нашей деятельности меня очень интересуют (хотя, кажется, не всегда они интересуют читателей, судя по реакциям, а то я бы только о них и писал). Также меня интересуют эмпирические исследования процессов создания программных систем — мне кажется, многие теории и фреймворки оторваны от реальной практики "на земле". Ну а вторая часть конференции — про исследование и принятие решений на основе данных — уже более практическая.

Обе конференции пройдут в Москве, InBetween — 8 сентября (когда же ещё обсуждать управление, как не в понедельник); BiasConf — 6 сентября (в субботу самое правильное поговорить о философии).

Если кто-то тоже соберется — буду рад увидеться! Я пока без докладов, посмотрю, как там что, и возможно подамся на следующий год.

* Не опечатка! Отсылка к старинному текстовому мему "я джва года хочу эту игру [в которой можно грабить корованы]"

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

Была такая отдельная роль — проектировщик интерфейсов, результатом работы которой был прототип, который потом отдавали дизайнеру для отрисовки в Фотошопе.

Например, об этом упоминается в статье про анализ вакансий (2013, и её продолжение через 10 лет — проектировщики интерфейсов и умение создавать прототипы исчезли полностью), а в этой статье Ярослава Перевалова (2012)  разбирается, какие роли участвуют в процессе дизайна и как они взаимодействуют (там вообще отдельно проектировщик, дизайнер и юзабилити-специалист, бизнес-аналитик и системный аналитик).

Потом появилась Figma, и финальный дизайн стало рисовать очень просто (когда у тебя есть подготовленные компоненты) и быстро. И предварительные мокапы оказались не нужны. А вместе с ними и процессы анализа и проектирования.

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

Только пользователи жалуются. И вот тут становится востребована новая роль — UX-исследователь! Который разбирается — что же этим пользователям нужно, что им там неудобно в этих интерфейсах, нарисованных без анализа и проектирования. А потом и рекомендации по исправлению можно выдать. Ну, то есть — быстро что-то делаем, а потом уже работающее улучшаем, этап анализа и проектирования после реализации.

Ничего не напоминает? Да это же ситуация с вайб-кодингом! Сначала будем невероятно быстро писать код, а потом долго и скрупулезно исследовать — что же там не так работает и как исправить? Как это там называется, vibe coding cleanup specialist, да?

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

С образованием системных аналитиков у нас всё плохо. В смысле, всё хорошо с интенсивными практическими программами, ну вы знаете :)

А вот фундаментальных нет — бакалавриата или магистратуры по системному анализу или по анализу и проектированию информационных систем вы не найдете. А если найдете — там скорее всего будет программирование с небольшими вкраплениями всего понемногу: немного управления проектами, немного моделирования бизнес-процессов, какая-нибудь "бизнес-аналитика" в виде элементарного введения в анализ данных и статистику + какой-то инструмент построения дэшбордов.

В общем, обучают специалистов широчайшего профиля.

Но и это ладно бы, проблема в том, что даже в такой программе с большой вероятностью не будет курсов по анализу систем, управлению требованиями и проектированию. Возможно, будет курс по системному анализу, но этот термин давно зарезервирован под совершенно другое направление: там вам будет рассказывать про обратную связь и колебания, многоагентные системы, теорию игр и методы рационального выбора из многих альтернатив, принятие решений и возможно про устойчивость или про сетевые взаимодействия. Пример — книга "Азбука системного мышления" Донеллы Медоуз или курс "Системный анализ и проектирование сложных систем" в Вышке. Это полезно для управленцев, бизнес-консультантов или авторов законопроектов, возможно даже для инженеров по надежности, но аналитик ИТ-систем с этим в своей повседневной работе редко сталкивается.

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

* Логика. На самом деле — Reasoning, умение рассуждать и делать выводы, но это плохо переводится на русский. Ни один академический руководитель не поставит в план дисциплину с названием "Умение рассуждать", так нельзя. Вы что, набрали студентов, которых нужно учить рассуждать? В лучшем случае там будет логика (математическая логика, мы же другой не знаем), или "критическое мышление", или вообще какой-нибудь "дискуссионный клуб". Между тем, это база. Что из чего следует, что из чего не следует, что что опровергает, и т.д. Modus ponens, modus tollens, ex falso quodlibe, вот это всё. Кванторы, признаки, классы. Границы формальной логики, где она пасует и становится бессмысленной. Виды импликаций. Что значит, "из A следует B"? Там ведь штук шесть или даже больше разных вариантов. Модальности: мы знаем, что некое X невозможно. Почему? Логически невозможно, запрещено нормативно, ценностно недопустимо или недоказано, что так можно? Это всё разные модальности. Способы рассуждения: индукция, дедукция, абдукция (кстати, Шерлок Холмс в основном применял именно её, а не дедукцию)

* Функциональная грамотность(?). Не знаю, как назвать. На самом деле — Verbal Reasoning. Умение понимать тексты и речь. Практическое применение логики. О чем говорится в тексте? Можно ли из этого текста сделать вывод, что определенное высказывание верно или ложно? Или однозначного вывода сделать нельзя? И какая информация нужна, чтобы его всё же можно было сделать? Говорится ли в тексте об одном предмете / классе / свойстве, или текст перепрыгивает с одного на другое? Если текст — ответ на вопрос, то ответил ли на самом деле респондент на заданный вопрос?

* Объектное моделирование данных. Что является частным случаем чего и общим случаем чего? Что является признаком, а что — самостоятельным объектом? Что является частью чего? И могут ли части существовать отдельно? Что будет, если к двум яблокам прибавить три груши? А к ним ещё килограмм творога?

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

Что забыл из обязательного фундаментального?

В Гигачате, тем временем, появился "умный редактор" документов с инструментами ИИ.

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

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

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

Что в редакторе есть сейчас: можно переписать, перевести и исправить ошибки. Переписать так:
— Выделить главную мысль
— Приукрасить текст
— Сократить
— Написать другими словами
— Сделать проще
— Расписать подробнее
— Поменять стиль (официально-деловой, научный, художественный)
— Адаптировать (под бумеров, под зумеров, под миллениалов)

Плохо, что этот редактор переписывает текст, то есть заменяет, а не добавляет.

Это нам для требований не особенно помогает, но сам подход мне нравится. Я бы сделал так:
Переписывание:
— Переписать в другом формате (канонические требования, user story, job story, use case)
— Расписать по шагам (в формате use case, в формате bdd-сценария)
— Проверить читаемость и упростить

Добавление:
— Добавить детализированные требования
— Разбить требования на подсистемы (фронт и бэк)
— Добавить описание интерфейса
— Добавить верхнеуровневое требование
— Добавить описание ошибок и исключительных ситуаций
— Добавить описание API
— Добавить схему данных

Прослеживание:
— Проверить соответствие верхнеуровневому требованию
— Проверить полноту операций
— Проверить соответствие модели данных (и добавить необходимые объекты и поля в модель)
— Проверить соответствие интерфейсам
и т.д.

Проектирование и планирование:
— Предложить модель данных
— Предложить структуру API
— Предложить варианты архитектуры
— Предложить этапы работ

Параллельно с текстом, где-нибудь сбоку, должна поддерживаться модель данных (с подсветкой объектов и атрибутов, упомянутых в тексте, но не присутствующих в модели); модель интерфейсов — UI/API; глоссарий; контекстная модель с названиями всех упомянутых систем; перечень ролей; матрица зависимостей требований. Все кросс-проверки, понятно, должны выполняться автоматически.

В идеале ещё (можно же помечтать?) документ можно оформить в виде перечня задач на изменения, а можно в форме описания "как есть", как новый baseline.

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

Вот такой бы редактор я хотел. А то почему у программистов есть всякие там курсоры, а у аналитиков нет специального инструмента?

Адаптация под разные поколения — это отдельный анекдот. Ну пятница же, вот вам для веселья:

Исходный текст (тоже сгенерированный):

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

Адаптированный для бумеров:

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

Заметили разницу? Зачем использовать иностранные слова "учебные материалы", "навигация" и "контент", когда есть замечательные русские "пособия", "перемещение" и, хм, опять "материалы".

Для миллениалов (обязательно нужно 90-е упомянуть и журналы! прям песочек посыпался):

Система управления обучением — это такая штука, типа школьного дневника на стероидах, который помогает организовать учебный процесс, чтобы никто ничего не потерял и вовремя получил свою порцию знаний. Представьте себе классный портал, где собраны учебники, задания, оценки и даже место для общения преподавателей и студентов. Тут тебе и курсы разные найдутся, и контент удобно разложат, чтобы сразу было понятно, куда идти дальше. Как в девяностых и нулевых годах, когда мы листали журнал, надеясь найти интересную статью или рубрику, здесь тоже всё легко ищется и быстро открывается. Удобно, современно и никаких тетрадок с пометкой «сдать срочно!» 😉

Для зумеров (нужно больше смайликов!):

Эта штуковина называется системой управления обучением 💻 Она создана, чтобы сделать твоё обучение классным и удобным! Представь себе место, где собраны все твои учебники, задания и оценки 😎 Ты можешь смотреть курсы, общаться с учителями и одноклассниками, получать обратную связь и даже проходить тесты онлайн! Всё удобно организовано, легко найти нужную инфу и управлять своими успехами ✨ Короче говоря, эта система помогает тебе учиться весело и эффективно 🚀😊

Короче, я понял вот что:
1) Все типовые посты в тг-каналах пишут зумеры.
2) По умолчанию Гигачат пишет в стиле поколения X (это я). Видите, под него не нужно текст адаптировать!

Ну как, в каком стиле переписываем все документы? 😆

Сходил на BiasConf от JUG RU Group. Это эксперимент. Заявлена как конференция про философско-методологические и научные основы исследований в бизнесе, но больше было про исследования вообще.

Доклады на конференции разбились на два очень далеких друг от друга класса: конкретные рассказы про приемы исследований и доклады про философию.

К сожалению, последних было не очень много, но именно на них было больше всего людей!

Кажется, люди очень интересуются философскими основаниями своей деятельности!

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

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

В докладе собственно основные методы описаны:
— феноменология: то, что происходит со мной, и как я это чувствую. Возможно, с обобщением — что вообще происходит с людьми, когда они говорят о каком-то явлении. Отделить феномен от того, кто его воспринимает, невозможно. Можно максимум проанализировать, как разные воспринимающие о нем думают или его ощущают. Это, мне кажется, вообще типовая форма мышления большинства стейкхолдеров: зацепились за какой-то конкретный факт или событие, и про него рассказывают. Особенно почему-то топы так любят делать. Также мы это делаем, когда пытаемся "думать и чувствовать, как пользователь", "проявлять эмпатию". User story, CJM, наблюдение за деятельностью без предварительной установки — это всё феноменологические подходы. Когда в обсуждении человек говорит вам "а у меня не так" — это феноменология.

— герменевтика: изучение текстов и — шире — вообще символов. А что по этому поводу написано? Как мы можем интерпретировать этот текст? А как те, кого мы исследуем, интерпретируют этот текст/символ? Что они говорят? Что мы у них спросим? Как наши тексты переплетутся между собой? В каком контексте был создан этот текст и в каком он интерпретируется? В общем, это всё про анализ документов, описаний, формальных моделей (которые тоже не явление само по себе, а его описание). Если вы любите строить и изучать модели бизнес-процессов, UML-диаграммы, а потом ещё и толковать их и обсуждать — вы занимаетесь герменевтикой. Если вы изначально задаете модель какого-то явления, и подгоняете под его структуру наблюдаемую реальность — это герменевтика. Когда человек говорит "а давайте сначала определим это понятие" — это герменевтика. На герменевтику опирается вся современная наука (опишем явление словами/моделями). Забавное замечание в Википедии: Гермес идеально выражает суть герменевтики, так как по верованиями греков он изобрел речь и язык, а также был посредником, переводчиком, вором, обманщиком и трикстером, и уводил души в царство мертвых.

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

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

Вообще я сегодня должен был написать либо про философские доклады с BiasConf, либо про InBetween.

Но внезапно я сделал новую версию карты интеграций: https://github.com/yksi12/integrations/blob/main/Integrations%20Tech%201.0.1.pdf

Добавил туда JSON-RPC, т.к. он в последнее время стал популярен в связи с MCP — протоколом для взаимодействия LLM с внешними источниками данных и сервисами. Также он используется в блокчейн-проектах (они не на слуху, но вообще-то вполне себе живы и развиваются).

На картинке видно, что протокол легковесный: вся линейка почти пустая.

Впрочем, карта уже дает предсказательную силу — ну не опишешь ведь RPC ни в OpenAPI, ни в AsyncAPI. Но должен же быть формат для описания спецификаций? Ну вот он и есть: OpenRPC! https://open-rpc.org/

То есть, когда вы сталкиваетесь с какой-то новой для себя технологией или приёмом, можете задать себе всё те же вопросы:
— Верхнеуровневый паттерн: это удаленный вызов или обмен сообщениями (надеюсь, общую БД и файловый обмен вы не используете)
— Это синхронно или асинхронно?
— Какая метафора используется? Какая семантика взаимодействия? Вызов процедуры, CRUD над ресурсами, гипермедиа, запрос данных, извещение, подписка на событие, очередь? У некоторых авторов это называется "интеграционный стиль"
— На каком это протоколе? HTTP, HTTP/2, TCP с какой-то своей нашлепкой? И если HTTP, то только как транспорт, или по полной, как в REST? Протокол-то вообще бинарный или текстовый? И вообще, этот метод завязан на конкретный протокол, или может использоваться с разными?
— В каком формате передаем данные? Есть ли у этого формата схема? Строгая ли типизация в этом формате? Он плоский, или допускает вложенность? Насколько сложным по структуре может быть ответ?
— Если нам нужно преобразование данных, то есть ли штатные средства для этого?
— Что с обработкой ошибок? Можно ли определить и возвращать собственные коды ошибок и дополнительную информацию?
— Что с безопасностью? Аутентификация и разделение полномочий? Есть ли штатные средства? Или всё ограничивается TLS/SSL и OAuth?
— Что с производительностью, скоростью и гарантиями доставки?
— В чем мы это будем описывать, какие есть языки спецификаций и инструменты тестирования? Где мы эти спецификации храним и как обеспечиваем их актуальность?

И если мы берем какую-то совершенно новую технологию, нужно просто задаться всеми этими вопросами. И мы можем сравнить две технологии — дублируют ли они друг друга? Можно ли использовать на одном проекте RabbitMQ и Kafka? Что выбрать — GraphQL или gRPC?

В общем, кажется, схема работает. Про что ещё можно спросить в отношении технологий интеграции, чтобы сравнить их друг с другом?

Говорят, у некоторых не загружается pdf из Github, прикреплю сюда файлом.

Ну и напоминаю, что любые предложения, комментарии и идеи с удовольствием принимаю, пишите!

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

Ещё один вариант использования — адаптация карты под свою организацию, нечто вроде техрадара. А что у нас есть? Что мы для чего используем? На какие технологии мы пока смотрим только в экспериментальном режиме, что является стандартом, а что ещё используется, но новых проектов на этом делать не нужно.

Сюда же можно добавить шаблон ADR для выбора интеграций и их нюансов — рассматривали вот такие варианты, решили делать так.

Но это уже не просто картинка, это какой-то инструмент должен быть. Что думаете, полезно ли было бы?

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

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

Ну а дальше меня лично (или виртуально) можно будет увидеть на курсах Systems.Education:

25-27 сентября: «Системный анализ + ИИ. Разработка требований и функциональное проектирование систем». Это наш классический курс для систематизации знаний в системном анализе, где мы даем четкую последовательность действий и артефактов. Но сейчас — с помощью ИИ, когда мы можем ускорить анализ (например, выявление бизнес-сущностей из текстов), формирование текстов и диаграмм, и кросс-проверки. В общем, классика на новом уровне в формате интенсивного погружения за 3 дня. Курс-боевик. В очном формате, кстати, довольно редко проводится.

А с 29 сентября начинаем экспериментальный онлайн-курс «Микросервисы для системных аналитиков». Без программирования и DevOps, ровно то, что нужно аналитикам. По-сути, это введение в архитектуру: там будет Event Storming, построение архитектурных диаграмм C4 до уровня компонент, практика составления записей архитектурных решений ADR, расчет нагрузки, ну и проектирование интеграций, но уже применительно к микросервисам: основные паттерны, сценарии взаимодействия, описание контрактов в OpenAPI и AsyncAPI (для Rabbit и Kafka). Это будет онлайн по три часа с утра.

Ну и 3-4 октября — Flow в Санкт-Петербурге. Там буду делать доклад про логику построения карты интеграций, а точнее даже — про морфологию интеграций: что во всех технологиях в любом случае есть, о чем нужно задуматься и как разные технологии между собой сравнивать.

Про InBetween 2025.

Ещё одна экспериментальная джуговская конференция. Про задачи связи стратегии и тактики.

Очень бодрое начало, но к концу как будто не хватило заряда. А в первой половине доклады были прямо огненные!

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

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

Впрочем, в рассказе была и новая перспектива: как, собственно, запускать этот авральный режим, когда всё застыло. Ответ — через параллельные управленческие структуры. Про то же говорится и в курсе "История бюрократии", кстати — на примере разных стран и эпох. Ну и сам я, если задуматься, довольно часто работал именно в параллельных структурах, выключенных из устоявшейся системы. Знание, которому не учат в бизнес-школах (ну или мне так не повезло, напишите, если кого-то учили такому).

Следующий отличный доклад Ильи Балахнина про стратегические сессии. Доклад вокруг одного слайда — куда только ПК смотрит?! 😂
Много полезных советов про проектирование и ведение стратсессий, я раньше их вел иногда, так что отзывается. Из интересных тезисов:

* не жалейте времени на выяснение главного вопроса. Ну иначе результаты будут бесполезны. А в чем главный вопрос (а не острый симптом, например) — это нужно выяснять.

* используйте при анализе принцип деления MECE (Mutually Exclusive, Collectively Exhaustive) — так, чтобы предметы и признаки, которые вы делите, не попадали одновременно в разные категории (Mutually Exclusive), и покрывали все возможные варианты (Collectively Exhaustive). Нарушение этого принципа мы достаточно часто наблюдаем — когда часть вариантов пересекается, и из этого пересечения выстраиваются обобщения то в одну, то в другую сторону.

* применяйте разные методы анализа проблемы:
** структурный (раскладываем проблему на части, смотрим, из чего она состоит)
** хронологический (раскладываем по времени / последовательности / сезонности, смотрим — что было до, что будет после)
** причинно-следственный (раскладываем по логике: что из чего вытекает, что на что влияет. Дерево текущей реальности Голдратта, Impact Mapping)
** иерархический (раскладываем по важности — что тут самое главное, а что второстепенное, что во что вложено)

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

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

* фиксируйте зоны ответственности по RASCI: кто выполняет задачу (R), кто отвечает за то, чтобы задача была выполнена с должным уровнем качества (A), кто помогает (S), кто консультирует (C), кто должен быть в курсе (I). Тут мы потом немного поговорили про DACI: Driver, Approver, Contributor, Informed. Но supported и consulted тоже интересные роли, можно и так.

Вот эти доклады мне очень запомнились. Остальные были уже не такими насыщенными, но я не все смотрел. Интересная мысль была у Алексея Кирпичникова из Контура: при руководстве 80 продуктами и ~2,5 тыс. человек ты, как руководитель, вообще не можешь ни кем конкретно руководить, вот такой парадокс. Ты можешь только устанавливать правила и политики, задавать стандарты и контролировать их внедрение / соблюдение. Тоже, кстати, было в курсе про бюрократию — многие великие правители государств именно с этого начинали — со свода законов и конфигурации управленческих структур. А всё остальное уже потом "само" получается, если правильно организовано.