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

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

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

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

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

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

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

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

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

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

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

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

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

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

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