Пост на злобу дня: Аэрофлот упал, но быстро поднялся. В других отраслях тоже проблемы — то ли из-за атак, то ли по другим причинам.

Это всё, с одной стороны, про безопасность, а с другой — про непрерывность бизнеса. Обычно это считают подразделом безопасности — требования иметь планы BCP и DRP описаны в стандарте ISO 27001, в основном в виде сохранения защиты данных при авариях/чрезвычайных происшествий.

BCP — Business Continuity Plan: как мы собираемся работать, несмотря ни на что (атаки, аварии, стихийные бедствия, другие форс-мажоры).

DRP — Disaster Recovery Plan: как мы собираемся восстанавливаться после аварии.

Это очень клёвые документы, особенно если они разработаны по-честному, а не для галочки/чтобы пройти аудит. Это как аптечка в походе — обычно не нужна, но если нужна, то очень.

Близки к этому понятия RTO — Recovery Time Objective, целевое время восстановления, и RPO — Recovery Point Objective, целевая точка восстановления (а к какому, собственно, состоянию мы восстанавливаемся, что мы готовы потерять? далеко не факт, что ответ "ничего не готовы").

Я вам честно скажу — не знаю, как это в крупных компаниях организовано. Вроде интернет говорит, что есть какие-то отдельные BCM — Business Continuity Managers, менеджеры по непрерывности бизнеса. Не знаю, не видел.

В проектах, где я в разработке таких планов участвовал, всегда была рабочая группа из представителей бизнеса (операционного подразделения, клиентского, рисков), безопасности, ИТ и с обязательными участием бизнес- и системных аналитиков. Потому что бизнес выдает требования и оценивает последствия рисков, ИТ предлагает решения, а прокапыванием и проектированием деталей занимается аналитик. Ну а кто кроме БА знает, что в процессе может пойти не так и как его можно выполнить альтернативно?

Какие процессы наиболее критичны? Какая последовательность восстановления? Какие системы наиболее критичны для работы?

Есть документ, который даже в названии содержит слово "анализ": BIA — Business Impact Analysis.

Это вообще кайфовый документ для людей, склонных к упорядочиванию всего: вот у нас есть такой риск, что случится, если он реализуется? Что кто будет делать? Что кто не сможет сделать? Какие процессы остановятся/замедлятся? К чему это приведет? Что мы потеряем в деньгах и репутации, чем навредим людям, партнерам и обществу?

Упражнение в чем-то напоминает то, что дает Сергей Нужненко: Какие входы у вас есть? Какие выходы? Какие ресурсы? Как это всё управляется? Что будет, если потоки на них прервутся/замедлятся? Люди не смогут войти в здание, оборвется электричество, заболеют ключевые сотрудники, будут уничтожены данные / виртуальные сервера, прекратится доступ к Интернету или отдельным сервисам?

В конце концов, у армии США есть даже план по отражению угрозы нашествия зомби (CONPLAN 8888), а чем мы хуже?

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

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

К чему я, собственно, это пишу. Слышу во многих обсуждениях сомнения в функциях системного/бизнес-аналитика. Мол, то ли всех заменит ИИ, то ли всех уволят из-за перехода на agile, то ли ещё что. Да и куда расти непонятно: то ли в архитекторы, то ли в продакты (рост ли это?), то ли в стратегию/CIO, то ли ещё куда. Вот один из вариантов — если вы любите операционку и кайфуете от налаживания процессов. Вариант, кстати, вполне реальный: у меня как-то раз именно в операционное подразделение сманили лучшего бизнес-аналитика — там задачи интереснее и рост понятнее.

Мы вместе с NextWay и Flow проводим независимое исследование рынка системных и бизнес-аналитиков. В виде опроса:

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

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

Результаты везде опубликуем.

Ссылка на опрос

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

Вопрос достаточно простой (на каждое новое соединение открывается собственный сокет, то есть отличаться они будут локальным портом), так что даже начинаешь подозревать какой-то подвох. Ну, можно ещё рассказать про различие между HTTP/1.1 и HTTP/2 (в последнем будет удерживаться одно TCP-соединение, а запросы и ответы для разных вкладках будут передаваться в разных потоках).

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

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

Итак, странные вопросы для собеседования:

1. В какой интеграции нет очередей: RabbitMQ, gRPC, Kafka?
2. Как устроена пагинация в GraphQL?
3. Есть ли в MCP HATEOAS?
4. Какой самый простой способ организации Service Discovery?
5. Что лучше с точки зрения безопасности — JSON или XML?
6. В каких версиях HTTP можно передавать потоки данных с сервера на клиент по инициативе сервера?
7. Что передается в методе PATCH по стандарту?
8. Каким методом HTTP нужно создавать ресурс на сервере?
9. Чем ограничивается число входящих сетевых подключений на сервере?
10. Какими функциями должна обладать система, чтобы её можно было считать полноценной шиной?

Ооо, какая штука! Каталог паттернов работы с легаси-системами: https://legacy-modernization.io/

Вытащил из сообщества архитекторов Russian Association of Software Architects

Удушение, миграция, параллельная работа. В связи и импортозамещением (не всё ещё заместили?..) очень актуально.

Как обычно, многие паттерны — это просто здравый смысл, но хорошо, что они названы и собраны в одном месте.

Каталог разбит на 4 части:
— миграция с легаси-системами
— синхронизация данных
— организационные паттерны
+ не паттерны, а перечень типовых проблем и мотивов перехода со старых систем.

Паттерны интеграции:
— "душитель" (по-английски он фикус-душитель, Strangler Fig): откусываем от легаси-системы по одному юскейсу — ставим на входящем потоке роутер, который перенаправляет некоторые частные случаи в новую систему. Сначала единичные, потом всё больше и больше, потом все.

— "пузырь": развитие идеи anti-corruption level — внешние системы и пользователи работают с новой моделью (и функций, и операций), а он преобразует и сохраняет данные в легаси-системах. Постепенно он всё меньше и меньше зависит от легаси-систем, а потом они совсем отключаются — пузырь "лопнул". "Автономный пузырь" — изначально со своим хранилищем данных. "Обратный пузырь" — когда ставим его после легаси-системы, и отправляем в него запросы для обработки, то есть легаси как интерфейс, а в пузыре новая бизнес-логика с новой доменной моделью.

— можно прикрутить к легаси новое API или UI, или отлавливать и публиковать события из неё.

— дальше разные стратегии миграции: пишем в легаси, читаем из новой системы/читаем из легаси, пишем в новую систему. Или делим по сегментам пользователей (по странам, клиентам, юскейсам).

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

Паттерны синхронизации данных:

— CDC, чтобы гонять только изменения
— Sync and Backfill — когда у нас два отдельных процесса на синхронизацию новых данных (в реальном времени) и подгрузке исторических (асинхронно)
— Двойная запись (пишем одновременно в старую и новую систему)
— Общая БД

Обратите внимание: миграция требует практически тех же подходов, что и интеграция!

Организационные паттерны:

— AMET (Architecture Modernization Enabling Team) — вот это крутая идея! Временная команда, выделенная на фасилитацию перехода: помогает спроектировать новую архитектуру, не давать угасать импульсу, добавлять экспертизу там, где она нужна. Вот тут подробная статья про AMET https://livebook.manning.com/book/architecture-modernization/chapter-15, из книги Jean-Georges Perrin и Nick Tune 'Architecture Modernization: Socio-technical Alignment of Software, Strategy, and Structure' (на русском вроде её нет)

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

— Inner-Sourced Client Migration: команда со стороны сервиса берется за переписывание кода в клиентских системах (эффективно, но только для тех клиентов, кто готов пустить в свою кодовую базу). Да мы уже сами вам всё перепишем, только перейдите уже на новую версию!

— Dual Track — когда вы разделяете команду на две: одна занимается текущими доработками, другая миграцией.

Говорю же: нужно просто дать название какому-то приему, и уже паттерн. Всё, можно тренинги продавать.

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

Интересно, что в опросе в канале ЛАФа 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?

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