ИИ как источник развивающего когнитивного вызова
Сегодня послушал свежий стрим нейробиолога (Владимир Алипов) с мнением на тему ИИ. Кратко тезисы + мои комментарии:
1. Преимущества: резкий прирост компетенций пользователя в тех областях, в которых он не разбирается.
2. Недостатки: в дальней перспективе утрата специалистами профессиональных навыков, поскольку многие перестанут понимать сути процессов, что может привести к проблемам и ошибкам.
3. У некоторых специалистов, использующих ИИ, может развиваться неуверенность в своих компетенциях, синдром самозванца и хронический стресс по этому поводу.
4. У других, с ИИ под рукой, может развиваться ложное чувство компетентности и самоуверенности, при поверхностном понимании предмета. Когнитивная лень.
5. ИИ не приведет к деградации мозга в рамках одного поколения, это так быстро не работает. Напротив, может оказаться, что мозг вырастет: якобы за последние 50 лет интеллектуальные возможности и объем коры головного мозга увеличились, несмотря на письменность и калькуляторы.
6. Для усиления когнитивных способностей необходим когнитивный вызов* для мышления, положительный стресс. Мышление деградирует как при когнитивной лени, так и при чрезмерном стрессе (отрицательном). Если ИИ будет источником стимулирующего когнитивного вызова (положительного), то мышление будет развиваться, а не деградировать.
*когнитивный вызов — это задача, ситуация или проблема, которая требует от человека значительных умственных усилий, напряжения и активной работы мозга. Он заставляет нас выходить за рамки привычного мышления и задействовать такие функции, как анализ, решение проблем, творчество, память и логика. Когнитивные вызовы играют ключевую роль в поддержании и развитии умственных способностей. Подобно тому как физические упражнения укрепляют мышцы, регулярные умственные нагрузки создают новые нейронные связи и укрепляют существующие, что повышает нейропластичность мозга. Примеры:
Повседневные
- Изучение нового маршрута в незнакомом городе без навигатора.
- Чтение сложного текста и попытка понять его смысл.
- Планирование сложного мероприятия, такого как свадьба или большой переезд.
Образовательные и профессиональные
- Изучение иностранного языка.
- Решение логической головоломки или кроссворда.
- Разработка новой идеи для проекта или бизнеса.
- Освоение нового музыкального инструмента.
От ИИ
ИИ способен генерировать правдоподобные, но ложные или предвзятые ответы. Это бросает вызов способности человека:
-- Критически оценивать информацию: отличать факты от вымысла.
-- Верифицировать данные: проверять источники, логику и последовательность.
-- Распознавать манипуляции: понимать, когда ИИ имитирует аргументацию без глубокого понимания.
-- Понимать базовые принципы человеческого мышления и формирования собственного мировоззрения.
Ссылка на стрим - https://www.youtube.com/watch?v=VLNtby11f9M
Сегодня послушал свежий стрим нейробиолога (Владимир Алипов) с мнением на тему ИИ. Кратко тезисы + мои комментарии:
1. Преимущества: резкий прирост компетенций пользователя в тех областях, в которых он не разбирается.
2. Недостатки: в дальней перспективе утрата специалистами профессиональных навыков, поскольку многие перестанут понимать сути процессов, что может привести к проблемам и ошибкам.
3. У некоторых специалистов, использующих ИИ, может развиваться неуверенность в своих компетенциях, синдром самозванца и хронический стресс по этому поводу.
4. У других, с ИИ под рукой, может развиваться ложное чувство компетентности и самоуверенности, при поверхностном понимании предмета. Когнитивная лень.
5. ИИ не приведет к деградации мозга в рамках одного поколения, это так быстро не работает. Напротив, может оказаться, что мозг вырастет: якобы за последние 50 лет интеллектуальные возможности и объем коры головного мозга увеличились, несмотря на письменность и калькуляторы.
6. Для усиления когнитивных способностей необходим когнитивный вызов* для мышления, положительный стресс. Мышление деградирует как при когнитивной лени, так и при чрезмерном стрессе (отрицательном). Если ИИ будет источником стимулирующего когнитивного вызова (положительного), то мышление будет развиваться, а не деградировать.
*когнитивный вызов — это задача, ситуация или проблема, которая требует от человека значительных умственных усилий, напряжения и активной работы мозга. Он заставляет нас выходить за рамки привычного мышления и задействовать такие функции, как анализ, решение проблем, творчество, память и логика. Когнитивные вызовы играют ключевую роль в поддержании и развитии умственных способностей. Подобно тому как физические упражнения укрепляют мышцы, регулярные умственные нагрузки создают новые нейронные связи и укрепляют существующие, что повышает нейропластичность мозга. Примеры:
Повседневные
- Изучение нового маршрута в незнакомом городе без навигатора.
- Чтение сложного текста и попытка понять его смысл.
- Планирование сложного мероприятия, такого как свадьба или большой переезд.
Образовательные и профессиональные
- Изучение иностранного языка.
- Решение логической головоломки или кроссворда.
- Разработка новой идеи для проекта или бизнеса.
- Освоение нового музыкального инструмента.
От ИИ
ИИ способен генерировать правдоподобные, но ложные или предвзятые ответы. Это бросает вызов способности человека:
-- Критически оценивать информацию: отличать факты от вымысла.
-- Верифицировать данные: проверять источники, логику и последовательность.
-- Распознавать манипуляции: понимать, когда ИИ имитирует аргументацию без глубокого понимания.
-- Понимать базовые принципы человеческого мышления и формирования собственного мировоззрения.
Ссылка на стрим - https://www.youtube.com/watch?v=VLNtby11f9M
🔥2
Закон об ИИ в Казахстане: 6 критических проблем в текущей версии проекта
Полная версия поста здесь - https://teletype.in/@nicksu/1_wRNzxvz75
В Казахстане готовится к принятию закон «Об искусственном интеллекте» (принят Мажилисом во втором чтении), но экспертный анализ показывает, что в его текущей редакции заложены серьёзные риски для граждан, бизнеса и государства. Вот краткое изложение ключевых проблем и предложений по их решению.
1. Расплывчатое определение ИИ
• Проблема: Закон определяет ИИ через философское понятие «имитации когнитивных функций человека». Это создаёт правовую неопределённость: под определение может попасть как обычный калькулятор, так и «ускользнуть» от ответственности сложная вредоносная система.
• Решение: Перейти к функциональному определению, которое описывает, что система делает (например, использует обучаемые модели для выводов, влияющих на решения), а не на что она похожа.
2. Классификация рисков без последствий
• Проблема: В законе правильно вводится деление систем ИИ по уровням риска (минимальный, средний, высокий). Однако в нём не прописано, какие конкретные обязанности это накладывает на владельцев систем высокого риска. Это делает классификацию бессмысленной и создаёт поле для коррупции.
• Решение: Внедрить в закон чёткую «матрицу обязанностей». Например, для систем высокого риска обязать проводить оценку воздействия, вести журнал инцидентов и страховать ответственность.
3. Монополия Национального оператора и данные
• Проблема: Проект предполагает назначение Правительством единого оператора национальной платформы ИИ, который получит доступ ко всем госданным. Это прямой путь к монополии, завышенным ценам и колоссальным рискам в случае утечки данных.
• Решение: Закрепить в законе принципы открытого конкурса для выбора оператора и равного доступа к данным для всех участников рынка.
4. Лазейка для массовой слежки
• Проблема: Закон вроде бы запрещает удалённую биометрическую идентификацию в реальном времени, но с оговоркой «за исключением случаев, определенных законами». Эта формулировка позволяет через другие законы легализовать практически любую слежку.
• Решение: Максимально сузить и конкретизировать исключения: применение таких технологий возможно только при острой необходимости, с разрешения суда и с чётким ограничением по времени и цели.
5. Отсутствие реальной компенсации вреда
• Проблема: В случае вреда от ИИ (например, врачебной ошибки) закон отсылает к Гражданскому кодексу, а страхование делает добровольным. Пострадавшему будет практически невозможно доказать вину разработчика и получить компенсацию.
• Решение: Ввести обязательное страхование ответственности для систем ИИ высокого риска. Это создаст гарантийный фонд для выплат пострадавшим.
6.«Цифровое бесправие» граждан
• Проблема: Если алгоритм отказал человеку в кредите или при приёме на работу, закон даёт лишь право «быть информированным». Этого недостаточно.
• Решение: Чётко закрепить в законе права граждан: право на получение понятного объяснения логики решения, право на человеческий пересмотр и право на подачу жалобы.
Вывод: Законопроект — важный шаг, но он требует серьёзной доработки. Без предложенных изменений он рискует стать источником правовой неопределённости, монополизма и нарушения прав граждан.
Полная версия поста здесь - https://teletype.in/@nicksu/1_wRNzxvz75
#ИИ #Казахстан #Законопроект #Технологии #ПраваЧеловека #AI
Полная версия поста здесь - https://teletype.in/@nicksu/1_wRNzxvz75
В Казахстане готовится к принятию закон «Об искусственном интеллекте» (принят Мажилисом во втором чтении), но экспертный анализ показывает, что в его текущей редакции заложены серьёзные риски для граждан, бизнеса и государства. Вот краткое изложение ключевых проблем и предложений по их решению.
1. Расплывчатое определение ИИ
• Проблема: Закон определяет ИИ через философское понятие «имитации когнитивных функций человека». Это создаёт правовую неопределённость: под определение может попасть как обычный калькулятор, так и «ускользнуть» от ответственности сложная вредоносная система.
• Решение: Перейти к функциональному определению, которое описывает, что система делает (например, использует обучаемые модели для выводов, влияющих на решения), а не на что она похожа.
2. Классификация рисков без последствий
• Проблема: В законе правильно вводится деление систем ИИ по уровням риска (минимальный, средний, высокий). Однако в нём не прописано, какие конкретные обязанности это накладывает на владельцев систем высокого риска. Это делает классификацию бессмысленной и создаёт поле для коррупции.
• Решение: Внедрить в закон чёткую «матрицу обязанностей». Например, для систем высокого риска обязать проводить оценку воздействия, вести журнал инцидентов и страховать ответственность.
3. Монополия Национального оператора и данные
• Проблема: Проект предполагает назначение Правительством единого оператора национальной платформы ИИ, который получит доступ ко всем госданным. Это прямой путь к монополии, завышенным ценам и колоссальным рискам в случае утечки данных.
• Решение: Закрепить в законе принципы открытого конкурса для выбора оператора и равного доступа к данным для всех участников рынка.
4. Лазейка для массовой слежки
• Проблема: Закон вроде бы запрещает удалённую биометрическую идентификацию в реальном времени, но с оговоркой «за исключением случаев, определенных законами». Эта формулировка позволяет через другие законы легализовать практически любую слежку.
• Решение: Максимально сузить и конкретизировать исключения: применение таких технологий возможно только при острой необходимости, с разрешения суда и с чётким ограничением по времени и цели.
5. Отсутствие реальной компенсации вреда
• Проблема: В случае вреда от ИИ (например, врачебной ошибки) закон отсылает к Гражданскому кодексу, а страхование делает добровольным. Пострадавшему будет практически невозможно доказать вину разработчика и получить компенсацию.
• Решение: Ввести обязательное страхование ответственности для систем ИИ высокого риска. Это создаст гарантийный фонд для выплат пострадавшим.
6.«Цифровое бесправие» граждан
• Проблема: Если алгоритм отказал человеку в кредите или при приёме на работу, закон даёт лишь право «быть информированным». Этого недостаточно.
• Решение: Чётко закрепить в законе права граждан: право на получение понятного объяснения логики решения, право на человеческий пересмотр и право на подачу жалобы.
Вывод: Законопроект — важный шаг, но он требует серьёзной доработки. Без предложенных изменений он рискует стать источником правовой неопределённости, монополизма и нарушения прав граждан.
Полная версия поста здесь - https://teletype.in/@nicksu/1_wRNzxvz75
#ИИ #Казахстан #Законопроект #Технологии #ПраваЧеловека #AI
🔥5👍3
Государственный ИИ: казахская Конкиста (часть 1)
В последнее время тема искусственного интеллекта звучит на самом высоком государственном уровне. Акцент, который делает на этом Президент, говорит о том, что это не просто очередной технологический тренд, а стратегическая ставка. Но если посмотреть глубже, можно увидеть в этом не только технологический, но и продуманный социальный проект.
Для понимания его механики полезна неожиданная историческая аналогия — испанская Конкиста.
В конце XV века Испания завершила Реконкисту и столкнулась с проблемой: в стране оказалось огромное количество молодых, амбициозных и воинственных дворян-идальго. В мирное время их энергия могла легко стать разрушительной силой, направленной внутрь страны. Открытие Нового Света стало для испанской короны решением этой проблемы. Был создан новый «фронтир» — огромное пространство возможностей, куда устремился этот беспокойный социальный слой в поисках славы и богатства. Так энергия потенциального внутреннего конфликта была перенаправлена на внешнюю экспансию.
В Казахстане XXI века стоит схожая по структуре, но иная по содержанию задача. Есть активная, талантливая и амбициозная молодежь. Традиционные карьерные пути не всегда могут удовлетворить их запросы, что создает риски «утечки мозгов» и роста социального недовольства.
В этой ситуации форсированное развитие ИИ и высоких технологий — это создание нового, цифрового «фронтира». Это глобальная отрасль, предлагающая быстрый и меритократический социальный лифт, основанный на знаниях и компетенциях, а не на традиционных иерархиях.
Государство, инвестируя в эту сферу, не просто развивает экономику. Оно создает мощный магнит для интеллектуального капитала страны, предлагая молодежи амбициозную цель и возможность самореализации внутри Казахстана. По сути, это тонкий инструмент социальной инженерии, направленный на решение стратегических внутренних задач.
Однако у этой инициативы есть и второе, более прагматичное измерение, касающееся непосредственно системы госуправления. Об этом — в следующей части.
#ИИ #Казахстан #Стратегия #Госуправление #СоциальнаяИнженерия #Технологии
В последнее время тема искусственного интеллекта звучит на самом высоком государственном уровне. Акцент, который делает на этом Президент, говорит о том, что это не просто очередной технологический тренд, а стратегическая ставка. Но если посмотреть глубже, можно увидеть в этом не только технологический, но и продуманный социальный проект.
Для понимания его механики полезна неожиданная историческая аналогия — испанская Конкиста.
В конце XV века Испания завершила Реконкисту и столкнулась с проблемой: в стране оказалось огромное количество молодых, амбициозных и воинственных дворян-идальго. В мирное время их энергия могла легко стать разрушительной силой, направленной внутрь страны. Открытие Нового Света стало для испанской короны решением этой проблемы. Был создан новый «фронтир» — огромное пространство возможностей, куда устремился этот беспокойный социальный слой в поисках славы и богатства. Так энергия потенциального внутреннего конфликта была перенаправлена на внешнюю экспансию.
В Казахстане XXI века стоит схожая по структуре, но иная по содержанию задача. Есть активная, талантливая и амбициозная молодежь. Традиционные карьерные пути не всегда могут удовлетворить их запросы, что создает риски «утечки мозгов» и роста социального недовольства.
В этой ситуации форсированное развитие ИИ и высоких технологий — это создание нового, цифрового «фронтира». Это глобальная отрасль, предлагающая быстрый и меритократический социальный лифт, основанный на знаниях и компетенциях, а не на традиционных иерархиях.
Государство, инвестируя в эту сферу, не просто развивает экономику. Оно создает мощный магнит для интеллектуального капитала страны, предлагая молодежи амбициозную цель и возможность самореализации внутри Казахстана. По сути, это тонкий инструмент социальной инженерии, направленный на решение стратегических внутренних задач.
Однако у этой инициативы есть и второе, более прагматичное измерение, касающееся непосредственно системы госуправления. Об этом — в следующей части.
#ИИ #Казахстан #Стратегия #Госуправление #СоциальнаяИнженерия #Технологии
🔥5🤔2
Государственный ИИ: организующий таран (часть 2)
В первой части мы рассмотрели, как инициатива по ИИ работает в качестве инструмента социальной инженерии. Теперь — о ее влиянии на сам государственный аппарат, где она может сыграть роль «организующего тарана».
Не секрет, что одна из хронических проблем цифровизации госуправления — это хаос в данных. Разрозненные базы, устаревшие справочники, отсутствие единых стандартов и ведомственная замкнутость. Предыдущие попытки навести порядок часто вязли в бюрократии, поскольку это сложнейшая организационная, а не просто техническая задача. У ведомств не было достаточно веского стимула для ее решения.
Инициатива по внедрению ИИ кардинально меняет ситуацию. Любая система на базе машинного обучения критически требовательна к качеству данных. Она просто не будет работать на противоречивой, неполной или неструктурированной информации. Этот технологический императив становится мощным политическим рычагом.
Требование «внедрить ИИ», спущенное сверху, превращается в таран, который заставляет госорганы делать то, что откладывалось годами. Чтобы запустить аналитическую модель, ведомства будут вынуждены:
Стандартизировать данные. Начать создавать и использовать единые, эталонные справочники.
Внедрить управление данными (Data Governance). Назначить ответственных за качество, актуальность и доступность данных, прописать соответствующие регламенты.
Провести аудит и очистку. Разгрести накопленные за десятилетия массивы информации, чтобы подготовить их для анализа.
Обеспечить интеграцию. Наладить реальный межведомственный обмен данными на основе современных протоколов, разрушая информационные «колодцы».
Таким образом, даже если внедрения ИИ не дадут прорывного эффекта, побочный продукт этой деятельности может оказаться куда более ценным. В стране начнет формироваться упорядоченная, надежная и хорошо управляемая национальная инфраструктура данных.
Это тот самый фундамент, без которого невозможно построить настоящее цифровое государство. И, возможно, именно ИИ станет тем инструментом, который заставит этот фундамент наконец-то залить.
#ГосТех #Цифровизация #DataGovernance #Данные #ИИ #Госуправление #Казахстан
В первой части мы рассмотрели, как инициатива по ИИ работает в качестве инструмента социальной инженерии. Теперь — о ее влиянии на сам государственный аппарат, где она может сыграть роль «организующего тарана».
Не секрет, что одна из хронических проблем цифровизации госуправления — это хаос в данных. Разрозненные базы, устаревшие справочники, отсутствие единых стандартов и ведомственная замкнутость. Предыдущие попытки навести порядок часто вязли в бюрократии, поскольку это сложнейшая организационная, а не просто техническая задача. У ведомств не было достаточно веского стимула для ее решения.
Инициатива по внедрению ИИ кардинально меняет ситуацию. Любая система на базе машинного обучения критически требовательна к качеству данных. Она просто не будет работать на противоречивой, неполной или неструктурированной информации. Этот технологический императив становится мощным политическим рычагом.
Требование «внедрить ИИ», спущенное сверху, превращается в таран, который заставляет госорганы делать то, что откладывалось годами. Чтобы запустить аналитическую модель, ведомства будут вынуждены:
Стандартизировать данные. Начать создавать и использовать единые, эталонные справочники.
Внедрить управление данными (Data Governance). Назначить ответственных за качество, актуальность и доступность данных, прописать соответствующие регламенты.
Провести аудит и очистку. Разгрести накопленные за десятилетия массивы информации, чтобы подготовить их для анализа.
Обеспечить интеграцию. Наладить реальный межведомственный обмен данными на основе современных протоколов, разрушая информационные «колодцы».
Таким образом, даже если внедрения ИИ не дадут прорывного эффекта, побочный продукт этой деятельности может оказаться куда более ценным. В стране начнет формироваться упорядоченная, надежная и хорошо управляемая национальная инфраструктура данных.
Это тот самый фундамент, без которого невозможно построить настоящее цифровое государство. И, возможно, именно ИИ станет тем инструментом, который заставит этот фундамент наконец-то залить.
#ГосТех #Цифровизация #DataGovernance #Данные #ИИ #Госуправление #Казахстан
🔥5🤔1
Государственный ИИ: вызовы и риски (часть 3)
В первых двух частях мы рассмотрели стратегические плюсы госпрограммы по ИИ — как «Конкисту» для талантов и «таран» для упорядочивания данных. Эти аналогии показывают мощный созидательный потенциал инициативы.
Но у этой медали есть и обратная, куда более тёмная сторона. Внедрение ИИ в масштабах государства — это не просто технологический апгрейд. Это фундаментальный вызов, который проверяет на прочность демократические институты, права человека и экономическую модель. Рассмотрим главные риски.
Риск №1: Цифровая клетка вместо цифрового будущего
Технологии искусственного интеллекта дают государству беспрецедентные инструменты контроля. Без жестких правовых и этических рамок «умное государство» легко может превратиться в «полицейское государство 2.0».
Тотальная слежка: Для работы ИИ нужны данные. Это стимулирует государство собирать и объединять всё: видео с камер наблюдения, банковские транзакции, перемещения, активность в интернете. Грань между безопасностью и тотальным контролем над частной жизнью становится угрожающе тонкой.
Системы социального рейтинга: Собранные данные можно использовать для оценки граждан. Это прямой путь к созданию систем, где доступ к кредитам, госуслугам или выезду за границу зависит от уровня «лояльности», вычисленного алгоритмом.
Алгоритмическая дискриминация: ИИ, обученный на предвзятых данных, будет систематически дискриминировать определенные социальные группы. «Предиктивная полиция», например, может начать необоснованно пристальное наблюдение за жителями определенных районов, создавая порочный круг подозрений и арестов.
Непрозрачность власти: Как оспорить решение, принятое «черным ящиком» нейросети? Отсутствие прозрачности и возможности апелляции подрывает базовые права граждан и делает власть абсолютно непроницаемой для общества.
Риск №2: Бюджетная «черная дыра» и монополия
Масштабные государственные инвестиции в хайповую и сложную отрасль — это идеальная среда для коррупции и подавления конкуренции.
«Освоение бюджетов»: Сложность ИИ-проектов затрудняет их аудит. Под прикрытием «наукоемких разработок» можно тратить огромные средства с минимальной эффективностью и общественным контролем.
Создание монополий: Возникает соблазн назначить несколько «национальных чемпионов» — крупных, аффилированных с государством компаний, которые получат все ключевые контракты.
Уничтожение конкуренции: В такой среде малый и средний инновационный бизнес будет задушен. Настоящие таланты и прорывные стартапы не смогут конкурировать с гигантами, чей главный актив — административный ресурс. Вместо экосистемы инноваций мы получим дорогой и неэффективный картель.
Усиление «утечки мозгов»: Талантливые специалисты не захотят работать в закрытой, неконкурентной системе и будут еще активнее уезжать из страны.
Вывод
Искусственный интеллект в перспективе — это мощный инструмент. С его помощью можно построить как более эффективное и справедливое общество, так и высокотехнологичную диктатуру. Итог зависит не от самой технологии, а от институциональной среды.
Без создания системы «предохранителей» — сильного законодательства о защите данных, независимого общественного контроля и реальной поддержки конкуренции — мы рискуем получить совсем не то будущее, о котором говорится с высоких трибун.
#ИИ #Риски #Цифровизация #ПраваЧеловека #Коррупция #Госуправление #Казахстан
В первых двух частях мы рассмотрели стратегические плюсы госпрограммы по ИИ — как «Конкисту» для талантов и «таран» для упорядочивания данных. Эти аналогии показывают мощный созидательный потенциал инициативы.
Но у этой медали есть и обратная, куда более тёмная сторона. Внедрение ИИ в масштабах государства — это не просто технологический апгрейд. Это фундаментальный вызов, который проверяет на прочность демократические институты, права человека и экономическую модель. Рассмотрим главные риски.
Риск №1: Цифровая клетка вместо цифрового будущего
Технологии искусственного интеллекта дают государству беспрецедентные инструменты контроля. Без жестких правовых и этических рамок «умное государство» легко может превратиться в «полицейское государство 2.0».
Тотальная слежка: Для работы ИИ нужны данные. Это стимулирует государство собирать и объединять всё: видео с камер наблюдения, банковские транзакции, перемещения, активность в интернете. Грань между безопасностью и тотальным контролем над частной жизнью становится угрожающе тонкой.
Системы социального рейтинга: Собранные данные можно использовать для оценки граждан. Это прямой путь к созданию систем, где доступ к кредитам, госуслугам или выезду за границу зависит от уровня «лояльности», вычисленного алгоритмом.
Алгоритмическая дискриминация: ИИ, обученный на предвзятых данных, будет систематически дискриминировать определенные социальные группы. «Предиктивная полиция», например, может начать необоснованно пристальное наблюдение за жителями определенных районов, создавая порочный круг подозрений и арестов.
Непрозрачность власти: Как оспорить решение, принятое «черным ящиком» нейросети? Отсутствие прозрачности и возможности апелляции подрывает базовые права граждан и делает власть абсолютно непроницаемой для общества.
Риск №2: Бюджетная «черная дыра» и монополия
Масштабные государственные инвестиции в хайповую и сложную отрасль — это идеальная среда для коррупции и подавления конкуренции.
«Освоение бюджетов»: Сложность ИИ-проектов затрудняет их аудит. Под прикрытием «наукоемких разработок» можно тратить огромные средства с минимальной эффективностью и общественным контролем.
Создание монополий: Возникает соблазн назначить несколько «национальных чемпионов» — крупных, аффилированных с государством компаний, которые получат все ключевые контракты.
Уничтожение конкуренции: В такой среде малый и средний инновационный бизнес будет задушен. Настоящие таланты и прорывные стартапы не смогут конкурировать с гигантами, чей главный актив — административный ресурс. Вместо экосистемы инноваций мы получим дорогой и неэффективный картель.
Усиление «утечки мозгов»: Талантливые специалисты не захотят работать в закрытой, неконкурентной системе и будут еще активнее уезжать из страны.
Вывод
Искусственный интеллект в перспективе — это мощный инструмент. С его помощью можно построить как более эффективное и справедливое общество, так и высокотехнологичную диктатуру. Итог зависит не от самой технологии, а от институциональной среды.
Без создания системы «предохранителей» — сильного законодательства о защите данных, независимого общественного контроля и реальной поддержки конкуренции — мы рискуем получить совсем не то будущее, о котором говорится с высоких трибун.
#ИИ #Риски #Цифровизация #ПраваЧеловека #Коррупция #Госуправление #Казахстан
🔥3
Почему бизнес-аналитик – самая лучшая профессия в 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.me/how2scheme
Многие аналитики писали User Stories. Каковы их слабые места? Часто «Я, как пользователь…» на самом деле прикрывает «Я, как бизнес, хочу, чтобы пользователь…», а ценность в «чтобы…» притягивается за уши просто для соблюдения формата .
Но главная боль, как по мне, в другом. В классической User Story нет предметной области. Нет данных, нет сущностей, нет «объектов». Из-за этого получается огромный разрыв между историей и тем, что потом увидят дизайнеры и разработчики.
Андрей Шапиро дал почитать рукопись книги о своем методе «Рабочие истории». ИМХО, это очень удачная попытка всю эту кухню систематизировать и вылечить. Это не просто «еще один шаблон», а целая технология.
Структура и содержание
Книга разделена на две части. Первая часть анализирует эволюцию пользовательских историй как инструмента сбора требований. Андрей делится практическими примерами из реальных проектов, обсуждая шаблоны, преимущества и недостатки user stories. Он подчеркивает их роль в преодолении "вавилонской башни" — языковых барьеров между стейкхолдерами, — но отмечает ограничения: краткость часто приводит к потере контекста, а отсутствие строгой структуры затрудняет работу в сложных доменах.
Новый шаблон «Рабочей истории» (НСДОЦ)
Вторая часть вводит ключевую инновацию — рабочие истории и Карту реализации историй (КРИ). Рабочие истории расширяют шаблон user stories, фиксируя не только роль, функциональность и ценность, но и ситуацию, объекты оперирования, а также каскад реализации (от замысла к форме).
Автор предлагает 5-компонентную структуру:
• Н (Носитель действия)
• С (Ситуация)
• Д (Способ действия)
• О (Объекты оперирования)
• Ц (Цель действия)
И ключевое здесь — «О (Объекты оперирования)». Нас наконец-то заставляют на уровне требования описать, с какими вещами, данными и сущностями работает носитель действия. Это сразу снимает кучу вопросов и заземляет историю.
«Карта реализации историй» (КРИ)
Это тот самый мост от «что» к «как». КРИ — это матрица , где по горизонтали идет процесс (логика следования) , а по вертикали — «каскад реализации». Каждая история раскладывается на:
• Саму Рабочую историю (описание необходимой деятельности) .
• Форму реализации (как именно это будет воплощено, какие технологии, допущения, решения).
• Структуру блоков интерфейса (что конкретно будет на экране, какие инфо-блоки и элементы управления).
В итоге получается мощное развитие техники. Такой подход лечит «проблему молотка» (когда в User Story сразу «пихают» готовое решение, а не потребность). И он помогает четко отделить потребности пользователя от требований бизнеса (для этого есть специальный прием с инверсией Носителя, когда им становится «Система»).
Для аналитиков книга предлагает практический фреймворк для сбора требований в запутанных проектах. Метод помогает структурировать беседы со стейкхолдерами, выявлять пробелы в знаниях и проверять адекватность моделей. Вспомогательные практики — приёмочные тесты, чистка от ложных требований, оценка в сторипоинтах — интегрируются с agile-подходами. Примеры ошибок и рекомендаций по сессиям картирования делают книгу ценным руководством для командной работы. Автор подчеркивает: без практики инструмент не освоить, рекомендуя применять техники на реальных проектах.
В общем, для системных и бизнес-аналитиков — очень советую прочесть книгу, когда она будет опубликована. (А также для продактов, дизайнеров, разработчиков). Это достаточно просто, но куда более строгий и инженерный подход к требованиям, чем то, к чему многие привыкли.
Канал Андрея - https://t.me/how2scheme
🔥4❤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🔥3
Системный анализ — для отстающих?
Ой ли? Давайте разбираться.
Перечитал курс по системной инженерии от Анатолия Левенчука. Там есть раздел «Смерть инженерии требований». Не метафора - буквально так называется. Разбираемся, почему так думает автор.
Тезисы:
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