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

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

Это тем более удивительно, что изначально — ещё с 60-х — анализ и проектирование систем описывали именно как последовательность ясных шагов, выполняя которые аналитик приходит к модели целевой системы. Вопрос только, с чего мы начинаем. У Дугласа Росса (SADT, IDEF0) всё начинается с функции, её входов и выходов, потом прорабатывается внутренняя последовательность шагов. Информационные системы ведь просто берут входящую информацию (с перфокарт) и преобразуют её в исходящую (ну, так было в 60-70-х). У вас нет юскейса — у вас есть функция, а требования описывают входы, выходы, управление и шаги процесса + скорость работы.

Можно пойти наоборот от данных, как у Тома ДеМарко и Ларри Константина — тогда вашей первой диаграммой будет контекстная, показывающая систему в окружении пользователей и других систем, обменивающихся данными с вашей, а следующими — набор DFD: диаграмм потоков данных, с указанием процессов. Информационная система ведь — набор входящих и исходящих данных, процессы по их обработке (то есть функции, это же время структурного программирования), места и форматы хранения (уже появились базы данных).

К концу 80-х развились графические интерфейсы, и у пользователя появился выбор — что конкретно делать именно сейчас, какую функцию вызвать. В логике OOSE Ивара Якобсона всё начиналось с типов пользователей и юскейсов: а что в принципе пользователь может сделать в системе в любой момент? Потом каждый юскейс раскрываем в виде диаграммы устойчивости (robustness): показываем интерфейсы, управляющую логику и сущности, и какие данные они друг другу передают. Ведь ИТ-система состоит из интерфейсов, логики и объектов данных (впрочем, интерфейсы и логика — это тоже объекты). А как они конкретно хранятся в БД — это уже низкий уровень, ORM с этим разберется.

Новейшие подходы (EDA, Event Sourcing, Event Storming и даже в чем-то REST) говорят, что всё начинается с события. У вас в предметной области есть события, они вызывают срабатывание какого-то обработчика и реакцию системы/пользователя и изменение данных. А события возникают в результате отдачи команд или реакции на предшествующее событие. ИТ-системы ведь навешиваются на шину или брокер, по которой бегают сообщения о событиях — нужно просто их ловить и на них правильно реагировать.

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

Вот даже INCOSE говорит, что мы должны прийти к реализованной системе путем формальных трансформаций потребностей (needs) стейкхолдеров в требования (requirements), потом в спецификации, а потом уже в самую систему.

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

Кстати, в последней версии руководства INCOSE рекомендует начать выявление требований с "концепта жизненного цикла" системы, а перед потребностями ставит "ожидания от мира". Это что-то новенькое, напишу отдельным постом.

Руководство по написанию требований INCOSE версии 4 только на первый взгляд не сильно отличается от предыдущей версии, для которой есть русский перевод. На уровне источников требований есть одно принципиальное различие: теперь главным, самым верхним источником считаются "концепции жизненного цикла". Это новое понятие, в предыдущей версии всё начиналось со стратегии компании, а потом шли интересы стейкхолдеров.

Давайте разбираться. Во-первых, кроме Руководства по написанию требований у INCOSE теперь есть ещё один документ: Needs and Requirements Manual (NRM), выпущенный в 2024 году, то есть совсем свежий. Почему один из них guide, а другой manual, и как это адекватно перевести на русский, непонятно. Видимо, дело в размере — guide всего 140 страниц, а manual — почти 500!

Во-вторых, в мануале есть детальное объяснение всей используемой онтологии. Руководство её только использует.

Всё начинается с Сущности (Entity). Сущность — это то, к чему применяется концепция, потребность или требование. Сущности бывают трех типов:
— физические или программные (системы или части систем),
— процессные (включая сюда модели и рабочие инструкции),
— бизнес или люди (тут могут быть компании, подразделения или роли).

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

Идея решения, короче.

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

На самом деле, это ещё в ГОСТ 34.601—90 написано, но кто ж его читал. И в ГОСТ Р 59793—2021 повторено. Если вас в следующий раз попросят всё "по ГОСТу" делать, вы людям этот самый ГОСТ покажите, там начинается всё не с ТЗ, а с обследования, формирования пользовательских требований и разработки вариантов концепции АС (нескольких!). А ТЗ — это третья по счету стадия, перед ним ещё 2 стадии и 8 этапов работ, на минуточку.

Концепции, из которых проистекают потребности, берутся не любые, а именно концепции жизненного цикла. Правда, не уточняется — ЖЦ чего именно. Судя по этапам — сущности. То есть, как организация собирается управлять, приобретать, проектировать, разрабатывать, строить/программировать, интегрировать, верифицировать, валидировать, передавать, инсталлировать, эксплуатировать, поддерживать, обслуживать и выводить из эксплуатации сущность.

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

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

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

Ещё одна важная деталь: в мануале ясно написано, что первично установленные значения целевых показателей и метрик очень часто не являются осуществимыми, и приходят к каким-то реальным значениям только через несколько итераций анализа и "дозревания", да и то с оговоркой "с приемлемым уровнем риска для этой стадии жизненного цикла"! (Кто вообще оценивает уровень риска?)

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

Вышел очередной Requests for Startups от известнейшего акселератора Y Combinator. Не то чтобы я собирался подавать туда заявку, но я регулярно мониторю их запросы, чтобы понять — что сейчас вообще востребовано и куда рынок смотрит.

Конечно, в последнее время там сплошной ИИ. Конечно, они идут за глобальными событиями — в 2020-21 был биотех и противодействие глобальным эпидемиям, а в 2024 появились военные технологии (ну в смысле — защитные, defence). Climate-tech, в том числе про разные источники энергии и электрические автомобили там вообще чуть ли не в каждом наборе. Биология, здравоохранение, климат, технологии безопасности, роботы и генеративный ИИ для программирования и инженерии.

Весной 2025 все хотели AI-агентов и RPA на новом уровне. Такие агенты, сякие агенты, инструменты для создания AI-агентов, софт для потребления AI-агентами (B2A). Скреппинг, машинно-читаемая информация и API на новом уровне — не для людей, а для ИИ. В общем, понятная история, это мы и без YC знали.

И тут! В запросе на летний набор 2025, внезапно — образование! Чтобы вы понимали, про образование и EdTech Y Combinator в последний раз спрашивал в 2017 году! Ну, может быть помните — бум MOOCов, Coursera, edX, вот это всё. В 2010-2016 был прямо бум. Российские проекты примерно тогда же появились - Нетология, Skyeng.

А потом — как отрезало. В смысле инвестиций. Последний всплеск был в 2020-21, когда был ковид и самоизоляция, а потом на радостях все дружно вышли на биржу. Но революции не случилось. Дизрапта индустрии не произошло. Мы не бросили учиться у живых учителей, школы и университеты не закрываются массово, люди не покупают подписку на обучение в течение всей жизни, как было обещано. Отлично себя чувствует только токсичная зеленая сова Duo (цепляет здорово, кстати — мало чем в жизни я каждый день занимаюсь уже несколько лет — ну вот в канал пишу 😹 ). EdTech уже практически стал ругательным словом, можно найти множество статей с заголовками 'EdTech is dead' на разные лады.

И тут, внезапно, запрос от YC. Аж в двух видах:

1) Персональный AI тьютор. С идеями от "Мемекса" Ванновара Буша (это 1940-е годы) до "Алмазного букваря" Нила Стивенсона. Идеальный ИИ-учитель, который сгенерирует контент специально для вас лично, причем хоть текст, хоть инфографику, хоть видео с озвучкой. Хотели бы такого персонального учителя в кармане, который бы помог вам разобраться в любой теме в любой момент, и с настроенным на вас уровнем погружения?

2) Будущее образования. Опять двадцать пять. Нет, ну 1.5 миллиардов обучающихся в мире — это прямо лакомый рынок! Как-то даже обидно признать, что ничего на нём не меняется — как 100 лет назад учились (а то и 200, и 400), так и сейчас учатся. Ну и, конечно, AI тут сейчас всё поменяет. Они там честно пишут — не знаем, что конкретно "всё" — we're still very early in figuring out what AI can truly achieve here — и как на этом заработать, но должно же уже что-то поменяться в обучении, сколько можно!

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

Если бы было возможно всё, что угодно — каким бы вы видели идеальный способ обучения?

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

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

Технологии интераций — это 7 уровень, прикладной. Там живет REST (HTTP), и чуть выше -- SOAP (хотя он использует HTTP только как транспорт), GraphQL, gRPC.

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

Вопросы симметрии и асимметрии: вы достаточно большие, чтобы диктовать всем клиентам свои стандарты, и клиентам не остается ничего другого, кроме как подстроиться под них? Или вам придется подстраиваться под клиентов?

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

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

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

Два зама сговорились и "дружат" против третьего, чтобы поставить на его место своего человека. Руководитель одного из подразделений хочет отгрызть себе дополнительную зону влияния. Два подразделения бьются за одну область ответственности. Новый зам собирает под себя разрозненные функции, с ним борются люди из старой команды. Группа стейкхолдеров хотят развалить проект и обвинить в этом другую группу. Кто-то хочет получить контроль над важными данными (например, отчетами для руководителя или политиками выделения ресурсов). Это всё примеры политических игр, которые я наблюдал своими глазами. И это игры, которые могут определять согласие или противодействие вопросам развития систем и их интеграции.

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

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

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

А вы принимаете в расчет эти уровни?

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

Аналитик как медиатор. У аналитика много задач, и одна из них — разрешение конфликтов.

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

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

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

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

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

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

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

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

Иногда удивительный эффект возникает, если просто озвучить свои чувства.

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

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

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

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

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

Преподавание в ML – штука непростая

С одной стороны, оно становится всё более техническим: нужно объяснять не только линейную алгебру, но и архитектуру трансформеров, пайплайны, метрики, устройства токенизации и fine-tuning. С другой – важно выстроить образовательную траекторию, создать комфортную среду для студентов и развить критическое мышление.  

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

Таких не очень много, и важно их поддерживать. Я увидел, что Яндекс в этом году фокусирует свою премию ML Prize на преподавателях. Делюсь, потому что это редкий случай, когда преподавательская практика становится объектом внимания в профессиональном сообществе.

Три направления:
  - преподаватели с опытом 3+ лет
  - молодые специалисты (1–3 года)
  - руководители ML-программ.

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

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

Слушайте, я понял, что не показывал вам классный инструмент — радар для определения, подходит ли вам Agile, водопад (Plan-driven) или гибридный подход.

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

Вот: https://suitabilityfilter.com/

Оси оценки:
— Доступ к заказчику (на ежедневной основе)
— Приверженность agile-подходу спонсора проекта
— Доверие команде со стороны заказчика
— Разрешается ли команде принимать решения самостоятельно
— Возможность инкрементальной поставки продукта
— Критичность ошибок в продукте (время, деньги, критичные деньги, жизни людей)
— Вероятность изменения требований (% изменившихся требований за месяц)
— Размер команды
— Опыт членов команды

Сразу понятно, почему конкретно в вашем случае Agile не подходит.

Попробуйте, напишите в комментариях — что у вас получилось? Очень интересно.

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

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

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

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

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

Есть ГОСТ Р 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-й вариант? Или ИИ-трансформирующий аналитик должен делать что-то другое?

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

Может быть вы слышали про падение сервисов 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.

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