Мы тут с коллегами из нескольких школ и конференций решили сделать большое исследование индустрии системного и бизнес-анализа в РФ и не только.

Хотим узнать про отрасль, её размер, зрелость и вообще.

А что бы вы хотели узнать про нашу индустрию? Что интересно узнать про развитие СА/БА в компаниях и про людей? (Ну, помимо очевидного вопроса -- сколько зарабатывают люди в соседней организации)

Напишите в комментариях!
👇👇👇

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

Есть ГОСТ Р 27.102-2021 "Надежность в технике. НАДЕЖНОСТЬ ОБЪЕКТА. Термины и определения". Там всё есть.

Запишу для себя и для вас верные термины:

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

Короче, это про функции. Для сложных объектов может быть частично работоспособное состояние, когда часть функций ещё выполняется, а часть уже нет. Есть ещё исправное и неисправное состояние, а ещё — рабочее и нерабочее. Рабочее состояние — объект выполняет какую-то свою функцию прямо сейчас.

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

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

Отказ: событие, заключающееся в нарушении работоспособного состояния объекта. То есть, он становится частично или полностью неработоспособным, перестает выполнять одну или все функции.

Сбой: самоустраняющийся отказ или однократный отказ, устраняемый незначительным вмешательством оператора. В общем, если вы обратились к системе и получили ответ 500, а потом снова обратились, и получили нормальный ответ — это был сбой.

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

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

Дефект — это несоответствие объекта требованиям, установленным в документации. Дефект может проявляться только при определенных обстоятельствах, и приводить к сбою или отказу.

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

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

Доступность (availability) этом стандарте приравнивается к готовности: способность объекта выполнять требуемые функции в заданных условиях, в заданный момент или период времени при условии, что все необходимые внешние ресурсы обеспечены.

При этом надежность объекта и готовность объекта не зависят друг от друга!

А вот эту загадку я уже оставляю вам — как такое может быть? (Upd: ответ в комментариях)

Давно не писал ничего про ИИ, а вот хорошая раскладка по уровням освоения ИИ-скиллов от CEO Zapier.

Как пишет их CEO, это не чек-лист, а просто примеры навыков для понимания — на каком этапе человек в освоении ИИ.

1. Неприемлющий: Сопротивляется использованию ИИ-инструментов и скептически оценивает их пользу.

2. Способный: Использует наиболее популярные инструменты. Скорее всего — опыт использования менее 3-х месяцев.

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

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

Если говорить о системном анализе, я пока не видел и не слышал о применении на 4 уровне, только редкие одиночные примеры 3-го.

Ну и, кстати, — как бы могли уровни выглядеть для системного аналитика? Что-нибудь вроде такого:

1. Отказывается использовать ИИ, считая его ненадёжным. Пишет требования и составляет диаграммы вручную. Не автоматизирует анализ или моделирование систем.

2. Использует ChatGPT для генерации черновиков требований, user stories и диаграмм. Проверяет корректность ИИ-вывода вручную. Знает базовые понятия LLM и применяет шаблоны промптов.

3. Автоматизирует анализ пользовательских интервью и составление требований с помощью ИИ. Применяет LLM для генерации и валидации моделей (BPMN, UML). Проверяет и устраняет пробелы в требованиях через автоматическое сравнение и трассировку разных видов требований и моделей. Оптимизирует промпты.

4. Формирует основанный на ИИ процесс сбора, генерации и валидации требований. Создает LLM-агентов для анализа требований, отслеживания изменений и генерации спецификаций. Внедряет ИИ в аналитические процессы на уровне организации, сокращая время анализа на 30-50%

Что думаете? Возможен 4-й вариант? Или ИИ-трансформирующий аналитик должен делать что-то другое?

На днях готовил велосипеды к сезону, сразу 4 штуки — чистил, смазывал, подтягивал. Очень медитативное занятие. Сразу вспомнил книгу, про которую забыл здесь написать — "Дзен и искусство ухода за мотоциклом" Робета Пирсига.

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

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

Но безотносительно правильности всех идей, книга-то сейчас суперактуальна! Особенно в связи с появлением генеративного ИИ.

Она про отношение к работе.

Вот цитата про механиков, которые не хотят разбираться (и не чувствуют качества):

Они были как зрители. Такое чувство, будто сами туда только что забрели, а им сунули в руки по гаечному ключу. Нет причастности к работе. Нет такого, мол: «Я – механик». Ровно в 17:00 или когда у них там заканчиваются их восемь часов, они отключаются – и больше ни единой мысли о работе. Они и на работе стараются о ней не думать. По-своему они достигли того же, что и Джон с Сильвией, – живут бок о бок с техникой, но не имеют с ней ничего общего. Вернее, что-то общее с ней у них таки есть, но их собственные «я» – где-то вне ее, отстранены, удалены. Они работают, но им все равно.

За работой я думал как раз об этом наплевательстве в инструкциях к цифровым компьютерам – я редактирую такие тексты. Одиннадцать месяцев в году зарабатываю на жизнь тем, что пишу и правлю технические инструкции, – и знаю, что в них полно ошибок, двусмысленностей, упущений и таких искажений информации, что приходится перечитывать по шесть раз, чтобы хоть что-то понять. Но теперь меня впервые поразило вот что: насколько эти инструкции согласуются с тем зрительским отношением, что я видел в мастерской. Эти инструкции – для зрителей. Они подобраны под такой формат. В каждой строчке сквозит идея: «вот машина, изолированная во времени и пространстве от всего остального во вселенной; она не имеет отношения к тебе, ты не имеешь отношения к ней, знай верти определенные ручки, поддерживай уровень питания, проверяй условия возникновения ошибки…» – и так далее. Вот в чем дело. Механики по своему отношению к машине ничем не отличались от отношения инструкции к машине или от меня, привезшего машину к ним. Мы все были зрителями. И тут меня осенило, что не существует инструкции по истинному уходу за мотоциклом, по самому важному аспекту. Неравнодушие к тому, что делаешь, либо считается несущественным, либо принимается как должное.

Вот это как раз про неравнодушие. Ты или хочешь побыстрее закончить задачу и забыть про неё, либо ты хочешь сделать свою работу максимально качественно. Я всегда стремлюсь к качеству, поэтому некоторые мои постоянные заказчики говорят: Юра будет делать дольше других, но разберется на гораздо более глубоком уровне (и спроектирует систему, которая будет без больших изменений работать много лет — это уже из опыта).

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

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

Мы на тренинге по интеграциям много разбираем обработку ошибок и мониторинг, захватываем иногда и тему поэтапного раскатывания обновлений (и автоматического отката, если что-то пошло не так), а тут на днях просто эпичная иллюстрация основных концепций.

Может быть вы слышали про падение сервисов Google 12 июня. Почти 8 часов API гугловских облачных продуктов выдавало ошибку 503 на каждый запрос.

Что произошло:

Любое обращение к API в Гугле проходит предварительный контроль: авторизацию, политики доступа, не выбрана ли квота доступа к API и т.п. Это региональный сервис, раскатанный на каждом региональном сервере. Он быстро ходит в свою базу, проверяет политики и разрешает исполнение вызова API или запрещает его. Базы с политиками синхронизированы и реплицируются почти мгновенно. Для скорости работы сервис выполнен в виде бинарника.

29 мая 2025 г. в сервис контроля была добавлена новая фича — дополнительная проверка. Обычно новые версии автоматически накатываются на внутренние проекты, и если там всё хорошо — постепенно раскатываются на все регионы. Если на какой-то стадии пошли ошибки — обновление так же автоматически откатывается. Обычно для обновлений делают "красную кнопку" — флаг, выключающий именно эту новую проверку. Ну и вообще на фичу принято вешать фича-флаги для быстрого включения/отключения.

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

И когда 12 июня в базу наконец добавили новую политику — случайно забыли заполнить пару полей. База политик, как мы помним, реплицируется почти мгновенно. А новый бинарник уже был раскатан во всех регионах. И он — угадайте — начал падать с null pointer exception, соответственно перекрывая доступ к вызову API.

Тут начинается какой-то процедурал-боевик, как в кино. За 2 минуты Site Reliability Engineering team отловила и оценила уровень проблемы. За 10 — выяснила причину(!). Ещё за 15 была готова "красная кнопка". Примерно через 40 минут красную кнопку раскатали, и региональные сервера начали возвращаться к работе.

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

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

Я не знаю, насколько тут помог бы системный аналитик (их в Гугле вроде бы и нет), но каждый раз на тренинге я долблю и долблю: пропишите обработку всех технических ошибок и ошибок в данных! Примите решение по стратегии гарантий доставки! Если есть перепосылки-ретраи — определите механизм задержки и рассинхронизации ретраев! Это выглядит сложно и заморочено, но может уронить нагруженный сервис на несколько часов, как мы видим.

Сам же Гугл обещает, по итогам инцидента:
— сделать сервис проверки политик модульным (чтобы падение одной проверки не валило весь сервис — вот для чего нужно уходить с монолита!)
— Провести аудит всех глобально реплицируемых данных
— Принудить всех изготовителей бинарников использовать фича-флаги
— Улучшить статический анализ кода и тестирование (ну null pointer-то как пропустили?!)

Отчет об инциденте. Будьте внимательны при проектировании API!

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

Что думаете?

в общем двачую, что на интервале 10 лет системные аналитики сметут нахер архитекторов (по крайней мере для условно безответственных программных систем автоматизации бизнеса, а точнее — сбыта — информационный учёт, элементарная обработка, приём заказов, маршрутизация, логистика, аналитика)

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

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

первый гвоздь в крышку гроба дало движение Systems Design, которое показало, что можно проектировать программные системы без Archimate, UML и прочих умных слов.

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

Интересный метод исследования тут обнаружил: исследование путем провокации.

Нашел я его в обзоре этнографических методов исследования, когда мы выезжаем на местность и изучаем объект непосредственно в среде и естественных условиях. Ну, мы, как аналитики, часто таким занимаемся — это включенное и невключенное наблюдение, хронометраж и картирование рабочего дня, партисипативное наблюдение, теневое наблюдение (shadowing), рефлексивное озвучивание (thinking aloud), анализ контекста.

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

В статье оно описано так:

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

Очень простое определение и понятная техника, но мощная!

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

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

Ладно, я шучу. Тут нужно действовать очень аккуратно.

Но иногда такие сбои получаются не по чьему-то умыслу. Тогда получается извлечь интересную информацию. Отвалилась "очень важная" функция, но это обнаружили только через пару недель? Хм. А так ли она была важна.

Нужно обязательно автоматизировать вот этот процесс? А давайте сделаем кнопку, по которой будет уходить запрос в службу поддержки, а там, если такой запрос придёт, руками быстро поправим. Сколько раз нажали на кнопку за месяц? (реальный пример)

У нас числится больше 90 смежных систем, все очень нужны, но неизвестно кому? А давайте на день отключим их (с предупреждением о регламентных работах и контакте, куда обращаться в случае чего), и посмотрим — кто прибежит с просьбой срочно включить? (реальный пример)

Очень действенная техника!

А вы как относитесь к провокациям? Применяете?

PS. У меня есть ощущение, что этой техникой в совершенстве владеют архитекторы и тех.лиды разработки.

Нашел отличный кейс по интеграциям, всем теперь рассказываю: как Netflix перешел c REST на GraphQL.

История вообще мощная, особенно если начать издалека. Вначале у Netlix было API, оно было REST, и оно было одно на всех (как и положено REST API). Потом они выяснили, что у них больше 800 разных типов устройств, на которые они могут стримить (не знаю, откуда столько, видимо, включая утюги и зажигалки). И всем нужно разное. Где-то какие-то функции есть, где-то нет. У кого-то огромный экран, а у кого-то еле влезает кнопка "Play". Кто-то умеет обрабатывать большие древообразные структуры данных, а кому-то только небольшие плоские подходят.

В принципе, они все делают примерно одно и то же, но каждому клиенту нужен немного кастомизированный эндпоинт. И они сделали конструктор API (это 2012, все что-нибудь изобретали).

А потом, в 2015, как приличные люди, они придумали свой вариант переосмысления REST: библиотеку Falcor. Правда, не так далеко ушли, как, например, создатели GraphQL. Больше всего Falcor похож на внутреннее решение по вытаскиванию произвольных данных из одной большой модели. Я такие видел, только не все выползают наружу (многим просто стыдно показывать).

Тут нужно понимать основное назначение Netflix для пользователя: найти и посмотреть фильм. А искать его можно очень по-разному, и из разных точек: то ли с жанра начать, то ли с года, то ли все фильмы определенного режиссера вытащить, то ли те, где играл какой-то актер, или всё это сразу. А ещё есть рекомендации и рейтинги. В общем, всё со всем связано, и потянуть можно за любую ниточку. Получается граф. В Falcor он тоже получается, JSON Graph. Причем со встроенными функциями для работы с ним, это уже остроумно.

В общем, с этим Falcor'ом Netflix жил до 2020 года. Но проблема в том, что архитектурно Falcor — монолит. При том, что внутри вся архитектура давно на микросервисах. И скорость изменений микросервисов стала опережать возможности команды, поддерживающей монолитный API-сервер.

И тут они стали смотреть в сторону GraphQL, потому что там есть federation. Логично: одну монолитную модель данных делим на много частных моделей, за которые отвечает своя команда. А GraphQL всё собирает автомагически.

Переход на GraphQL сначала случился в Netfilx Studio — той части, где идёт производство фильмов и сериалов — одно из крупнейших в мире. А потом уже и для всех клиентов. Причем сначала это была просто прокладка перед старым монолитным API, чтобы перевести клиентов на новую технологию, но принципиально не менять модели. А дальше аккуратно, без даунтайма(!), всех перевели на федеративную структуру.

Так что сейчас у них есть федеративный GraphQL на фронте, в котором удовлетворяются потребности и всех возможных клиентов, и асинхронная эволюция разных сервисов на бэке; gRPC для связи между микросервисами внутри (тоже довольно хитро докрученные), и ещё где-то там Kafka.

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

С некоторым удивлением узнал о существовании бинарного XML: формата EXI (https://www.w3.org/TR/exi/)

То есть, это такой Protobuf/AVRO, но из экосистемы XML. Работает примерно так же: подаете на вход схему XSD и документ XML, получаете на выходе байтовый поток. В принципе, можно схему не подавать, но она позволит лучше упаковать всякие сложные типы вроде даты или перечислений.

Звучит просто. Внутри, как часто бывает с XML, нечеловечески сложные концепции: формальные обучающиеся грамматики, конечные автоматы, нужна ученая степень, чтобы разобраться.

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

Там даже есть специальный заголовок '$'.'E'.'X'.'I'!

По размеру итоговый поток получается в 100 раз меньше, чем XML, и в 14 раз меньше, чем просто заархивированный GZIP'ом XML (в худших случаях — на 60% лучше обычного архиватора). Скорость обработки в среднем в 14.5 выше, чем обычного XML (в лучших случаях — в 250 раз!). Ну и скорость упаковки/распаковки тоже в десятки раз выше — за счет понимания структуры XML.

Первый драфт вышел в 2007, последняя версия спецификации — в 2014, а в 2018 появились странные вещи типа EXI for JSON, который по некоторым замерам тоже жмет лучше, чем альтернативы.

Protobuf вышел в 2008.

Всё это мне напоминает конвергентную эволюцию, когда неродственные виды приобретают схожие черты при обитании в схожих условиях (то есть, решающих одну и ту же задачу). Ну и борьбу за экологическую нишу. Мы знаем, что EXI массово не используется, это место бинарного первого выбора занимает Protobuf. Когда освобождается какая-то ниша, представители каждого класса и отряда предлагают своих кандидатов. Так в Южной Америке роль копытных долго выполняли грызуны, а хищников — сухопутные длинноногие крокодилы и плотоядные нелетающие журавли. Бывают странности в изолированных экосистемах. Конкуренции они обычно не выдерживают, что и видно в случае Protobuf / EXI.

Хотя в отдельных изолятах могут и сейчас использоваться (и EXI применяется!)

А разговоры про переход на JSON каких-нибудь 2009-2010 годов напоминают нынешние разговоры про GraphQL. Ну вы посмотрите на этот JSON! Ведь не пойми что: схемы нет, безопасности нет, стандартного протокола вызова нет, зачем туда идти? (Характерная цитата из обсуждения: 'There are also a range of protocols/standards that are built on top of XML, such as SOAP, XML-Signature, XML-Encryption, WS-Security, SAML, etc. This does not exist for JSON.'). А вот ещё подождем немного, EXI включат в набор инструментов SOAP, и тогда заживем.

Ну реально — мог бы появиться свой gRPC на основе XML. Never happend. Многие виды в изолированных экосистемах не выдерживают конкуренции с более приспособленными.

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

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

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

И вот хорошая статья с заманчивым названием 'Cognition in Software Engineering: A Taxonomy and Survey of a Half-Century of Research' — "Мышление в программной инженерии: таксономия и обзор за полвека исследований", 2022 год.

Они предлагают следующие концепты в области мышления:

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

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

Все эти процессы в приложении к программной инженерии исследуются с 1973, но массово только с 2010. Примерно тогда же кроме памяти, знаний и рассуждений стали исследовать внимание, когнитивные искажения и когнитивную нагрузку.

Любопытно, что, в разбивке по областям SWEBoK, в области Requirements и Design исследуют в основном знания (очевидный предмет), но в индустриальных публикациях исследуют больше рассуждения (что логичнее). К сожалению, именно в этих исследованиях нет никакой физиологической рамки или теории, объясняющей, что вообще в голове происходит.

При этом в целом по требованиям и проектированию больше всего исследований, после Software Construction (никогда не мог понять эту разницу, это типа низкоуровневое проектирование?..)

Любопытная находка исследователей:

Восприятие — менее всего изученная область. А ведь у нас постоянно возникает вопрос — как представить требования или постановки, чтобы не возникло искажение понимания! Что давать: диаграмму, макет интерфейса, формальный текст, историю, что-то близкое к коду, типа OpenAPI? Наука не дает ответа.

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

Тем временем продолжается отбор докладов на осеннюю конференцию Flow. Если задумываетесь о выступлении — завтра в 19:00 по Мск будет встреча с программным комитетом, можно задать вопросы про конференцию, тематики докладов, о чем интересно рассказать и что ПК ищет в заявках. Приходите! (А то уже надоели одни и те же спикеры на всех конференциях, если честно)

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

Очень интересные мысли там оказались, и не устаревают!

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

Ещё есть две растяжки:
1) как мы обходимся со знаниями: заталкиваем их в людей (push) или предоставляем по мере надобности (pull).
2) к чему мы больше стремимся: к кодификации (извлечению из людей и фиксации где-то отдельно: в документах, чек-листах, процессах и коде) или к персонализации (накоплении экспертности в людях).

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

Push и pull можно отличить по отношению к обучению: если вас заранее учат всему на свете, что вам сразу может и не пригодится — это культура push.

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

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

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

Смотрим на API, как программисты.

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

Покажу пример, как может быть устроена логика мышления например при выборе технологий API, если вы смотрите на них с позиции программиста.

Чуть ли не главное понятие в языках программирования — система типов. Всех программистов в университетах мучают понятиями "статическая типизация", "динамическая типизация", "сильная и слабая типизация". Проблемы с типами являются источником большинства ошибок в программах: не учли значение null; складывали числа, а они оказались строками; вышли за пределы массива; думали, что дробная часть отделяется точкой, а в данных была запятая; и т.п. Ну, и все мы сталкивались с превращением всего подряд в дату в Excel.

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

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

Запросы и ответы HTTP API по умолчанию вообще никак не типизированы. Это просто строки.

Соответственно, REST API сам по себе тоже не типизирован. По крайней мере Филдинг ничего про это не писал. Он писал только про media types, на уровне всего ответа целиком, а не отдельных его полей. Это всё в русле JavaScript — динамически-типизируемого и слабо-типизированного языка. Погуглите ради интереса "JavaScript memes" — они все про преобразование типов 😹

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

Поэтому всё, что появилось после REST — было сразу типобезопасно. Собственно, зачем OpenAPI с его схемами? Если генерировать код и клиентов, и сервера из одной спецификации — он будет типобезопасным.

GraphQL — сразу типобезопасный, потому что для него вообще первичная схема, всё остальное из неё генерится.

Protobuf (и gRPC, соответственно) — сразу типобезопасный, для него тоже первичная схема.

Kafka, как и HTTP, по умолчанию вообще не проверяет содержимое сообщения и его формат. Но есть Kafka Schema Registry — хранилище схем сообщений с готовыми клиентами для продюсеров и консьюмеров.

И вот эта типобезопасность может быть для разработчиков хорошим аргументом для перехода на что-то дальше REST (а хотя бы и на OpenAPI с генерацией кода).

Может ли системный аналитик говорить со своей командой на этом уровне?

Я давно подозреваю, что Agile (в частности — малые размеры итераций) имеет математическое обоснование -- из теории вероятностей или теории игр. А также, что развитие роли системного аналитика и применение agile-методик являются двумя разными ответами на одну и ту же проблему — несоответствие функций и свойств поставленного ПО ожиданиям заказчика и пользователей.

И вот одно из подтверждений -- задача о разорении игрока. Формулируется она так: два игрока садятся за стол и играют в стохастическую игру — например, делают ставки и подбрасывают монетки. Как будет развиваться игра в зависимости от начального капитала каждого игрока, размера ставок, стратегии изменения ставки и вероятности выигрыша в конкретном подбрасывании (монета честная, или одна сторона выпадает чаще)?

Почему задача о разорении: доказано, что если игрок повышает ставку после каждого выигрыша, и не понижает её после проигрыша, то он неизбежно разорится. А также, если шансы хоть немного против игрока, а у его противника денег сильно больше (игрок против казино), то игрок с меньшим капиталом тоже рано или поздно разорится (для этого небольшого смещения на рулетке есть 0, а в некоторых ещё 00 и 000 — именно за их счет казино в конечном счете всегда выигрывает ).

Это всё очень напоминает ситуацию, когда небольшая компания по разработке ПО берет регулярные заказы у крупной компании (с бесконечным количеством денег). Ну или наоборот — небольшая компания обращается к системному интегратору с бесконечным количеством денег. Дальше понятно. Если меньшая компания и не разорится, всё равно может сильно пострадать — рано или поздно.

Что тут можно сделать:
1) увеличивать вероятность исхода "в свою пользу". В ИТ-проектах вероятность успешного результата проекта всё-таки не 50/50, а немного выше: 60/40. Тогда вероятность не разориться уже становится около 55%! А при попадании в цель 80/20 — вероятность уже больше 93%!!! Ого. Это путь аналитиков — стараться разобраться в проекте и повысить вероятность его успеха вдвое (кстати, нигде не видел исследований, насколько улучшение качества сбора и анализа требований повышает вероятность успеха проекта).

2) уменьшать размер ставки: не весь проект целиком, а порезанный на небольшие спринты. Уменьшение ставки в одной игре раз в 10 радикально увеличивает количество игр, за которое игрок с большим банком вас переиграет, то есть он просто не будет успевать, и шансы на успех приближаются к 98-99%. Неплохо, да? Это путь agile — вести разработку небольшими частями (снижать размер ставки).

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

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

Срочно в номер! Мы все неправильно понимали, как работают методы HTTP!

Всегда ведь всем говорят, что REST строится вокруг методов HTTP, а они соответствуют операциям CRUD:
POST — это Create,
GET — Read,
PUT — Update,
DELETE — Delete.

Но не всё так просто. Есть документ с объяснением семантики HTTP — RFC 7231, 'HTTP/1.1 Semantics and Content', датируется 2014 годом, за авторством самого Роя Филдинга (и обновлённый в 2022 как RFC 9110)

Там всё написано, из первых уст, так сказать.

Понятнее всего с GET — это действительно запрос получения ресурса.

Создание ресурса — это PUT: 'The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload.'

То есть PUT может и изменять ресурс, и создавать его. Главное — в PUT создается или изменяется ресурс по конкретному адресу (URI). Понятно, что это не сработает, если мы включаем в URI идентификатор, который выдает сервер (его и знать может только сервер). Но мы, например, можем положить через PUT оценку конкретным пользователем товара или статьи: тогда первый PUT создаст оценку, последующие её поменяют, но доступна она всегда будет по одному и тому же URI. В этом примере понятно, почему PUT небезопасный: кроме самой оценки конкретного пользователя ещё поменяется и общая оценка товара (и б-г знает что ещё — может быть, место в поисковой выдаче, а может этот товар попадет на главную, и т.п.).

DELETE — это не совсем удаление. Это скорее отключение ресурса — по этому URI он больше не будет доступен. Что там внутри сервера при этом произойдет — только его дело. Может быть, на самом деле всё удалится. Может быть, пометится как удаленный. Может быть, отправится в архив и появится по новому адресу (поэтому DELETE тоже небезопасная операция). В RFC сказано, что DELETE достаточно редкая операция, и может применяться к ресурсам, созданным при помощи PUT. Могут быть интересные истории, например с ресурсом, указывающим на "последнюю версию статьи". Если сказать ему DELETE — что должно произойти? Вся статья удалиться, или удалиться последняя версия, и на этом же URI должна восстановиться предыдущая версия?.. Возникает неоднозначность семантики.

И самое сложное — POST. Это вовсе не создание ресурса, как мы всегда думали. Это, вообще говоря, просто семантическая дыра: 'The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics.'

То есть, как хотите, так и понимайте. Единственный смысл — мы хотим что-то сказать серверу, вот как. А дальше сервер уже будет решать, в соответствии с "собственной специфической семантикой ресурса". Это может быть:
— передача блока данных для обработки (не факт, что что-то тут создается!);
— создание нового ресурса, у которого ещё нет идентификатора и URI (обратите внимание, URI у ресурса появляется уже позже: мы обращаемся к одному адресу — к сервису, по сути, — чтобы создать ресурс по другому адресу);
— добавление данных к имеющемуся ресурсу (!!!)

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

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

И, конечно, в его диссертации вообще не упоминаются ни POST (там только GET и HEAD из методов упоминаются), ни CRUD.
В отдельном посте на эту темы он так и говорит: вся эта возня с методами просто не важна для обсуждения архитектурного стиля REST, главное — соблюдать единообразие и не делать получение данных через POST (а то кэширование и перезапросы работать не будут).

Так что POST — это операция со смыслом 'this action isn’t worth standardizing', "это действие не стоит стандартизации".

Как видно из поста Филдинга, в нулевые было распространено представление, что "настоящий" REST должен вообще обходиться без POST(!), видимо были сильны ассоциации с SOAP.

А вот в 2014 в связи с CQRS обсуждался "REST без PUT" — ничего менять вообще нельзя, можно только постить новые версии ресурсов. (Там же, кстати, интересное рассуждение про CRUD и грануляцию ресурсов — мол, это создает слишком болтливые API и переносит бизнес-логику на клиентов).

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

Upd.: пока выглядит так, что если вы досконально знаете стандарты и активно пытаетесь им следовать — вы идете против мейнстрима и хотите странного.

Продолжая тему про стратегию: лично мне не удавалось никак влиять на стратегию ни из роли аналитика, ни из роли программиста, ни из роли техлида. Вся стратегия только с C-level начинается.

Или из интересной роли советника. Это самая высокая роль, в которой ещё можно оставаться специалистом и индивидуальным контрибьютором, а не руководителем. Я говорю про советника директора, ну или одного из директоров (я, например, был советником директора по технологиям. В смысле, не советник по технологиям, а директор). Мистическая это должность, загадочная для всех. Чем он занимается — только сам директор и знает. Отчитывается тоже только перед своим директором. Вроде бы ничем формально не управляет, но статус высокий. Хотя может и порулить каким-нибудь временным проектом. В общем — чиновник по особым поручениям.

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

Как туда попадают — не скажу, меня по карьерной лестнице так тащило (причем иногда эту должность под меня делали — подкиньте мысль начальству/HR).

Про стратегию на WAW был отличный доклад Бориса Вольфсона: в принципе, стратегия это набор трёх решений:
— где играем?
— как выигрываем? (за счет чего)
— что не делаем?
и как всё это связано с конкретными проектами.

Поэтому системному и даже бизнес-аналитику до этих вопросов далеко. Вот быть проводником стратегии аналитик может. Особенно последних двух вопросов.

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

Но ещё лет 100 назад всё было не так очевидно.

Вот, например, организационная схема ТЕО — Театрального отдела Наркомпроса, составленная В.Э.Мейерхольдом, возглавлявшим этот отдел в 1920-1921 годах (с сентября по февраль, если быть точным).

В интернете её нет, я сфотографировал её в доме-музее Мейерхольда в Пензе, она там в уголочке скромно висит.

Ну красота же? Это вам не бездушные орг.чарты, это больше похоже на супрематизм Малевича (с которым Мейерхольд сотрудничал).

Подписи разобрать сложно, но справа вверху явно читается "ТЕО 1920-1921", "Отделов и секций". Дальше я немного теряюсь, может быть вы сможете лучше распознать. В центре зеленый треугольник — "Кино"? Под ним — "Те. Прос." и "Те. Обр.", то есть — театральное просвещение и образование? Справа в синем треугольнике — "Всеобуч"? (то есть, тут показаны ещё и смежные программы). Слева красный треугольник — ЦУТ, видимо "Центральное управление театрами"?

Среди мелкого текста можно разобрать "городской", "цирк", "школа", "массовых действий", "нац. меньшинств". ИИ где-то там видит ещё "режиссёрские курсы", "ТЕАТР", "Гостеатр", "Театр драмы", "Кукольный театр", "Мюзик-холл", "учреждения", "гос. труппы", "самодеятельность", "областные театры".

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

Как вам нравится такая визуализация? Использовали бы в своих проектах?

McKinsey опубликовал карту принятия решений агентными ИИ. Точнее — какие решения можно им отдать и какую роль играет человек.

Получилась матрица, для разнообразия не 2x2, как обычно у консалтеров, а аж 3x3 — мир становится сложнее.

Ну хоть координат пока две:
— Риск от последствий неверного решения
— Сложность решения

Соответственно, риски могут быть трёх уровней:
— низкие (либо низка вероятность, либо почти нет урона)
— средние (потеряем много денег или репутацию)
— необратимые (может произойти что-то фатальное: гибель или ранения людей, разорение компаний, отзыв лицензий/запрет деятельности, падение рынков)

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

И дальше смотрим на пересечениях — какую роль играет ИИ, какую человек.

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

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

У нас были безрисковые роботы, про которых точно было известно, что они могут принести прибыль, но не могут сыграть в убыток (в основном за счет времени — если успеют, получат прибыль, если нет — ничего не получат, вот и всё. Риска нет.) Они просто запускались утром и отключались вечером, за ними особо и не следил никто, разве что для улучшения алгоритмов и скорости.

Были роботы с риском — они работали под пристальным наблюдением.

Были операции в миддле и бэке, проходящие автоматически — контроль рисков, формирование обязательств, проводок — человек за ними только следил, но в некоторых случаях брал управление на себя (или сама система передавала управления — что-то здесь я не понимаю, нужно вмешательство человека).

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

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

А теперь всё то же не на рынке есть, а, например, в программировании или управлении продуктом. Ну и в анализе тоже будет.

Что уже сейчас можно отдать агентам?

Или иначе: где обычно находятся решения аналитика? Мне кажется (давайте поспорим!), что аналитик обычно работает в зоне низкого-среднего риска и средней-высокой сложности. С очень редкими попаданиями в зону высокого риска — туда аналитика не всегда пускают; точнее, там он выполняет как раз роль ИИ: makes recommendations, support humans. Это, кстати, и есть направление роста — хотите расти, идите туда, где ваши решения имеют больший риск.

Кстати, ИИ пока (пока!) не может удерживать под контролем долгосрочные дела — например, вести бухгалтерский баланс в течение года. Стратегические решения, от которых зависят будущие ситуации, пока плохо им всем даются. GPT o3, o4-mini и Gemini 2.5 Pro даже первый месяц не смогли корректно закрыть, Grok после 5-го месяца стал расходиться больше чем на 5%, а Claude Sonnet — после 8-го.