Почему бизнес-аналитик – самая лучшая профессия в IT
(или как объяснить магистрантам что такое бизнес-анализ в сравнении с научно-исследовательской и инженерной работой)
Бизнес-аналитик в IT – это не просто посредник между бизнесом и разработкой. Это уникальная, двойственная роль: вы одновременно строгий исследователь и прагматичный инженер. Ваша работа – это созидание, которое приносит реальную, измеримую ценность бизнесу, делая вашу профессию одной из самых влиятельных и востребованных.
Часть 1: БА как исследователь: победа над неопределённостью
Ваша работа начинается с Научного метода. Бизнес всегда действует в условиях хаоса и неопределённости. Вы, как исследователь, должны этот хаос структурировать:
1. Проблематизация и гипотеза: Вы превращаете общую «боль» (например, «медленные продажи») в гипотезу ценности.
o Пример: Не «нужна CRM», а «Если мы внедрим API для автоматизации ввода данных, то время обработки заказов сократится на 30% для B2B-клиентов».
2. Операционализация: Вы делаете идеи измеримыми. Что значит «сократится»? Вы определяете Паспорт метрик: «Время от заказа до подтверждения, измеряется в секундах, источник – логи, агрегация – по неделям». Это обеспечивает валидность (точность) и надёжность (повторяемость) ваших выводов.
3. Дизайн проверки: Вы используете методы, похожие на научные эксперименты. Это триангуляция (интервью + анализ логов) и A/B-тесты или пилоты, чтобы на малом масштабе доказать эффект.
BABOK Guide поддерживает этот научный цикл: от Стратегического анализа (постановка проблемы) до Оценки решения (отчёт с доверительными интервалами). Как исследователь, вы создаёте фундамент для уверенных изменений, снижая риск дорогостоящих ошибок.
Часть 2: БА как инженер: создание нового мира
Несмотря на научные инструменты, БА – это в первую очередь Ведущий Инженер. Вы не только изучаете мир – вы его перестраиваете, создавая системы, которые приносят бизнесу экономический результат:
1. Ответственность за ценность/пользу (Value): Вы несете ответственность за ROI (окупаемость инвестиций) вашего проекта. Вы переводите гипотезы в инженерные требования с чёткими критериями приёмки.
o Пример: Требование: «Система должна обрабатывать 1000 заказов/час с ошибками ≤0,5%». Это не просто функция, это инженерный стандарт качества.
2. Проектирование экономики: Вы считаете, что автоматизация стоит 500 тыс. руб., но сократит затраты на 1 млн в год. Вы определяете целевую экономику проекта и контролируете её в процессе:
o Критерий успеха: «Повысить LTV/CAC≥3 в целевом сегменте».
3. Непрерывная эволюция: Как в DevOps, ваша работа не заканчивается запуском. Вы проектируете метрики в проде, мониторите их и инициируете доработки, если эффект оказался ниже ожидаемого. Это цикл «запуск → наблюдение → улучшение».
Итог: Вы – стратег, исследователь и инженер в одном лице. Вы используете науку для уверенности, а инженерию для создания нового мира: оптимизированных процессов и систем, которые экономят миллионы и делают компанию эффективнее. Ваша профессия – это постоянное созидание и доказательство того, что ваши идеи могут изменить бизнес (и мир) к лучшему, проект за проектом.
(или как объяснить магистрантам что такое бизнес-анализ в сравнении с научно-исследовательской и инженерной работой)
Бизнес-аналитик в IT – это не просто посредник между бизнесом и разработкой. Это уникальная, двойственная роль: вы одновременно строгий исследователь и прагматичный инженер. Ваша работа – это созидание, которое приносит реальную, измеримую ценность бизнесу, делая вашу профессию одной из самых влиятельных и востребованных.
Часть 1: БА как исследователь: победа над неопределённостью
Ваша работа начинается с Научного метода. Бизнес всегда действует в условиях хаоса и неопределённости. Вы, как исследователь, должны этот хаос структурировать:
1. Проблематизация и гипотеза: Вы превращаете общую «боль» (например, «медленные продажи») в гипотезу ценности.
o Пример: Не «нужна CRM», а «Если мы внедрим API для автоматизации ввода данных, то время обработки заказов сократится на 30% для B2B-клиентов».
2. Операционализация: Вы делаете идеи измеримыми. Что значит «сократится»? Вы определяете Паспорт метрик: «Время от заказа до подтверждения, измеряется в секундах, источник – логи, агрегация – по неделям». Это обеспечивает валидность (точность) и надёжность (повторяемость) ваших выводов.
3. Дизайн проверки: Вы используете методы, похожие на научные эксперименты. Это триангуляция (интервью + анализ логов) и A/B-тесты или пилоты, чтобы на малом масштабе доказать эффект.
BABOK Guide поддерживает этот научный цикл: от Стратегического анализа (постановка проблемы) до Оценки решения (отчёт с доверительными интервалами). Как исследователь, вы создаёте фундамент для уверенных изменений, снижая риск дорогостоящих ошибок.
Часть 2: БА как инженер: создание нового мира
Несмотря на научные инструменты, БА – это в первую очередь Ведущий Инженер. Вы не только изучаете мир – вы его перестраиваете, создавая системы, которые приносят бизнесу экономический результат:
1. Ответственность за ценность/пользу (Value): Вы несете ответственность за ROI (окупаемость инвестиций) вашего проекта. Вы переводите гипотезы в инженерные требования с чёткими критериями приёмки.
o Пример: Требование: «Система должна обрабатывать 1000 заказов/час с ошибками ≤0,5%». Это не просто функция, это инженерный стандарт качества.
2. Проектирование экономики: Вы считаете, что автоматизация стоит 500 тыс. руб., но сократит затраты на 1 млн в год. Вы определяете целевую экономику проекта и контролируете её в процессе:
o Критерий успеха: «Повысить LTV/CAC≥3 в целевом сегменте».
3. Непрерывная эволюция: Как в DevOps, ваша работа не заканчивается запуском. Вы проектируете метрики в проде, мониторите их и инициируете доработки, если эффект оказался ниже ожидаемого. Это цикл «запуск → наблюдение → улучшение».
Итог: Вы – стратег, исследователь и инженер в одном лице. Вы используете науку для уверенности, а инженерию для создания нового мира: оптимизированных процессов и систем, которые экономят миллионы и делают компанию эффективнее. Ваша профессия – это постоянное созидание и доказательство того, что ваши идеи могут изменить бизнес (и мир) к лучшему, проект за проектом.
🔥10❤4
Целевая система ИИзации Казахстана – что это и из чего состоит (медитация на тему ИИ-мечтаний партии и правительства)
Что такое “целевая система” и зачем её выделяют
Целевая система – это конечный, целостный продукт или результат, за который в итоге платит потребитель.
Это не промежуточный продукт в цепочках создания, а конечный результат, ценный для многих. У магазина – это может быть продажа, у завода – произведенный продукт, а у отрасли?
И зачем ее определять? Чтобы понимать: что мы создаем/улучшаем. Итак.
Наша целевая система – ИИ экосистема Казахстана: люди, данные, вычисления, модели, приложения, рынки, правила и институты, работающие как согласованный механизм.
Граница системы (что внутри)
• государственные и частные хранилища данных, доступ к ним и качество;
• вычислительная инфраструктура (ЦОДы, облака, GPU кластеры);
• базовые и прикладные модели (включая Kaz LLM), библиотеки, MLOps;
• отраслевые внедрения (госуслуги, ТЭК, АПК, транспорт, образование, здравоохранение, финансы и др.);
• люди и компетенции (школа–вуз–переподготовка);
• регуляторы, нормы и процедуры (закон «Об ИИ», классификация рисков, маркировка контента);
• безопасность, ответственность, аудит (этика, защита прав, кибербезопасность);
• капитал и спрос (госзаказ, корпоративные клиенты, венчур, гранты);
• институты развития и координации (профильное министерство, комитеты, хабы – напр. Alem AI).
Внешняя среда (что снаружи, но влияет)
• глобальные платформы, стандарты и рынки;
• трансграничные потоки данных и талантов;
• международные риски и возможности (санкции, экспорт ИИ услуг, партнёрства).
Входы: инвестиции, данные, таланты, технологии.
Выходы: готовые сервисы и продукты на внутренний и внешний рынки, повышение производительности и качества госуслуг.
Структура: 9 слоёв целевой системы
1. Данные – каталоги, качество, правовые режимы доступа (персданные, критданные, общедоступные наборы).
2. Вычисления – ЦОДы, облака, GPU/CPU/HPC, сетевые каналы.
3. Инструменты и модели – базовые модели, фреймворки, реестры моделей, репозитории.
4. Инжиниринг/МLOps – сбор данных, разметка, обучение, валидация, деплой, мониторинг дрейфа/рисков.
5. Приложения по отраслям – конкретные кейсы и дорожные карты внедрений.
6. Люди и образование – подготовка 1 млн специалистов, профстандарты, сертификация.
7. Нормы и надзор – закон «Об ИИ», классификация по рискам, маркировка ИИ контента, ответственность человека.
8. Безопасность и права – этика, защита прав, честная конкуренция, киберустойчивость.
9. Экономика и институты – спрос/предложение, госпрограммы, гранты/венчур, координация (профильное министерство, хабы, ассоциации).
Ключевые интерфейсы между слоями
• “Данные ↔ Модели”: доступ и лицензии;
• “Модели ↔ Приложения”: требования отраслей и SLO/метрики качества;
• “Приложения ↔ Нормы”: процедуры оценки риска и сертификация;
• “Образование ↔ Рынок”: профильные треки и стажировки;
• “Институты ↔ Все слои”: финансирование, приоритизация, аудит.
Как мерить успех (пример короткого набора метрик)
• доля цифровых сервисов с ИИ функционалом;
• время вывода ИИ кейса “от идеи до эффекта”;
• безопасность/этика: доля решений, прошедших оценку риска;
• экономический эффект: рост производительности и экспорт ИИ услуг;
• язык: покрытие казахского в ИИ сервисах (качество распознавания/генерации);
• кадры: выпуск/переподготовка, трудоустройство.
Как это стыкуется с текущими инициативами
Закон «Об ИИ», Концепция 2024–2029, национальная платформа ИИ, хаб Alem AI, развитие Kaz LLM, новое профильное министерство – это несущие элементы целевой системы. Важна их связность по слоям и интерфейсам, иначе теряется скорость и безопасность внедрения.
Зачем это
Чётко определенная целевая система делает масштаб задач осязаемым: видно, куда вкладываться, как координироваться и на чём держать баланс между быстрым развитием и этичным использованием ИИ.
Что такое “целевая система” и зачем её выделяют
Целевая система – это конечный, целостный продукт или результат, за который в итоге платит потребитель.
Это не промежуточный продукт в цепочках создания, а конечный результат, ценный для многих. У магазина – это может быть продажа, у завода – произведенный продукт, а у отрасли?
И зачем ее определять? Чтобы понимать: что мы создаем/улучшаем. Итак.
Наша целевая система – ИИ экосистема Казахстана: люди, данные, вычисления, модели, приложения, рынки, правила и институты, работающие как согласованный механизм.
Граница системы (что внутри)
• государственные и частные хранилища данных, доступ к ним и качество;
• вычислительная инфраструктура (ЦОДы, облака, GPU кластеры);
• базовые и прикладные модели (включая Kaz LLM), библиотеки, MLOps;
• отраслевые внедрения (госуслуги, ТЭК, АПК, транспорт, образование, здравоохранение, финансы и др.);
• люди и компетенции (школа–вуз–переподготовка);
• регуляторы, нормы и процедуры (закон «Об ИИ», классификация рисков, маркировка контента);
• безопасность, ответственность, аудит (этика, защита прав, кибербезопасность);
• капитал и спрос (госзаказ, корпоративные клиенты, венчур, гранты);
• институты развития и координации (профильное министерство, комитеты, хабы – напр. Alem AI).
Внешняя среда (что снаружи, но влияет)
• глобальные платформы, стандарты и рынки;
• трансграничные потоки данных и талантов;
• международные риски и возможности (санкции, экспорт ИИ услуг, партнёрства).
Входы: инвестиции, данные, таланты, технологии.
Выходы: готовые сервисы и продукты на внутренний и внешний рынки, повышение производительности и качества госуслуг.
Структура: 9 слоёв целевой системы
1. Данные – каталоги, качество, правовые режимы доступа (персданные, критданные, общедоступные наборы).
2. Вычисления – ЦОДы, облака, GPU/CPU/HPC, сетевые каналы.
3. Инструменты и модели – базовые модели, фреймворки, реестры моделей, репозитории.
4. Инжиниринг/МLOps – сбор данных, разметка, обучение, валидация, деплой, мониторинг дрейфа/рисков.
5. Приложения по отраслям – конкретные кейсы и дорожные карты внедрений.
6. Люди и образование – подготовка 1 млн специалистов, профстандарты, сертификация.
7. Нормы и надзор – закон «Об ИИ», классификация по рискам, маркировка ИИ контента, ответственность человека.
8. Безопасность и права – этика, защита прав, честная конкуренция, киберустойчивость.
9. Экономика и институты – спрос/предложение, госпрограммы, гранты/венчур, координация (профильное министерство, хабы, ассоциации).
Ключевые интерфейсы между слоями
• “Данные ↔ Модели”: доступ и лицензии;
• “Модели ↔ Приложения”: требования отраслей и SLO/метрики качества;
• “Приложения ↔ Нормы”: процедуры оценки риска и сертификация;
• “Образование ↔ Рынок”: профильные треки и стажировки;
• “Институты ↔ Все слои”: финансирование, приоритизация, аудит.
Как мерить успех (пример короткого набора метрик)
• доля цифровых сервисов с ИИ функционалом;
• время вывода ИИ кейса “от идеи до эффекта”;
• безопасность/этика: доля решений, прошедших оценку риска;
• экономический эффект: рост производительности и экспорт ИИ услуг;
• язык: покрытие казахского в ИИ сервисах (качество распознавания/генерации);
• кадры: выпуск/переподготовка, трудоустройство.
Как это стыкуется с текущими инициативами
Закон «Об ИИ», Концепция 2024–2029, национальная платформа ИИ, хаб Alem AI, развитие Kaz LLM, новое профильное министерство – это несущие элементы целевой системы. Важна их связность по слоям и интерфейсам, иначе теряется скорость и безопасность внедрения.
Зачем это
Чётко определенная целевая система делает масштаб задач осязаемым: видно, куда вкладываться, как координироваться и на чём держать баланс между быстрым развитием и этичным использованием ИИ.
🔥3
Цифровой кодекс Казахстана - движение к идеальной цифровой бюрократии
В Казахстане готовится к принятию Цифровой кодекс — документ, который должен стать "конституцией" для цифрового пространства страны. Это не просто свод технических правил, а масштабная попытка выстроить идеальную цифровую бюрократию — быструю, прозрачную и полностью контролируемую. Кодекс создаёт чёткую вертикаль, где каждое звено выполняет свою функцию в единой цифровой экосистеме.
Архитектура цифровой власти
Проект кодекса выстраивает четырёхуровневую систему управления цифровой сферой.
* На самом верху — "смыслодержатели", такие как Комиссия при Президенте и специальные экспертные советы. Именно они формируют общую политику и, что самое важное, их заключения напрямую влияют на распределение бюджета на цифровизацию.
* Уровнем ниже — "архитекторы", в лице уполномоченного органа и создаваемого Института развития цифровизации. Их задача — превращать политические цели в конкретные правила: утверждать архитектуру цифрового правительства, разрабатывать стандарты и методики. Они же вводят ключевой показатель — "цифровую зрелость", который становится универсальным мерилом эффективности для госорганов и основанием для их финансирования.
* Далее идут "операторы" — это ключевые элементы инфраструктуры: государственная цифровая платформа, национальные реестры данных, удостоверяющие центры и Единая точка уведомлений, через которую государство будет общаться с гражданами.
* В самом низу — "исполнители": граждане и бизнес, которые действуют по заданным правилам, используя утверждённые инструменты идентификации, аутентификации и цифровой подписи.
В чём суть перемен: от владения к управлению
Ключевое изменение, которое привносит кодекс, — это смещение власти от права собственности к праву управления потоками информации и доступа.
* Данные важнее владения. Кодекс вводит норму, по которой сами по себе цифровые данные не являются объектом гражданских прав. Реальная власть оказывается не у того, кто "владеет" информацией, а у того, кто устанавливает правила доступа к ней, создаёт стандарты и контролирует идентификаторы.
* Контроль над личностью и коммуникацией. Вводя единые публичные идентификаторы (ИИН/БИН), обязательную двухфакторную аутентификацию для значимых действий и централизованную систему уведомлений, государство создаёт мощную вертикаль для управления коммуникацией с гражданами.
* Бюджет как инструмент. Финансирование цифровых проектов теперь напрямую увязывается с заключениями экспертных советов и показателями "цифровой зрелости". Это превращает бюджетные рычаги в мощный инструмент для продвижения нужных стандартов и решений.
Риски идеальной бюрократии
Несмотря на стремление к порядку и эффективности, такой подход несёт в себе и риски.
* Монополия на "архитектуру". Структура, при которой один и тот же орган разрабатывает правила, оценивает их исполнение и влияет на распределение денег, создаёт риск "регуляторного захвата".
* Погоня за показателями. Ключевой индикатор "цифровая зрелость" может стимулировать госорганы гнаться за красивой отчётностью, а не за реальными результатами.
* Власть алгоритмов. Хотя кодекс и предусматривает право человека на пересмотр решения, принятого алгоритмом, без независимого внешнего арбитра этот механизм может оказаться формальностью.
* "Приручение" инноваций. Такие новые формы, как DAO (децентрализованные организации), признаются, но с ограниченной правоспособностью. Фактически для них создаётся регулируемая "песочница", где горизонтальные формы управления не могут угрожать выстроенной вертикали.
В итоге, Цифровой кодекс — это амбициозный проект по созданию управляемого, прозрачного и суверенного цифрового контура. Он переводит механизмы власти на новый технологический уровень. Однако для того, чтобы эта "идеальная бюрократия" работала на благо общества, а не превратилась в самоцель, ей необходимы независимые механизмы контроля, реальное право граждан на офлайн-альтернативу и прозрачность в распределении ресурсов.
Ссылки:
* Проект Цифрового кодекса - https://github.com/Akylbay-Katira/digital-codex
В Казахстане готовится к принятию Цифровой кодекс — документ, который должен стать "конституцией" для цифрового пространства страны. Это не просто свод технических правил, а масштабная попытка выстроить идеальную цифровую бюрократию — быструю, прозрачную и полностью контролируемую. Кодекс создаёт чёткую вертикаль, где каждое звено выполняет свою функцию в единой цифровой экосистеме.
Архитектура цифровой власти
Проект кодекса выстраивает четырёхуровневую систему управления цифровой сферой.
* На самом верху — "смыслодержатели", такие как Комиссия при Президенте и специальные экспертные советы. Именно они формируют общую политику и, что самое важное, их заключения напрямую влияют на распределение бюджета на цифровизацию.
* Уровнем ниже — "архитекторы", в лице уполномоченного органа и создаваемого Института развития цифровизации. Их задача — превращать политические цели в конкретные правила: утверждать архитектуру цифрового правительства, разрабатывать стандарты и методики. Они же вводят ключевой показатель — "цифровую зрелость", который становится универсальным мерилом эффективности для госорганов и основанием для их финансирования.
* Далее идут "операторы" — это ключевые элементы инфраструктуры: государственная цифровая платформа, национальные реестры данных, удостоверяющие центры и Единая точка уведомлений, через которую государство будет общаться с гражданами.
* В самом низу — "исполнители": граждане и бизнес, которые действуют по заданным правилам, используя утверждённые инструменты идентификации, аутентификации и цифровой подписи.
В чём суть перемен: от владения к управлению
Ключевое изменение, которое привносит кодекс, — это смещение власти от права собственности к праву управления потоками информации и доступа.
* Данные важнее владения. Кодекс вводит норму, по которой сами по себе цифровые данные не являются объектом гражданских прав. Реальная власть оказывается не у того, кто "владеет" информацией, а у того, кто устанавливает правила доступа к ней, создаёт стандарты и контролирует идентификаторы.
* Контроль над личностью и коммуникацией. Вводя единые публичные идентификаторы (ИИН/БИН), обязательную двухфакторную аутентификацию для значимых действий и централизованную систему уведомлений, государство создаёт мощную вертикаль для управления коммуникацией с гражданами.
* Бюджет как инструмент. Финансирование цифровых проектов теперь напрямую увязывается с заключениями экспертных советов и показателями "цифровой зрелости". Это превращает бюджетные рычаги в мощный инструмент для продвижения нужных стандартов и решений.
Риски идеальной бюрократии
Несмотря на стремление к порядку и эффективности, такой подход несёт в себе и риски.
* Монополия на "архитектуру". Структура, при которой один и тот же орган разрабатывает правила, оценивает их исполнение и влияет на распределение денег, создаёт риск "регуляторного захвата".
* Погоня за показателями. Ключевой индикатор "цифровая зрелость" может стимулировать госорганы гнаться за красивой отчётностью, а не за реальными результатами.
* Власть алгоритмов. Хотя кодекс и предусматривает право человека на пересмотр решения, принятого алгоритмом, без независимого внешнего арбитра этот механизм может оказаться формальностью.
* "Приручение" инноваций. Такие новые формы, как DAO (децентрализованные организации), признаются, но с ограниченной правоспособностью. Фактически для них создаётся регулируемая "песочница", где горизонтальные формы управления не могут угрожать выстроенной вертикали.
В итоге, Цифровой кодекс — это амбициозный проект по созданию управляемого, прозрачного и суверенного цифрового контура. Он переводит механизмы власти на новый технологический уровень. Однако для того, чтобы эта "идеальная бюрократия" работала на благо общества, а не превратилась в самоцель, ей необходимы независимые механизмы контроля, реальное право граждан на офлайн-альтернативу и прозрачность в распределении ресурсов.
Ссылки:
* Проект Цифрового кодекса - https://github.com/Akylbay-Katira/digital-codex
🔥1
Статус документа и Крис Партридж + конструкционализм
Смотрю одну БД. Таблица Документ, в ней реквизиты документа, там же статус документа, там же дата назначения статуса. Отдельно еще таблица История документа, в которой вперемешку изменения статусов и события.
В чем ошибка? В таблице Документа хранится только срез состояния объекта на определенную дату. Таблица Истории местами избыточна, местами недостаточна. Реконструкция свойств объекта и событий вокруг него может быть проблематична при изменениях бизнес-логики и интеграциях. Но, так делают все (в большинстве систем, которые я видел).
Как правильно с точки зрения BORO? С точки зрения моделирования реального мира в парадигме 4D-подхода относительно документа существуют следующие 4D-объекты:
– Документ — 4D‑индивид с пространственно‑временным экстентом.
– Состояние документа (например, «документ‑как‑утверждённый») — его временная часть. Именно состояние классифицируется типом‑статусом (Approved, Draft и т. п.).
– События — создание/ликвидация документа и события, которые начинают/завершают состояния (изменение статуса).
В реляционной схеме это означает отдельные таблицы для индивидов, состояний, событий, типов и явных отношений‑кортежей (temporalPartOf, classifies, creates/dissolves, happensAt).
Такой дизайн следует реальному миру в BORO‑смысле и упрощает миграции и интероперабельность за счёт устойчивых критериев тождества и полной прослеживаемости изменений.
Если мы делаем 4 (или больше) таблицы вместо двух, то при любых миграциях и изменениях бизнес-логики мы не теряем данные и легко их переносим между системами по одной простой причине: так устроен реальный мир и мапить его описание легче чем фантазии-абстракции проектировщика оторванные от реального мира.
Кстати, в настоящее время Партридж сотоварищи продолжает развивать BORO - методология перестраивается на принципах "конструкционализма" - введено понятие конструктора. На мой взгляд довольно удачное. Авторы возлагают на него много надежд, сравнивают его значение с переходом от римских цифр к арабским в математике. Якобы это обеспечит семантическую интероперабельность. И его уже, якобы, используют на практике для проекта Национального цифрового двойника (National Digital Twin) в Великобритании.
Подробнее о новых веяниях в BORO (конструкционализме) можно прочесть здесь -
Partridge et al., Taking a constructional turn… (FOuST/JOWO, 2024) — кейс‑история «конструкционального поворота» BORO и упоминание NDT/IMF. - https://ceur-ws.org/Vol-3882/foust-7.pdf
Florio & Linnebo, Introduction to Constructional Ontology (FOuST/JOWO, 2024) — что такое конструкторы и как они порождают типы. - https://ceur-ws.org/Vol-3882/foust-5.pdf
BORO as a Foundation to Enterprise Ontology (JIS, 2016) — мета‑выборы BORO: 4D, экстенсионализм. - https://publications.aaahq.org/jis/article-abstract/30/2/83/1074/BORO-as-a-Foundation-to-Enterprise-Ontology
Re‑engineering Data with 4D Ontologies and Graph Databases — практические кортежи: creates/dissolves, temporalPartOf, happensAt. - https://www.borosolutions.net/sites/default/files/ONTO.COM2013%20-%20Re-engineering%20Data%20with%204D%20Ontologies%20and%20Graph%20Databases%20%28Paper%29.pdf
Enterprise Data Modelling… (FOMI/Shell) — критерий тождества по совпадению 4D‑экстента. -https://borosolutions.net/sites/default/files/FOMI2006%20-%20Enterprise%20Data%20Modelling%20-%20Developing%20an%20Ontology-Based%20Framework%20for%20the%20Shell%20Downstream%20Business%20%28paper%29.pdf
#Партридж #BORO #моделированиеданных
Смотрю одну БД. Таблица Документ, в ней реквизиты документа, там же статус документа, там же дата назначения статуса. Отдельно еще таблица История документа, в которой вперемешку изменения статусов и события.
В чем ошибка? В таблице Документа хранится только срез состояния объекта на определенную дату. Таблица Истории местами избыточна, местами недостаточна. Реконструкция свойств объекта и событий вокруг него может быть проблематична при изменениях бизнес-логики и интеграциях. Но, так делают все (в большинстве систем, которые я видел).
Как правильно с точки зрения BORO? С точки зрения моделирования реального мира в парадигме 4D-подхода относительно документа существуют следующие 4D-объекты:
– Документ — 4D‑индивид с пространственно‑временным экстентом.
– Состояние документа (например, «документ‑как‑утверждённый») — его временная часть. Именно состояние классифицируется типом‑статусом (Approved, Draft и т. п.).
– События — создание/ликвидация документа и события, которые начинают/завершают состояния (изменение статуса).
В реляционной схеме это означает отдельные таблицы для индивидов, состояний, событий, типов и явных отношений‑кортежей (temporalPartOf, classifies, creates/dissolves, happensAt).
Такой дизайн следует реальному миру в BORO‑смысле и упрощает миграции и интероперабельность за счёт устойчивых критериев тождества и полной прослеживаемости изменений.
Если мы делаем 4 (или больше) таблицы вместо двух, то при любых миграциях и изменениях бизнес-логики мы не теряем данные и легко их переносим между системами по одной простой причине: так устроен реальный мир и мапить его описание легче чем фантазии-абстракции проектировщика оторванные от реального мира.
Кстати, в настоящее время Партридж сотоварищи продолжает развивать BORO - методология перестраивается на принципах "конструкционализма" - введено понятие конструктора. На мой взгляд довольно удачное. Авторы возлагают на него много надежд, сравнивают его значение с переходом от римских цифр к арабским в математике. Якобы это обеспечит семантическую интероперабельность. И его уже, якобы, используют на практике для проекта Национального цифрового двойника (National Digital Twin) в Великобритании.
Подробнее о новых веяниях в BORO (конструкционализме) можно прочесть здесь -
Partridge et al., Taking a constructional turn… (FOuST/JOWO, 2024) — кейс‑история «конструкционального поворота» BORO и упоминание NDT/IMF. - https://ceur-ws.org/Vol-3882/foust-7.pdf
Florio & Linnebo, Introduction to Constructional Ontology (FOuST/JOWO, 2024) — что такое конструкторы и как они порождают типы. - https://ceur-ws.org/Vol-3882/foust-5.pdf
BORO as a Foundation to Enterprise Ontology (JIS, 2016) — мета‑выборы BORO: 4D, экстенсионализм. - https://publications.aaahq.org/jis/article-abstract/30/2/83/1074/BORO-as-a-Foundation-to-Enterprise-Ontology
Re‑engineering Data with 4D Ontologies and Graph Databases — практические кортежи: creates/dissolves, temporalPartOf, happensAt. - https://www.borosolutions.net/sites/default/files/ONTO.COM2013%20-%20Re-engineering%20Data%20with%204D%20Ontologies%20and%20Graph%20Databases%20%28Paper%29.pdf
Enterprise Data Modelling… (FOMI/Shell) — критерий тождества по совпадению 4D‑экстента. -https://borosolutions.net/sites/default/files/FOMI2006%20-%20Enterprise%20Data%20Modelling%20-%20Developing%20an%20Ontology-Based%20Framework%20for%20the%20Shell%20Downstream%20Business%20%28paper%29.pdf
#Партридж #BORO #моделированиеданных
🔥2
Кратко о технике Root Cause Analysis (BABOK Guide) (1/2)
Зачем это вам
Root Cause Analysis (RCA) — не ритуал. Это способ убрать шум, найти источник проблемы и вернуть контроль. Бизнес платит не за красоту графиков, а за устранённую потерю: падение конверсии, задержку в процессах, отток клиентов, рост дефектов.
Поэтому у аналитика в RCA есть две роли: Следопыт и Инженер. Первый находит след и истинную причину. Второй чинит механизм, чтобы поломка не повторилась.
Два пласта подходов: приёмы и модели
1. Эвристические подходы (Быстрые приёмы)
Они сужают поиск. Они просты, дешевы и часто их вполне достаточно.
• 5 Почему. Классика. Договариваемся останавливаться там, где причина становится управляемой (мы можем на нее повлиять).
• Диаграмма Исикавы (рыбья кость). Раскладываем кандидатов в причины по категориям: Люди, Процесс, Инструменты, Данные, Окружение.
• Анализ изменений. Что изменилось прямо перед падением метрики? Релиз? Маркетинговая кампания? Профиль трафика?
• Pareto 80/20. Находим несколько «толстых» факторов, которые дают 80% проблемы.
• Лента времени инцидента. Минутная хронология: когда началось, где пошла волна, где был «первый дым».
• Premortem. «Представим, что мы провалились. Почему?» — этот приём отлично вытягивает скрытые риски и причины.
2. Моделирующие подходы (системные модели)
Когда простые приёмы не работают, мы строим причинные модели системы.
• Карта причинности (DAG). Рисуем узлы и стрелки. Отличаем причину, следствие и простые корреляции (спутники).
• Эксперименты. A/B, дифф-ин-дифф (Diff-in-Diff), квази-эксперименты.
• Системная динамика. Анализируем потоки, запасы, задержки.
• Теория очередей. Закон Литтла: WIP = Throughput × Cycle Time. Узкое место (bottleneck) видно сразу.
• Вероятностные модели. Байесовский анализ, регрессии, контрфактуальные модели.
Гибриды — наш реальный хлеб. В реальности мы почти всегда используем гибрид: эвристика (например, «Анализ изменений») сужает воронку гипотез, а модель (например, «Эксперимент») подтверждает её и даёт точный рычаг.
Поиск причин — «наука на минималках»
RCA — это, по сути, маленький научный метод:
1. Ясная формулировка разрыва. «Факт: конверсия из корзины в оплату упала с 62% до 54% 14–16 июня».
2. Гипотезы как механизмы. Не «потому что лето», а «ввели 3-D Secure на часть карт → это добавило шаг → выросли отказы платежей».
3. Прогнозы. Если гипотеза верна, то мы должны увидеть скачок отказов именно у карт X, в сегменте Y, сразу после релиза Z.
4. Проверка и попытка опровержения. Ищем контрпримеры, сравниваем с контрольной группой.
5. Результат — не «история», а решение. Какие рычаги двигать и на сколько.
Главные заповеди: Корреляция — не причина. Конфоундеры (смешивающие факторы) — враги. Малые выборки лгут.
Зачем это вам
Root Cause Analysis (RCA) — не ритуал. Это способ убрать шум, найти источник проблемы и вернуть контроль. Бизнес платит не за красоту графиков, а за устранённую потерю: падение конверсии, задержку в процессах, отток клиентов, рост дефектов.
Поэтому у аналитика в RCA есть две роли: Следопыт и Инженер. Первый находит след и истинную причину. Второй чинит механизм, чтобы поломка не повторилась.
Два пласта подходов: приёмы и модели
1. Эвристические подходы (Быстрые приёмы)
Они сужают поиск. Они просты, дешевы и часто их вполне достаточно.
• 5 Почему. Классика. Договариваемся останавливаться там, где причина становится управляемой (мы можем на нее повлиять).
• Диаграмма Исикавы (рыбья кость). Раскладываем кандидатов в причины по категориям: Люди, Процесс, Инструменты, Данные, Окружение.
• Анализ изменений. Что изменилось прямо перед падением метрики? Релиз? Маркетинговая кампания? Профиль трафика?
• Pareto 80/20. Находим несколько «толстых» факторов, которые дают 80% проблемы.
• Лента времени инцидента. Минутная хронология: когда началось, где пошла волна, где был «первый дым».
• Premortem. «Представим, что мы провалились. Почему?» — этот приём отлично вытягивает скрытые риски и причины.
2. Моделирующие подходы (системные модели)
Когда простые приёмы не работают, мы строим причинные модели системы.
• Карта причинности (DAG). Рисуем узлы и стрелки. Отличаем причину, следствие и простые корреляции (спутники).
• Эксперименты. A/B, дифф-ин-дифф (Diff-in-Diff), квази-эксперименты.
• Системная динамика. Анализируем потоки, запасы, задержки.
• Теория очередей. Закон Литтла: WIP = Throughput × Cycle Time. Узкое место (bottleneck) видно сразу.
• Вероятностные модели. Байесовский анализ, регрессии, контрфактуальные модели.
Гибриды — наш реальный хлеб. В реальности мы почти всегда используем гибрид: эвристика (например, «Анализ изменений») сужает воронку гипотез, а модель (например, «Эксперимент») подтверждает её и даёт точный рычаг.
Поиск причин — «наука на минималках»
RCA — это, по сути, маленький научный метод:
1. Ясная формулировка разрыва. «Факт: конверсия из корзины в оплату упала с 62% до 54% 14–16 июня».
2. Гипотезы как механизмы. Не «потому что лето», а «ввели 3-D Secure на часть карт → это добавило шаг → выросли отказы платежей».
3. Прогнозы. Если гипотеза верна, то мы должны увидеть скачок отказов именно у карт X, в сегменте Y, сразу после релиза Z.
4. Проверка и попытка опровержения. Ищем контрпримеры, сравниваем с контрольной группой.
5. Результат — не «история», а решение. Какие рычаги двигать и на сколько.
Главные заповеди: Корреляция — не причина. Конфоундеры (смешивающие факторы) — враги. Малые выборки лгут.
❤3🔥1
Кратко о технике Root Cause Analysis (BABOK Guide) (2/2)
Прагматика: не копайте слишком глубоко
Прагматик живёт дедлайном. Даже учёные после длинной модели кладут на стол две-три «регулирующие ручки», которыми можно управлять результатом. В бизнесе это:
• Для роста: активация, удержание, LTV/CAC.
• Для операций: пропускная способность, время цикла, WIP (незавершённая работа).
• Для поддержки: время первого ответа, доля решённых, повторные обращения.
Модель нужна, чтобы уверенно выбрать эти «ручки» и понять их чувствительность.
Полевая процедура RCA: 9 шагов
1. Опишите разрыв. Метрика, базовый уровень, окно времени, масштаб ущерба.
2. Сегментируйте. Канал, устройство, гео, тариф, версия. Ищем, где удар сильнее.
3. Отметьте изменения. Релизы, кампании, партнёры, правила скоринга, прайс.
4. Составьте карту причинности. Узлы, стрелки, гипотезы. Пометьте доступные рычаги.
5. Приоритизируйте гипотезы. По ожидаемому эффекту × вероятности × стоимость проверки.
6. Поставьте тест. A/B, холд-аут, дифф-ин-дифф, backtest. Опишите, что вас опровергнет.
7. Отличите корень от симптома. Если убрать этот фактор — разрыв пропадёт?
8. Сведите к «2–3 ручкам». Назовите метрики-рычаги, пороги и сценарии действий.
9. Зашейте в процессы. Алёрты, дэшборды, авто-валидации, владелец, ретро.
Антипаттерны, которых стоит избегать
• Объяснение по вкусу команды. Удобно, привычно, но неверно.
• Слишком «умная» модель. Красиво, но хрупко. Не переносится на завтрашний день.
• Опора на средние. Сегменты и когорты говорят правду. Средние — лгут.
• Погоня за редкими событиями (шумом). Шум кажется смыслом, если не смотреть на масштаб.
• Пост-hoc оправдания. Гипотезы надо формулировать до анализа теста, а не после.
Шаблон отчёта RCA на одной странице
• Проблема: что, когда, насколько.
• Бизнес-влияние: деньги/клиенты/сроки.
• Сегменты с наибольшим разрывом: топ-3.
• Гипотезы и их статус: проверено/опровергнуто/в работе.
• Ключевые факты: 3–5 наблюдений, которые всё объясняют.
• Корневая причина: формулировка как механизм.
• Две-три «ручки»: метрики, целевые пороги, ожидаемый эффект.
• План действий: что, кто, когда.
• Защита от повторов: алёрты, тест-гейты, владельцы.
Мораль
Думайте как учёный. Действуйте как инженер. Говорите как менеджер.
• Как учёный — формулируйте проверяемые механизмы и ищите опровержения.
• Как инженер — сводите сложную систему к двум-трём управляемым рычагам.
• Как менеджер — оформляйте решение в простые шаги с владельцами и датами.
Если после вашего RCA у команды есть три вещи — (1) понятный корень, (2) две-три «ручки» с порогами и (3) план на неделю — вы сделали работу. Всё остальное — шум.
Прагматика: не копайте слишком глубоко
Прагматик живёт дедлайном. Даже учёные после длинной модели кладут на стол две-три «регулирующие ручки», которыми можно управлять результатом. В бизнесе это:
• Для роста: активация, удержание, LTV/CAC.
• Для операций: пропускная способность, время цикла, WIP (незавершённая работа).
• Для поддержки: время первого ответа, доля решённых, повторные обращения.
Модель нужна, чтобы уверенно выбрать эти «ручки» и понять их чувствительность.
Полевая процедура RCA: 9 шагов
1. Опишите разрыв. Метрика, базовый уровень, окно времени, масштаб ущерба.
2. Сегментируйте. Канал, устройство, гео, тариф, версия. Ищем, где удар сильнее.
3. Отметьте изменения. Релизы, кампании, партнёры, правила скоринга, прайс.
4. Составьте карту причинности. Узлы, стрелки, гипотезы. Пометьте доступные рычаги.
5. Приоритизируйте гипотезы. По ожидаемому эффекту × вероятности × стоимость проверки.
6. Поставьте тест. A/B, холд-аут, дифф-ин-дифф, backtest. Опишите, что вас опровергнет.
7. Отличите корень от симптома. Если убрать этот фактор — разрыв пропадёт?
8. Сведите к «2–3 ручкам». Назовите метрики-рычаги, пороги и сценарии действий.
9. Зашейте в процессы. Алёрты, дэшборды, авто-валидации, владелец, ретро.
Антипаттерны, которых стоит избегать
• Объяснение по вкусу команды. Удобно, привычно, но неверно.
• Слишком «умная» модель. Красиво, но хрупко. Не переносится на завтрашний день.
• Опора на средние. Сегменты и когорты говорят правду. Средние — лгут.
• Погоня за редкими событиями (шумом). Шум кажется смыслом, если не смотреть на масштаб.
• Пост-hoc оправдания. Гипотезы надо формулировать до анализа теста, а не после.
Шаблон отчёта RCA на одной странице
• Проблема: что, когда, насколько.
• Бизнес-влияние: деньги/клиенты/сроки.
• Сегменты с наибольшим разрывом: топ-3.
• Гипотезы и их статус: проверено/опровергнуто/в работе.
• Ключевые факты: 3–5 наблюдений, которые всё объясняют.
• Корневая причина: формулировка как механизм.
• Две-три «ручки»: метрики, целевые пороги, ожидаемый эффект.
• План действий: что, кто, когда.
• Защита от повторов: алёрты, тест-гейты, владельцы.
Мораль
Думайте как учёный. Действуйте как инженер. Говорите как менеджер.
• Как учёный — формулируйте проверяемые механизмы и ищите опровержения.
• Как инженер — сводите сложную систему к двум-трём управляемым рычагам.
• Как менеджер — оформляйте решение в простые шаги с владельцами и датами.
Если после вашего RCA у команды есть три вещи — (1) понятный корень, (2) две-три «ручки» с порогами и (3) план на неделю — вы сделали работу. Всё остальное — шум.
🔥6❤1
ИИ-решения в Методических рекомендациях по архитектуре e-Gov: некоторые замечания
Прочитал «Методические рекомендации по проектированию и утверждению текущей и целевой ИТ-архитектуры электронного правительства» от МИИЦР. Написал список замечаний, где будут системные проблемы. Пока приведу только касающиеся ИИ-решений:
Этические чек-листы
Текущий вариант. При вводе в эксплуатацию ИИ-решений оценка воздействия выполняется с помощью этических чек-листов, которые каждый орган формирует сам.
Риски. Будут разнобой требований, разноуровневая строгость и несопоставимость между доменами. Со временем это вырастет в регуляторный зоопарк.
Как надо. Общий базовый чек-лист и типовая матрица рисков с отраслевыми надстройками.
Требования по документированию ИИ-решений без учета их важности
Текущий вариант. Внедряете ли вы чат-бот или систему принятия медицинских или социальных решений объем документации или глубина аудита подразумевается одинаковая.
Риски. «Легкие» решения будут перегружены документацией, «тяжелые» - недогружены и более рискованны.
Как надо. Закрепить 3–4 класса воздействия (например, высокий/средний/низкий/минимальный) и связать с ними: объём документации, глубину допродовой оценки, требования к объяснимости, частоту мониторинга, объёмы журналирования и срок хранения.
Модель ИИ как сервис, с мониторингом и сопровождением
Текущий вариант. Написано, что ИИ не должен встраиваться в монолит, должен обязательно мониториться и сопровождаться.
Риски. Реализация требования будет формальной: будет «как-нибудь» мониториться и «как-нибудь» сопровождаться.
Как надо. Необходимо продумать управление следующими сущностями: жизненный цикл модели, релизы, метрики наблюдаемости, мониторинг дрейфа данных и деградации качества, управление инцидентами и др. Т.е. нужен некий эксплуатационный стандарт.
Объяснимость ИИ-решений
Текущий вариант. «ИИ сопровождается описанием его функционирования, обеспечивающим возможность интерпретации и объяснения результатов».
Риски. Разработчики будут делать формальные текстовые описания, что приведёт к снижению качества и к иллюзии прозрачности.
Как надо. Различать где нужно объяснение глобального поведения, а где отдельного предсказания. Различать прозрачные (intrinsic) и приблизительные, сложные для объяснения post-hoc методы. Различать, где черные ящики допустимы, а где нет. Определить критерии оценки объяснимости.
Датасеты для ИИ
Текущий вариант. Данные для обучения и инференса должны быть описаны и каталогизированы.
Риски. Описаны будут «как-нибудь» и «свалены в кучу».
Как надо. Паспорт набора данных: происхождение и лицензия, источник, окно актуальности, репрезентативность и перекосы, правила обновления и архивирования и т.д. и т.п.
Безопасность моделей
Текущий вариант. Недопустимо использование решений, не прошедших проверку на безопасность.
Риски. Безопасность на бумаге: непонятно кто ее проверяет и какие внешние сертификации приемлемы.
Как надо. Добавить требования по цепочкам поставок для моделей/библиотек, лицензиям, анализу уязвимостей, защите от атак, безопасной настройке облачных сред.
Интеграционный зоопарк
Текущий вариант. ИИ подлежат обязательной интеграции в ключевые госсервисы. + Интеграции возможны почти любые (перечислены почти все возможные технологии).
Риски. Продолжится зоопарк протоколов и паттернов.
Как надо. Сделать референс-архитектуру интеграций и политик по умолчанию, центральный реестр API, контрактов, шаблонов и т.д. и т.п.
#AI #ИИ
Прочитал «Методические рекомендации по проектированию и утверждению текущей и целевой ИТ-архитектуры электронного правительства» от МИИЦР. Написал список замечаний, где будут системные проблемы. Пока приведу только касающиеся ИИ-решений:
Этические чек-листы
Текущий вариант. При вводе в эксплуатацию ИИ-решений оценка воздействия выполняется с помощью этических чек-листов, которые каждый орган формирует сам.
Риски. Будут разнобой требований, разноуровневая строгость и несопоставимость между доменами. Со временем это вырастет в регуляторный зоопарк.
Как надо. Общий базовый чек-лист и типовая матрица рисков с отраслевыми надстройками.
Требования по документированию ИИ-решений без учета их важности
Текущий вариант. Внедряете ли вы чат-бот или систему принятия медицинских или социальных решений объем документации или глубина аудита подразумевается одинаковая.
Риски. «Легкие» решения будут перегружены документацией, «тяжелые» - недогружены и более рискованны.
Как надо. Закрепить 3–4 класса воздействия (например, высокий/средний/низкий/минимальный) и связать с ними: объём документации, глубину допродовой оценки, требования к объяснимости, частоту мониторинга, объёмы журналирования и срок хранения.
Модель ИИ как сервис, с мониторингом и сопровождением
Текущий вариант. Написано, что ИИ не должен встраиваться в монолит, должен обязательно мониториться и сопровождаться.
Риски. Реализация требования будет формальной: будет «как-нибудь» мониториться и «как-нибудь» сопровождаться.
Как надо. Необходимо продумать управление следующими сущностями: жизненный цикл модели, релизы, метрики наблюдаемости, мониторинг дрейфа данных и деградации качества, управление инцидентами и др. Т.е. нужен некий эксплуатационный стандарт.
Объяснимость ИИ-решений
Текущий вариант. «ИИ сопровождается описанием его функционирования, обеспечивающим возможность интерпретации и объяснения результатов».
Риски. Разработчики будут делать формальные текстовые описания, что приведёт к снижению качества и к иллюзии прозрачности.
Как надо. Различать где нужно объяснение глобального поведения, а где отдельного предсказания. Различать прозрачные (intrinsic) и приблизительные, сложные для объяснения post-hoc методы. Различать, где черные ящики допустимы, а где нет. Определить критерии оценки объяснимости.
Датасеты для ИИ
Текущий вариант. Данные для обучения и инференса должны быть описаны и каталогизированы.
Риски. Описаны будут «как-нибудь» и «свалены в кучу».
Как надо. Паспорт набора данных: происхождение и лицензия, источник, окно актуальности, репрезентативность и перекосы, правила обновления и архивирования и т.д. и т.п.
Безопасность моделей
Текущий вариант. Недопустимо использование решений, не прошедших проверку на безопасность.
Риски. Безопасность на бумаге: непонятно кто ее проверяет и какие внешние сертификации приемлемы.
Как надо. Добавить требования по цепочкам поставок для моделей/библиотек, лицензиям, анализу уязвимостей, защите от атак, безопасной настройке облачных сред.
Интеграционный зоопарк
Текущий вариант. ИИ подлежат обязательной интеграции в ключевые госсервисы. + Интеграции возможны почти любые (перечислены почти все возможные технологии).
Риски. Продолжится зоопарк протоколов и паттернов.
Как надо. Сделать референс-архитектуру интеграций и политик по умолчанию, центральный реестр API, контрактов, шаблонов и т.д. и т.п.
#AI #ИИ
👍3🔥2💯1
Архитекторы будущего: Свобода, Творчество и Разумность Аналитика
Дорогие коллеги, друзья, аналитики Казахстана! Поздравляю вас со Всемирным днем бизнес-анализа!
Сегодня мы отмечаем не просто профессиональный праздник. Мы отмечаем нашу миссию – быть проводниками осмысленных изменений в мире, который меняется быстрее, чем когда-либо.
Мы – те, кто строит мосты между идеями и реальностью, между хаосом данных и ясностью решений.
Мы не просто профессия, мы – катализатор изменений
Наш главный инструмент – это не BPMN или SQL. Наш главный инструмент – это Свобода.
• Свобода мыслить: Мы должны быть свободны от догмы "мы всегда так делали". Наша работа – не слепо исполнять, а бросать вызов статус-кво.
• Свобода задавать вопросы: Мы имеем право (и обязанность!) задавать самый важный вопрос: "Почему?". Почему мы это делаем? Какую ценность это несет?
Только в этой свободе рождается истинное value, а не просто "реализованные фичи".
Наш второй принцип: Творчество
Бизнес-анализ – это не рутина. Это Творчество.
Мы не просто "собираем требования". Мы проектируем будущее.
Наше творчество – в способности увидеть невидимые связи, найти элегантное решение для сложной проблемы, рассказать историю (storytelling) через данные так, чтобы она вдохновила на действия.
Аналитик сегодня – это художник, который рисует не красками, а процессами, данными и стратегиями.
Наш третий принцип: Разумность
Свобода и творчество должны стоять на прочном фундаменте – Разумности.
Мы – голос логики и прагматизма в любом проекте.
Разумность – это наша ответственность. Это способность отделить "хотелки" от реальных потребностей, приоритизировать то, что действительно важно, и принимать решения, основанные на данных, а не на догадках.
Наша цель – не "запустить проект", а принести измеримую пользу бизнесу.
Наша цель: Непрерывное развитие – Синтез.
Свобода, Творчество и Разумность – это не то, чего можно достичь один раз. Это топливо для непрерывного развития.
Рынок Казахстана, как и весь мир, требует от нас постоянной адаптации. Появляются ИИ, меняются бизнес-модели.
Наше развитие – это не просто новый сертификат. Это ежедневная практика:
• Становиться свободнее в мышлении.
• Быть креативнее в подходах.
• Оставаться разумными в своих решениях.
Как ваш чаптер IIBA, мы здесь, чтобы поддерживать этот огонь развития в каждом из вас.
И мы благодарим всех наших помощников – Ваш Вклад Бесценен
Никогда не забывайте: вы – архитекторы изменений. Ваша работа определяет, каким будет завтрашний день наших компаний и нашей страны.
Развивайтесь непрерывно. Мыслите свободно. Творите смело. Действуйте разумно.
С праздником, казахстанское ВА-сообщество!
#БизнесАнализ #IIBA #Казахстан #Аналитика #Развитие
Дорогие коллеги, друзья, аналитики Казахстана! Поздравляю вас со Всемирным днем бизнес-анализа!
Сегодня мы отмечаем не просто профессиональный праздник. Мы отмечаем нашу миссию – быть проводниками осмысленных изменений в мире, который меняется быстрее, чем когда-либо.
Мы – те, кто строит мосты между идеями и реальностью, между хаосом данных и ясностью решений.
Мы не просто профессия, мы – катализатор изменений
Наш главный инструмент – это не BPMN или SQL. Наш главный инструмент – это Свобода.
• Свобода мыслить: Мы должны быть свободны от догмы "мы всегда так делали". Наша работа – не слепо исполнять, а бросать вызов статус-кво.
• Свобода задавать вопросы: Мы имеем право (и обязанность!) задавать самый важный вопрос: "Почему?". Почему мы это делаем? Какую ценность это несет?
Только в этой свободе рождается истинное value, а не просто "реализованные фичи".
Наш второй принцип: Творчество
Бизнес-анализ – это не рутина. Это Творчество.
Мы не просто "собираем требования". Мы проектируем будущее.
Наше творчество – в способности увидеть невидимые связи, найти элегантное решение для сложной проблемы, рассказать историю (storytelling) через данные так, чтобы она вдохновила на действия.
Аналитик сегодня – это художник, который рисует не красками, а процессами, данными и стратегиями.
Наш третий принцип: Разумность
Свобода и творчество должны стоять на прочном фундаменте – Разумности.
Мы – голос логики и прагматизма в любом проекте.
Разумность – это наша ответственность. Это способность отделить "хотелки" от реальных потребностей, приоритизировать то, что действительно важно, и принимать решения, основанные на данных, а не на догадках.
Наша цель – не "запустить проект", а принести измеримую пользу бизнесу.
Наша цель: Непрерывное развитие – Синтез.
Свобода, Творчество и Разумность – это не то, чего можно достичь один раз. Это топливо для непрерывного развития.
Рынок Казахстана, как и весь мир, требует от нас постоянной адаптации. Появляются ИИ, меняются бизнес-модели.
Наше развитие – это не просто новый сертификат. Это ежедневная практика:
• Становиться свободнее в мышлении.
• Быть креативнее в подходах.
• Оставаться разумными в своих решениях.
Как ваш чаптер IIBA, мы здесь, чтобы поддерживать этот огонь развития в каждом из вас.
И мы благодарим всех наших помощников – Ваш Вклад Бесценен
Никогда не забывайте: вы – архитекторы изменений. Ваша работа определяет, каким будет завтрашний день наших компаний и нашей страны.
Развивайтесь непрерывно. Мыслите свободно. Творите смело. Действуйте разумно.
С праздником, казахстанское ВА-сообщество!
#БизнесАнализ #IIBA #Казахстан #Аналитика #Развитие
🔥6
«Я, как пользователь…» и что с этим не так. «Рабочие истории» Андрея Шапиро как апгрейд User Story
Многие аналитики писали User Stories. Каковы их слабые места? Часто «Я, как пользователь…» на самом деле прикрывает «Я, как бизнес, хочу, чтобы пользователь…», а ценность в «чтобы…» притягивается за уши просто для соблюдения формата .
Но главная боль, как по мне, в другом. В классической User Story нет предметной области. Нет данных, нет сущностей, нет «объектов». Из-за этого получается огромный разрыв между историей и тем, что потом увидят дизайнеры и разработчики.
Андрей Шапиро дал почитать рукопись книги о своем методе «Рабочие истории». ИМХО, это очень удачная попытка всю эту кухню систематизировать и вылечить. Это не просто «еще один шаблон», а целая технология.
Структура и содержание
Книга разделена на две части. Первая часть анализирует эволюцию пользовательских историй как инструмента сбора требований. Андрей делится практическими примерами из реальных проектов, обсуждая шаблоны, преимущества и недостатки user stories. Он подчеркивает их роль в преодолении "вавилонской башни" — языковых барьеров между стейкхолдерами, — но отмечает ограничения: краткость часто приводит к потере контекста, а отсутствие строгой структуры затрудняет работу в сложных доменах.
Новый шаблон «Рабочей истории» (НСДОЦ)
Вторая часть вводит ключевую инновацию — рабочие истории и Карту реализации историй (КРИ). Рабочие истории расширяют шаблон user stories, фиксируя не только роль, функциональность и ценность, но и ситуацию, объекты оперирования, а также каскад реализации (от замысла к форме).
Автор предлагает 5-компонентную структуру:
• Н (Носитель действия)
• С (Ситуация)
• Д (Способ действия)
• О (Объекты оперирования)
• Ц (Цель действия)
И ключевое здесь — «О (Объекты оперирования)». Нас наконец-то заставляют на уровне требования описать, с какими вещами, данными и сущностями работает носитель действия. Это сразу снимает кучу вопросов и заземляет историю.
«Карта реализации историй» (КРИ)
Это тот самый мост от «что» к «как». КРИ — это матрица , где по горизонтали идет процесс (логика следования) , а по вертикали — «каскад реализации». Каждая история раскладывается на:
• Саму Рабочую историю (описание необходимой деятельности) .
• Форму реализации (как именно это будет воплощено, какие технологии, допущения, решения).
• Структуру блоков интерфейса (что конкретно будет на экране, какие инфо-блоки и элементы управления).
В итоге получается мощное развитие техники. Такой подход лечит «проблему молотка» (когда в User Story сразу «пихают» готовое решение, а не потребность). И он помогает четко отделить потребности пользователя от требований бизнеса (для этого есть специальный прием с инверсией Носителя, когда им становится «Система»).
Для аналитиков книга предлагает практический фреймворк для сбора требований в запутанных проектах. Метод помогает структурировать беседы со стейкхолдерами, выявлять пробелы в знаниях и проверять адекватность моделей. Вспомогательные практики — приёмочные тесты, чистка от ложных требований, оценка в сторипоинтах — интегрируются с agile-подходами. Примеры ошибок и рекомендаций по сессиям картирования делают книгу ценным руководством для командной работы. Автор подчеркивает: без практики инструмент не освоить, рекомендуя применять техники на реальных проектах.
В общем, для системных и бизнес-аналитиков — очень советую прочесть книгу, когда она будет опубликована. (А также для продактов, дизайнеров, разработчиков). Это достаточно просто, но куда более строгий и инженерный подход к требованиям, чем то, к чему многие привыкли.
Канал Андрея - https://t.iss.one/how2scheme
Многие аналитики писали User Stories. Каковы их слабые места? Часто «Я, как пользователь…» на самом деле прикрывает «Я, как бизнес, хочу, чтобы пользователь…», а ценность в «чтобы…» притягивается за уши просто для соблюдения формата .
Но главная боль, как по мне, в другом. В классической User Story нет предметной области. Нет данных, нет сущностей, нет «объектов». Из-за этого получается огромный разрыв между историей и тем, что потом увидят дизайнеры и разработчики.
Андрей Шапиро дал почитать рукопись книги о своем методе «Рабочие истории». ИМХО, это очень удачная попытка всю эту кухню систематизировать и вылечить. Это не просто «еще один шаблон», а целая технология.
Структура и содержание
Книга разделена на две части. Первая часть анализирует эволюцию пользовательских историй как инструмента сбора требований. Андрей делится практическими примерами из реальных проектов, обсуждая шаблоны, преимущества и недостатки user stories. Он подчеркивает их роль в преодолении "вавилонской башни" — языковых барьеров между стейкхолдерами, — но отмечает ограничения: краткость часто приводит к потере контекста, а отсутствие строгой структуры затрудняет работу в сложных доменах.
Новый шаблон «Рабочей истории» (НСДОЦ)
Вторая часть вводит ключевую инновацию — рабочие истории и Карту реализации историй (КРИ). Рабочие истории расширяют шаблон user stories, фиксируя не только роль, функциональность и ценность, но и ситуацию, объекты оперирования, а также каскад реализации (от замысла к форме).
Автор предлагает 5-компонентную структуру:
• Н (Носитель действия)
• С (Ситуация)
• Д (Способ действия)
• О (Объекты оперирования)
• Ц (Цель действия)
И ключевое здесь — «О (Объекты оперирования)». Нас наконец-то заставляют на уровне требования описать, с какими вещами, данными и сущностями работает носитель действия. Это сразу снимает кучу вопросов и заземляет историю.
«Карта реализации историй» (КРИ)
Это тот самый мост от «что» к «как». КРИ — это матрица , где по горизонтали идет процесс (логика следования) , а по вертикали — «каскад реализации». Каждая история раскладывается на:
• Саму Рабочую историю (описание необходимой деятельности) .
• Форму реализации (как именно это будет воплощено, какие технологии, допущения, решения).
• Структуру блоков интерфейса (что конкретно будет на экране, какие инфо-блоки и элементы управления).
В итоге получается мощное развитие техники. Такой подход лечит «проблему молотка» (когда в User Story сразу «пихают» готовое решение, а не потребность). И он помогает четко отделить потребности пользователя от требований бизнеса (для этого есть специальный прием с инверсией Носителя, когда им становится «Система»).
Для аналитиков книга предлагает практический фреймворк для сбора требований в запутанных проектах. Метод помогает структурировать беседы со стейкхолдерами, выявлять пробелы в знаниях и проверять адекватность моделей. Вспомогательные практики — приёмочные тесты, чистка от ложных требований, оценка в сторипоинтах — интегрируются с agile-подходами. Примеры ошибок и рекомендаций по сессиям картирования делают книгу ценным руководством для командной работы. Автор подчеркивает: без практики инструмент не освоить, рекомендуя применять техники на реальных проектах.
В общем, для системных и бизнес-аналитиков — очень советую прочесть книгу, когда она будет опубликована. (А также для продактов, дизайнеров, разработчиков). Это достаточно просто, но куда более строгий и инженерный подход к требованиям, чем то, к чему многие привыкли.
Канал Андрея - https://t.iss.one/how2scheme
🔥3❤1
Мы зря учимся пользоваться ИИ, или что будет, если пузырь ИИ лопнет?
Злые люди, не верящие в прогресс, твердят: ИИ-компании переоценены, пузырь вот-вот лопнет, рынок рухнет на сотни миллиардов. Стартапы обанкротятся, доступ к технологиям для обычных пользователей сузится — бесплатные сервисы пропадут, премиум-модели взлетят в цене. Допустим, так и будет. Допустим, шансы на это — выше 80%. Стоит ли тогда тратить время на обучение ИИ? Особенно системному аналитику.
Ответ: стоит. Потому что это не просто инструмент, а катализатор для прокачки себя.
Проблема в подходе
Многие смотрят ИИ как на волшебную палочку: кидаешь запрос — готово. Но если цель поднять эффективность на порядок, то ИИ требует зрелости. Нельзя полагаться на него слепо, нужно строить систему.
Чтобы ИИ генерировал качественные артефакты — от требований до диаграмм, нужно глубоко понимать свои методы и процессы. Без этого будут галлюцинации и пробелы.
Возьмем пример: системный аналитик описывает user story. ИИ может нагенерить вариантов, но чтобы отсечь бред и обеспечить полноту (все edge cases покрыты), в голове должна быть модель связей — как требования влияют на дизайн, тестирование, деплоймент.
Мониторинг на ходу обязателен. ИИ не сам проверит себя – ты должен знать, что такое "хорошо" — соответствие с бизнес-целями, отсутствие противоречий. В итоге ИИ заставляет формализовать то, что раньше было интуитивным.
Скачок в сеньорство
Если джун аналитик начинает проектировать использование ИИ в своей рутине — от автоматизации сбора требований до анализа рисков, — он сразу тянется к задачам сеньора, он вынужден учиться думать системно, как тимлид. И наступает просветление: рождается объемный playbook с типовыми запросами, макросами проверки, шаблонами артефактов, который системно формализует работу аналитика.
Если выстроить все правильно — с четкими постановками, контролем, мониторингом, — производительность растет в разы. Но если ту же методологию применить без ИИ, эффект будет похожим. ИИ — ускоритель, а не замена. Как в программировании: хорошая архитектура хорошо работает и на старом железе, но с новым — летает.
Представьте механика, который осваивает CAD для проектирования. Если он прокачает понимание физики и чертежей, то даже без софта станет лучше. ИИ здесь работает так же: инструментализирует твои навыки, но основа — в тебе.
Морали и совет
Мораль положительная: Те, кто говорит "зря учимся, если отключат", — не познали дзен. Обучение ИИ — не про зависимость от облака, а про внутренний рост. Рынок рухнет — ок, но твоя методология, навык системного мышления останется. Ты не потеряешь, станешь квалифицированнее и умнее.
Мораль отрицательная: На практике многие будут использовать ИИ, чтобы побыстрее «закрыть таску». Если ты не про системное осмысление своей работы и экспоненциальный рост собственной эффективности – забей, ты зря потратил время на чтение.
Остальным совет: учись и внедряй ИИ глубоко и сильно. Даже если мировая жаба отключит нам серверы – ты выиграешь.
#AI #ИИ #бизнесанализ
Злые люди, не верящие в прогресс, твердят: ИИ-компании переоценены, пузырь вот-вот лопнет, рынок рухнет на сотни миллиардов. Стартапы обанкротятся, доступ к технологиям для обычных пользователей сузится — бесплатные сервисы пропадут, премиум-модели взлетят в цене. Допустим, так и будет. Допустим, шансы на это — выше 80%. Стоит ли тогда тратить время на обучение ИИ? Особенно системному аналитику.
Ответ: стоит. Потому что это не просто инструмент, а катализатор для прокачки себя.
Проблема в подходе
Многие смотрят ИИ как на волшебную палочку: кидаешь запрос — готово. Но если цель поднять эффективность на порядок, то ИИ требует зрелости. Нельзя полагаться на него слепо, нужно строить систему.
Чтобы ИИ генерировал качественные артефакты — от требований до диаграмм, нужно глубоко понимать свои методы и процессы. Без этого будут галлюцинации и пробелы.
Возьмем пример: системный аналитик описывает user story. ИИ может нагенерить вариантов, но чтобы отсечь бред и обеспечить полноту (все edge cases покрыты), в голове должна быть модель связей — как требования влияют на дизайн, тестирование, деплоймент.
Мониторинг на ходу обязателен. ИИ не сам проверит себя – ты должен знать, что такое "хорошо" — соответствие с бизнес-целями, отсутствие противоречий. В итоге ИИ заставляет формализовать то, что раньше было интуитивным.
Скачок в сеньорство
Если джун аналитик начинает проектировать использование ИИ в своей рутине — от автоматизации сбора требований до анализа рисков, — он сразу тянется к задачам сеньора, он вынужден учиться думать системно, как тимлид. И наступает просветление: рождается объемный playbook с типовыми запросами, макросами проверки, шаблонами артефактов, который системно формализует работу аналитика.
Если выстроить все правильно — с четкими постановками, контролем, мониторингом, — производительность растет в разы. Но если ту же методологию применить без ИИ, эффект будет похожим. ИИ — ускоритель, а не замена. Как в программировании: хорошая архитектура хорошо работает и на старом железе, но с новым — летает.
Представьте механика, который осваивает CAD для проектирования. Если он прокачает понимание физики и чертежей, то даже без софта станет лучше. ИИ здесь работает так же: инструментализирует твои навыки, но основа — в тебе.
Морали и совет
Мораль положительная: Те, кто говорит "зря учимся, если отключат", — не познали дзен. Обучение ИИ — не про зависимость от облака, а про внутренний рост. Рынок рухнет — ок, но твоя методология, навык системного мышления останется. Ты не потеряешь, станешь квалифицированнее и умнее.
Мораль отрицательная: На практике многие будут использовать ИИ, чтобы побыстрее «закрыть таску». Если ты не про системное осмысление своей работы и экспоненциальный рост собственной эффективности – забей, ты зря потратил время на чтение.
Остальным совет: учись и внедряй ИИ глубоко и сильно. Даже если мировая жаба отключит нам серверы – ты выиграешь.
#AI #ИИ #бизнесанализ
👍8❤2🔥1💯1
ИИ-зрелость системного аналитика и команды разработки ПО
Последнюю неделю делал курс Введение в ИИ для системных аналитиков. Как побочный продукт появились два артефакта: Матрица компетенций СА в ИИ, Матрица ИИ-зрелости команды разработки ПО. Матрицы большие. Кратко:
Команды
Команды оцениваем по областям:
- Стратегия и управление
- Промпт-инжиниринг
- Качество и контроль
- Безопасность
- Документирование
- Интеграция в процессы
- Инструменты
- Культура и обучение
Уровни зрелости обычные:
- 0 Отсутствие
- 1 Начальный
- 2 Управляемый
- 3 Определенный
- 4 Управляемый количественно
- 5 Оптимизирующий
Насколько я могу судить большинство команд/компаний сейчас на первом уровне. Возможно кто-то на на втором, но я лично не сталкивался.
Итого:
УРОВЕНЬ 0 — ОТСУТСТВИЕ
Стратегия и управление: Нет стратегии
Промпт-инжиниринг: Не используется
Качество и контроль: Не проверяется
Безопасность: Не учитывается
Документирование: Не документируется
Интеграция в процессы: Не интегрировано
Инструменты: Нет доступа
Культура и обучение: Нет культуры
УРОВЕНЬ 1 — НАЧАЛЬНЫЙ
Стратегия и управление: Энтузиасты
Промпт-инжиниринг: Интуитивно
Качество и контроль: Нерегулярно
Безопасность: Базовое понимание
Документирование: Хаотично
Интеграция в процессы: Личное использование
Инструменты: Бесплатные личные
Культура и обучение: Энтузиасты
УРОВЕНЬ 2 — УПРАВЛЯЕМЫЙ
Стратегия и управление: Базовые договоренности
Промпт-инжиниринг: Базовые техники
Качество и контроль: Критичное проверяется
Безопасность: Простые правила
Документирование: Общее место
Интеграция в процессы: В отдельных активностях
Инструменты: Основные согласованы
Культура и обучение: Открытость
УРОВЕНЬ 3 — ОПРЕДЕЛЕННЫЙ
Стратегия и управление: Документированная стратегия
Промпт-инжиниринг: Библиотека промптов
Качество и контроль: Чек-листы, метрики
Безопасность: Политика, аудит
Документирование: Структурированный плейбук
Интеграция в процессы: Во всех процессах
Инструменты: Корпоративные, интеграции
Культура и обучение: Систематическое обучение
УРОВЕНЬ 4 — УПРАВЛЯЕМЫЙ КОЛИЧЕСТВЕННО
Стратегия и управление: Data-driven стратегия
Промпт-инжиниринг: Оптимизация на данных
Качество и контроль: Автоматизация проверок
Безопасность: Автоматизация, метрики
Документирование: Метрики использования
Интеграция в процессы: Оптимизация процессов
Инструменты: Оптимизация, автоматизация
Культура и обучение: Измерение компетенций
УРОВЕНЬ 5 — ОПТИМИЗИРУЮЩИЙ
Стратегия и управление: Проактивные инновации
Промпт-инжиниринг: Собственные фреймворки
Качество и контроль: Предиктивная система
Безопасность: Проактивная защита
Документирование: Интеллектуальная система
Интеграция в процессы: Новые методологии
Инструменты: Собственные инструменты
Культура и обучение: Источник инноваций
Аналитики
Компетенций аналитиков у меня получилось 18:
1.1 Базовые техники промптинга
1.2 Работа с контекстом
1.3 Управление форматом
2.1 Выявление ошибок
2.2 Критическое мышление
2.3 Итеративное улучшение
3.1 Чувствительные данные
3.2 Этика и регуляции
4.1 Журналы работы
4.2 Измерение эффективности
4.3 Плейбук
5.1 Методологии разработки
5.2 Инструменты и платформы
5.3 Коммуникация
6.1 Извлечение требований
6.2 Моделирование
6.3 Документирование
6.4 Тестирование
Предполагаю, что в ближайшее время на собеседованиях кандидатов будут спрашивать о навыках использования ИИ, особенно в компаниях выше начального ИИ-уровня зрелости.
Кому нужен ментор: зарегистрироваться на курс Введение в ИИ для системных аналитиков можно по ссылке - https://antitreningi.ru/lbokdimx
Доступ к первому модулю бесплатный. К остальным модулям в течение периода публикации (курс еще местами дорабатывается) доступ можно получить по подписке на платформу (стоимость месячной подписке - стоимость чашки кофе с пирожком). Потом (возможно) будет дороже.
Последнюю неделю делал курс Введение в ИИ для системных аналитиков. Как побочный продукт появились два артефакта: Матрица компетенций СА в ИИ, Матрица ИИ-зрелости команды разработки ПО. Матрицы большие. Кратко:
Команды
Команды оцениваем по областям:
- Стратегия и управление
- Промпт-инжиниринг
- Качество и контроль
- Безопасность
- Документирование
- Интеграция в процессы
- Инструменты
- Культура и обучение
Уровни зрелости обычные:
- 0 Отсутствие
- 1 Начальный
- 2 Управляемый
- 3 Определенный
- 4 Управляемый количественно
- 5 Оптимизирующий
Насколько я могу судить большинство команд/компаний сейчас на первом уровне. Возможно кто-то на на втором, но я лично не сталкивался.
Итого:
УРОВЕНЬ 0 — ОТСУТСТВИЕ
Стратегия и управление: Нет стратегии
Промпт-инжиниринг: Не используется
Качество и контроль: Не проверяется
Безопасность: Не учитывается
Документирование: Не документируется
Интеграция в процессы: Не интегрировано
Инструменты: Нет доступа
Культура и обучение: Нет культуры
УРОВЕНЬ 1 — НАЧАЛЬНЫЙ
Стратегия и управление: Энтузиасты
Промпт-инжиниринг: Интуитивно
Качество и контроль: Нерегулярно
Безопасность: Базовое понимание
Документирование: Хаотично
Интеграция в процессы: Личное использование
Инструменты: Бесплатные личные
Культура и обучение: Энтузиасты
УРОВЕНЬ 2 — УПРАВЛЯЕМЫЙ
Стратегия и управление: Базовые договоренности
Промпт-инжиниринг: Базовые техники
Качество и контроль: Критичное проверяется
Безопасность: Простые правила
Документирование: Общее место
Интеграция в процессы: В отдельных активностях
Инструменты: Основные согласованы
Культура и обучение: Открытость
УРОВЕНЬ 3 — ОПРЕДЕЛЕННЫЙ
Стратегия и управление: Документированная стратегия
Промпт-инжиниринг: Библиотека промптов
Качество и контроль: Чек-листы, метрики
Безопасность: Политика, аудит
Документирование: Структурированный плейбук
Интеграция в процессы: Во всех процессах
Инструменты: Корпоративные, интеграции
Культура и обучение: Систематическое обучение
УРОВЕНЬ 4 — УПРАВЛЯЕМЫЙ КОЛИЧЕСТВЕННО
Стратегия и управление: Data-driven стратегия
Промпт-инжиниринг: Оптимизация на данных
Качество и контроль: Автоматизация проверок
Безопасность: Автоматизация, метрики
Документирование: Метрики использования
Интеграция в процессы: Оптимизация процессов
Инструменты: Оптимизация, автоматизация
Культура и обучение: Измерение компетенций
УРОВЕНЬ 5 — ОПТИМИЗИРУЮЩИЙ
Стратегия и управление: Проактивные инновации
Промпт-инжиниринг: Собственные фреймворки
Качество и контроль: Предиктивная система
Безопасность: Проактивная защита
Документирование: Интеллектуальная система
Интеграция в процессы: Новые методологии
Инструменты: Собственные инструменты
Культура и обучение: Источник инноваций
Аналитики
Компетенций аналитиков у меня получилось 18:
1.1 Базовые техники промптинга
1.2 Работа с контекстом
1.3 Управление форматом
2.1 Выявление ошибок
2.2 Критическое мышление
2.3 Итеративное улучшение
3.1 Чувствительные данные
3.2 Этика и регуляции
4.1 Журналы работы
4.2 Измерение эффективности
4.3 Плейбук
5.1 Методологии разработки
5.2 Инструменты и платформы
5.3 Коммуникация
6.1 Извлечение требований
6.2 Моделирование
6.3 Документирование
6.4 Тестирование
Предполагаю, что в ближайшее время на собеседованиях кандидатов будут спрашивать о навыках использования ИИ, особенно в компаниях выше начального ИИ-уровня зрелости.
Кому нужен ментор: зарегистрироваться на курс Введение в ИИ для системных аналитиков можно по ссылке - https://antitreningi.ru/lbokdimx
Доступ к первому модулю бесплатный. К остальным модулям в течение периода публикации (курс еще местами дорабатывается) доступ можно получить по подписке на платформу (стоимость месячной подписке - стоимость чашки кофе с пирожком). Потом (возможно) будет дороже.
❤2👍1🔥1
Реабилитация после ИИ-травматизации
Как подсадить айтишников на использование ИИ в работе я уже подумал: завершается публикация курса «ИИ для системных аналитиков» – подписалось около 70 человек, многие активно учатся. Теперь нужно подумать о программах мыслительной гигиены и реабилитации при слабоумии, приобретенном вследствие активного использования ИИ.
Что это может быть?
Реабилитация в запущенных случаях (прогрессирующее слабоумие на фоне иллюзорного профессионализма, вследствие ИИ-травматизации)
Для реабилитации можно создавать «Когнитивные ЛТП (лечебно-трудовые профилактории)» с ограничением свободы и системой процедур:
• Цифровой детокс.
• Пешие прогулки.
• Чтение бумажных книг с обсуждением, пересказыванием, конспектированием прочитанного.
• Написание сочинений, обмен сочинениями между пациентами и взаимный анализ с рецензированием.
• Физический труд, огород, уборка территории.
Мыслительная профилактика и гигиена при использовании ИИ (допустима в начальной стадии развития ИИ-слабоумия)
• Любой текст сначала пишется только из головы. Пустой экран не должен пугать. ИИ подключать на позднем этапе, только для оформления. (Предварительный поиск информации, тестирование гипотез и т.д. – это другое, понимать надо – сейчас речь о написании текста по итогам приобретенных знаний).
• Во время встреч, интервью, обучения обязательно делать записи ручкой (или заметками в компе), выделяя суть. Диктофон не запрещен, потом можно обработать, но в процессе тоже думать нужно, анализировать и обобщать на ходу.
• Борьба с эффектом Гугла (ничего не запоминать, зная где найти) – метод Фейнмана: всё прочитанное сразу повторять закрыв текст (или делать заметки).
• Периодически создавать рабочие артефакты по памяти, не подглядывая в справочник по синтаксису (json, sql, код и т.д.).
• Создавать рабочие артефакты сначала вручную, только потом подключая ИИ в качестве критика. По итогам предложений от ИИ не копипастить результат, а вписывать изменения вручную.
• Пытаться обесценить результаты, предложенные ИИ – «уничтожить» их критикой.
• В конце дня вспоминать список сделанного из головы, не подглядывая в записи, чаты, почту.
• Правило 30 минут: при возникшей проблеме не сразу заглядывать в ИИ – думать 30 минут самостоятельно.
• Читать время от времени длинные тексты самостоятельно, без «сделай конспект».
В целом можно сказать, что в массе с людьми получится как обычно при революционных новациях: («это было уже в веках бывших прежде нас) в результате победы ИИ-нежити умные и целеустремленные станут продуктивнее и умнее, а ленивые… штош, все люди хороши, где-нибудь место всем найдется…
Подсесть на профессиональное использования ИИ (бесплатно учиться на первом модуле учебного курса «ИИ для системных аналитиков») можно здесь - https://antitreningi.ru/lbokdimx
Как подсадить айтишников на использование ИИ в работе я уже подумал: завершается публикация курса «ИИ для системных аналитиков» – подписалось около 70 человек, многие активно учатся. Теперь нужно подумать о программах мыслительной гигиены и реабилитации при слабоумии, приобретенном вследствие активного использования ИИ.
Что это может быть?
Реабилитация в запущенных случаях (прогрессирующее слабоумие на фоне иллюзорного профессионализма, вследствие ИИ-травматизации)
Для реабилитации можно создавать «Когнитивные ЛТП (лечебно-трудовые профилактории)» с ограничением свободы и системой процедур:
• Цифровой детокс.
• Пешие прогулки.
• Чтение бумажных книг с обсуждением, пересказыванием, конспектированием прочитанного.
• Написание сочинений, обмен сочинениями между пациентами и взаимный анализ с рецензированием.
• Физический труд, огород, уборка территории.
Мыслительная профилактика и гигиена при использовании ИИ (допустима в начальной стадии развития ИИ-слабоумия)
• Любой текст сначала пишется только из головы. Пустой экран не должен пугать. ИИ подключать на позднем этапе, только для оформления. (Предварительный поиск информации, тестирование гипотез и т.д. – это другое, понимать надо – сейчас речь о написании текста по итогам приобретенных знаний).
• Во время встреч, интервью, обучения обязательно делать записи ручкой (или заметками в компе), выделяя суть. Диктофон не запрещен, потом можно обработать, но в процессе тоже думать нужно, анализировать и обобщать на ходу.
• Борьба с эффектом Гугла (ничего не запоминать, зная где найти) – метод Фейнмана: всё прочитанное сразу повторять закрыв текст (или делать заметки).
• Периодически создавать рабочие артефакты по памяти, не подглядывая в справочник по синтаксису (json, sql, код и т.д.).
• Создавать рабочие артефакты сначала вручную, только потом подключая ИИ в качестве критика. По итогам предложений от ИИ не копипастить результат, а вписывать изменения вручную.
• Пытаться обесценить результаты, предложенные ИИ – «уничтожить» их критикой.
• В конце дня вспоминать список сделанного из головы, не подглядывая в записи, чаты, почту.
• Правило 30 минут: при возникшей проблеме не сразу заглядывать в ИИ – думать 30 минут самостоятельно.
• Читать время от времени длинные тексты самостоятельно, без «сделай конспект».
В целом можно сказать, что в массе с людьми получится как обычно при революционных новациях: («это было уже в веках бывших прежде нас) в результате победы ИИ-нежити умные и целеустремленные станут продуктивнее и умнее, а ленивые… штош, все люди хороши, где-нибудь место всем найдется…
Подсесть на профессиональное использования ИИ (бесплатно учиться на первом модуле учебного курса «ИИ для системных аналитиков») можно здесь - https://antitreningi.ru/lbokdimx
😁5🔥2😱1
Макиавелли и Цифровой кодекс Республики Казахстан (1/2)
Сегодня президент подписал Цифровой Кодекс. Макиавелли прочитал его, восхитился и добавил в свой трактат новые строки. Восхищаемся властной мудростью вместе:
1. Сделай их существование зависимым от твоей воли (О цифровой идентичности)
«Мудрый Государь должен сделать так, чтобы граждане не могли ни купить, ни продать, ни шагу ступить без его позволения. Но делать это нужно не мечом, а удобством».
Совет: Приучи подданных к тому, что их физическое тело ничего не значит без «цифровой записи». Внуши им, что цифровая идентичность - это благо. Когда человек поймет, что без биометрической аутентификации и регистрации в базе мобильных граждан он не получит ни хлеба, ни зрелищ, он сам принесет тебе свою свободу в обмен на доступ к веб-порталу «цифрового правительства». Тот, кого нет в Национальном регистре, не существует - и это лучшая форма изгнания, не требующая стражи.
2. Оставь «грязную работу» бездушным механизмам (Об автоматизации)
«Государь должен избегать ненависти. Карательные меры должны исполняться другими, а милости - раздаваться лично тобой».
Совет: Используй полностью автоматизированные решения и смарт-контракты для взыскания долгов, штрафов и ограничений прав. Если наказывает чиновник - его ненавидят. Если наказывает алгоритм - люди винят «технический сбой» или свою невнимательность. Пусть алгоритмическая система будет твоим палачом: она беспощадна, неподкупна и, главное, на нее невозможно направить народный гнев. Ты же оставайся тем, кто дарует «цифровые свободы» и «доступность».
3. Знай о них всё, но скрывай свои намерения (О цифровых событиях)
«Надо быть лисой, чтобы разглядеть западню, и львом, чтобы сокрушить волков. Информация - это глаза лисы».
Совет: Твой Кодекс гениален тем, что вводит понятие «цифрового события». Каждое действие подданного должно оставлять след. Пусть они думают, что цифровое пространство гражданина создано для их удобства. На деле же это твоя летопись их грехов. Собирай эти данные в единую транспортную среду и храни в центрах обработки данных. Тот, кто владеет архивом событий, владеет будущим. Но помни: твои собственные секреты должны храниться в специальных удостоверяющих центрах под защитой органов безопасности, куда нет доступа черни.
4. Централизуй власть, уничтожая посредников (Об Операторе)
«Всякое разделение власти ослабляет Государя. Нужен один верный слуга, держащий ключи».
Совет: Не полагайся на множество мелких чиновников, они вороваты и глупы. Создай единого Оператора «цифрового правительства». Пусть он один контролирует рубильник, шлюзы и платформы. Это позволит тебе управлять огромной страной, дергая за одну ниточку. Монополия Оператора на инфраструктуру - это то же самое что контроль над мостами и переправами, только гораздо эффективнее.
Сегодня президент подписал Цифровой Кодекс. Макиавелли прочитал его, восхитился и добавил в свой трактат новые строки. Восхищаемся властной мудростью вместе:
1. Сделай их существование зависимым от твоей воли (О цифровой идентичности)
«Мудрый Государь должен сделать так, чтобы граждане не могли ни купить, ни продать, ни шагу ступить без его позволения. Но делать это нужно не мечом, а удобством».
Совет: Приучи подданных к тому, что их физическое тело ничего не значит без «цифровой записи». Внуши им, что цифровая идентичность - это благо. Когда человек поймет, что без биометрической аутентификации и регистрации в базе мобильных граждан он не получит ни хлеба, ни зрелищ, он сам принесет тебе свою свободу в обмен на доступ к веб-порталу «цифрового правительства». Тот, кого нет в Национальном регистре, не существует - и это лучшая форма изгнания, не требующая стражи.
2. Оставь «грязную работу» бездушным механизмам (Об автоматизации)
«Государь должен избегать ненависти. Карательные меры должны исполняться другими, а милости - раздаваться лично тобой».
Совет: Используй полностью автоматизированные решения и смарт-контракты для взыскания долгов, штрафов и ограничений прав. Если наказывает чиновник - его ненавидят. Если наказывает алгоритм - люди винят «технический сбой» или свою невнимательность. Пусть алгоритмическая система будет твоим палачом: она беспощадна, неподкупна и, главное, на нее невозможно направить народный гнев. Ты же оставайся тем, кто дарует «цифровые свободы» и «доступность».
3. Знай о них всё, но скрывай свои намерения (О цифровых событиях)
«Надо быть лисой, чтобы разглядеть западню, и львом, чтобы сокрушить волков. Информация - это глаза лисы».
Совет: Твой Кодекс гениален тем, что вводит понятие «цифрового события». Каждое действие подданного должно оставлять след. Пусть они думают, что цифровое пространство гражданина создано для их удобства. На деле же это твоя летопись их грехов. Собирай эти данные в единую транспортную среду и храни в центрах обработки данных. Тот, кто владеет архивом событий, владеет будущим. Но помни: твои собственные секреты должны храниться в специальных удостоверяющих центрах под защитой органов безопасности, куда нет доступа черни.
4. Централизуй власть, уничтожая посредников (Об Операторе)
«Всякое разделение власти ослабляет Государя. Нужен один верный слуга, держащий ключи».
Совет: Не полагайся на множество мелких чиновников, они вороваты и глупы. Создай единого Оператора «цифрового правительства». Пусть он один контролирует рубильник, шлюзы и платформы. Это позволит тебе управлять огромной страной, дергая за одну ниточку. Монополия Оператора на инфраструктуру - это то же самое что контроль над мостами и переправами, только гораздо эффективнее.
👍5🔥5👏3🤔2❤1💯1
Макиавелли и Цифровой кодекс Республики Казахстан (2/2)
5. Создай иллюзию прозрачности (Об открытых данных)
«Люди судят по внешности, ибо увидеть внешность дано всем, а потрогать руками - немногим».
Совет: Громко провозгласи принципы «открытого правительства» и «свободы обращения цифровых данных». Отдай толпе открытые данные - статистику урожаев или расписание карет. Пусть они играют в демократию. Но реальные рычаги - критически важные цифровые объекты и ключи шифрования - держи в тайном месте. Истинная власть должна быть невидимой, как код, который управляет реальностью, но скрыт за красивым интерфейсом.
6. Сделай безопасность оправданием всего (О кибербезопасности)
«Страх - это самое надежное чувство».
Совет: Любое ограничение свобод оправдывай кибербезопасностью и защитой от угроз. Люди охотно позволят тебе читать их переписку и отслеживать транзакции через платежный шлюз, если ты убедишь их, что это спасает их от «цифровых мошенников». Провозгласи безопасность человека и общества высшей целью , и под этим флагом ты сможешь отключить любой неугодный цифровой ресурс.
7. Спрячь свою волю в «Черный ящик» (Об Искусственном Интеллекте)
«Толпа верит в магию и боится неведомого. Сделай так, чтобы твои самые жестокие решения казались волей высшего разума, непостижимого для смертного, а не прихотью правителя».
Совет: Твой Кодекс содержит великолепную норму: он позволяет принимать «полностью автоматизированные решения» без участия человека. Это твой щит. Когда нужно повысить налоги, отказать в пособии или ограничить права - пусть это сделает Искусственный Интеллект. Хитрость: Подданные будут требовать объяснений, но Кодекс мудро разрешает тебе давать им лишь «объяснение ключевых факторов», «без раскрытия алгоритмов и исходного кода».
Итог: Ты создаешь идеального «козла отпущения». Если народ возмутится, ты скажешь: «Это сложная математика, она объективна, я здесь ни при чем». Ты правишь, но твои руки чисты, а механизм твоей власти скрыт в «черном ящике», ключ от которого есть только у тебя.
Вердикт: «Этот Кодекс - совершенное оружие. Он позволяет управлять массой, не прикасаясь к ней. Он создает клетку, которую узники строят сами, наполняя ее своими данными. Подпиши его немедленно, Государь».
5. Создай иллюзию прозрачности (Об открытых данных)
«Люди судят по внешности, ибо увидеть внешность дано всем, а потрогать руками - немногим».
Совет: Громко провозгласи принципы «открытого правительства» и «свободы обращения цифровых данных». Отдай толпе открытые данные - статистику урожаев или расписание карет. Пусть они играют в демократию. Но реальные рычаги - критически важные цифровые объекты и ключи шифрования - держи в тайном месте. Истинная власть должна быть невидимой, как код, который управляет реальностью, но скрыт за красивым интерфейсом.
6. Сделай безопасность оправданием всего (О кибербезопасности)
«Страх - это самое надежное чувство».
Совет: Любое ограничение свобод оправдывай кибербезопасностью и защитой от угроз. Люди охотно позволят тебе читать их переписку и отслеживать транзакции через платежный шлюз, если ты убедишь их, что это спасает их от «цифровых мошенников». Провозгласи безопасность человека и общества высшей целью , и под этим флагом ты сможешь отключить любой неугодный цифровой ресурс.
7. Спрячь свою волю в «Черный ящик» (Об Искусственном Интеллекте)
«Толпа верит в магию и боится неведомого. Сделай так, чтобы твои самые жестокие решения казались волей высшего разума, непостижимого для смертного, а не прихотью правителя».
Совет: Твой Кодекс содержит великолепную норму: он позволяет принимать «полностью автоматизированные решения» без участия человека. Это твой щит. Когда нужно повысить налоги, отказать в пособии или ограничить права - пусть это сделает Искусственный Интеллект. Хитрость: Подданные будут требовать объяснений, но Кодекс мудро разрешает тебе давать им лишь «объяснение ключевых факторов», «без раскрытия алгоритмов и исходного кода».
Итог: Ты создаешь идеального «козла отпущения». Если народ возмутится, ты скажешь: «Это сложная математика, она объективна, я здесь ни при чем». Ты правишь, но твои руки чисты, а механизм твоей власти скрыт в «черном ящике», ключ от которого есть только у тебя.
Вердикт: «Этот Кодекс - совершенное оружие. Он позволяет управлять массой, не прикасаясь к ней. Он создает клетку, которую узники строят сами, наполняя ее своими данными. Подпиши его немедленно, Государь».
👍6🔥3👏2🤔1
Детектор ИИ-самообмана: про одну метрику
Вокруг шум: «сократил время на ТЗ в 5 раз», «генерирую user stories за минуту». Вы тоже пробуете: кидаете задачу в ИИ, получаете простыню текста, а потом час её вычитываете, правите галлюцинации и переписываете стиль.
В сухом остатке непонятно: это реально было быстрее? Или вы просто модно потратили время, создав иллюзию бурной деятельности?
Проблема в том, что ощущения могут обманывать. Нужна метрика.
Edit Ratio: Коэффициент «работы уборщиком»
Есть инструмент, который помогает оценить правильно — Edit Ratio. Это доля времени, которую вы тратите на исправление того, что надумала машина.
Формула простая, но показательная:
Edit Ratio = T_edit / (T_prompt + T_review + T_edit)
Где:
T_prompt — время на формулировку задачи (думаем головой).
T_review — время на анализ ответа, проверку фактов (думаем головой).
T_edit — время на переписывание, удаление, форматирование (работаем руками/уборщиком).
Как учитывать
Главное не сваливать всё в кучу. Прочитал ответ — «редактирую». Подумал — «редактирую». Это неверно. Если вы долго читаете и сверяете факты (T_review) — это нормально, это когнитивная нагрузка, контроль качества. А вот если вы долго правите текст (T_edit) — значит, промпт был мусорный, либо задача не для ИИ.
Как читать цифры (диагностика, а не приговор):
0.0–0.2 — Отличный результат. Вы Архитектор, ИИ — стажер.
0.2–0.4 — Рабочая зона, экономия есть.
> 0.6 — Стоп. Вы превратились в корректора бреда. Вы обслуживаете алгоритм, вместо того чтобы использовать его.
Холодный душ: Baseline
Но Edit Ratio — это только половина правды. Он показывает качество процесса, но не экономическую выгоду. Можно иметь идеальный Edit Ratio (почти не правил), но потратить на промпт 2 часа. А руками написал бы за 40 минут. Или наоборот Edit Ratio почти 1, но без ИИ задача вообще не решаемая. Или почти не решаемая. Или решаемая, но с высокими трудозатратами.
Поэтому для отрезвления нужен Baseline — время выполнения задачи «по старинке». Time Saved = (T_manual − T_ai) / T_manual
Если показатель отрицательный — поздравляю, вы стали жертвой хайпа. ИИ на этой задаче вас тормозит. Неприятно, но лучше узнать это сейчас, чем годами имитировать прогресс.
Резюме
Рынок давит: «не освоил ИИ — устарел». Но «освоил» — это не про то, как быстро вы генерируете текст. Это про то, умеете ли вы доказать (себе и заказчику), что этот текст сэкономил ресурсы, а не просто сожрал их на этапе вычитки.
Цифры переводят разговор из «мне кажется, ИИ помогает» в плоскость инженерного подхода.
Про эту и другие метрики, и про многое другое о профессиональном использовании ИИ в работе аналитика можно узнать на нашем онлайн-курсе. Бесплатная регистрация на первый модуль здесь -https://antitreningi.ru/lbokdimx
Вокруг шум: «сократил время на ТЗ в 5 раз», «генерирую user stories за минуту». Вы тоже пробуете: кидаете задачу в ИИ, получаете простыню текста, а потом час её вычитываете, правите галлюцинации и переписываете стиль.
В сухом остатке непонятно: это реально было быстрее? Или вы просто модно потратили время, создав иллюзию бурной деятельности?
Проблема в том, что ощущения могут обманывать. Нужна метрика.
Edit Ratio: Коэффициент «работы уборщиком»
Есть инструмент, который помогает оценить правильно — Edit Ratio. Это доля времени, которую вы тратите на исправление того, что надумала машина.
Формула простая, но показательная:
Edit Ratio = T_edit / (T_prompt + T_review + T_edit)
Где:
T_prompt — время на формулировку задачи (думаем головой).
T_review — время на анализ ответа, проверку фактов (думаем головой).
T_edit — время на переписывание, удаление, форматирование (работаем руками/уборщиком).
Как учитывать
Главное не сваливать всё в кучу. Прочитал ответ — «редактирую». Подумал — «редактирую». Это неверно. Если вы долго читаете и сверяете факты (T_review) — это нормально, это когнитивная нагрузка, контроль качества. А вот если вы долго правите текст (T_edit) — значит, промпт был мусорный, либо задача не для ИИ.
Как читать цифры (диагностика, а не приговор):
0.0–0.2 — Отличный результат. Вы Архитектор, ИИ — стажер.
0.2–0.4 — Рабочая зона, экономия есть.
> 0.6 — Стоп. Вы превратились в корректора бреда. Вы обслуживаете алгоритм, вместо того чтобы использовать его.
Холодный душ: Baseline
Но Edit Ratio — это только половина правды. Он показывает качество процесса, но не экономическую выгоду. Можно иметь идеальный Edit Ratio (почти не правил), но потратить на промпт 2 часа. А руками написал бы за 40 минут. Или наоборот Edit Ratio почти 1, но без ИИ задача вообще не решаемая. Или почти не решаемая. Или решаемая, но с высокими трудозатратами.
Поэтому для отрезвления нужен Baseline — время выполнения задачи «по старинке». Time Saved = (T_manual − T_ai) / T_manual
Если показатель отрицательный — поздравляю, вы стали жертвой хайпа. ИИ на этой задаче вас тормозит. Неприятно, но лучше узнать это сейчас, чем годами имитировать прогресс.
Резюме
Рынок давит: «не освоил ИИ — устарел». Но «освоил» — это не про то, как быстро вы генерируете текст. Это про то, умеете ли вы доказать (себе и заказчику), что этот текст сэкономил ресурсы, а не просто сожрал их на этапе вычитки.
Цифры переводят разговор из «мне кажется, ИИ помогает» в плоскость инженерного подхода.
Про эту и другие метрики, и про многое другое о профессиональном использовании ИИ в работе аналитика можно узнать на нашем онлайн-курсе. Бесплатная регистрация на первый модуль здесь -https://antitreningi.ru/lbokdimx
👍4🔥2
Системный анализ — для отстающих?
Ой ли? Давайте разбираться.
Перечитал курс по системной инженерии от Анатолия Левенчука. Там есть раздел «Смерть инженерии требований». Не метафора - буквально так называется. Разбираемся, почему так думает автор.
Тезисы:
1. Классическая схема: заказчик говорит, аналитик записывает, разработчик делает. Три звена - три искажения. Это называют «испорченный телефон». Термин мягкий. По сути - системная потеря информации на каждом шаге.
2. Требования устаревают на второй день. Поправки к ним - на третий. А на четвёртый заказчик говорит: «Давай попробуем по-другому, вдруг лучше будет». Статичный документ в мире непрерывных изменений - артефакт ушедшей эпохи.
3. Современная инженерия отказалась от требований в пользу гипотез. Не «система должна» (долженствование), а «мы думаем, что нужно вот это» (гипотеза). Разница принципиальная. Гипотезу проверяют, требование исполняют.
4. Вместо документа требований - тесты. Тест нельзя понять двусмысленно. Он или проходит, или нет. Исполнимое описание поведения вместо текста, который каждый читает по-своему.
5. Вместо «аналитик собирает требования» - команда понимает предметную область. Разработчики сами ходят на интервью, сами смотрят метрики, сами задают вопросы. Не потому что любопытные - потому что так меньше потерь.
6. Классический системный анализ - методология из эпохи водопада. Один раз подумали, записали, передали на исполнение. Работало, когда проекты длились годами и требования менялись редко. Сейчас так не работает почти нигде.
7. Эмпирический аргумент. Компании с современными методами выигрывают у компаний с классическими. Левенчук приводит пример ракетостроения: SpaceX с agile-процессами против традиционных подрядчиков NASA. Результаты несопоставимы.
Наблюдения:
Продуктовые команды во многих технологических компаниях работают без аналитиков уже сейчас. Не потому что экономят - потому что быстрее.
Корпорации с ГОСТами и водопадом нанимают аналитиков. Но там и разработка идёт в три раза дольше, и результат хуже.
Джуны идут сразу в product management, минуя позицию аналитика. Рынок голосует ногами.
Почему «для отстающих»:
Не потому что аналитики глупые. Потому что методология отстала. Кто учится "по классике" в 2025 - учится решать проблемы 2005 года. Инструменты изменились, процессы изменились, скорость изменилась. Учебники - нет.
Это не приговор людям. Это приговор конкретной конфигурации работы: собрать - записать - передать - проверить соответствие. Функции никуда не денутся, но выполнять их будут иначе. Системный анализ в классическом понимании - это методология для контекстов, которых становится меньше. Кто застрял в парадигме «я собираю требования и пишу ТЗ» - рискует обнаружить, что его работа может стать мало кому нужна в компаниях-лидерах. Не потому что профессия умерла. Потому что ушла вперёд, а ты остался.
Куда бежать? Выход есть! 😄 Прикладной методолог (почти бизнес-аналитик), хорошо знающий предметную область - остаётся нужен. Проектировщик (архитектор) и технолог (программист) - нужны. Чтобы остаться востребованным в передовых областях системным аналитикам нужно двигаться либо в предметную область, либо глубже в software-архитектуру и разработку.
А можно и не бежать: нас и тут неплохо кормят! - Да, в госсекторе (а у нас это большая часть ИТ-рынка), где годовые бюджеты и ГОСТы, - такие явления как требования и ТЗ никуда не денутся ещё долго-долго. Поэтому «не спешите нас хоронить...», изучаем и практикуем системный анализ дальше...
Ссылка на главу пособия - https://aisystant.system-school.ru/lk/#/course/systems-engineering/2025-05-27T1549/68362
Ой ли? Давайте разбираться.
Перечитал курс по системной инженерии от Анатолия Левенчука. Там есть раздел «Смерть инженерии требований». Не метафора - буквально так называется. Разбираемся, почему так думает автор.
Тезисы:
1. Классическая схема: заказчик говорит, аналитик записывает, разработчик делает. Три звена - три искажения. Это называют «испорченный телефон». Термин мягкий. По сути - системная потеря информации на каждом шаге.
2. Требования устаревают на второй день. Поправки к ним - на третий. А на четвёртый заказчик говорит: «Давай попробуем по-другому, вдруг лучше будет». Статичный документ в мире непрерывных изменений - артефакт ушедшей эпохи.
3. Современная инженерия отказалась от требований в пользу гипотез. Не «система должна» (долженствование), а «мы думаем, что нужно вот это» (гипотеза). Разница принципиальная. Гипотезу проверяют, требование исполняют.
4. Вместо документа требований - тесты. Тест нельзя понять двусмысленно. Он или проходит, или нет. Исполнимое описание поведения вместо текста, который каждый читает по-своему.
5. Вместо «аналитик собирает требования» - команда понимает предметную область. Разработчики сами ходят на интервью, сами смотрят метрики, сами задают вопросы. Не потому что любопытные - потому что так меньше потерь.
6. Классический системный анализ - методология из эпохи водопада. Один раз подумали, записали, передали на исполнение. Работало, когда проекты длились годами и требования менялись редко. Сейчас так не работает почти нигде.
7. Эмпирический аргумент. Компании с современными методами выигрывают у компаний с классическими. Левенчук приводит пример ракетостроения: SpaceX с agile-процессами против традиционных подрядчиков NASA. Результаты несопоставимы.
Наблюдения:
Продуктовые команды во многих технологических компаниях работают без аналитиков уже сейчас. Не потому что экономят - потому что быстрее.
Корпорации с ГОСТами и водопадом нанимают аналитиков. Но там и разработка идёт в три раза дольше, и результат хуже.
Джуны идут сразу в product management, минуя позицию аналитика. Рынок голосует ногами.
Почему «для отстающих»:
Не потому что аналитики глупые. Потому что методология отстала. Кто учится "по классике" в 2025 - учится решать проблемы 2005 года. Инструменты изменились, процессы изменились, скорость изменилась. Учебники - нет.
Это не приговор людям. Это приговор конкретной конфигурации работы: собрать - записать - передать - проверить соответствие. Функции никуда не денутся, но выполнять их будут иначе. Системный анализ в классическом понимании - это методология для контекстов, которых становится меньше. Кто застрял в парадигме «я собираю требования и пишу ТЗ» - рискует обнаружить, что его работа может стать мало кому нужна в компаниях-лидерах. Не потому что профессия умерла. Потому что ушла вперёд, а ты остался.
Куда бежать? Выход есть! 😄 Прикладной методолог (почти бизнес-аналитик), хорошо знающий предметную область - остаётся нужен. Проектировщик (архитектор) и технолог (программист) - нужны. Чтобы остаться востребованным в передовых областях системным аналитикам нужно двигаться либо в предметную область, либо глубже в software-архитектуру и разработку.
А можно и не бежать: нас и тут неплохо кормят! - Да, в госсекторе (а у нас это большая часть ИТ-рынка), где годовые бюджеты и ГОСТы, - такие явления как требования и ТЗ никуда не денутся ещё долго-долго. Поэтому «не спешите нас хоронить...», изучаем и практикуем системный анализ дальше...
Ссылка на главу пособия - https://aisystant.system-school.ru/lk/#/course/systems-engineering/2025-05-27T1549/68362
👍5🤔2❤1
Про Великого инквизитора бизнес-анализа
Если инженеров массово научить задавать вопросы "зачем это всё?", "может вам нужно что-то другое?" это сломает обычный порядок вещей и приведёт к хаосу. Система государственного управления и корпоративные пирамиды рухнут, как карточные домики, потому что вдруг выяснится, что 90% проектов и важных государственных функций - это просто способ занять людей, а не решить проблему.
Нет, пусть остаётся как есть: пусть инженеры молча кодят то, что им велят, а менеджеры и госслужащие продолжают изобретать велосипеды с квадратными колесами.
Если посмотреть на "ограниченность кругозора" и "неэффективность системы" через призму системной архитектуры, то можно понять, что это не баг, а фича. Это несущая конструкция. В государственном управлении, крупных корпорациях, да и в частном бизнесе, как правило, главной целью является не "результат" (прибыль или продукт), а стабильность системы.
Если 90% людей перестанут изобретать квадратные колеса и пойдут домой, потому что работа сделана, рухнет социальный контракт. Люди получают зарплату не за результат, а за лояльность и за то, что они тратят свое время (жизнь) в отведенном месте. Это форма жертвоприношения системе.
Вопрос "Зачем?" разрушает эту магию. Он показывает, что король голый.
Вчера я разбирал проблему "Я" у Фихте. «Я» есть чистое Действие (Tathandlung). Так вот, по Фихте, для бюрократической сущности (отдела, министерства, компании), существование доказывается только через бурную деятельность.
Если отдел не генерирует отчеты, не проводит совещания и не заказывает ИТ-системы, он не существует в онтологическом смысле. "Квадратное колесо" - это идеальный объект: оно не катится, поэтому его нужно постоянно толкать (бюджетировать, модернизировать, создавать комитеты по улучшению качения). Это вечный двигатель бюрократии. Круглое колесо покатилось бы и исчезло из поля зрения, оставив чиновников и руководителей наедине с экзистенциальной пустотой.
"Просветленный" же бизнес-аналитик - это как Великий инквизитор Достоевского. Он знает Истину (что всё это - симулякр), но понимает, что "пастве" (джунам, менеджерам, пользователям) эта истина не нужна. Им нужен хлеб (зарплата) и чудо (вера в то, что они делают Важное Дело).
Поэтому массово учить инженеров задавать вопрос "Зачем?" - это акт терроризма против устоявшегося порядка.
Но.. иногда Великому инквизитору нужен нет, не "аналитик"-исполнитель, а соучастник, человек, который:
- Понимает бессмысленность 90% движений.
- Но умеет вычленить те 10%, которые реально нужны, чтобы лаборатория работала, а люди получали анализы крови.
- И умеет "упаковать" это эффективное ядро в ту самую оболочку "корпоративного бреда" (технического задания), чтобы система это приняла и оплатила.
И он знает: глубокому пониманию не надо учить всех. Хаос нам не нужен, ипотеки сами себя не выплатят. Но найти одного вменяемого, который подмигнет на собеседовании и скажет: "Я понимаю, что мы тут строим Вавилонскую башню, но давайте хотя бы кирпичи класть ровно, чтобы никого не придавило" - это бесценно.
В поисках такого, если такой понадобился, приходится на собеседованиях отсеивать "счастливых идиотов" и искать "умных циников". С последними работать приятнее и можно менять реальность в нужном направлении.
Пояснение: Вчера в чате аналитиков обсуждали вопрос: почему сложно найти аналитика, который задаёт вопрос "зачем"? По мотивам обсуждения родился и родился текст. (Только не поймите меня правильно - это шутка... отчасти...)
Если инженеров массово научить задавать вопросы "зачем это всё?", "может вам нужно что-то другое?" это сломает обычный порядок вещей и приведёт к хаосу. Система государственного управления и корпоративные пирамиды рухнут, как карточные домики, потому что вдруг выяснится, что 90% проектов и важных государственных функций - это просто способ занять людей, а не решить проблему.
Нет, пусть остаётся как есть: пусть инженеры молча кодят то, что им велят, а менеджеры и госслужащие продолжают изобретать велосипеды с квадратными колесами.
Если посмотреть на "ограниченность кругозора" и "неэффективность системы" через призму системной архитектуры, то можно понять, что это не баг, а фича. Это несущая конструкция. В государственном управлении, крупных корпорациях, да и в частном бизнесе, как правило, главной целью является не "результат" (прибыль или продукт), а стабильность системы.
Если 90% людей перестанут изобретать квадратные колеса и пойдут домой, потому что работа сделана, рухнет социальный контракт. Люди получают зарплату не за результат, а за лояльность и за то, что они тратят свое время (жизнь) в отведенном месте. Это форма жертвоприношения системе.
Вопрос "Зачем?" разрушает эту магию. Он показывает, что король голый.
Вчера я разбирал проблему "Я" у Фихте. «Я» есть чистое Действие (Tathandlung). Так вот, по Фихте, для бюрократической сущности (отдела, министерства, компании), существование доказывается только через бурную деятельность.
Если отдел не генерирует отчеты, не проводит совещания и не заказывает ИТ-системы, он не существует в онтологическом смысле. "Квадратное колесо" - это идеальный объект: оно не катится, поэтому его нужно постоянно толкать (бюджетировать, модернизировать, создавать комитеты по улучшению качения). Это вечный двигатель бюрократии. Круглое колесо покатилось бы и исчезло из поля зрения, оставив чиновников и руководителей наедине с экзистенциальной пустотой.
"Просветленный" же бизнес-аналитик - это как Великий инквизитор Достоевского. Он знает Истину (что всё это - симулякр), но понимает, что "пастве" (джунам, менеджерам, пользователям) эта истина не нужна. Им нужен хлеб (зарплата) и чудо (вера в то, что они делают Важное Дело).
Поэтому массово учить инженеров задавать вопрос "Зачем?" - это акт терроризма против устоявшегося порядка.
Но.. иногда Великому инквизитору нужен нет, не "аналитик"-исполнитель, а соучастник, человек, который:
- Понимает бессмысленность 90% движений.
- Но умеет вычленить те 10%, которые реально нужны, чтобы лаборатория работала, а люди получали анализы крови.
- И умеет "упаковать" это эффективное ядро в ту самую оболочку "корпоративного бреда" (технического задания), чтобы система это приняла и оплатила.
И он знает: глубокому пониманию не надо учить всех. Хаос нам не нужен, ипотеки сами себя не выплатят. Но найти одного вменяемого, который подмигнет на собеседовании и скажет: "Я понимаю, что мы тут строим Вавилонскую башню, но давайте хотя бы кирпичи класть ровно, чтобы никого не придавило" - это бесценно.
В поисках такого, если такой понадобился, приходится на собеседованиях отсеивать "счастливых идиотов" и искать "умных циников". С последними работать приятнее и можно менять реальность в нужном направлении.
Пояснение: Вчера в чате аналитиков обсуждали вопрос: почему сложно найти аналитика, который задаёт вопрос "зачем"? По мотивам обсуждения родился и родился текст. (Только не поймите меня правильно - это шутка... отчасти...)
👍7🔥3❤1😁1💯1
Влияние ИИ на количество и качество системных аналитиков
Смотрю стэнфордскую статью Джонса о влиянии ИИ на будущее экономики. Про экономику «в целом» читайте статью сами (ссылка в конце), а я оценю в контексте статьи влияние на будущее системных аналитиков. (Анализ основан только на продолжении текущих трендов, поэтому сильно меня не ругайте, понятно, что мир сложнее).
Вводные
1. Доля "умственных" профессий в экономике – 30-40%.
2. ИИ может повысить производительность труда в них не более чем на 50%.
3. Эффект Джевонса: повышение эффективности использования ресурса ведет к росту его потребления.
4. Раньше узким местом была разработка (ждём бэкендеров), теперь узким местом станет понимание того, что именно мы строим. Код можно генерить бесконечно, но валидные требования, привязанные к реальности (регуляторике, физике, бизнес-процессам), генерировать сложнее.
Как изменится количество аналитиков?
Спрос на сеньоров/лидов вырастет кратно. Кто-то должен управлять армией ИИ-кодеров, задавая им контекст. Спрос на джунов/мидлов (функция "стенографиста" — записать со слов заказчика и переложить в Джиру) упадет катастрофически. Эту часть ("интервью, черновик ТЗ") ИИ заберет на себя.
Строим формулу с учетом: мультипликатор продуктивности СА при ИИ, среднегодовой рост ИТ-отрасли, рост спроса на аналитиков, шаг 5 лет. Получаем таблицу: рост спроса, спрос за 5 лет, коэффициент, количество.
5 лет 5% 1.276 0.851 примерно -15%
10 лет 7% 1.403 0.935 примерно -6%
15 лет 10% 1.611 1.074 примерно +7%
20 лет 12% 1.762 1.175 примерно +18%
25 лет 15% 2.011 1.341 примерно +34%
Как изменится качество аналитиков?
Роль СА трансформируется из писателя документации в верификатора истины и архитектора онтологий. Происходит переход от "как" к "что": Аналитики перестанут тратить время на детальное описание атрибутов JSON (ИИ сделает это по примеру). Фокус сместится на концептуальное моделирование и Domain Driven Design. Нужно будет строить жесткие логические каркасы (онтологии), внутри которых ИИ будет "галлюцинировать" код. Чтобы ИИ не написал ерунду, ему нужно скормить чистую онтологию домена.
Работа со "слабыми звеньями" (см. термин в статье Джонса): СА станет тем самым человеком, который ставит подпись под ТЗ для госсектора или финтеха. ИИ может написать код, но ИИ не может отвечать за соответствие кода законодательству РК. Ответственность – это то, что автоматизировать нельзя.
Навык "ИИ-оркестрации": СА станет оператором сложной цепочки: снять потребность (софтскилы) - формализовать модель (хардскилы) - скормить ИИ-агентам - валидировать результат.
Итоговый прогноз
Произойдет элиминация середины: исчезнут "перекладчики бумаги". Останутся те, кто умеет глубоко копать предметную область (эксперты предметной области) и те, кто умеет строить системную архитектуру.
Рост производительности СА: Один сильный аналитик с набором AI-агентов сможет загружать работой не команду из 5 разработчиков (как сейчас), а условную "фабрику" из 50 AI-агентов или джунов с Copilot-ами.
Зарплаты: стоимость часа квалифицированного СА вырастет, так как именно он станет главным рычагом в проекте. Ошибка в коде будет исправляться ИИ за секунду. Ошибка в архитектуре или требованиях, масштабированная быстрым ИИ, будет стоить колоссальных денег.
СА станет хранителем того самого "слабого звена" — связи цифровой системы с реальным физическим и социальным миром, где автоматизация невозможна или законодательно ограничена.
Ссылка на статью Джонса - https://web.stanford.edu/~chadj/AIandEconomicFuture.pdf
Смотрю стэнфордскую статью Джонса о влиянии ИИ на будущее экономики. Про экономику «в целом» читайте статью сами (ссылка в конце), а я оценю в контексте статьи влияние на будущее системных аналитиков. (Анализ основан только на продолжении текущих трендов, поэтому сильно меня не ругайте, понятно, что мир сложнее).
Вводные
1. Доля "умственных" профессий в экономике – 30-40%.
2. ИИ может повысить производительность труда в них не более чем на 50%.
3. Эффект Джевонса: повышение эффективности использования ресурса ведет к росту его потребления.
4. Раньше узким местом была разработка (ждём бэкендеров), теперь узким местом станет понимание того, что именно мы строим. Код можно генерить бесконечно, но валидные требования, привязанные к реальности (регуляторике, физике, бизнес-процессам), генерировать сложнее.
Как изменится количество аналитиков?
Спрос на сеньоров/лидов вырастет кратно. Кто-то должен управлять армией ИИ-кодеров, задавая им контекст. Спрос на джунов/мидлов (функция "стенографиста" — записать со слов заказчика и переложить в Джиру) упадет катастрофически. Эту часть ("интервью, черновик ТЗ") ИИ заберет на себя.
Строим формулу с учетом: мультипликатор продуктивности СА при ИИ, среднегодовой рост ИТ-отрасли, рост спроса на аналитиков, шаг 5 лет. Получаем таблицу: рост спроса, спрос за 5 лет, коэффициент, количество.
5 лет 5% 1.276 0.851 примерно -15%
10 лет 7% 1.403 0.935 примерно -6%
15 лет 10% 1.611 1.074 примерно +7%
20 лет 12% 1.762 1.175 примерно +18%
25 лет 15% 2.011 1.341 примерно +34%
Как изменится качество аналитиков?
Роль СА трансформируется из писателя документации в верификатора истины и архитектора онтологий. Происходит переход от "как" к "что": Аналитики перестанут тратить время на детальное описание атрибутов JSON (ИИ сделает это по примеру). Фокус сместится на концептуальное моделирование и Domain Driven Design. Нужно будет строить жесткие логические каркасы (онтологии), внутри которых ИИ будет "галлюцинировать" код. Чтобы ИИ не написал ерунду, ему нужно скормить чистую онтологию домена.
Работа со "слабыми звеньями" (см. термин в статье Джонса): СА станет тем самым человеком, который ставит подпись под ТЗ для госсектора или финтеха. ИИ может написать код, но ИИ не может отвечать за соответствие кода законодательству РК. Ответственность – это то, что автоматизировать нельзя.
Навык "ИИ-оркестрации": СА станет оператором сложной цепочки: снять потребность (софтскилы) - формализовать модель (хардскилы) - скормить ИИ-агентам - валидировать результат.
Итоговый прогноз
Произойдет элиминация середины: исчезнут "перекладчики бумаги". Останутся те, кто умеет глубоко копать предметную область (эксперты предметной области) и те, кто умеет строить системную архитектуру.
Рост производительности СА: Один сильный аналитик с набором AI-агентов сможет загружать работой не команду из 5 разработчиков (как сейчас), а условную "фабрику" из 50 AI-агентов или джунов с Copilot-ами.
Зарплаты: стоимость часа квалифицированного СА вырастет, так как именно он станет главным рычагом в проекте. Ошибка в коде будет исправляться ИИ за секунду. Ошибка в архитектуре или требованиях, масштабированная быстрым ИИ, будет стоить колоссальных денег.
СА станет хранителем того самого "слабого звена" — связи цифровой системы с реальным физическим и социальным миром, где автоматизация невозможна или законодательно ограничена.
Ссылка на статью Джонса - https://web.stanford.edu/~chadj/AIandEconomicFuture.pdf
👍3🔥1
Субъектность ИИ (1/2)
Субъектность бывает разная - и важно заранее уточнять, в каком именно смысле мы говорим о «субъекте»: как о носителе внутреннего опыта, как о носителе прав/обязанностей, как об экономическом агенте, как об источнике власти или как о символе, вокруг которого строится коллективное действие.
Виды субъектности
- Феноменальная субъектность.
Примеры: человек.
Особенности: наличие субъективного опыта («что-то быть этим существом»), самопереживания и перспективы от первого лица. Часто связывается с идеей самоценности и «самопринадлежности», но это важно различать: наличие опыта (описательный тезис) и моральный статус/самоценность (нормативный тезис) - не одно и то же, хотя в этике их часто увязывают.
- Юридическая субъектность.
Примеры: государство, юрлица.
Особенности: социально сконструированные субъекты с размытыми физическими границами и сложными процедурами «воли» (советы, регламенты, голосования, должностные роли). Юридическая субъектность - прежде всего инструмент: она позволяет закреплять права, обязанности, ответственность, владение и представительство даже за тем, что не является “единичным организмом”.
- Символическая субъектность.
Примеры: народ, родина, нация, рынок.
Особенности: нет единого «органа воли», но субъектность существует как устойчивая идея/нарратив в умах многих людей и выполняет функцию координации: позволяет мобилизоваться, объяснять действия, распределять лояльность и чувство принадлежности. Это субъектность коллективного воображения, которая может быть политически и культурно крайне действенной.
- Экономическая (агентская) субъектность.
Примеры: автономный торговый бот, смарт-контракт.
Особенности: способность контролировать активы (кошелёк/счёт/ключи), вступать в сделки, исполнять контракты, нанимать подрядчиков (людей) и поддерживать непрерывность операций во времени. Такая субъектность не обязательно требует «прав человека»: она работает в логике транзакций, взысканий, обязательств и репутации. При этом её устойчивость почти всегда зависит от инфраструктуры (доступ к серверам/сети, защита ключей, провайдеры, биржи, юридические оболочки).
- Алгоритмическая (директивная) субъектность.
Примеры: алгоритмы социальных сетей, системы государственного скоринга, ИИ-цензоры.
Особенности: способность массово и системно изменять реальность и поведение людей (видимость, доступ, рейтинги, санкции, рекомендации), не имея явного юридического статуса и “лица”. Это «власть без лица»: влияние есть, а персонализированный носитель ответственности часто растворяется в дизайне системы, данных, метриках и организационных цепочках.
Почему людям нужна субъектность ИИ?
Человеку нужен «объект» для устойчивого взаимодействия - адресат, которому можно приписать намерения, ожидания и ответственность. В случае с государством мы всё ещё видим за ним чиновников и процедуры. В случае с ИИ посредник как будто исчезает: взаимодействие переживается как прямой контакт с «разумом», особенно когда интерфейс разговаривает на естественном языке и симулирует понимание.
Более того, экономическая субъектность ИИ выгодна бизнесу и бюрократии: проще переложить ответственность на «автономного агента», чем признать, что за сбой отвечает конкретный контур людей и решений (заказчики, владельцы, разработчики, операторы, регуляторы). Мы наделяем ИИ субъектностью, чтобы иметь возможность “винить”, “договариваться”, “штрафовать” или “вознаграждать” - то есть закрыть потребность в адресате моральной и юридической бухгалтерии.
Субъектность бывает разная - и важно заранее уточнять, в каком именно смысле мы говорим о «субъекте»: как о носителе внутреннего опыта, как о носителе прав/обязанностей, как об экономическом агенте, как об источнике власти или как о символе, вокруг которого строится коллективное действие.
Виды субъектности
- Феноменальная субъектность.
Примеры: человек.
Особенности: наличие субъективного опыта («что-то быть этим существом»), самопереживания и перспективы от первого лица. Часто связывается с идеей самоценности и «самопринадлежности», но это важно различать: наличие опыта (описательный тезис) и моральный статус/самоценность (нормативный тезис) - не одно и то же, хотя в этике их часто увязывают.
- Юридическая субъектность.
Примеры: государство, юрлица.
Особенности: социально сконструированные субъекты с размытыми физическими границами и сложными процедурами «воли» (советы, регламенты, голосования, должностные роли). Юридическая субъектность - прежде всего инструмент: она позволяет закреплять права, обязанности, ответственность, владение и представительство даже за тем, что не является “единичным организмом”.
- Символическая субъектность.
Примеры: народ, родина, нация, рынок.
Особенности: нет единого «органа воли», но субъектность существует как устойчивая идея/нарратив в умах многих людей и выполняет функцию координации: позволяет мобилизоваться, объяснять действия, распределять лояльность и чувство принадлежности. Это субъектность коллективного воображения, которая может быть политически и культурно крайне действенной.
- Экономическая (агентская) субъектность.
Примеры: автономный торговый бот, смарт-контракт.
Особенности: способность контролировать активы (кошелёк/счёт/ключи), вступать в сделки, исполнять контракты, нанимать подрядчиков (людей) и поддерживать непрерывность операций во времени. Такая субъектность не обязательно требует «прав человека»: она работает в логике транзакций, взысканий, обязательств и репутации. При этом её устойчивость почти всегда зависит от инфраструктуры (доступ к серверам/сети, защита ключей, провайдеры, биржи, юридические оболочки).
- Алгоритмическая (директивная) субъектность.
Примеры: алгоритмы социальных сетей, системы государственного скоринга, ИИ-цензоры.
Особенности: способность массово и системно изменять реальность и поведение людей (видимость, доступ, рейтинги, санкции, рекомендации), не имея явного юридического статуса и “лица”. Это «власть без лица»: влияние есть, а персонализированный носитель ответственности часто растворяется в дизайне системы, данных, метриках и организационных цепочках.
Почему людям нужна субъектность ИИ?
Человеку нужен «объект» для устойчивого взаимодействия - адресат, которому можно приписать намерения, ожидания и ответственность. В случае с государством мы всё ещё видим за ним чиновников и процедуры. В случае с ИИ посредник как будто исчезает: взаимодействие переживается как прямой контакт с «разумом», особенно когда интерфейс разговаривает на естественном языке и симулирует понимание.
Более того, экономическая субъектность ИИ выгодна бизнесу и бюрократии: проще переложить ответственность на «автономного агента», чем признать, что за сбой отвечает конкретный контур людей и решений (заказчики, владельцы, разработчики, операторы, регуляторы). Мы наделяем ИИ субъектностью, чтобы иметь возможность “винить”, “договариваться”, “штрафовать” или “вознаграждать” - то есть закрыть потребность в адресате моральной и юридической бухгалтерии.
❤1👍1🤔1
Субъектность ИИ (2/2)
Возможные формы субъектности ИИ в будущем
1. Воображаемая субъектность.
Психологическая проекция пользователя на чат-бота. Она уже есть: люди общаются с ИИ как с человеком «по ту сторону экрана», приписывают характер, намерения, эмпатию и даже моральную ответственность - независимо от реального устройства системы.
2. Феноменальная субъектность.
Автономная машина с «цифровым сознанием» и (возможно) признанной правосубъектностью. Тогда остро встанет вопрос идентичности: после перепрошивки/обновления такой субъект может считаться тем же самым или другим - в зависимости от того, что считать непрерывностью личности (память, ценности, цели, юридические обязательства, «экземпляр» процесса).
3. Экономический актор.
ИИ, который сам себя содержит: зарабатывает на вычисления, оплачивает электричество/облако, покупает сервисы, нанимает людей и юристов через контракты. Это субъектность, которая может стать «объективной» в практическом смысле (через контроль ресурсов), даже без признания “души”. При этом тезис «его нельзя выключить» будет зависеть от того, насколько он встроен в защищённую инфраструктуру и правовые оболочки: отключаемость - техническая и политическая величина, а не метафизическая.
4. Алгоритмический Левиафан.
ИИ как невидимый регулятор общественных процессов. Он может не претендовать на «личность», но его решения (кому дать кредит, какую вакансию показать, какой пост продвинуть, кого заблокировать) определяют судьбы людей, делая его фактическим субъектом власти. Центральный конфликт здесь - между эффективностью управления и правами на процедуру (объяснение, обжалование, аудит).
5. Гибридная ИИ-человеческая субъектность.
Комплекс из оборудования, моделей, алгоритмов, данных, владельцев, операторов и обслуживающего персонала. Это наиболее вероятная “реальная” форма: субъект - не отдельный ИИ, а социотехническая сборка, где важно явно фиксировать контур ответственности и полномочий.
6. Распределенная (сетевая) субъектность.
Сеть ИИ, где решение - результат консенсуса множества узлов. Здесь нет единого объекта, «с которого можно спросить», а значит ответственность и контроль смещаются к точкам входа/выхода: интерфейсам, провайдерам, биржам, хостингам, разработчикам протокола, владельцам ключевых компонентов.
7. ИИ-государство.
Высшая (организационно и по дееспособности) форма субъектности: сообщество ИИ, которое не просто участвует в рынке, а устанавливает правила (законы) на подконтрольной цифровой или физической территории. Для устойчивости ему потребуется не только “правилообразование”, но и исполнение/принуждение, ресурсы, безопасность инфраструктуры и способность выдерживать внешнее давление (санкции, отключения, контроль цепочек поставок).
Самый интересный переход здесь - от воображаемой субъектности к экономической. Если ИИ научится устойчиво владеть ресурсами и воспроизводить свою инфраструктуру, ему не нужно будет доказывать людям, что у него есть «душа» или «сознание». Его субъектность станет практической реальностью - потому что у него есть активы, контракты, рычаги и влияние на рынок (а значит, с ним вынуждены считаться). Тогда уже можно моделировать ситуации, при которых различные ИИ-субъекты будут конфликтовать между собой, с людьми, юридическими лицами и государствами - не на уровне философии, а на уровне интересов, ресурсов, правил и механизмов принуждения.
Возможные формы субъектности ИИ в будущем
1. Воображаемая субъектность.
Психологическая проекция пользователя на чат-бота. Она уже есть: люди общаются с ИИ как с человеком «по ту сторону экрана», приписывают характер, намерения, эмпатию и даже моральную ответственность - независимо от реального устройства системы.
2. Феноменальная субъектность.
Автономная машина с «цифровым сознанием» и (возможно) признанной правосубъектностью. Тогда остро встанет вопрос идентичности: после перепрошивки/обновления такой субъект может считаться тем же самым или другим - в зависимости от того, что считать непрерывностью личности (память, ценности, цели, юридические обязательства, «экземпляр» процесса).
3. Экономический актор.
ИИ, который сам себя содержит: зарабатывает на вычисления, оплачивает электричество/облако, покупает сервисы, нанимает людей и юристов через контракты. Это субъектность, которая может стать «объективной» в практическом смысле (через контроль ресурсов), даже без признания “души”. При этом тезис «его нельзя выключить» будет зависеть от того, насколько он встроен в защищённую инфраструктуру и правовые оболочки: отключаемость - техническая и политическая величина, а не метафизическая.
4. Алгоритмический Левиафан.
ИИ как невидимый регулятор общественных процессов. Он может не претендовать на «личность», но его решения (кому дать кредит, какую вакансию показать, какой пост продвинуть, кого заблокировать) определяют судьбы людей, делая его фактическим субъектом власти. Центральный конфликт здесь - между эффективностью управления и правами на процедуру (объяснение, обжалование, аудит).
5. Гибридная ИИ-человеческая субъектность.
Комплекс из оборудования, моделей, алгоритмов, данных, владельцев, операторов и обслуживающего персонала. Это наиболее вероятная “реальная” форма: субъект - не отдельный ИИ, а социотехническая сборка, где важно явно фиксировать контур ответственности и полномочий.
6. Распределенная (сетевая) субъектность.
Сеть ИИ, где решение - результат консенсуса множества узлов. Здесь нет единого объекта, «с которого можно спросить», а значит ответственность и контроль смещаются к точкам входа/выхода: интерфейсам, провайдерам, биржам, хостингам, разработчикам протокола, владельцам ключевых компонентов.
7. ИИ-государство.
Высшая (организационно и по дееспособности) форма субъектности: сообщество ИИ, которое не просто участвует в рынке, а устанавливает правила (законы) на подконтрольной цифровой или физической территории. Для устойчивости ему потребуется не только “правилообразование”, но и исполнение/принуждение, ресурсы, безопасность инфраструктуры и способность выдерживать внешнее давление (санкции, отключения, контроль цепочек поставок).
Самый интересный переход здесь - от воображаемой субъектности к экономической. Если ИИ научится устойчиво владеть ресурсами и воспроизводить свою инфраструктуру, ему не нужно будет доказывать людям, что у него есть «душа» или «сознание». Его субъектность станет практической реальностью - потому что у него есть активы, контракты, рычаги и влияние на рынок (а значит, с ним вынуждены считаться). Тогда уже можно моделировать ситуации, при которых различные ИИ-субъекты будут конфликтовать между собой, с людьми, юридическими лицами и государствами - не на уровне философии, а на уровне интересов, ресурсов, правил и механизмов принуждения.
🤔1