Русский перевод Guide to Product Ownership Analysis: приглашение к сотрудничеству

Перевожу профессиональный стандарт по аналитике в продуктовой разработке - Руководство по POA от IIBA. Перевел 40 страниц из 300 (за исключением картинок). (UPD. Уже 298 стр.)

Если кто-то хочет внести свой вклад в перевод, то по ходу перевода может понадобиться следующая помощь:

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

2. Хорошо бы сделать сводный англо-русский словарь терминологии БА, объединяющий термины из BABOK Guide, Guide to BDA, Guide to POA, Agile-extention to BABOK Guide, Strategy to Execution Framework - я понимаю, что это сильно упростит и ускорит процессы переводов стандартов и формирования русскоязычной терминологии по БА в русскоязычных коммьюнити аналитиков, но пока не могу найти на это времени. Возможно кто-то может взяться за этот подвиг.

Свои замечания и предложения можно писать в комментах к этому посту.

Ссылка на черновик перевода: https://docs.google.com/document/d/19qxsnvFgvpDjTjJ6zRAPnDfE3_pT1NGrbO8--0Ngp_g/edit?usp=sharing

#переводы #iiba #бизнесанализ

Сделал каталог казахстанских телеграм-каналов и групп по IT (87). У кого есть что добавить - пишите в комментарии.

https://docs.google.com/document/d/1iBSwKB1rmmRo_Jw1r4ra4fjjdkdjUh1cwi2TEt6JD2U/edit?usp=sharing7

Карта процесса-опыта и люди с квадратными подбородками

Однажды я участвовал в проекте по реинжинирингу бизнес-процессов большого ведомства. Заказчики – мужчины и женщины с квадратными подбородками, холодными глазами и не очень высоким лбом. Описание бизнес-процессов надо было делать так, чтобы заказчик его понимал.

Как вы можете догадаться, не подходили категорически: BPMN, CJM, UML, Service Blue Print и прочие приятные вещи. Пришлось использовать «прямоугольники-стрелочки-дорожки» и упрощенный SIPOC. На каждый бизнес-процесс мы делали карточку процесса, отдельные важные процессы рисовали на диаграмме. Заказчики и это понимали не очень ясно, но можно было как-то объяснить.

Недавно я увидел интересный метод «Карта процесса-опыта» Андрея Шапиро. Этот метод интересен тем, что при описании бизнес-процессов позволяет соблюсти определенный баланс между простотой, понятностью, информативностью. Метод объединяет некоторые из преимуществ CJM, Service Blue Print и классического «стрелочного» потока работ, с возможностью указания каналов, входов/выходов и другой важной информации. Возможно, если бы я был знаком с этим методом несколько лет назад, то я использовал бы именно его на пользу людям с холодной головой, чистыми руками и горячим сердцем.

Советую попробовать, а кто пробовал - поделитесь опытом, плиз.

Ссылки:
1. Статья и сайт с описанием Карты процессы-опыта – https://ashapiro.ru/articles/xpm
2. Видео мастер-класса по описанию процесса фасилитации стратегирования с помощью карты процесса-опыта – https://www.youtube.com/watch?v=uQPyVQFlzRo&t=110s&ab_channel=AndreiShapiro
3. Телеграм-канал метода – https://t.me/xpmap
4. Методичка – https://ashapiro.gitbook.io/xpm

#бизнесанализ #картапроцессаопыта #андрейшапиро

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

Пока сегодня стоял в пробках послушал любопытный подкаст с Владимиром Алиповым. Владимир – врач, нейробиолог, блогер, занимается исследованиями мозга в России и США. Из интересного:

1. IQ тесты хорошо работают для людей среднего интеллекта, в пределах от 100 до 115. Чем выше, тем они менее точные. Если сравнивать между собой людей с показателями выше 130 – то это малоинформативные данные. (Теперь понятно почему проф. Сергей Савельев часто говорит, что первые IQ тесты созданы Айзенком только для отбора посредственностей и не пригодны для отбора людей с незаурядными способностями, о чем, якобы, возмущался и сам Айзенк, когда его тесты использовались не по назначению. Также понятно почему, когда я сдавал несколько разных тестов лет 35 назад, то они показывали высокие результаты, но с очень большим разбросом значений.)

2. Еще IQ тесты хорошо работают чтобы отсеять совсем неспособных. Например, одно время из-за дефицита призывников, в армию США стали брать людей с IQ ниже 80% (в США таким примерно 15% населения), как оказалось, вред, который они наносят собственной армии в ходе службы, обходится дороже по сравнению с приносимой пользой – практику отменили.

3. Несмотря на недостатки IQ тестов, есть хорошая корреляция между уровнем IQ и профессиональным и социальным успехом.

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

5. Это объясняет почему несмотря на то, что тестирование на IQ мужчин и женщин показывает почти одинаковые результаты (статистическая разница есть, но она очень небольшая), девочек в IT и в STEM в среднем не больше 10% - они просто не любят такие задачи, но любят задачи, связанные с тем, что называется EQ – эмоциональный интеллект. Это также объясняет гендерный дисбаланс в различных профессиях. Некоторые отдельно взятые женщины могут быть много умнее некоторых отдельно взятых хороших программистов, и они даже потенциально могли бы быть более хорошими программистами, но им не интересно решение задач такого рода.

6. Интеллект в различных социальных группах отличается очень сильно. 👇👇👇

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