2023-10-29: AnalystDays - стабильно хорошие доклады и качественное общение

Короткая ссылка: AnalystDays-2023b

Ссылки сюда (2) →

О других конференциях

Два дня был и выступал на конференции AnalystDays. Было много общения и хорошее содержание докладов. В этот раз на конференции было почти 900 очных участников и еще более 300 online. Как обычно, я публиковал заметки в ходе конференции, и сразу собираю их в отчет, дополнив еще несколькими докладами, заметки с которых отдельно опубликовать не успел.

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

1. Нескромно начну со своего доклада Рациональное и системное мышление и мастер-класса Иры Суровой к нему - в обсуждении на конференции многие отмечали, что это было актуально и полезно, несмотря на то. что часть материала я не успел рассказать подробно.
2. #Анатолий Левенчук. Интеллект-стек для инженеров и менеджеров — комплексное представление о наборе дисциплин/умений/практик мышления, которые требуются для эффективной деятельности, позволяют строить модели и обеспечивать изменения в реальном мире на их основе.
3. #Светлана Дергачева. Применение ТРИЗ для решения задач с предельным уровнем неопределенности — лучший доклад про применение ТРИЗ в ИТ из тех, что я слышал на разных конференциях.
4. #Валерий Разномазов. Объектно-ориентированный подход в построении архитектуры решений — глубокий доклад о применении DDD, противопоставление между опорой на бизнес-объекты и опорой на бизнес-процессы. Опора на объекты лучше, так как они более стабильны и легче проявляются, и дальше на них можно строить разные процессы. А еще в докладе было очень классное определение архитектуры, отличающееся от обычного «важные, ключевые решения»: система — большее, чем совокупность отдельных фич, и архитектукра — это то, за счет чего система работает как целое.
5. #Ольга Подолина. Расширение нотации BPMN: использование совместно с DMN (управление решениями) и CMMN (кейс-менеджмент) — нотации, позволяющие наглядно представлять бизнес-функции, которые не являются процессами, а организованы иначе.

Еще хочу отдельно отметить два доклада, на которых я не был.

1. Мария Яковлева. Как написать свою первую спецификацию на REST API. Он занял первое место на конференции.
2. Максим Шаломович и Евгений Асламов. Долой SQL! Или краткий обзор мира нереляционных данных.

На этом перехожу к конкретным докладам.

Мой доклад Рациональное и системное мышление и мастер-класс Иры Суровой к нему

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

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

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

Polina Latypova из Evocargo. Как мы столкнулись с тщеславной метрикой и победили её. История из мира беспилотной логистики

Очень интересный доклад по предметной области — беспилотные грузовики, которые уже активно работают на закрытых территориях, обычно складах. Автономные, электрические, 2 тонны, средняя скорость 20 км/ч, зарядка от розетки 6 часов на 200 км. На той же площадке могут ездить трактора, управляемые людьми, и ходить люди. Хотя грузовики — автономные, в особых ситуациях требуется вмешательство оператора с диспетчерского пункта. Речь не идет о срочной остановке, просто машина по какой-либо причине не может продолжать движение из-за каких-то препятствий и, например. может запросить разрешение на объезд по встречной полосе или сигнализировать о проблеме. В докладе были примеры и для других автороботов, например, застрявший в сугробе доставщик или массовый сбой Cruise, когда много машин приехали в одно место создали пробку.

Метрика disengagement rate — число вмешательств оператора на км. И это метрика, в которой соревнуются компании. Был график с сайта therobotreport.com — в Калифорнии публикация этих данных обязательна. И они тоже начали собирать эту метрику. Однако, в исходном виде — число вмешательств на км — ничего не говорит. Уменьшение значения — не говорит, что технология стала лучше. Кроме того, автомобили — в разных погодных условиях, поэтому сравнение этих метрик по разным складам или разным дням тоже не информативно. Потребовалась дополнительная аналитика, в частности деление по причинам вмешательства: ошибка автопилота, физическая неисправность, изменение задачи уже в процессе движения и внешние обстоятельства, например, полная блокировка разрешенного участка дороги. При этом есть нюанс квалификации. Машины умеют объезжать препятствия. Но могут быть тупики, когда автомобиль окружили фуры, и проехать реально нельзя. Далее Обогащение данных: время вмешательства, в какой режим из автоматического переключаешься, что использовал оператор для вмешательства, версия релиза и так далее, и не только из автопилота, но и из других систем. И на обогащенных данных получилась возможность ловить реальные проблемы и разбираться. В докладе было несколько примеров, связанных с частыми остановками или ручными вмешательствами в определенном месте. И дальше выявляется и устраняется причина. В одном случае это был маленький человечек на разметке, которого автопилот принимал за человека, в другом — после обновления автопилот перестал доезжать несколько сантиметров до гейта, а на конкретном складе это было важно и потребовалось дообучить, и так далее. В целом это аналогично любому анализу инцидентов, но сама предметная область — интересная.

Павел Германов из НОТА. Плагинизация. Выделение функций системы в подключаемые плагины

Основная идея — вынести изменяемый и дополнительный функционал системы в плагины. В общем, давно известная конструкция, в массовых продуктов она появилась, наверное, в Mozilla Firefox, в котором с самого начала было множество плагинов, в отличие от IE. А в enterprise типичным плагином является форма печати, которые даже часто отдаются клиентам, потому что там есть большое разнообразие и механизмов настройки по шаблонам часто не хватает. Они выделяют плагины в своих системах, но их разработку держат сами, клиентам не отдают. При этом основа процесса остается в core-системы. И в этом отличие подхода плагинов от подхода оркестрации сервисов или компонентов внешним средством, как это делает comunda или аналогичные движки. К сожалению, глубокого погружения в выделение плагинов не было, был лишь слайд с принципами выделения.

Анатолий Левенчук. Интеллект-стек для инженеров и менеджеров

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

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

Дальше были комментарии к отдельным практикам. Школа этим практикам не учит, вернее учила лишь косвенно. В теории детей надо подготовить к жизни, чтобы они могли себя прокормить, но на этом в школе фокуса нет, и в ВУЗе тоже. Раньше жизни учила улица и подъезд, а сейчас эта часть социальной жизни отвалилась, так что все — сами.

Но сначала — совершенно роскошная метафора. Очень многие люди, почему-то не думают о воплощении модели в реальном мире, они считают, что написали документ, сделали модель — и мир изменится сам. Это — магическое мышления, подобное магу вуду, который полагает, что достаточно воткнуть булавки в куклу — модель человека и у реального человека что-то изменится. Практика говорит, что это — не так.

• Понятизация. Картинка — дайте имя объекту. И эо когда вы приходите к клиенту — и каждые два дня понимаете, что имя не то и объект не тот. А можно ощутить дребезг в теле, кинестетика, ощущение. И у всех кто на высоком уровне есть та или иная телеска для того, чтобы чуять — правильно или нет. Что ты выделяешь, когда смотришь на оратора. Можешь ли поменять фигуру и фон.
• Собранность. Кривая забывания и компьютерная память. Мнемотехники. Удержания понятий. Список работает до 400 строк, а дальше — заведи базу данных. А до 400 — все равно написать, начиная с 2 строк, а лучше — с одной. У организации тоже есть собранность: либо коллектив помнит, каким проектом занимался вчера, или не помнит.
• Понятия — математика, предметы окружающего мира — физика. Математическому мышлению не учат, учат отраслям математики. Так же как и физическому мышлению вообще.
• Семантика. Нагружение знаков смыслом, связь их с реальным миром.
• Теория понятий — теория прототипов или образцов, и это экспериментально подтверждено. Логики там нет. Объяснить нейросети, что такое двуручный меч?
• Онтология — машинка типов. 5 уровней: foundation ontology — типы систем, практик — типы объектов труда, деятельности — типы объектов прикладных дисциплин — модель экземпляров объектов.
• Алгоритмика. 1.0 — то, что все делают, 2.0 — ИИ и обучение, 3.0 — когда онтологии и программы пишут нейронные сетки.
• Логика. А чо такова? Реагировать на ошибки в рассуждениях. 2*2=5 — ну и что?
• Рациональность.
• Эстетика, как естественная наука.
• Этика — многоуровневая.
• Риторика — должна быть этична. И переводит между разными теориями понятий.
• Методология — схема, как устроено предприятие. Она дает объекты внимания, альфа, которые меняются в ходе проекта.
• Системная инженерия, то есть обобщенная инженерия систем. С 2017 года требований нет, архитектура — нечто другое. Инженерия платформ вместо devops.

А дальше пошли надстройки: инженерия конкретных систем, менеджмент — инженерия организация и инженерия личности.

Айгуль Габдрахимова. Стресс, адаптация, гибкость: как аналитику сохранить нервы и мозги

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

Первое. Про стресс, со ссылкой на научпоп модель было сказано, что он возникает как реакция на изменения, естественный, и ничего с ним сделать нельзя. Но стоит проверить физиологию, потому что связан уровнем кортизола, и он может просто плохо выводиться почками. И стоит посмотреть на базовые потребности по Маслоу, потому как если вы стабильно не высыпаетесь, что-то в жизни надо менять. Так вот, современная наука знает о стрессе достаточно много, там 5-6 разных вариантов, со своими причинами и способами управления. И надо сначала диагностировать, что именно у вас, а потом — работать над устранением конкретных причин. Как при любых нарушениях. Если кому интересны подробности, то можно посмотреть доклады Обуховой, у нее их много, она профи — среди ее шести высших есть биология и нейрофизиология.

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

Третья печалька — про теорию множественных интеллектов, которая признана как актуальная теория в современной педагогике. Говард Гадрнер выделил 9 видов интеллекта: Внутриличностный, Вербальный (или лингвистический), Логико-математический, Экзистенциальный, Пространственный, Музыкальный, Межличностный, Телесно-кинестетический, Природоведческий, позднее добавил еще несколько. Причина появления этой теории понятна — социальный заказ объяснить, что все люди — ценны, независимо от их IQ. Он выполнен, IQ меняет только 3 из них, а есть вот еще сколько.

Но дело в том, что эта классификация — это типология Борхеса, она не имеет оснований. Если смотреть на реальные конструкции, то надо исследовать системы мозга и обосновывать. И как-то отделать системы нейронов в мозгу, ответственные за конкретные типы интеллекта. Восприятие целостно, это хорошо иллюстрирует восприятие фрагмента От улыбки станет всем светлей, которому еще подтанцовывали — там музыка, движения тела, текст, да еще культурный контекст. При этом культурная составляющая играет существенную роль. В той же музыке — западная музыка, основанная на приятном нотном стане сильно отличается от имеющих другие лады. Да и языковые интеллект карты у китайцев сильно отличаются от западных, арабских и других алфавитных письменностей, потому что в Китае сильное влияние описывают конструкции иероглифов из конкретных образов. Отдельная вишенка на торте тут экзистенциальный интеллект, который отвечает за осознание смысла жизни, а вкладывают в него умение наслаждаться текущим моментом, достигаемое через медитации, направленные на осознание своих ощущений. Понятно, что это тоже социальный заказ, человек, реально задумывающийся о смысле жизни в деятельном залоге, стремящийся сделать мир лучше — опасен для современного общества. Поэтому объявим правильным смыслом жизни умение наслаждаться текущим моментом. Отмечу, что тут к спикеру — никаких претензий, она адекватна изложила теорию, я погуглил другие краткие изложения и сопоставил.

Светлана Дергачева. Применение ТРИЗ для решения задач с предельным уровнем неопределенности

Тема ТРИЗ на ИТ-конференциях возникает регулярно, я слушал много докладов и хочу отметить, что это — замечательный доклад. Он — на основе большого практического опыта, а не просто на основе первоначального знакомства. При этом достигнуть такого уровня у Светланы получилось только с третьего раза, на первых попытках отпугивала инженерная сложность и приземление на совершенно другой материал — ведь подход Альтшулер создавал в 50-е. Но потом появилась сложная задача — определять, читерит ли студент на экзамене, при том, что нейронные сетки выдавали ответ с достоверностью 50 %, там ТРИЗ помог и пошло развитие. Еще я отдельно хочу отметить оформление презентации и сквозной игровой пример с канарейкой, которой надо добыть еду зимой — это наряду с примерами из ИТ.

ТРИЗ — ощущение тупика, когда мы не знаем куда идти. Теодюль Рибо в своих исследованиях показал, что креативность линейно растет с возрастом ребенка, достигает пика в 12-15, а потом идет на спад. Дети умеют рисовать картинки, которые не видели в реальной жизни, а инженеры уже преимущественно копируют. Я тут хочу отметить, что есть зефирный эксперимент (marshmallow Peter Skillman, русское описание), который показал, что креативность падает не сама по себе, ее подавляет система образования.

Проблемы на пути поиска решения.

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

Что рекомендует ТРИЗ.

Для начала перейти от проблемы к задаче. Проблема — тупик: «нет еды» — ложись и умирай. «где птице достать еду зимой» — уже задача. Методы: Отказ от терминов, если мешают и переформулировать с акцентами на выхлоп, на процесс, на актора.

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

Акцент на актора — работа с ресурсами, с простоями (нет задач у тестировщиков), с мотивацией, подход к людям в маленькой компании. Изолируем ресурс, расписываем как систему, 3 сильные стороны, формулировки «существует в среде», как добиться ситуации.

Акцент на процесс — оптимизация, бутылочное горлышко (архитектор-тимлид), стимуляция к поиску. Изолировать главный процесс, описать пошагово: кто — что делает — с кем, как устранить препятствия.

Дальше — поиск решения.

Системное мышление. Хороший инженер видит объект и вариации, а АРИЗ-инженер видит надсистему — систему — подсистему, все это в прошлое-настоящее-будущее и еще антиподы систем. И в презентации был хороший пример, эволюция faq -> чат-бот -> AI-помощник с соответствующей эволюцией надсистемы и подсистемы.

Поиск противоречия — несколько видов

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

Другое деление: явное — пришли пользователи, авторизация упала, неявное — хотим сделать.

Для формулирования противоречий хорошо помогает SWOT-анализ, их формулируют слабости и угрозы .

Способы решения противоречия:

• Симбиоз с системой. Что надо изменить внутри, чтобы соответствовать надсистеме, что в надсистеме мешает развитию, что надо изъять. Задача про экзамен студента — надо подружиться с LMS, а они все разные. Оказалось, что LMS не любят открывать в iframe. Они написали плагин, он изолирует и разрешает, и заодно куки решили.
• Обратная связь. Если обратная связь есть — изменить ее, если она не решает проблему.
• Конструктор — соединение разные элементы. Когда ломается узел, уходит человек, сложно заменить — представим его по частям, а не целиком.
• Применяем роль — де Боно взглянуть на задачу как ученый (факты), художник (эмоции), критик (риски), оптимист (плюсы), креатор (нестандартно, начальник (координация).
• Метод одноразового стаканчика — заменяем дорогой набором дешевых. Worker — их можно запускать много.
• Экстрадетализация. Когда нет никаких идей. Просто расписываешь задачу как маньяк, синонимы, прилагательные, глаголы, ассоциации — пока не щелкнет.
• Вред в пользу: использовать вредные факторы для положительного эффекта, устранить вредный за счет сложения с другим вредным, усилить вредный, чтобы перестал быть вредным. У них — 5 нейросетей-распознавалок до 300 мб (лицо, голос и так далее). Они перенесли загрузку на самое начало и пустили параллельно с административными шагами — проверить оборудование, сфотографировать документ и т. п. И они в конце вставили экран с правилами, и пока человек читает, кнопка «продолжить» не горит, они дают время человеку и себе.
• Инверсия. Глаголов, прилагательных, смыслов, меняем объекта и субъекта, инверсия актора, цели, порядка действий в процессе… Freemium и trial версии — сначала пользуйся, потом плати.
• Посредник — использовать промежуточный объект передающий или переносящий действие, на время присоединить легко удаляемый объект. Вынесение частей из монолитов.
• Дробление — декомпозиция: разделить на части, выполнить разборным, увеличить степень дробления. Модульность, микросервисы
• Вынесение лишнего. Отделить мешающее или выделить нужное. Живо-чат — вынесли чат из сервис-деска и можно прикрепить куда угодно, и еще контекст пишешь.
• Чуть меньше или чуть больше, если трудно точно нужное. Готовые библиотеки, пусть там есть не нужное, или наоборот, не хватает, но мало.
• Самообслуживание: объект должен сам себя обслуживать, выполняя вспомогательные или ремонтные операции. Использовать отходы.

Интеграция — когда даем клиенту сделать все самому.

• Копирование. Вместо недоступного сложного дорогого использовать дешевые копии. Использовать изменение масштаба.
• Сумасшедший микс — де Боно. Накидываем самые разные слова по ассоциациям, случайные. Накидали производных слов — кенгуру — накидали всплывашки «сделай перерыв — есть приложение для медитации». Или автомобиль — фиксация что пользователь в автомобиле, за рулем и что-то адаптируем.
• Замена. Замещаем актора: делают не разработчики, а дети, алкоголики или врачи. Замещаем других акторов: разработка делает интерфейс совместно с конкурентами. Можно замещать среду, объект, цели
• Выше скорость — меньше ям. Ускорить негативные процессы, адекватно оценить как ускорить. Фаст-фуды — снижение качества пищи в обмен на скорость. Картинка в плохом качестве на плохом интернете. Скелетон первой страницы, если там долгая загрузка элементов.
• Метод вируса — подселение агента во враждебную часть среды, чтобы сделать управляемой. Выписать агенты проблемной зоны — акторы, субъекты живые и неживые, можно ли заменить? Удаленный рабочий стол.

Дальше Отбор идей. Как генерить — методы ТРИЗ. Линия рациональности — выгоды против затрат.

Подводя итог. Мнемоника ЗППП: Задачи из проблемы; Подсистемы (и надсистемы); подбираем метод; приоритизируем фичи. И в конце довольно большой список литературы по ТРИЗ и смежным темам.

Валерий Разномазов. Объектно-ориентированный подход в построении архитектуры решений

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

Дальше конспект. Потребность в архитектуре порождается семантическим безумием, многообразием и вариативностью представления данных в разных системах. И как средство от этого — корпоративная архитектура данных, единый язык. Раньше это было относительно просто, на основе EBS и Global business objects by IBM — он давал общий формат xml ваших данных. А сейчас при построении экосистем на основе open api требуется объединить очень разное, например, продажу бургеров, онлайн кинотеатр и выдачу кредитов. А грядет интернет вещей, где объединять все со всем. Он астрофизик, и мыслит аналогиями: смысл сущностей — новая гравитация, туманность сведений о заемщике и галактика продуктов.

Доклад был на двух примерах: Событийно-ориентированная производственная систем Amanita, для которых был предварительный анализ и CRM психологов — понятная практика, в ней было рамочное пожелание заказчика без предварительного анализа.

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

Теорема бизнес-анализа: любой бизнес-процесс можно представить как описание связей между субъектами и объектами которые могут участвовать в других бизнес-процессах. Задача бизнес-аналитика — определять это. Системный аналитик далее делает отражение в реализацию.

Есть два варианта развития проектов: от бизнеса к ИТ и наоборот, от ИТ к бизнесу. Внедрение вендорского решения — от ИТ к бизнесу, перекраиваем бизнес под возможности ИТ. Бизнес может рухнуть, примеры есть. SaaS — тоже самое, натягиваем одно решение на другое.

Первоначальные требования: легаси, существующий проект или новый проект.

• Легаси — чужое. И часто без комментариев, и с атрибутным хранением.
• Если проект есть — можно сделать лингвистический анализ и частотный — можно построить граф.
• Принципиально новый проект, а заказчик не очень понимает что делает — то agile и UI/UX макетирование — можно стартовать.

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

Онтология — не патентуется, а воплощение в виде классов — патентуется. Бизнес-объект: DTO, Json (xml), таблица как проекции друг друга. Платформа дает json, а интеграция — xml с xsd.

При реализации событийно-ориентированная производственная система Amanita опирались на производственные журналы в цехах — там готовая модель событий, его можно сразу переносить в данные.

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

Ontology driven MSA. Границы микросервиса — границы домена. Микросервисы и цитадели: в цитаделях те объекты, которые относительно статичны и изменения не меняются. Еще в цитадель попадают данные, которые надо защищать.

Объектно-ориентированные RESTfull — привязываем к объектам. И дальше SCRUD.

Модель поставщик-потребитель. Объекты, и взаимодействие: синхронное или асинхронное

Интеграция по Фаулеру: File transfer, shared database, remote procedure invocation, messaging.

Amanita. Мониторинг брака — видеокамера — json — обработка данных — и два потока: нормально и отклонение. Kafka, она была известна. Но между Kafka и RabbitMQ — большая разница, зависит от того, нужна ли будет обработка.

Messaging: JSONSchema или XSD. И проверка в шлюзе API Gateway. В Amanita шлюз между фронтом и бэком. В современных проектах бизнес-логика — не SQL, а Java. Декомпозиция бизнес-идеи — выделяем субъекты и объекты — строим граф — строим json-схему — строим базу данных.

Сложности: У одного объекта бывает много хозяев, несколько мастер-систем, отсутствует корпоративная модель данных и глоссарий. Я отмечу, что тут должны работать ограниченные контексты из DDD.

Ольга Подолина. Расширение нотации BPMN: использование совместно с DMN (управление решениями) и CMMN (кейс-менеджмент)

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

Рассказ был на конкретном кейсе, проект генеральной прокуратуры по надзору за исполнением законов. Рамочно он хорошо описывается BPMN: Поступление, регистрация, назначение исполнителя — и дальше проверка или обоснованный отказ от нее. Операция назначения исполнителя: на ней надо выбрать человека с учетом тематики, квалификации и текущей занятости, и возможны сложные решения, когда назначают исполнителя и куратора. Эти факторы рассматриваются в совокупности. И для описания такого процесса удобно использовать DMN — decision model and notation. В простейшем варианте такое решение — просто таблица выбора исполнителя по критериям, а в сложном алгоритма нет, а схема фиксирует те данные, которые нужны для принятия решений — и они, во-первых, должны быть в системе а, во-вторых — представлены исполнителю для принятия решения, собраны совместно на экране. Элементы DMN: решение, модель бизнес-знаний, источник знаний, входные данные.

Далее был рассмотрена операция проведения проверки в рамках надзора. D рамках проверки может быть большое количество разных мероприятий и подготовлены различные документы, но их проведение — на усмотрение ответственного. И в финале тоже есть опциональная часть — обращение в суд. Для этого хорошо подходит нотация CMMN — Case management model notation. В ней акцент — не на процессе, а на информации по конкретному случаю. Цель процесса — ясна, а путь — вариативен и определяется исполнителем. Элементы CMMN: Сцена, этап, задача с критериями входа и выхода, веха. Строится так. (1) Папка «Проведение проверки». (2) Входные критерии — с чего начинается кейс. (3) Этапы проведения проверки: свернутые или развернутые. Дискреционный этап — не обязательный, выполнение зависит от исполнителя. (4) Критерии входа и выхода для каждого этапа, и артефакты, связанные с критерием. (5) Фрагментация плана. Для рассматриваемого примера: обязательный этап изучения дела и законодательства, дальше дискреционные этапы проведения мероприятий и подготовки документов реагирования, а потом — финальный обязательный этап — акт проверки, и снова дискреционный — работа с судом, а дальше выходные критерии.

В презентации были примеры диаграмм, их опубликуют быстро — можно смотреть. В Comunda есть работа с DMN, CMMN еще нет, обещают. Есть шаблоны для visio, в презентации были ссылки.

Ярослав Кучеров из Газпромбанка. Матрица сценариев — инструмент бизнес-анализа

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

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

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

Ольга Азимбаева. Discovery. Честная внутрянка — стоимость, процессы, эволюция подходов на живых примерах

Discovery в этом докладе — проектирование и оценка реализуемости концепции, обычно через прототип или какую-то еще разработку. Рассмотрено три подхода к формированию команды, которая делает discovery-фазу нового проекта: набор из числа свободных ресурсов, привлечение экспертов по необходимости с частичной занятостью и сработанная команда квалифицированных экспертов. Первый способ работает лишь для несложных проектов, потому что эксперты редко бывают свободными, обычно получается привлечь лишь джунов и мидлов, а они сложный проект не сделают. Привлечение экспертов с частичной занятостью увеличивают доступную сложность, но для сложных проектов временно привлекаемых экспертов недостаточно. Сработанная команда лучше всего справляется со сложными проектами, но для того способа нужен постоянный поток проектов, иначе люди начинают простаивать. Был пример состава сбалансированной команды: Solution Architect, BA expert, 3 senior dev и 2 junior BA для документирования. Кроме этого, было рассказано несколько историй выполнение discovery — фазы в различных вариантах с анализом результата.

Ольга Зубкова. Игра как инструмент для исследования реальных кейсов

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

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

И дальше в докладе был обзор набора задач, которые можно решать с помощью игры, с примерами конкретных игр:

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

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

Естественно, игру надо готовить: определить контекст, где и зачем будет игра, подготовить участников, определить их роли и модераторов, выработать правила. А после игры — оценить результаты, не те, что достигнуты внутри игры, а те, ради которых проводилась игра.

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

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 09:23, 29 октября 2023 • нет комментариев