IT и IQ – про интеллект айтишников (2/2)

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

7. Выгорание – это просто нервное истощение. Легкая и средняя степень депрессии не лечится антидепрессантами. Точнее лечится, но они работают как плацебо. Мета-мета-анализ исследований по антидепрессантам показывает, что статистически значимо они помогают только в случае тяжелой депрессии. При этом никто не знает механизм работы антидепрессантов – серотониновая теория депрессии пока совершенно не доказана – серотонин никак не влияет на настроение.

8. Прокрастинация – это не лень. Это перенос страха перед неприятной (непонятной, или трудной, или бессмыссленной, и т.д.) задачей на другие задачи – смещенная активность. Есть хитрости как ее преодолевать.

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

10. Ноотропы и всяческая химия не может повысить интеллект, в лучшем случае она имеет эффект плацебо. Некоторые вещества могут несколько изменить личность, но не в сторону усиления интеллекта. Скорее напротив.

Ссылки:
1. Подкаст с Владимиром Алиповым – https://www.youtube.com/watch?v=5NSr4bZk7-M&t=2311s&ab_channel=DecembristITTV

2. Телеграм-канал Владимира Алипова - https://t.me/alipov_shorts

3. Ютуб-канал Алипова - https://www.youtube.com/@neurobiology-alipov/playlists

Технологиялық Ұлт – партия инженеров (досужие ночные фантазии) (1/3)

Однажды ночью мне не спалось, и я задумался: какую партию я бы создал, если бы занимался политикой в Казахстане. Понятно, что руководить всем должны айтишники и прочие инженеры. Поэтому, пожалуй, я бы создал правоконсервативную партию инженеров (технарей) и назвал бы ее что-то вроде «Технологическая нация».

Миссия партии – формирование у наиболее образованной, активной и дееспособной части общества идентичности «высокотехнологичного казаха» и преобразование страны на основе компетентного рационализма и прагматизма.

В программе отразил бы цели на ближайшие лет пятьдесят:
1. Технологическое развитие в соответствии с мировыми технологическими трендами. Тренды: атомная энергетика, роботизация, биотехнологии.

a. Достижение энергетической безопасности. Страна имеет большие запасы углеводородов, урана, угля, и при этом испытывает дефицит электроэнергии, не может стабильно обеспечивать себя топливом, не умеет строить и качественно обслуживать электростанции. Большая часть бюджета страны формируется за счет экспорта сырья. Необходимо постепенно отказаться от роли сырьевого придатка, научиться строить и обслуживать АЭС, а также угольные электростанции, соответствующие требованиям «зеленой энергетики». Экспортировать не нефть и газ, а продукцию нефтехимической промышленности, топливо. Для достижения этих целей необходимо создавать национальные инженерные в области энергетики, ядерной физики, нефтехимии, геологии. Метрики: 1) 4 крупных АЭС через 20 лет; 2) способность строить малые АЭС через 25 лет; 3) способность строить экологичные угольные ТЭС и ТЭЦ через 10 лет; 4) сокращение доли экспорта сырья в 3 раза через 10 лет.

b. Достижение продовольственной безопасности. Дефицит водных ресурсов несет угрозу продовольственной безопасности страны. Половина воды при использовании для орошения уходит на потери при транспортировке. Необходима модернизация системы использования водных ресурсов. Необходимо создание единой водно-энергетической системы с соседними странами. Метрики: 1. Сокращение потерь воды в 3 раза через 10 лет. 2. Соглашение, проектирование и создание единой водно-энергетической системы через 10 лет.

c. Освоение роботизированных производственных технологий «шестого технологического уклада». В ближайшие десятилетия все большее значение будут приобретать технологии роботизированного производства, при которых роботизация и использование 3D-печати позволят выпускать мелкосерийную продукцию с той же себестоимостью, для которой в настоящее время необходимо крупносерийное производство. Необходимо обеспечить своевременное освоение данных технологий национальными кадрами. Метрики: 1) подготовка ежегодно не менее 1000 специалистов в области робототехники и 3D-печати через 10 лет.

d. Адаптация системы высшего и среднего образования к целям развития страны. В настоящее время система образования преимущественно выполняет функции социализации учащихся, а не подготовки высококвалифицированных специалистов. Нельзя отрицать важности функции социализации, но необходимо добиться, чтобы появилась система по-настоящему высшего образования. Для подготовки инженерной и гуманитарной элиты страны достаточно 3-4 университета, обеспеченных высококвалифицированными кадрами, ресурсами и свободных от коррупции, где наиболее способные студенты смогут получать настоящее высшее образование. За остальными многочисленными ВУЗами может быть оставлена функция социализации и имитации высшего образования. В системе среднего образования так же должна быть проведена адаптация: для наиболее способных учеников должен проводиться отбор и качественное обучение в целях дальнейшего получения настоящего высшего образования, для большинства – обеспечение социализации и «обычного» среднего образования. Крупные энергетические и другие инфраструктурные проекты должны выступать драйверами развития системы образования.
Метрики: 1) 3 университета с «настоящим» высшим образованием через 5 лет.

Технологиялық Ұлт – партия инженеров (досужие ночные фантазии) (2/3)

2. Консервативная внутренняя политика.

a. Имперский подход. Внутренняя политика должна строиться в целях обеспечения способности к развитию при обеспечении эволюционного пути развития с исключением возможности радикализации (этнической, языковой, религиозной, классовой). Имперский подход подразумевает возможность сохранения в рамках одного государства поликультурного и полиэтнического общества, отказ от радикальной унификации мировоззрения граждан по единым критериям. Казахстан в этом смысле должен быть империей, способной управлять группами населения, отличающимися по культуре, этносу, языку, религии. Империя сложнее в управлении, но имперская культура управления дает большую гибкость и адаптивность к изменениям. Общая имперская идентичность: Казахстан – сердце Евразии, росток разума, прорастающий и набирающий силу в сухой степи глупости, лени и жадности. Метрики: 1) народы Казахстана должны получить не декоративную политическую субъектность (Ассамблея – не работает) через 3 года. (Примечание: Поскольку термин «империя» стигматизирован в современном общественном сознании, он может быть заменен).

b. Традиционная семья. Исторически апробированная основа социальной устойчивости общества – семья. Мужчины и женщины равноправны в политической и профессиональной деятельности. Современный трансгуманизм (нетрадиционные гендеры и половое поведение) в частной жизни не должен преследоваться, но не допустим для пропаганды. Метрики: 1) наличие ежемесячного отчета специальных служб о размерах грантов, выделяемых посольствами США и Великобритании на пропаганду ЛГБТ в Казахстане через никогда лет.

c. Религии и идеологии – инструмент поддержки традиционной нравственности. Государство должно одобрительно относиться к усилиям религий и других идеологий в поддержке семейных ценности и гуманизма. Государство должно ограничивать последователей религий и идеологий от радикализации и архаизации общественных отношений. Метрики: 1. Наличие государственного контроля образовательных программ в религиозных учебных заведениях. 2. Не менее 90% процентов религиозных функционеров должны получать религиозное образование внутри страны.

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

Технологиялық Ұлт – партия инженеров (досужие ночные фантазии) (3/3)

Метрики: 1. Не менее 50% государственных служащих центральных органов должны составлять профессиональные инженеры (бизнес-аналитики, аналитики данных, архитекторы ПО, профильные инженеры). 2. Публичный реестр доходов государственных служащих и членов их семей (включая родителей, детей и внуков).

<На этом месте меня потянуло в сон, и ход мыслей замедлился>

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

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

<Пошёл спать. Продолжение будет потом, когда заниматься будет нечем. Или никогда>

Use Case 3.0 и Use Case 2.0: В чем разница?

Use Case 3.0 — это эволюция методологии моделирования юзкейсов, основанной Иваром Якобсоном. Она углубляет идеи Use Case 2.0, учитывая современный контекст Agile и DevOps.

1. Разделение на фрагменты (Slices)
В Use Case 2.0
• Идея Use Case Slices уже была (основной и альтернативные потоки разбиваются на «слайсы»).
• Это позволяло использовать юзкейсы итеративно, делая их менее громоздкими.
В Use Case 3.0
• Усилена роль слайсов для инкрементальной поставки ценности.
• Расширены рекомендации по применению в спринтах и при релиз-менеджменте.

2. Гибкость и минимализм
В Use Case 2.0
• Предполагался отказ от чрезмерной детализации, однако на практике иногда ведут большие документы.
В Use Case 3.0
• Ещё сильнее акцент на описании только ключевых аспектов, «лёгкой» документации и быстрой адаптации.

3. Интеграция с Agile и DevOps
В Use Case 2.0
• Учитывались принципы Agile: юзкейсы разбиваются на небольшие слайсы.
• Некоторые команды всё ещё использовали классические UML-схемы, не всегда «стыкуясь» с итеративным циклом.
В Use Case 3.0
• Фокус на тесной интеграции с CI/CD и DevOps, связывании с user stories и тестами.
• Предусмотрен механизм выбора слайсов на каждую итерацию.

4. Визуализация и коммуникация
В Use Case 2.0
• Основан на текстовом описании и UML, что может приводить к «толстой» документации.
В Use Case 3.0
• Используются современные способы визуализации (графы фрагментов, прототипирование).
• Упрощается взаимодействие аналитиков, разработчиков и заказчиков.

5. Фокус на ценности
В Use Case 2.0
• Идеи «feature-driven» и «value-driven» уже заложены, но иногда применяются формально.
В Use Case 3.0
• Каждому слайсу приписывается конкретная бизнес-ценность.
• Упрощается приоритизация и увязывание с реальными интересами пользователя.

Заключение
Use Case 3.0 — это продолжение, а не полный разрыв с 2.0. Главные отличия:
1. Use Case Slices (уже были в 2.0) получили ещё больше развития.
2. Гибкость и минимализм усилились.
3. Интеграция с Agile и DevOps стала более формальной.
4. Визуализация (лёгкие диаграммы, графы) помогает командам.
5. Фокус на ценности делает подход «value-driven» центральным.
Use Case 2.0 подходит при необходимости умеренного формализма и итеративного процесса.
Use Case 3.0 оптимален, если важны гибкость, бизнес-результаты, быстрая адаптация под Agile/DevOps.

Ссылки
1. USE-CASE 3.0 The Guide to Succeeding with Use Cases
2. Видео от авторов метода
3. Разбор «онтологического дребезга» от А.Левенчука

Граф создателей реальности и карта гипотез

Что такое стратегирование с точки зрения графа создателей и метода «карта гипотез»? Стратегирование представляет собой процесс проектирования новой, будущей реальности, в которую стратеги стремятся внести свои изменения: создать новые продукты или системы, а также изменить поведение определённых субъектов. При этом стратеги учитывают следующие аспекты:

1. Понимание текущей реальности: знание того, как устроена существующая среда (например, рыночная ситуация).
2. Видение будущего: прогнозирование изменений, которые произойдут в реальности (визионерство).
3. Проектирование новых объектов: разработка новых продуктов или систем с определением их характеристик, которые будут внедрены в новой реальности.
4. Изменение поведения субъектов: прогнозирование того, как изменится поведение участников среды вследствие появления новых объектов и деятельности проектной команды (системы-создателя), с определением характеристик этого нового поведения.
5. Определение выгод: формулирование того, что стратеги (владельцы) хотят получить от создания новой реальности.
6. Анализ ресурсов: осознание имеющихся ресурсов для работы проектной команды.
7. Формулирование гипотез: выдвижение предположений о том, как субъекты и контекст реальности будут реагировать на новые объекты и действия проектной команды.
8. Планирование стратегических задач для команды: определение ключевых задач, которые должна выполнить проектная команда.
9. Планирование задач по созданию команды: разработка стратегических задач, направленных на формирование и развитие самой проектной команды.

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

Для удобства оформления стратегии можно использовать метод «карта гипотез», разработанный Александром Бындю (о котором я уже писал ранее). На карте гипотез цветными стикерами выделяются:

1. Цели с показателями.
2. Ключевые субъекты: лица или организации, поведение которых планируется изменить в будущей реальности, включая их «боли» и желания.
3. Гипотезы: идеи стратегов о том, почему с помощью новых объектов и действий проектной команды удастся изменить поведение ключевых субъектов в создаваемой реальности.
4. Задачи по созданию новой реальности: действия, выполнение которых приведёт к достижению целей и подтверждению гипотез.

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

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

• Характеристики новых объектов (продуктов, систем).
• Изменения в поведении субъектов (например, желание покупать и/или использовать новый объект).
• Реакции контекста (конкурентов, других субъектов).
• Выгоды, получаемые владельцем проектной команды.

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

На графе создателей (см. диаграмму) в соответствии с принятой системой обозначений карты гипотез цели отмечены зелёным цветом, субъекты — оранжевым, гипотезы — жёлтым, а задачи — голубым.
#картагипотез

Рождественское чтение об ИИ - Маркус Хаттер и UAI

Маркус Хаттер (Marcus Hutter ) выдал публике Рождественский подарок – опубликовал ссылку на книгу «An Introduction to Universal Artificial Intelligence». В книге много информации, для понимания которой нужно неплохо разбираться в математике, поэтому я ее пролистал вскользь, и внимательно прочитал только главу о философии ИИ.

Маркус Хаттер – один из ведущих ученых в области ИИ, наиболее известен своей работой над Universal AI и AIXI.

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

AIXI – это теоретическая модель универсального агента, или конкретная реализация или такого «максимально рационального» агента, использующего универсальную (соломоновскую) индукцию и последовательное принятие решений.

Резюмирующие заметки на полях 16 главы «Philosophy of AI»:

1. Утверждает, что универсальная индукция AIXI (универсальный индуктивный вывод – Ray Solomonoff) решает проблему оптимального обучения. Основания:
a. Принцип Эпикура: «Если более одной теории согласуются с наблюдениями, сохраняй все теории».
b. Бритва Оккама: «Не умножай сущности без необходимости».
c. Правило Байеса.
d. Тезис Чёрча–Тьюринга: все физические процессы вычислимы.

2. Ставит вопросы о сознании ИИ, свободе воли, ощущении боли или удовольствия, наличии субъективного опыта, может ли машина думать, как ИИ может «телепортироваться» (самокопироваться). Естественно, на них не отвечает, но обозначает подходы, по которым можно рассматривать эти вопросы.

3. Задается вопросом о возможности создания AGI: приводит 4 аргумента против и 3 за.

4. Длинно рассуждает о различных определениях что такое интеллект. Из интересного – неформальное определение (там есть еще и формальное, с математикой) Legg–Hutter (LH) Intelligence: «Интеллект — это способность агента успешно достигать целей во множестве сред. В отличие от «способности решать только шахматы», ключевое, чтобы агент был универсален и мог осваивать любую новую задачу».

5. Рассуждает о Deep Learning и LLM – говорит, что последние годы их успехи привели к тому, что дебаты о возможности AGI сместились к обсуждению сроков и масштабов. Но замечает, что LLM до AGI не хватает долгосрочного планирования, отсутствия явной памяти и т. д., но, замечает, что «сочетание LLM с RL-подходами (Toolformer, Chain-of-Thought, MCTS) приближает нас к реализациям, похожим на AIXI».

6. Делает выводы: «AIXI и LH-интеллект не реализуемы в чистом виде из-за колоссальных вычислительных затрат», но «AGI достижим при достаточных вычислительных ресурсах и корректном учёте неопределённости».

Ссылки и допы:
1. Текст книги An Introduction to Universal Artificial Intelligence - http://www.hutter1.net/publ/uaibook2.pdf
2. Определение AIXI из сети:
«AIXI — это теоретический математический формализм для искусственного общего интеллекта. Он сочетает индукцию Соломонова с теорией последовательных решений. AIXI — это агент на основе обучения с подкреплением, который взаимодействует с некоторой стохастической и неизвестной, но вычислимой средой. Алгоритм работы AIXI:

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

Б. Обещанные вознаграждения взвешиваются с учётом субъективного убеждения, что эта программа составляет истинную среду. Это убеждение вычисляется из длины программы: более длинные программы считаются менее вероятными.

В. AIXI выбирает действие с наивысшим ожидаемым общим вознаграждением в взвешенной сумме всех этих программ.

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

Гибкая (эволюционная) архитектура

Читаю Нила Форда сотоварищи "Build Evolutionary Architecture: Support Constant Change". Первая редакция была в 2019 году, последняя – в 2022, русский перевод – 2024.

До 2000-х господствовал подход к архитектуре, что это нечто стабильное, не меняющееся. Потом стали появляться agile-методы, микросервисы и т.д. К 2020-ым развился подход, что архитектура – не закрепленные конструктивные решения, а базовые принципы системы, позволяющие ей непрерывно эволюционировать. Подходы эволюционной архитектуры обобщены в данной книге.

Подходы:
1. Эволюционная архитектура - это архитектура, которая способна непрерывно изменяться и развиваться с минимальными затратами, поддерживая при этом высокие стандарты качества и производительности.

2. Фитнес-функции – архитектура строится не вокруг конструктивных решений, а вокруг фитнес-функций - метрик, которые оценивают, насколько хорошо архитектура соответствует требованиям и может адаптироваться к изменениям. Группы метрик: масштабируемость, надежность, производительность, модульность, тестируемость и т.д. Не все фитнес-функции важны для каждой системы.

3. Секрет успешной разработки – постоянные инкрементные изменения с автоматизированной проверкой.

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

5. Топология (модульность конструкции) должна обеспечивать контролируемую связанность, которая позволяет системе эволюционировать.

6. Схемы баз данных должны строиться так, чтобы они также могли эволюционировать.

7. Необходимо искать баланс между связностью (внутренним «единством») и связанностью (внешними зависимостями) модулей. Для контроля связанности также должны использоваться фитнес-функции.

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

9. Эволюционная архитектура обеспечивает высокую адаптивность ПО и, как следствие, высокую адаптивность бизнеса.

По всем перечисленным темам в книге есть пояснения и примеры как это делать на практике.

Резюме: книга обязательна к прочтению не только архитекторам, но также аналитиками и ПМ.

Ссылки:
1. Форд Н., Парсонс Р., Куа П., Садаладж П. - Эволюционная архитектура – 2024 – https://drive.google.com/file/d/1Um6L5hXaILAjY5jtMfa1ETx3x8eRRQgR/view?usp=sharing

BABOK Guide и Ницше: путь аналитика от верблюда к сверхчеловеку

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

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

Верблюд: бери груз, не думай

На первой стадии вы — идеальный верблюд. Ваше предназначение — поглощать. Вы учите всё, что написано в BABOK Guide:

• Как правильно формировать требования.
• Как моделировать бизнес-процессы.
• Какие техники использовать в анализе и почему их именно 50.

Вы тащите этот груз безропотно, не задавая вопросов. Потому что на этом этапе ваша задача — впитать всё, что вам велено.

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

Но не переживайте, друзья. Это испытание надо пройти. Потому что только с таким «горбом» вы сможете перейти на следующую стадию.

Лев: да пошли вы со своими регламентами

Поздравляем, вы переработали столько методичек, что начали замечать их слабости. И вот он, ваш момент славы: вы превращаетесь в «льва».

Лев — это аналитик, который:

• Смотрит на BABOK Guide и говорит: «А зачем здесь 50 техник? Достаточно пяти».
• Смеётся в лицо тем, кто пытается продать ему «канонический подход».
• Критикует шаблоны, процессные карты и корпоративные регламенты за их формализм и тупость.

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

Ребёнок: пусть будет так, как нужно

И вот вы наконец становитесь ребёнком — или, если хотите, «сверхчеловеком». Это аналитик, который:

• Уже не злится на BABOK Guide, а использует его, как мастерский инструмент.
• Создаёт свои методологии и меняет их под задачу.
• Легко сочетает разные подходы, находя в каждом только лучшее.

Ребёнок открыт новому. Он любопытен. Но главное — он свободен. Он больше не пытается доказать, что «всё плохо», потому что он уже нашёл свой путь. И теперь его задача — создавать и двигаться дальше.

Почему начинать надо с BABOK Guide?

А теперь серьёзно. Вы не можете стать «сверхчеловеком», если у вас нет базы. BABOK Guide — это ваш старт:
1. Системность. Вы получите структурированное понимание бизнес-анализа: от выявления требований до стратегических решений.
2. Признание. Знание BABOK Guide позволяет говорить с профессионалами на одном языке.
3. Гибкость. Это база, от которой вы сможете отталкиваться, чтобы позже создавать своё.

Итог: от верблюда до творца

Путь аналитика — это не вечное таскание методологий. Это рост. Сначала вы учите, как правильно. Потом — кричите, что всё неправильно. И только потом вы начинаете создавать своё.

Поэтому, если вы хотите стать «сверхчеловеком» аналитики, начните с BABOK Guide. Наберитесь терпения, накопите знаний, отрастите «горб». И только тогда вы сможете перейти к стадиям «льва» и «ребёнка», где начинается настоящее творчество.

Зачем AGI онтологии?

"— Если имена не исправлены, то слова не соответствуют истине; если слова не соответствуют истине, то дела не могут быть совершены успешно" Конфуций. Лунь юй.

Посмотрел семинар AGI Russia на тему использования онтологий в ИИ. Что понял:

1. Нужны ли онтологии AGI?
Да. Основной вывод в том, что большие языковые модели (LLM) невероятно сильны в обработке языка, однако без онтологий трудно обеспечить:
• Устранение “галлюцинаций” путём проверки ответов на формальные знания и сценарии;
• Интеграцию с реальными бизнес-процессами (через сценарные и предметные модели);
• Верификацию решений в критически важных применениях.
В итоге получается «гибридный» подход: нейросеть (LLM) + онтология (граф знаний, формальная модель). Онтологии становятся тем «заземлением», которое даёт интерпретируемость и структурированность знаний, дополняя креативность и универсальность модели.

2. Нужна ли одна общая онтология «для всего»?
Нет. Скорее признано, что единой “универсальной” онтологии не существует и вряд ли она достижима. На практике лучше говорить о множествах специализированных онтологий, каждая из которых описывает определённую предметную область или сценарий, и о механизмах согласования (мета-онтология), если необходимо стыковать разные области. При этом «одна онтология на весь мир» не только чрезвычайно сложна в реализации, но и не обязательна: зачастую удобнее иметь локальные, отраслевые и проектные онтологии, которые можно расширять и согласовывать по мере необходимости.

Ссылки:
1. Конспект семинара - https://telegra.ph/Zachem-AGI-ontologii-i-sistemy-logicheskogo-nechetkogo-vyvoda---konspekt-seminara-AGI-Russia-01-14
2. Видео семинара – https://www.youtube.com/watch?v=5pQf9zib7-Y&ab_channel=siberai

Сова интуитивности на глобусе проекта, или как перестать мыслить «на глазок»

Бизнес-анализ – вещь, казалось бы, понятная. Вот проект, вот требования, вот клиент с горящими глазами и идеями наполеоновского масштаба. Ваше дело — всё это записать, структурировать, подписать, отправить и сдать. Условно, конечно.

Но как всегда, дьявол в деталях, а точнее — в том, что именно у вас внутри головы, пока вы «занимаетесь анализом».

S1 и S2: краткая теория натягивания совы

Даниэль Канеман (тот самый, который с Нобелевской премией) объяснил, что у нас есть две системы мышления.

• Система 1 (S1): это та, которая живёт на автомате. Видите пять яблок здесь и пять там — мозг уверенно сообщает: «десять». Или почти десять. Точность его не волнует, главное — скорость.

• Система 2 (S2): это медлительная, педантичная зануда. Если S1 говорит: «Дорога до работы займёт минут двадцать», то S2 полезет в расписания, проверит пробки, учтёт погоду и подсчитает, что вы опоздаете, потому что забыли заправить машину.

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

Недоаналитик и его интуитивная сова

Недоаналитик — это тот, кто мыслит интуитивно. Он не умеет объяснить, почему выбрал тот или иной подход, не понимает, зачем делает то, что делает – «все так делают, и я тоже».
Его S1 говорит ему: «Примерно так делал в прошлый раз — и в этот раз прокатит». И иногда это действительно работает. До тех пор, пока заказчик не спросит: «А почему именно так?» Или пока система не упадёт, потому что в спецификациях не учли половину реальных процессов.

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

Умный аналитик и его методологический глобус

Умный аналитик знает, что S2 — это не враг, а инструмент. Он вникает в методологию, чтобы понимать, как устроены проекты, и умеет думать не только о «что нужно сделать», но и о «как и зачем это делать», и «почему люди решили, что удобнее делать именно так».

Вот его дорожная карта:

1. Начните с BABOK Guide. Для первого этапа это ваш священный текст. Даже если половина из него будет казаться вам избыточной — вторая половина объяснит, как перестать гадать на кофейной гуще.

2. Изучите системную инженерию (SEBoK). Звучит скучно? Да. Полезно? Абсолютно.

3. Поймите плюсы и минусы, а также истоки BPMN, UML и ArchiMate. Это не просто стрелочки и квадратики. Это ваш новый язык общения с миром сложных систем. Разберитесь в ограничениях этого языка.

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

Как перестать натягивать сову на глобус?

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

Освойте S2, погрузитесь в методологию, научитесь мыслить формально. Это не сделает вас сверхчеловеком, но часто спасёт от проблем, которые появляются, когда вы уже согласовали всё с клиентом, а потом понимаете, что «там что-то не учли».

Хотите стать настоящим аналитиком? Уберите сову в шкаф. И возьмите в руки BABOK Guide.

Написал про Технофеодализм в неайтишном блоге. Поскольку тема пересекается с IT, оставлю здесь ссылку:

https://t.me/thinkingbyletter3/19

Как в крупной компании из 1 архитектора вырастить 100+ (1/2)

Посмотрел видео 2021 года семинара Школы системного менеджмента по опыту внедрения архитектурного мышления в крупной компании (Awem Games, как я догадываюсь) от Ивана Подобеда. Вдохновился. Конспект:

1. Задача: «вырастить сотню архитекторов»

• Компания быстро растёт (несколько сотен сотрудников, более 500 млн $ капитализации), есть десятки команд, каждая разрабатывает свой функционал.
• При этом наблюдались классические «болезни роста»:
o Проекты начинали без проработанной архитектуры,
o Эксперты-инженеры становились «бутылочным горлышком»,
o Команды порой дублировали или ломали уже существующий функционал.

Решение: внедрить простой, но массовый процесс описания «solution-архитектуры» для каждой новой фичи или подсистемы, обучив этому всех командных инженеров (а не выделенных архитекторов).

2. Выбранный инструмент и подход

1. Confluence в роли «простого» репозитория архитектурных описаний:
o Сам по себе Confluence привычен для инженеров, его выбрали путём опроса (оппонентом были другие вики-системы),
o В нём хранятся шаблоны («solution design template») и типовые чек-листы.

2. Шаблон описания фичи (solution design):
o В одну «фичу» попадает короткое описание проблемы (pitch), затем продуктовые детали (требования, метрики), а в финале — архитектурная часть (роли, сущности, компоненты).
o Функциональные модели (домены, сущности, роли, компоненты, интерфейсы) описываются по принципу «минимальной формализации»: люди заполняют разделы под строгие типы полей, но в читаемом виде.

3. Онтология и «справочники»:
o Сущности (entities) отсылаются к общекорпоративным бизнес-доменам: команды не выдумывают заново, а используют готовые типы (либо добавляют в общий список).
o Аналогично с ролями (внешние пользователи, внутренние, негативные акторы и т. п.).
o Компоненты пока перечисляются свободно, но ожидается их объединение в общий справочник.

4. Интеграция с рабочим потоком:
o Основные задачи ведутся в Jira и «подтягиваются» в Confluence, где заполняется solution design.
o Эксперты дают «review» (нет жёстких гейтов), команды получают обратную связь в slack-канале, правят модель.
o За первый квартал по новым правилам оформлено порядка 35 фич (с нуля до итогового описания).

3. Организация массового внедрения

1. Модель 8 шагов изменений (Джон Коттер)
o Сформировать «острое чувство необходимости» (случаи провалов без архитектуры),
o Найти «агентов перемен» (своих энтузиастов и лидеров),
o Показывать быструю победу (примеры фич, в которых шаблон помог сэкономить время и избежать проблем),
o Расширять успех и закреплять культуру.

2. Упор на «обучение через практику»
o Минимум сложных терминов, небольшие справочники, чек-листы в виде легкодоступных шаблонов,
o Каждый инженер/продакт в команде способен кратко описать «что за роль, какой домен, какой компонент» — без тяжёлых UML и ArchiMate.

3. Гибкость и отсутствие жёстких «гейт-процедур»
o Нет формальной «архкомиссии», которая одобряет/запрещает. Есть лишь общий канал для анонса готовой фичи и добровольных review.
o Это снижает страх у команд: они воспринимают архитектурную практику как помощь, а не тормоз.

Как в крупной компании из 1 архитектора вырастить 100+ (2/2)

4. Результаты и выводы

• Уже за 3 месяца более 30 крупных фич описаны с применением нового solution design, причём команды справляются сами, обращаясь за консультацией к «группе двух человек» (архитекторов-координаторов).

• Существенно улучшилась «прозрачность» и единообразие: в Confluence видны все решения (бизнес-домен, роли, компоненты, data flow).

• Культура осознанного проектирования формируется, а инженеры учатся «набегу», пополняя собственный «послужной список» архитектурных решений.

Планы:
• Во втором квартале укрепить «техдизайн» (углублённую техническую часть: интерфейсы, протоколы, миграции), снова «закрутить» 8 шагов изменений для новой волны практик.
• Продолжить сохранять формат «нет гейтов, а самоорганизация + добровольное ревью», чтобы не лишать команды гибкости.

5. Общий контекст и значение

1. Синтез «простой вики» и «архитектурных» методик
o Практика показывает, что графические или сложноформальные инструменты (ArchiMate, MagicDraw) тяжело приживаются в массовой среде (100+ разработчиков).
o Подход «минимально формализованного текста» (типизированные поля + легко доступные шаблоны) оказался успешным компромиссом.

2. Развитие системного мышления
o Каждый инженер фактически приобщается к основам архитектурного анализа: учится различать роли, сущности, компоненты, data flows.
o Тем самым распространяется культура осмысленной системной инженерии (с опорой на онтологию компании).

3. Пример «state of the art»
o Доклад демонстрирует, что массовая архитектурная практика в софтверной компании возможна, если:
 встроиться в уже используемый «продуктовый» процесс,
 дать простые «безопасные» форматы,
 воспитывать архитектурное мышление у каждого через обучение и ролевую модель («мы все — архитекторы, принимаем решения сами»).

Резюме: история показывает, как реально, без громоздких инструментов и жёсткой вертикали, вырастить «сто архитекторов», то есть сделать каждую команду способной к осознанным архитектурным решениям. При этом критичен упор на обучающие шаблоны, чек-листы и открытые review, а также бережное изменение организационной культуры по модели Коттера.

Ссылки:
1. Видео «Как из 1 архитектора вырастить 100+ архитекторов. Доклад Ивана Подобеда» - https://www.youtube.com/watch?v=JlXeQxAkDf0&ab_channel=%D0%A8%D0%BA%D0%BE%D0%BB%D0%B0%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE%D0%BC%D0%B5%D0%BD%D0%B5%D0%B4%D0%B6%D0%BC%D0%B5%D0%BD%D1%82%D0%B0

Блеск и нищета электронного правительства при работе с данными

Ознакомился с записью вчерашнего семинара AGI Russia на тему «Система управления базами знаний в контексте управления данными». Больше всего меня тронула тривиальная, в общем-то, фраза со ссылкой на DAMA-DMBOK: для сложных систем при работе с данными важно правильно выстроить подсистемы хранения метаданных и подсистемы мастер-данных (справочных данных). И я в очередной раз восхитился самоотверженности и героизму разработчиков систем нашего электронного правительства. Представьте себе:

1. Для большинства важных справочных данных в стране нет эффективной системы управления данными, для обеспечения надежности и непротиворечивости.
2. В стране нет общедоступных описаний метаданных общих объектов, использующихся в десятках систем.

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

Я не удивлюсь, если они каждый день перед работой подобно древним гладиаторам восклицают: «Ave, Deus Chaos, moritūrī tē salūtant!» (Слава, бог хаоса, идущие на смерть приветствуют тебя!)

Ссылки:
1. Видео семинара «Система управления базами знаний в контексте управления данными» - https://www.youtube.com/watch?v=5pxIDlKa46w&ab_channel=siberai
2. Конспект выступления Алексея Незнанова - https://teletype.in/@nicksu/DCTWDA3AJaf
3. Слайды презентации - https://github.com/agirussia/agirussia.github.io/blob/main/presentations/2025/Neznanov_KnowledgeManagement4DataManagement_2024.pdf

Почему системные аналитики под ударом ИИ?

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

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

А что с бизнес-аналитиками?

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

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

Как остаться в игре?

Сейчас самое время задать себе вопрос: что вы можете сделать, чтобы не оказаться в числе тех, кого заменят?

Путь 1 – дрейф в сторону бизнес-анализа:

1. Изучайте бизнес. Разбирайтесь в том, как работает экономика компании, что такое метрики и почему они важны. Чем лучше вы понимаете бизнес, тем сложнее вас заменить.
2. Развивайте soft skills. Переговоры, фасилитация, общение со стейкхолдерами — это то, что делает вас незаменимым. Люди ценят тех, кто умеет договориться.
3. Освойте ИИ. Используйте алгоритмы как инструмент, который усилит вашу работу. Это не угроза, а возможность быть продуктивнее.
4. Расширьте методологический кругозор. Познакомьтесь с BABOK Guide.

Путь 2 – из «среднего» СА станьте элитой СА:

1. Освойте системную инженерию: изучайте жизненный цикл систем (SEBoK, INCOSE), чтобы проектировать комплексные решения.
2. Развивайте системное мышление: думайте не только «что» и «как», но и «зачем», находя взаимосвязи в широком контексте.
3. Углубляйте фундамент: математика, алгоритмы, концепции информатики — залог глубины анализа и точных решений.
4. Осваивайте методологии: помимо UML/BPMN, изучайте TOGAF, ITIL, BABOK и адаптируйте инструменты к проектам.
5. Расширяйте технический кругозор: понимайте основы архитектуры, DevOps, безопасности.
6. Прокачивайте soft skills: коммуникация, фасилитация, переговоры.
7. Используйте ИИ: автоматизируйте рутину, освобождая время для стратегического анализа.

Резюме: Если вы «ботаник», инженер по призванию – станьте классным инженером, это трудно, но и зарабатывать будете на порядок больше. Если вы «гуманитарий» - двигайтесь в сторону БА.

IIBA выпустил новую версию стандарта The Business Analysis Standart v2.0. Сделал сравнение двух версий по разделам. Сравнение и ссылки на тексты версий здесь - https://teletype.in/@nicksu/MofFHKZuEmZ

Кто должен делать ТЗ для ГО в Казахстане (1/2)

В прошлую пятницу занесла меня судьба на круглый стол представителей IT-бизнеса с министром ЦРИАП. Среди прочего была озвучена проблема (Евгений Максимов) разработки технических заданий на информационные системы государственных организаций. Суть проблемы:

1. Для разработки качественных ТЗ у ГО нет компетенций.
2. ГО сваливают эту задачу на подрядчиков.
3. Стоимость проекта определена заранее.
4. ГО часто не имеют достаточных компетенций не только в части ИТ, но и в части адекватного описания собственной деятельности (бизнес-процессов).
5. Подрядчики тратят много времени и ресурсов на бизнес-анализ, выясняя что же ГО нужно на самом деле, при этом пытаясь вписаться в заранее ограниченный бюджет и оставшийся срок реализации проекта (бюджетный цикл у нас годовой – поэтому нужно успеть от проведения конкурса, создания и согласования ТЗ реализовать систему).

По ходу краткого обсуждения на круглом столе прозвучало несколько идей, главная из которых – сделать этап разработки ТЗ отдельным проектом и отдать этот этап компетентным разработчикам.

Что можно добавить? Не сказать, что тема новая: помню мы еще в 2008 году обсуждали вопрос, что хорошо бы было если бы ГО разрабатывали ТЗ отдельным проектом. Замечательно, что мы дожили до обсуждения данного вопроса на государственном уровне. Но что же можно предложить?

Варианты:
1. В госорганах появятся свои компетентные в ИТ и бизнес-анализе специалисты.
2. Компетентные специалисты появятся в одном ГО, который будет делать ТЗ для всех остальных ГО.
3. Будет создан институт аккредитованных экспертов по созданию ТЗ для ИС ГО.
4. Всё остается «как есть».

Разберем:

Вариант 1. В госорганах появятся свои компетентные в бизнес-анализе и ИТ специалисты.
• Утопия: Методологи ГО массово освоят бизнес-анализ, процессный анализ, анализ данных, основы ИТ. Качество ТЗ и эффективность госуправления вырастут на порядок. Обучившиеся эксперты не уйдут в частный сектор, а останутся работать в ГО на маленьких зарплатах, движимые патриотизмом и интересом к сложным задачам.
• Антиутопия: Введут несколько дополнительных экзаменов и курсов повышения квалификации для госслужащих по теме "Основы составления ТЗ на базе ИИ и блокчейн". По факту, ТЗ продолжат писать секретари и юристы в последний момент, а на экзаменах будут списывать. Ничего не изменится, кроме увеличения бюрократической нагрузки.

Вариант 2. Компетентные специалисты появятся в одном ГО (условный "Центр Разработки ТЗ"), который будет делать ТЗ для всех остальных ГО.
• Утопия: Создается элитное подразделение "ГосТехЗадание-Инновация", куда стекаются лучшие умы страны. Они разрабатывают стандартизированные, кристально чистые и идеально проработанные ТЗ для всех нужд госсектора. Проекты реализуются точно в срок и в бюджет, эффективность госуслуг достигает 100%. Все ГО счастливы делегировать эту сложную работу супер-профессионалам и получают предсказуемый результат.
• Антиутопия: Возникает мега-бюрократический монстр "Единый Республиканский Оператор Технических Заданий" (ЕРОТЗ). Очередь на разработку ТЗ растягивается на годы. ТЗ пишутся по универсальным, оторванным от реальности шаблонам, абсолютно не учитывая специфику каждого отдельного ГО. Госорганы тратят больше времени на "перевод" этих ТЗ на понятный язык и попытки их адаптировать (или обойти), чем если бы писали сами. Ответственность за провалы размыта, крайних не найти.

Кто должен делать ТЗ для ГО в Казахстане (2/2)

Вариант 3. Будет создан институт аккредитованных негосударственных экспертов по созданию ТЗ для ИС ГО.
• Утопия: Формируется прозрачный, конкурентный рынок высококвалифицированных и независимых экспертов и консалтинговых компаний, прошедших строгую, но справедливую аккредитацию. ГО получают доступ к лучшим практикам, инновационным подходам и могут выбирать исполнителя для разработки ТЗ на конкурсной основе, ориентируясь на качество и опыт. Госпроекты выигрывают от свежего взгляда и глубокой экспертизы.
• Антиутопия: Аккредитация превращается в очередной "клуб для своих" или формальность для получения госзаказов. Небольшой пул "придворных" консалтинговых фирм, получивших аккредитацию по непрозрачным критериям, делит между собой все контракты. Цены на услуги "сертифицированных гениев" взлетают до небес, а качество ТЗ остается посредственным, так как реальной конкуренции нет. ГО вынуждены работать с теми, "кого назначили", даже если их экспертиза вызывает сомнения.

Вариант 4. Всё остается как сейчас.
• Утопия: На самом деле сложившаяся система демонстрирует удивительную гибкость и саморегуляцию! ГО, не обремененные сложной IT-экспертизой, гениально транслируют свое "видение" и стратегические потребности на полутора страницах текста. Подрядчики, как опытные Шерлоки, мастерски дешифруют истинные потребности, проявляя чудеса адаптации к фиксированному бюджету и годовому циклу. Это уникальный симбиоз, где каждый год рождаются системы – не всегда идеальные, зато свои, родные, проверенные временем и бюджетными ограничениями. "Работает – не трогай" становится девизом стабильности и непрерывного освоения средств.
• Антиутопия: Ежегодный "День Сурка": ГО объявляют конкурсы с размытыми ТЗ и заранее определенной стоимостью. Подрядчики, заложив в смету "коэффициент на непредсказуемость заказчика", неделями и месяцами пытаются вытянуть из некомпетентных сотрудников ГО хоть какую-то конкретику, пока тикает годовой бюджетный цикл. Системы сдаются в последний момент, сырые, с урезанным функционалом, не отвечающие реальным нуждам, потому что "надо было освоить бюджет до конца года". Эффективность госуправления продолжает падать, граждане и бизнес недовольны, а на следующий год все повторяется с новой силой и новыми "инновационными" проектами на старых граблях.

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

Почему бизнес-аналитик должен быть умнее чем системный аналитик

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

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

К чему реплика? Наши уроки про ТЭО - это не совсем про ТЭО, а больше про бизнес-анализ на сложных проектах. Сложный бизнес-анализ. Это вам не апишечку описывать, тут думать надо, и искать нетривиальные решения.

Кто хочет научиться думать приходите на занятие завтра. Ссылка для регистрации - https://kazakhstan.iiba.org/events/teo-1/