#KnowledgeConf Денис Кучеров. Ошибки в менеджменте знаний: в качестве аргументации – страшилки. Доклад о том, что во многих компаниях вместо базы знаний - файловая свалка знаний с исторически сложившейся структурой или нечто аналогичное, где даже автор документа ищет его 20 минут. А потому сотрудники пользуются шпаргалками и устным творчеством. В докладе это показано через топ-5 ошибок, но это, лишь разные аспекты свалки вместо базы знаний. При этом Денис работает в Minervasoft с реальными проектами, каждая проблема иллюстрирована кейсами из реальных проектов, помимо примеров из Корпорации монстров, которые оживляли доклад. Понятно, что для доклада кейсы-страшилки отбирались, но по моему опыту свалки знаний действительно часто встречаются.

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

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

#KnowledgeConf Артем Варкулевич из Онтонет. Совместное мышление: усиливаем команду инженерными подходами в управлении знаниями. Для меня это доклад про странную реальности, где архитектор занимается тем, что ведет бесконечные реестры, а аналитики пишут разрозненные статьи. И дальше инструмент дает возможность строить связи между объектами, которые и являются строками реестров. По сути получается структурирование этих самых реестров, например, чтобы из реестра фич или хотелок пользоватлей получить вектора развития продукта в целом. При этом такая картина развития продукта ценна не столько для PM, у которого она в голове есть, сколько для команд и разработчиков - они начинают видеть, как их конкретные фичи ложатся в общее направление развития продукта. Можно получить связки между фичами и пользовательскими историями, и дальше при изменении фичи понимать, на что могут повлиять изменения и так далее. Это все - понятные действия, а вот почему они позиционируются как создание онтологии - мне непонятно. В целом концептуальная конструкция состоит в том, что мы с помощью моделей описываем продукт, как привычно в ИТ, а вот мир вокруг продукта описываем с помощью онтологий, а не используем описание бизнес-уровня на языке Archimate или аналогичном. Вероятно, это специфика самого разрабатываемого продукта - онтонет, который они для себя тоже используют. Это не слишком просто понять без примеров, а их в докладе было мало, был очень большой рассказ о том. каких результатов они достигли за счет своей методики, а вот сама методика раскрыта слабо, а примеры - фрагментарны. Я, в общем, из описания доклада онтологию в нем увидеть. Жаль.

В понедельник был на #KnowledgeConf - конференции по управлению знаниями в ИТ. Конференция первый раз прошла в 2019 в двухдневном формате, в 2020 была вынуждена уйти в онлайн, потом несколько лет шла как отдельный трек на Teamlead, а сейчас прошла отдельно. Один день, три трека докладов и один мастер-классов. 300 очных участников, что вполне неплохо.

Я публиковал заметки с докладов прямо в ходе конференции, а теперь собрал их в единый отчет https://mtsepkov.org/KnowledgeConf-2025. Основной фокус - практика: онбординг, получение знаний от экспертов и так далее. По вопросам организации и структурирования знаний, по их различным способам представления докладов не было, и меня лично это огорчает. Потому что из опыта я знаю, что есть проекты и продукты с хорошей документацией, а есть - с плохой и непонятной. Люди озаботились написанием, но у них не получилось. Так что это важный практический вопрос: чем как создать именно хорошую документацию. чем она отличается от плохой.

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

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

Я на #ЛАф, мой доклад был открывающим и слады уже опубликованы на моем сайте https://mtsepkov.org/ProjectModel-LAF

#ЛАФ Регина Шарафутдинова и Мария Хромых из Газпромнефти. Будущее бизнес-анализа: Роль критического мышления в эпоху автоматизации и ИИ. Рассказ про новую реальность, в которой аналитик активно использует ИИ. Как для того, чтобы создать варианты решений, так и затем, чтобы обработать интервью. То есть по-максимуму вынести свою мыслительную работу на аутсорсинг. При этом важный аспект - подвергать сомнению. И интервью, и предлагаемые решения. То есть владеть критическим мышлением.

Критическое мышление - активная позиция, когда мы принимаем информацию на веру, обращаем внимание на факты, учитываем контекст.
* Сомневаться разумно - блокировать эмоции и автопилоты, не вестись на очевидное. Самые опасные ошибки - там, где "всем понятно". Отслеживать эмоциональность и предвзятость.
* Думать строго - про логичность, структурность, четкость. Тезисы, аргументы, если связь между ними. Замечать неявные предположения, о которых умалчивается, часто в них суть
* Проверять коварно - не залипать на первой гипотезе, смотреть спектр вариантов.

Критическое мышление тоже можно зашить в промпт. В докладе много примеров, как ИИ создает решения, которые надо проверять, а для начала - в промпте ставить задачу получить несколько гипотез и объяснить их. И наоборот, как ИИ анализировал интервью и подсвечивал там разрывы логики и проблемные моменты. Например, что заказчик говорит о бесполезности какого-то функционала, а фактически он не пользуется, потому что там сильно неудобный UI/UX. Впрочем, примеров, что ИИ проверяет ответы ИИ - не было.

Доклад интересный. Но я хочу заметить, что есть два принципиально различных варианта мышления: нарративное, примером которого являются литературные тексты, но в повседневной жизни ей пользуются, и мышление структурными моделями разной степени формализации, при котором ты выделяешь типы и экземпляры объектов и не путаешь их, различаешь роли и индивидов, которые их играют, и так далее. ИИ мыслит нарративно. Так вот, доклад был об нарративном мышлении. Критическое мышление было лишь инструментом проверки нарративных текстов на формальную логику, разрывы аргументации, что важно. Но для аналитиков важнее структурное мышление моделями, и даже когда ему поступает текст - он должен его разметить, выделить понятия, определить их типы и так далее. ИИ, кстати, это тоже частично умеет - если специально попросить. Это базовое умение есть не у всех, в школе и институте этому не учат. В Школе системного менеджмента Левенчука об этом был курс Онтологики Прапион Медведевой, который сейчас вошел как часть курса Рациональной работы.

А про причинную связь и отличие причин от корреляций я тут хочу порекомендовать книгу The Book of Why (есть по-русски), в которой как раз рабирается современная разделение причин от корреляций на материале проверки лекартсв, вывления причин болезней и других подобных темах. Таам не тривиально.

#ЛАФ Анастасия Кайнова. Deep Dive in Problem Solving: опыт сотрудника поддержки в карьере аналитика. В докладе кейсы, как углубляться в устройство системы. При этом надо не просто уметь работать слогами, но и заглядывать в код, например, чтобы заметить отсутствие сортировки, понимать структуру передачи сообщений, когда между фронтом и бэком могут быть фильтры и прокси, так что сообщения не доходят. И, конечно, надо докапываться до причин - что не работает, почему возник запрос. Потому что задача по созданию отчета об опозданиях сотрудников может иметь в основе проблему, что система регистрации по пропускам работает плохо и отправляет данные с задержкой или теряет их - то есть реальных опозданий нет, после наладки системы задача отпала. В доладе много классных примеров. Спасибо!

Для тех, кто на #ЛАФ. Этого не было в программе, а рассказ ожидается очень интересный.

Завтра, 8 июня в 12-00 в зале Кострома будет мой мини- доклад "BABOK для чайников, или почему я не зря куплю эту толстую книжку".

#ЛАФ Артем Шуткин. Аналитик как страховой агент взаимозаменяемости участников команды. Доклад об актуальной теме: как быть готовым к рискам ухода сотрудников, в том числе внезапным. Не всегда это печальные, как болезнь или увольнение, может быть и свадьба или повышение. К этому надо быть готовым, и не только по вашей команде, но и по команде заказчика, уход в середине проекта РП заказчика, с которым было много неформальных согласований или ключевого пользователя. который все согласовывал - серьезный риск для проекта. И нужны сценарии действий, нужна оценка трудоемкости замены. И исходя из них - поддержка артефактами, фиксирующими знаниями, и организация перекрытия ответственности, которая создает буфер из людей, которые могут подхватить работу. В докладе все изложено относительно структурно. Один из артефактов - матрица RACI, из которой должны быть риски по уходу сотрудников.

Я долгий срок работы сталкивался с разными ситуациями, включая попадание ключевого разработчика платформы в больницу с аппендицитом за неделю до планируемого выхода первой версии для использования всей команды - пришлось подхватывать на лету, или уход на повышения спонсора проекта у Заказчика. Проблема актуальная, может реализоваться самый неожиданный сценарий и к этому надо быть готовым. А еще на одной из конференций я слышал доклад, как отдел тестирования устроил практическое тестирование bus-factor: было запланировано, что через две недели все тестировщики меняются друг с другом проектами на неделю. Тестирование показало, что больших провалов нет, но две недели подготовки все-таки недостаточно, даже когда информация есть заранее - и они дальше сделали план изменений, чтобы увеличить устойчивость.

#ЛАФ Наталья Седова из Skillbox. Карта компетенций как вариант оценки и развития навыков аналитика. При команде 15+ неформальное понимание о компетенциях сотрудников уже не укладывается в голове, его надо выложить в экзокортекс и сделать нагладным, а для этого - сделать структурным. Так появляется задача сделать карту компененций. Она к ней подступалась несколько раз, но заканчивалось все длинными mindmap навыков на 225 вопросов, с которой непонятно что делать, стандартная оценка нет/знает/применяет/может обучить - не прививается в компании. Она поменяла подход. Создание карты запустила как командный проект, с разделением по задачам и людям. Это дало нужный организационный фокус, а еще карта компетенций получилась коллективным достоянием, она не была в одной голове. И это позволило оценивать карту компетенций через интервью с обсуждением вместо формальной оценки.

В карте 85 вопросов, которые они сочли актуальными, с разным уровнем сложности и оценкой по баллам. На некоторые можно дополнительно приложить артефакты, которые подтверждают умения, например, BPMN-схемы, и это дает дополнительные баллы. Прошло успешно, интервью вели тимлиды, и нагрузка была тоже распределена по времени, не более часа в неделю, чтобы для основной работы было незаметно. Сотрудники восприняли позитивно, как внимание компании. А еще интервью оказалось способом освежить знания, не все темы одинаково используются в работе. Так что решили каждый год повторять. Опасались, что воспримут как экзамен, это не случилось, наверное потому, что опасность понимали и заранее давали разъяснения. Список вопросов не давали, только набор тем, так как задачей было оценить навыки, а не результат зубрежки. которую завтра забудут. Но при этом в интервью не мешали рассуждать и раскрывать вопросы, это и по форме не было экзаменом, скорее собеседованием.

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

#ЛАФ Ирина Гертовская. Почему требования – не всегда требования. А если не требования – то что? Ответы на вопросы в чатах аналитиков. Первая часть доклада - про разрыв между целями и задачами бизнеса, и требованиями. Аналитиков учат слушать стейкхолдеров, и дальше превращать это в требования. При этом стейкхолдер говорит, что ему ближе. И реальная задача аналитика - не превращать быстро информацию от стейкхолдеров в требования к системе, а восстановить комплексную картину целей и задач, и на основании ее уже сделать требования.

Дальше были инструменты из BABOK: схема BACCM со связями: начинаем с контекста (предметной области) и стейкходеров, а затем надо понять потребности стейкхолдера и ценности - ради чего работает бизнес. Ключевой вопрос даже не "Зачем", а "кому нужно (кто будет деньги выбивать)?" - и у него спрашивать "зачем?". Далее области знаний, это по сути треки в проекте. И техники, которых в BABOK 50 с описанием на 185 страниц. И это - справочник, в который полезно заглянуть, чтобы не упустить что-то важное в новом проекте, чего у вас не было в предыдущих.

А при формирование требований не забыть полезна модель Грейди FURPS - функциональность, то есть выполнение системой своих функций. В ней, помимо основных функций - поддержка: администрирование, логгирование, инфобез, почта и соцсети, подсказки, печать...

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

#ЛАФ Евгений Скориков. Декомпозиция и композиция функциональных моделей при цифровизации бизнес-процессов на практике в аспекте множественности и параллельности. В докладе - концептуальный взгляд на бизнес-процессы как на последовательность преобразования ресурсов, которые связываются на каких-то шагах в процессах, потом освобождаются. При этом речь идет о самых разных ресурсах - товарах, людях, кассовых местах и так далее. При этом в деятельности у нас одновременно идет множество процессов и множество ресурсов, и надо обеспечивать связывание и отслеживание этих связей.

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

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

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

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

#ЛАФ Ильназ Хайдаров из Московской биржи. Интеграция как предметная область: чем и как управляем? Идея доклада - сделать систему, чтобы иметь описание всех интеграций. Для этого поставщик интеграции регистрирует OpenAPI и регистрирует его в системе, и потребители тоже фиксируют использование конкретных интерфейсов. А дальше доступ между системами в тестовом и в боевом контуре поднимается на основе зарегистрированных интеграций, при этом в тестовой среде контролируется соответствие API, а в боевом контуре есть возможность включать мониторинг и контроль избирательно. Ну и дальше наворачивать сервисы, например, уведомлять команды-потребители при изменении API в тестовом контуре, и не проносить на прод, пока не получишь подтверждения. Понятная и полезная конструкция.

Я хочу отметить, что в ноябре на AnalystDays Лев Немировский из ПСБ делал аналогичный доклад, но для асинхронных интеграций, которые описываются спецификацией AsyncAPI.

#ЛАФ Ирина Баржак. Менеджмент конфликтов. Ирина - директор института публичных выступлений и публичных выступлений, перед чемпионатом мира по футболу она готовила людей отвечать на пресс-конференциях на провокационные вопросы, не впадая в эмоции, и о конфликтах знает очень много. И она рассказывала, как в конфликте сохранять спокойствие. Как же это сделать? А надо понять следующее: как правило, если человек гневно и не конструктивно о чем-то кричит - он просто проецирует наружу свои внутренние конфликты. "Вы не умеете управлять проектом" - это он не умеет. "Вы не можете организовать выполнение элементарной задачи" - это у него сейчас не получается организовать выполнение задач, или у него не получалось когда-то и осталась травма, которую он выплескивает. А если так - то нет смысла на него раздражаться, самому гневаться или вести себя агрессивно. Надо спокойно слушать и переводить его выплески на язык фактов. Ваша задача - снизить градус конфликта, потому что когда другой человек кипит, то конструктивный диалог невозможен. Говорите тихо. Записывайте претензии, явно. Часто реплика "позвольте я запишу ваши претензии, чтобы не ничего забыть" резко снижает конфликтность обсуждения.

А дальше техника трех да. Люди не любят, когда их лишают выбора. Если вам навязывают дают дополнительный scope - не говорите нет, скажите: это можно, но втрое дороже, или вдвое медленнее, или если вы дадите нам людей. Можно несоклько вариантов, и пусть он выберет. И другая техника - присоединение: признать проблемы и предложить вместе подумать над решением. Работает на поддержке и в call-центрах, Ирина обучала ей людей в МФЦ. Потому что кричать можно на другого, а тут вы получаетесь в одной команде.

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

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

В конце конспекта я хочу заметить, что у Ирины был аналогичный доклад осенью на SQAdays, вы можете посмотреть конспект в моем отчете https://mtsepkov.org/SQAdays-2024b, и там же - ссылка на сайт конференции, где опубликовано видео и презентация. У меня про тот доклад были размышления о том, что безусловно помогая справиться с проблемами тем, кто в слабой позиции техники доклада при этом усиливают тех, кто уже обладая сильной позицией отвергают любую обратную связь. В этом докладе такого отчетливого впечатления не возникло - появился выход в конструктив через технику трех да, через присоединение. Техника трех да была и в прошлом докладе, но не так акцентировано. Наверное, есть и другие примы, или просто иллюстрация кейсами. И в целом доклад ценный, потому что очень важно, чтобы люди не плакали потому, что на работе на них кричат или обесценивают результат.

Опубликовал отчет о #ЛАФ https://mtsepkov.org/LAF2025. Заметки я публиковал только в первый день, а во второй был едкий доклад Димы Безуглого о путях эволюции ИТ-компаний, мастер-класс Макса Дорофеева о том, как через синтаксис ловить ошибки в логике и еще много интересного. Так что читайте. И я по-прежнему с интересом наблюдаю за эволюцией смыслов сленговых слов с очисткой негатива: душнила из человека, душащего идею, превратился в человека, внимательного к деталям и логике. Про эволюцию токсика я пока не очень понимаю, но она тоже идет.

После конференции Школы системного менеджмента решил посмотреть обновленные версии курсов, и начал с Рациональной работы. Я этот курс смотрел еще в пререлизах курса Онтологики, а в 2023 году прошел и даже в качестве учебной работы написал статью "Онтологии социальных отношений", в которой попробовал построить онтологию мета-уровня, внутри которой можно описывать и сопоставлять онтологии социальных моделей. С тех пор курс превратился в руководство и сильно изменился, и я делюсь размышлениями https://mtsepkov.org/RationalWork. В частности, появились интересные концепты темпоральной части объектов и функциональных физических объектов. Появились мантры элегантной работы и операционная как способ наведения фокуса на текущую деятельность на предмет проверки ее рациональности и целесообразности. И многое другое. А разделы про причинность, в которых рассказывается про диаграммы причинности, позволяющий обосновать причинность через статистические данные, побудили меня прочитать книгу The Book of Why, на которую ссылается руководство, потому что плюшевые примеры в руководстве меня не удовлетворили совершенно. Книга оказалась очень содержательной, и о ней я тоже написал достаточно подробно. Думаю, будет полезным.

Завтра 18.06 в 18:00 в рамках проекта УНИВЁРS будет вторая часть моего семинара по инженерную модель личности. Первая часть была 05.06 и ее запись уже доступна, а завтра будет продолжение. Мы начнем с новой темы - модели ценностей, поэтому можно слушать и тем, кто не был 6на первой части. Ссылки на регистрацию - в посте-анонсе.

Опубликовано видео второй части моего семинара по развитию личности, https://youtu.be/cNM7IK9tlO0, в которой рассказ был о моделях ценностей и других социальные модели, а также схемы самоопределения. Самоопределение рассмотрено как создание аватара для новой деятельности, а личность в целом представляет собой множество аватаров, и такая конструкция рассматривается в ряде моделей психологии. В первой части https://youtu.be/w0xMgqVQli0 мы говорили о быстром и медленном мышлении, эмоциях и обучении, формировании личности.

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

Презентация доступна на моем сайте https://mtsepkov.org/PersonalityUnivers. Подробнее о модели личности можно узнать из моей книги, которая так и называется: Инженерная модель личности. Я благодарен УнивёрS за возможность участия цикле семинаров https://www.univers.id/seminari, где идет очень содержательный разговор.

#Highload Смена восприятия. Олег Бунин на открытии "есть похожее в создании музыки, создании ролика, создании программ", и я тут же додумываю: все эо сейчас хорошо делает ИИ/LLM/GPT. F он продолжает: "все это - создание чего-то из ничего, нужен лишь замысел" - и это тоже правда. Всем доброе утро! Я эту неделю на конференциях: Highload, потом Teamlead в Питере.