Слайды моего доклада на #AnalystDays на моем сайте https://mtsepkov.org/ReqLegacy-AD - смотрите

#AnalystDays Татьяна Половинкина. DataVault: разрывая звезды Кимбалла. Когда-то начиналось все с хранения широких таблиц - простые запросы, сложные изменения, если что-то меняется. Потом появилась звезда и снежинка, путь к третьей нормальной форме. А всего их 11, 6-я якорная. И надо выбирать, тут баланс скорости изменений и запросов. Потом пришла потребность в истории изменений - появились сначала интервалы действий в основной таблицы, а потом концепция DataVault: есть hub с бизнес-ключом, links между ними и satellite с историей изменений, их несколько, если разные атрибуты меняются в разном темпе, например, паспорт и фамилия меняют редко, а адрес и телефон - часто. И data vault решает проблемы множественности источников данных - делаем еще сателлиты. Для хранения историчности есть 7 форм, они различаются и надо выбирать. В докладе было много кейсов и историй, в пересказе это не воспроизведешь, так что ждите запись.

А я похвастаюсь, что в далеком 1999 году делал хранение объектов в якорной форме в АБС, позднее (в 2003) это ядро было доработано для гибридного хранения, когда часть атрибутов лежит в плоской таблице, а часть - как отдельные атрибуты, оно было использовано в нескольких проектах и до сих пор работает. В объектном хранении были атрибуты с историей изменения, а в гибридном варианте появились анкеты-сателлиты для хранения исторических атрибутов. При этом в системе коммунаального биллинга нам надо было решить более сложную задачу - уметь показать описание истории изменений объекта в системе, которое было в прошлом, на момент выполнения расчета. То есть показать, какова была история проживающих в квартире (прописки и выписки) в 13:00 2 числа текущего месяца, когда была создана квитанция на оплату, чтобы обосновать правильность работы системы.

Спасибо Тане за доклад!

#AnalystDays Максим Шаломович и Евгений Асламов. Забудь про физику, думай о логике! Доклад - продолжение того, о чем авторы говорили в 2023 году. Посыл того доклада был в том, что, хотя NoSQL пока используется мало, есть растущий тренд в нем графовые БД и много другого, и потому аналитикам не стоит лезть в физику хранения, а надо думать о концептуальной модели данных. На него была обратная связь, в том числе в форме "зачем нам барин-архитектор". И сейчас продолжение. Для начала, восходящего тренд графовых баз сдулся, это была флуктуация. И хотя про будущее Гартнер все равно рисует что будет больше, анализ вакансий показывает, что доля SQL сохраняется на прежнем уровне, уменьшения нет. Но вот рисовать реляционную базу данных они все равно не советуют. Потому что разработчикам она не нужна, им нужна структура объектов, где, в частности, выражены отношения часть-целое, им нужны структура DTO для передачи объектов между системами. Поэтому получается не нужная работа. Если аналитик реально хочет сделать полезное разработчикам - то используйте DDD, организуйте Event Storming (и зовите разработчиков), проектируйте DTO и структуры для ORM. Это требует несколько других знаний, но на этом языке разработчики будут говорить. А если все-таки надо выбирать базу данных - то нужен процесс принятия архитектурного решения. Модели барин и вече - одинаково ущербны. Нужно документирования целей, оснований, рассмотренных аргументов и принятия решения, как для всякого решения. Организовывать может кто угодно. И за решение должна быть персональная ответственность: тот, кто его принимал совместно с командой разгребает последствия, если решение оказалось на совсем удачным. Хороший доклад, спасибо за него Максу и Жене!

#AnalystDays Ильдар Гиматдинов. Как аналитику управлять Архитектурой, не привлекая внимания санитаров. Прикольный доклад с гротескным макросюжетом в стиле Кафки: в 2010 пришел scrum и аналитиков заморозили в криокапсуле, ведь команде они не нужны, а в 2025 начали размораживать - масштабирование SAFe, он сложный, без аналитиков не получается. Но это - макросюжет, а в докладе - история такого размороженного аналитика, которые осваивает микросервисную архитектуру, используя при этом старые подходы. Три такта, которые он осваивает, отчасти придумывает.

1. Декомпозируем схему данных предметной области, и не формально через метрики coupling и cohesion, а выделяя содержательные домены.
2. К традиционной схеме бизнес-процесса привешиваем микросервисы вместо обычного workflow документов, для реализации конкретных шагов. Получается похоже на archimate.
3. Проектирование RestAPI в виде mindmap: сервис - endpoint - чаcть url - query + create/update/delete. B к любому узлу - пояснение.

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

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

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

#AnalystDays Анастасия Кайнова. Диаграммы, которые ожили: PlantUML и немного кода. Есть задача описать API. Если нарисовать всю вложенность вызовов и альтернативные сценарии, диаграмма получается нечитаемой. Идея рисовать только основной сценарий, а подробности отдельно - неудобно, люди не ходят по ссылкам. Она решила попробовать сделать динамическую диаграмму с раскрытием частей. Ограничение: это должно встраиваться в корпоративный confluence, поэтому какие-то свои бэки - не рассматриваются. Смотрела draw.io - там есть раскрытие, но получается не очень хорошо. Потом поискала и увидела - в PlantUML есть переменные и препроцессинг, который позволяет скрывать части диаграммы в зависимости от значений переменных. И принципиально решение есть - ты делаешь html-страницу, в которой настраиваешь переменные, а дальше меняешь картинку в зависимости от их значений. Встраиваешь это в конфлюенс, там есть макрос встройки html-страниц. Но как сделать генерацию картинки по тексту диаграммы? Для этого есть api PlantUML, туда надо в url отправить запакованный и закодированный текст диаграммы, и получить png-файл результата, который и показывается на странице. В докладе были подробности и детали по тому, как она делала этот скрипт. Пришлось самой разбираться в JS чтобы доработать результат, выданный ИИ, исправив ошибки через сравнение с найденными на github примерами. В целом успешно, в конце доклада - ссылки на диаграммы, она выложила примеры с кодом и комментариями. Rendering выполняется внешним сервисом на plantuml.com, у нее работает. Но, наверное, если plantUML развернут локально, можно к нему обратиться вместо внешнего. Пока не доведено до продукта: если диаграмму меняешь, надо редактировать исходный текст, а дальше проходить цикл получения упакованной версии. Но тут можно сделать скрипт.

В нескольких выступлениях на последних конференциях использовали схему SDLC – System (Software) Development Life Cycle, и я в него внимательно вгляделся. И увидел в нем методику работы для Ивана-дурака: «пойди туда, не знаю куда, принеси то, не знаю что», только что б непременно по плану. Это, конечно, ирония, но она хорошо описывает суть дела. Кстати, сама схема – очень старая, это 1981 год, методика SAADM, когда отсутствовали не только современные методы разработки, но и RUP был еще в будущем. А люди до сих пор ссылаются и используют. Печалька. И я написал об этом статью https://habr.com/ru/companies/custis/articles/913016/, где разобрал подробнее, а также показал отличия от V-model, которая тоже старая, но гораздо разумнее.

Опубликовал отчет с #AnalystDays https://mtsepkov.org/AnalystDays-2025a. К своему 20 юбилею конференция выросла: после досрочного закрытия продаж на несколько последних конференциях организаторы сменили площадку и новая позволила вместить почти 1300 участников. Шесть параллельных треков: четыре докладов и два мастер-классов. И очень хороший контент, реально было несколько докладов, которые для меня были очень ценными. Так бывает далеко не на каждой конференции. И, как обычно много общения и нетворкинга. Про несколько докладов я публиковал заметки в ходе конференции, а сейчас их дополнил. До встречи на следующей неделе на KnowledgeConf и ЛАФ! И на других конференциях.

#KnowledgeConf Первый доклад Галина Ширанкова. Как мы начали учить LLM-модели в несколько раз быстрее, просто поменяв роли в процессе. Следующий такт освоения LLM-моделей - построение эффективных процессов обучения конкретных моделей. Речь шла про LLM, которая отвечает за продавцов. Есть метрика, что ответ в первый час после вопроса сильно повышает вероятность сделки. У них целевая метрика - именно повышение вероятности сделки, но если человек из ответов быстро поймет, что ему это не нужно - тоже хорошо - он пойдет искать другое. Дополнительно проверили гипотезу на простеньком боте, который умел отвечать на вопрос "Еще продаете?" - оказывается, это очень частое начало разговора. А дальше надо было отвечать на содержательные вопросы. У авито очень широкая линейка продуктов, и вопрос "какой размер?" про одежду, электронику или собаку предполагает совершенно разные ответы. Для ответа используют формальные характеристики и текстовое описание продукта, например, если продавец указал размер обуви 39, но в тексте написал "маломерки", то это - часть ответа.

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

Но для этого требовалось научить их делать промпты, потмоу что датасет готовится с помощью LLM общего назначения, и качественный датасет получают именно докручивая промпт. Это сделали. А еще для процесса создания датасета нарисовали блок-схему и нашли места, где можно сэкономить время. Например, можно не писать регулярные выражения для выбора исходного датасета из всего массива - продукт уже сделал это, когда оценивал перспективность тематики, и не страшно, что они неточные, можно не подбирать характеристики для конкретного ответа, а использовать все популярные и так далее. Плюс ручную разметку 100 строк датасета для старта может сделать "любой здравомыслящий человек" - это можно делать параллельно.

Результат - 23 модели, обученных за полквартала, с качеством ответа 91% против 93% у тщательно обученных первых четырех. и 88% у ChatGPT, используемой как baseline. Они сравнивают с ChatGPT и DeepSeek, при том что у них - маленькая LLM, чтобы понять возможный уровень ожидаемого результата. Такая история.

#KnowledgeConf Дарья Вьюнова. Как создать самообучающуюся команду. В докладе - фрейм аспектов самообучения в организации команды. Взрослые на обучаются впрок, поэтому должны быть развивающие задачи и должно быть понятно, как результаты обучения встроятся в процесс. Тройка правильной организации: фокус, ритм и метод. Надо фокусировать внимание на самообучении, и его надо держать, чтобы внимание выделяло нужные объекты, должен быть ритм подхода к задаче и надо подумать о методе, которым ты его делаешь, подобрать подходящий, оценивать результаты. В докладе фокус был на организации со стороны руководителя, но это не обязательно, можно проявлять инициативу или самоорганизовываться (хотя не во всех культурах, может оказаться, что надо менять команду).

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

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

Очень важно держать тон интереса. У нее уже пару лет стоит собственная развивающая задача, ежедневная напоминалка в календаре. А еще оптимизация зада с помощью ИИ. И привнести инструмент стратсессий в Команду ВУЗа, где она недавно работает - это им новое.

Самообучающаяся команда - это всегда культура. И эту культуру можно делать в рамках команды, даже если в организации в целом ее нет. Субкультура - это нормально, если не превращается в контркультуру. У нее был опыт в OTUS, когда культуру команды отличалась, а сейчас она пробует сделать то же в рамках ВУЗа. Пока - получается, но это - вызов, результаты будут понятны через год. Но важно, что культура команды, а не отдельного человека, нужна поддержка. В этом я хочу пожелать Дарье успехов!

#KnowledgeConf Дарья Мулык. Как грамотно общаться с экспертами, от которых вам нужны знания. Это доклад про наши реалии. Когда эксперты имеют личный опыт, который позволяет делать задачи, но не могут его изложить, не умеют разделить на важное и второстепенное - в общем, не владеют методами мышления, которые делют его ясным и структурным. И потому их приходится вести по пути извлечения для создания курсов, статей или других материалов, и человек, который это делает - тоже особо не погружен в контекст. И никаких глубоких know-how в этом процессе тоже нет: надо установить контакт, сформулировать решаемую проблему, выработать план. Проверить, что контент изложен адекватным языком, понятен для не-специалистов из целевой аудитории, что идет от простого к сложному. А главное - что результат закрывает поставленные задачи. В целом это тоже начальный уровень для извлечения знаний, потмоу что на практике занимаются этим не профи по работе со знаниями. И, в общем, это особенность текущей ситуации, о которой у меня была статья "Реальность цифрового мира: проекты делает некомпетентная команда". Так что если вам надо извлекать знания из экспертов, а вы этим не занимались - послушайте доклад Дарьи. А пунктиром я его содержанеи написал.

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

При этом в обоих докладах - громадное количество полезных практик, тут они дополняют друг друга. У Алексея много рекомендаций по начальному контакту. Важно, представит CTO или HRD: для инженера авторитетом являются инженеры. Важно не врываться с личным общением - разработчик занят текущей задачей, и оторвав - вы выбросите в корзину текущие мысли, ему придется начинать заново. Поэтому - письмо. И в письме сразу заявить: он - общепризнанный эксперт (так сказал СТО), и потому прилетела задача вынуть экспертные знания в такой-то форме, и предложить варинты: встреча, переписка, ответ на вопросы и так далее. В письме превентивно действуешь против низкой самооценки, потмоу что это - очень распространенная проблемА, эффект Данинга-Крюгера.

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

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

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

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

Трудности коммуникации
* Человек пришел, но зажатый и бука. Он имеет на это право. Он проснулся с таким лицом и пришел. НЕ меряем коммункиацию эмоциями, меряешь ключевыми словами и экспертизой
* Если человек говорит активно, но не про то, уводит разговор - просто перебиваешь. "Оля, нам надо вернуться, иначе не успеем"
* Если кажется, что человек ненавидит и предвзято относится - можно игнорировать, если отдает экспертизу. А если не отдает - проблема в целеполагании, и к нему возвращаешься. К целеполаганию постоянно возвращаешься, валидируешь и можно передоговориться или разойтись

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

Меня нельзя обидеть, потому что Леша остался дома, а на работу пришел эксперт. Можно только сорвать сроки или не дать экспертизу. При этом эмоции - остаются, просто они - на втором плане.

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

#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: было запланировано, что через две недели все тестировщики меняются друг с другом проектами на неделю. Тестирование показало, что больших провалов нет, но две недели подготовки все-таки недостаточно, даже когда информация есть заранее - и они дальше сделали план изменений, чтобы увеличить устойчивость.