Максим Юнусов. Изобретение архитектурного решения. Начат с классической ситуации: получив требования по времени отклика под нагрузкой и доступность сервиса с намеком, что для этого сервис должен масштабироваться, Архитектор выдает решение: PostgreSQL + хореография на событиях + Apache Kafka. Вопрос: как решение связано с исходными требованиями? И дальше был разбор предлагаемого порождения решений. Для начала посмотрим, что предлагают методологии: TOGAF, SEI, ADR. Интересно, что они все исходят из того, что должны быть стандартные решения, и задача выбора состоит лишь во взвешивании вариантов. Различается косметика, подходы к принятию и документированию этих решений. И это - печально. Поэтому предлагается посмотреть на смежные области, а именно на ТРИЗ. Там много интересного и полезного.
* Исходное описание - лишь описание ситуации, в ней пока не выявлено противоречие. Необходимо до этого довести, получить задачу.
* Противоречия бывают двух видов: противоречат два нефункциональных требования или нефункциональное требование противоречит архитектурному принципу.
* Для нефункциональных требований нужна заинтересованная сторона - кто заинтересован в его исполнении.
* Нефункциональное требование стоит подвергать сомнению. Действительно ли доступность сайта ниже 99.99 или время отклика более 0.1c приведет к оттоку пользователей (если это указали как основание требования). Может быть, требование можно ослабить или вообще снять?
* Решать противоречия следует, только если требования реально актуальны. Иначе будет overdesign, необоснованно сложное решение.
* Архитектурные принципы и ограничения тоже стоит подвергать сомнению.
* Антипаттерн, если в задаче не должно быть заложен подход к решению, когда сразу говорят, что из требований следует необходимость масштабировать сервиса на кластер
* Антипаттерн, если свобода сведена к свободе выбора из известного. А именно это предлагают методологии.

Разрешение противоречия
* Идеальное решение без ограничений
* Вводим ограничения до потери качества
* Формулируем физическое противоречие

Пример: архив должен создаваться для обеспечения надежности и НЕ должен создаваться, так как деградирует время отклика. Решаем
* во времени: делаем архив, когда низкая нагрузка
* в пространстве: делаем с отдельной ноды БД, которая для этого
* в структуре: две базы данных: для записи и для архива
* взаимодействия: приостанавливаем процесс архивирования при интенсивных запросах
* Архив как идеальный объект, архивирование без архива. Например, если архив нужен для отката - делаем откат иным образом, откручивая обработку событий назад.

Евгений Лукьянов. Как Event Storming, DDD и чистая архитектура помогают запустить стартап. Реально история стартапа в области здоровья, в котором много алгоритмики и ML. На первом шаге была проверка алгоритмов, потом - проверка концепции на знакомых с интерфейсом на чат-боте. При этом разработку вел один человек на python, и получился сложный, взаимно-перевязанный код из множества сервисов, который очень сложно дальше дорабатывать. В некоторый момент потребовалось научиться вести разработку командой, а для этого потребовалось разобраться и упростить то, что сделано, обеспечить возможность подключения новичков. А потом был следующий этап - проверка спроса на сервис с партнерами, и там был следующий такт изменений.

На первом этапе
* Event Storming, чтобы разобраться, что делает приложение. Он показал, что основной разработчик не слишком представляет.
* Шаг к гексагональной архитектуре
* Внедрили тактические паттерны DDD: сбор бизнес-логики в агрегаты, Value-object, большие сервисы разбили на UseCase.
* Сделали референсный проект для погружения новичков.

На втором этапе
* Научили аналитиков пользоваться Event storming. Получились ограниченные контексты, области поделились. И в контекстах можно менять технологии.
* Нарисовали интерфейсы, отдали партнерам на тестирование.
* Типизация стандартных решений позволила включать новичков на локальные задачи. У новичка на следующий день есть сделанная простая задача. Разделение по квалификации.
* Прогнозирование. Сложный агрегат - 2 недели, простой два дня, объект-значение 6 часов, usecase 3 часа. За счет типизации решений.
* Trunk Based Development. Без веток. Потому что решение конфликтов было дорогим. Но Trunk based - невозможен без автоматики и хорошего тестирования.
* Тесты - есть заранее подготовленные данные окружения для запуска теста.
* Локальная сборка экономит деньги. Build-server - предохранитель.
* TDD для сложных мест
* Начали допускать тех.долг на этапах апробации решений
* Ограничили свободу - типовые узлы уже изготовлены, используешь их.

Книга: Accelerate: The Science of Lean Software Development and DevOps. Jez Humble, Gene Kim, Nicole Forsgren.

Геннадий Круглов. SAGA — эволюция и новые смыслы. Сообщество архитекторов решило разобраться, что же такое SAGA, и в докладе представлен результат этого. К сожалению, не впечатляющий. Начали от базовых понятий, подняли статьи 1980-х о том, что же такое - транзакции, какие у них свойства (ACID) и какие проблемы. Одна из них - long life transaction при распределенных системах, которые при формальной реализации ведут к эскалации блокировок. И потому предложено делать промежуточный коммиты внутри транзакции, разбивая их на малые участки, после которых бизнес-консистентности нет, а SAGA - концептуальный способ восстановления этой консистентности, тоже предложенный давно, в 1986. За счет того, что есть управляющая часть, которая в случае прерывания в неконсистентном состоянии либо откатывает шаги, для чего должны быть предусмотрены средства отката, либо проталкивает до завершения, если для этого есть средства. Собственно, все. Как это реализуется - было за пределами доклада, хотя были ссылки на статьи Microsoft, Red Hat, AWS, Camunda. В общем, жаль, что содержание ограничилось этим. Я тут хочу отметить, что в сентябре был доклад Филиппа Дельгадо "Микросервисы через боль и превозмогание" на Saint Highload (кому интересно - мой конспект), где в числе прочего он говорил про SAGA, пунктиром обозначив минимум четыре шаблона реализации. И я надеялся услышать про шаблоны и концепты более детально, а получилась лишь историческая справка про статьи 1980-х о транзакциях и SAGA.

Дмитрий Таболич. Майндшифт или мысли, как Архитектор. Очень крутой доклад про отличие мышления архитектора от мышления инженера-разработчика. Это первый сдвиг мышления, касающийся именно технологического стека. Дальше добавляются другие аспекты: business focus, governance, strategy, но начало - именно в сдвиге мышления по техническим вопросам. Если кратко, то для каждой задачи архитектор смотрит спектр вариантов решений и ответственно делает выбор с учетом контекста конкретного проекта. Это достаточно абстрактно, поэтому в докладе это иллюстрировано большим количеством кейсов.
* Есть задача от проджекта. Инженер: давайте сделаем. Архитектор: какие ограничения?
* Silver bullet. Инженер: я много раз делал, и сделаю еще раз на своем опыте. Архитектор: для начала смотрим альтернативы индустрии, потом - выбираем. Если решение одно - значит нет ни одного.
* Документируй. Инженер: хороший код self-explained. Архитектор: очевидно, необходимо описывать ключевые решения, вопрос не стоит. И надо быть готовым
* Task-driven mindset. Инженеру важна четкая постановка задачи - что сделать. Для архитектора - зачем делаем, какую проблему решаем
* CV-driven mindset. Инженер: давайте втащим фреймворк. Архитектор: многофакторная оценка уместности - безопасность, скиллы команды и т.п. Вопрос не торможения, а именно многоаспектной оценки.
* Язык бэкенда и фронтенда. Инженер - только на техническом языке структуры приложения. Архитектор - много viewpoint, в том числе - на языке бизнес-стейкхолдеров, на языке безопасников и так далее.
* Копипаст. Инженер: посмотрим на stackoverflow и заберем готовый кусок не разбираясь. Архитектор: решения надо смотреть, но надо смотреть несколько и анализировать уместность, делая выбор.
* Призма мышления. Инженер: сужаем область понимания на задачу. Архитектор: включение задачи в большую систему и влияние на нее.
* Роль или функция? Инженер: играл роль архитектора в своей команде - значит архитектор. Архитектор: может играть эту роль НЕ ТОЛЬКО в своем проекте, где есть многолетний опыт, может быстро разбираться в других проектах.
* Я-эксперт. Инженер: отслеживаешь развитие своей платформы, своих технологий. Архитектор - смотришь на множество технологий, на варианты построения решений.
* HERO. Инженер: выбрана технология, и дальше много усилий, чтобы заставить работать, даже если она не подходит. Например, сначала выбрать JVM для serverless и бороться с долгим стартом JVM. Архитектор: оценивает решения в контексте проекта.
* Тот самый YAGNI. Мы решили выбрать Mongo, потому что там - транзакции, хотя они и не нужны. Архитектор - обоснованные решения в контексте конкретного проекта, а не вообще
* IT works on my machine: Инженер: у меня все работает. Архитектор - что DevOps процесс позволяет
* Все по Scrum. Инженер: о следующей функциональности посмотрим в следующем спринте. Архитектор: видим контекст вперед, не привязываем решения к моменту.
* Ответственность. Инженер: склонен передать ответственность на коллективное принятие решений. Архитектор - не просто принимает решения, но и несет ответственность за принятые решения.

И с заключении книги:
* 97 Things Every Software Architect Should Know и
* BTABoЛ 3.0: Business Technology Architecture Body of Knowledge

Денис Котов из Tinkoff. BPM(N,S, engine) — нужны или нет? Интересный доклад о месте BPM-схем и движков, которые их реализуют. Тезис состоит в том, что если у вас есть хороший BPM-движок, то вы из коробки имеет мощное средство реализации процессов, которое берет на себя не только задачу выполнения экземпляра процесса для конкретной ситуации, но так же отработку особых ситуаций, перезапуск или откат процесса, миграцию экземпляров при появлении новых версий версий описания и мониторинг. При этом у вас из коробки есть таймеры, напоминания, уведомления, механизмы прерываний по событиям и многое другое, и вам нужно лишь реализовывать конкретные шаги, которые может делать конкретная автоматизированная система или человек. Процессы, которые реализует BPMN - гораздо мощнее, чем те, которые дает State machine, процесс имеет много состояний. Это Денис показывал на примере регистрации ИП, которая начиналась с 10+ последовательных шагов, которые действительно просто реализовать на Sate machine, и за полтора года развития превратилась в сложную схему, в которой около 11 переменных-состояний.

Вопрос в том, где взять этот хороший BPMN-движок, который все это дает из коробки. Начинали они с использования IBM process designer, который всем хорош, только безнадежно отстал по технологиям: Java 6 и никакой интеграции с современными CI/CD и системами тестирования. Потом делали свою State machine, это жило, но с ростом числа процессов, команды и без визуализации и многих других поддерживающих сервисов было сложно. Cейчас - Kotlin как язык, Camunda как движок, spring для обвязки и Kafka для интеграций. Плюс свое решение на Prometheus и Grafana для мониторинга.

Есть нюанс про уместность использования. Маркетологи успешно продают BPM-решения как серебряную пулю для всего. А сейчас еще идет аккуратное брендирование этих движков под LowCode, когда люди смогут тыкать мышкой без программистов. Это все - маркетинг. Уместно применение для реально сложных процессов, где много взаимодействия людей и систем, и которые разворачиваются во времени. И с низкой нагрузкой, 10+ инстансов ежедневно. Хотя camunda 8 обещает масштабировать до 100-1000+ - но тоже ежедневно.

А еще BPMN - сложен, 15 абстракций и 500 графических конструкций. Поэтому для простых задач его использовать не надо, надо использовать Workflow engine, которых много - Temporal, Cadence и так далее. Там всего пара абстракций, и гораздо меньше графических конструкций и для большого количества задач этого достаточно.

Собрал свои заметки с ArchDays в отчет https://mtsepkov.org/ArchDays-2022 Отмечу, что конференция имеет свое лицо и отчетливый фокус на архитектуре и работе архитектора. Доклады по этой теме есть на Highload, но там больше фокуса на public web и высоконагруженные приложения, а на ArchDays речь идет больше про enterprise и связанные с этим темы, которые на Highload не слишком широко представлены. При этом в докладах на ArchDays больше фокус на объяснении базовых вещей. Для кого-то этот материал очевиден, а для других - является ценным. А еще было несколько докладов, посвященных мышлению архитектора и способам принятия архитектурных решений, и это, на мой взгляд, очень позитивно отличает конференцию в хорошую сторону.

Начинаю репортаж с #AnalystDays. Николай Соколовский. Модели решений и фреймворк: фиксируем сложную бизнес-логику. Рассказ про способ формальной записи развивающихся и усложняющихся правил. Которые начинаются с простой формулировки "Заявка может быть закрыта автором или исполнителем", а дальше добавляются новые роли, статусы (Отклонена), особые заявки, отметки на заявке и так далее, и текстовые формулировки становятся запутанными, а на трактовку влияют знаки препинания, что ведет к ошибкам. Это Decision Making Notation записи в виде табличек условий и заключений, столбцы условия объединяются по И, строки - по ИЛИ. Есть две визуализации, одна из 4 элементов: Входные данные, Решение, Бизнес-знания, Источник знаний, во второй погружаешься внутрь: Правила декомпозируются через Условия, они объединены в Семейства и Модели. Но основное - таблички, и фишка в том что бизнес такие таблички понимает и готов обсуждать и заполнять после 10 минут инструктажа. А по реализации - есть много движков, и можно написать свой, интерпретация довольно простая.

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

Достоинства - позволяют управлять большими наборами правил, 500+ выживают, можно увидеть зависимости, облегчают декомпозицию и управление. Сочетаются с BPMN. Автоматизация. Малый порог входа, бизнес понимает, включая финансистов и HR. Недостатки тоже понятны: еще одна нотация, слишком сложно для простых случаев. Требует аккуратного обращения с терминологией. Сложно описывать случаи, которых не было, но тут помогает сказать "ну, а пусть ошиблись - что система должна делать". Сложно согласовывать, когда декомпозиция не совпадает с границами ответственности - учитывайте их.

Екатерина Герт из Крок. Ресурсный менеджер аналитиков - кто он такой? Для начала я хочу заметить, что название "ресурсный менеджер" для меня имеет резко отрицательную коннотацию отношения к людям как к заменяемым деталям в машине выполнения бизнес-процессов, с исключением личного отношения. У Екатерины этого отношения нет, да и в современном ИТ это невозможно, хотя лет 10-15 назад для крупных компаний было практически нормой. Но вот название должности у них в компании - осталось, и, наверное, внутри коннотаций не несет. Интересно, как это воспринимают другие участники. Может быть, оно и для других уже не несет таких коннотаций, получило новый смысл. А может, люди просто не задумываются, что на самом деле значит относиться к людям как к заменяемым ресурсам в машине бизнеса.

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

Дальше быо детальное раскрытие работы. С кем работает?
* про людей: аналитики, HR-менеджеры;
* про бизнес: руководители направлений и владельцы продуктов - чтобы понять перспективные направления развития и потребности, финансовый директор - зарплаты и бюджеты;
* менеджеры продуктов и проектов - на стыке бизнеса и людей.

Дальше нагрузка по задачам, для ее ситуации с группой 20 человек
* Раз в год бюджет делаешь группы, и когда делаешь - большое погружение
* Мониторинг группы каждые полгода, подведение итогов
* итоги работы за квартал по группе, премии
* встречи с руководителем проекта и продукта 2 раза в месяц, планирование кто где работает
* встречи с HR-менеджером
* ведение ресурсного плана: сотрудники против проектов со сроками, чтобы во-время отслеживать изменения ситуацию
* встреча 1:1 с каждым аналитиком, 1-2 раза в месяц с каждым, отслеживание наставничества

Проблемы первого года работы, по убыванию. Хотя сортировка для нее не очевидна, но опрос дал именно ее.
* увольнение сотрудника
* негативная обратная связь
* бюджет (там же нужен прогноз премий и зарплат на год)
* зарплата и премии
* удержание сотрудника
* найм нового сотрудника
* подведение итогов сотрудника

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

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

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

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

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

Мифы
* эмоциональная компетенция синоним эмоциональности (или безэмоциональности). Это не так, он просто управляет
* Человек с высоким EQ всегда в позитиве и в хорошем настроении. Нет. Он может кричать - когда нужно, управляемо
* EQ важнее чем IQ - нет. EQ про коммуникации, устройство на работу, а IQ - про интеллектуальный результат, нужны обе составляющих.

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

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

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

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

Понятные фазы
* Подготовка: шаблоны и примеры, чек-лист с вопросами, первый раунд заполнения по фазе пресейла, определение лакун
* Создание: циклично, с постоянной обратной связью и командной работой
* Финализация и утверждение, распространение и актуализация

Содержание
* Предпосылки и контекст - кто клиент; почему хочет инициировать проект; особенности ситуации компании-клиента; специфика и тренды индустрии
* Заинтересованные лица: клиент, мы, третьи стороны (консультанты). Уровни вовлеченности, области ответственности. Перепроверять, что не упустили, встречаемся лично, не забывайте тех, кто негативно настроен. Не все публично.
* Целевая аудитория (пользователи): узкая или широкая, прямая или косвенная, ядро ЦА, боли и проблемы, персоны. Частая ситуация: "сейчас делаем для себя, а потом будем продавать". А еще "не ходите к финансистам, у них сейчас отчеты." интересы пользователей и стейкхолдеров часто отличаться и даже противоречат: пользователи сайта знакомств хотят найти половину и не ходить ,а стейкхолдеры - чтобы вечно искали.
* Описание проблемы: выясняем, спрашиваем текущие решения, ставим приоритеты. Аккуратнее с формулировками, это бывает чувствительно. Не забываем про цели. Помним, что озвучивают субъективное мнение, а не объективные факты.
* Цели, задачи и критерии успеха. Выясняем и формулируем цели, описываем измеримые задачи, расставляем приоритеты. Очень часто тут нет конкретики. Можно предложить, но надо себя не загнать в них.
* Границы проекта. В целом и MVP, приоритеты. Сочетаем визуализация и текстовое представление. Стараемся уменьшить MVP.
* Риски, зависимости, допущения. Все, что успеем выяснить - записываем. Зависимости и допущения часто переходят в риски. Привлекаем всю команду.
* Ограничения. Стоимость: бюджет, скрытые затраты (лицензии и т.п.), неучтенные ожидания. Время: дедлайн, особые даты и события. Границы: MVP, особые сценарии, нефункциональные требования.
* Что еще: маркетинговые исследования, внутренняя статистика, процессы AsIs и ToBe, требования к переходу, макеты, оценки трудозатрат и так далее - уровень подготовки проекта может быть разным.

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

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

* Фазы понятные: планирование, проектирование, создание-получение, хранение-обслуживание-архивирование, использование. Но потоки данных - меняются, хранение - деформируется.
* Фокусы: осмысленность данных, выгода использования. Доступность в условиях изменчивости. Масштабируемость. Качественность, доверие данным. Безопасность данных. Температура данных - частота обращения.
* Виды данных: Small (обычные БД), Big (с ними просто не получится), Smart (информативные данные, Fast (выявление Smart в Big, Темные (это что мы не знаем).
* Деление по хранению: Широкие (много колонок) Длинные (много строк).
* Сегментирование - партиционирование - шардирование: деление больших данных на группы.
* Виртуализация данных: они лежат везде, 60-70источников - обычная история, идея - промежуточный уровень для абстрагирование от изменений в конкретных источниках.
* Качество данных. Тут много характеристик, было 4, теперь 20.
* Безопасность: генерация, маскирование, шифрование. Маскирование всегда необратимо, а отличие от шифрования, при этом маскирование может быть частичным.
* Обогащение данных. Это не только дополнение, это еще удаление ненужных данных, маскирование для увеличения доступности.

Денис Позднев. Личная база знаний или как не потеряться в информационном шуме. Есть много способов вести заметки, которые превращаются в базу знаний: OneNote, EverNote, Notion. Но у первых двух нет ссылок между заметками, Notion - попробовали решить ссылки через Базу данных, но там все сложно. А главное у них проплиетарное хранение в облаке, и если что - ваша база данных у вас пропала.

Obsidian - markdown в тестовых файлах. Структура - папки. Механизм шаблонов, за счет которого быстро делаем страницу. Например, хотим описывать книги - делаем шаблон "цитата" - там текст, ссылка на источник, свои мысли. И описание книги - тоже шаблон с автором, идеями и так далее. Markdown позволяет делать ссылки - и obsidian умеет рисовать граф ссылок между статьями. При этом граф можно фильтровать.

Obsidian позволяет подключать внешние плагины. Есть плагин, который формирует таблицы по заметкам. Например, если вы делали заметки по книгам - то можно делать разные списки книг. Plugin Calendar. Плагинов много, они пополняются. Поддерживает JScript и Closure - и можно делать запросы и визуализировать по-своему.

Синхронизация в облака - стандартными способами перетирает заметки, но сообщество сделало собственный плагин, с ним проблем у него не было. Есть возможность синхронизации в git.

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

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

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

Измерение интеллекта. Тест Векслера IQ - плохая метрика лучше отсутствия. Используется в судебной медицине. <70 - умственно отсталый и ограниченно вменяемый, от 100 умный, от 120 очень умный, а вот от 140 - слишком умный, обычно есть проблемы в адаптации и социализации.

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

Переход количества в в качества - появление сознания в ходе эволюции у жевотных. Муравьи со своим языком, передача сигналов, счет до 58. Гориллы обучаются до уровня 6-8 летнего ребенка. Характер, психотравмы и атк далее. И у хомячков, не говоря о крысах.

Современное представление: сознания и бессознательное в гармоничном единстве. Сфера ясного сознания невелика.

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

Мышление. Абстрагирование, Объектно-Ориентированное программирование. Восприятие картинок, абстрактный стол. Есть первобытные племена, где оно слабо развито - не было нужно. Не стоит удивляться, если у Заказчика не развито абстрагирование.

Я тут отмечу, что дихотомия Сенсорик - Интуит Майерс-Бриггс по сути меряет уровень абстрактного мышления и частоту его использования по сравнению с мозаичным мышлением из отдельных деталей.

Мышление.
* Цель мышления - вывод ответа, решение задач. Проверка гипотез. Этим занимается когнитивная система и в ней есть баги.
* Методы: Обобщение, Классификация, Абстракция.
* Виды: Предметно-действенное - до 3 лет. Наглядно-образное - может быть сложное, но очень сложно ложится на алгоритмизацию. Словесно-логическое или понятийное. Два полушария, фокусировка одного на наглядно-образном, другое на словесно-логическим.

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

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

Разговор с уточкой. Объясняешь другому - и наконец-то сам понимаешь.

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

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

Эффект Зейгарник. Заканчивайте на самом интересном месте.

Рекомендации
* учить язык каждый день 5-10 минут, читать по 5 страниц дважды каждый день
* магическое число 7+-2. Задача Эйнштейна, решить без бумаги - потому что надо держать много сущностей.
* Инженерные практики: цикломатическая сложность (7-9), количество реализуемых интерфейсов (5), количество методов до 9, глубина наследования до 5 - чтобы все это помещалось в голову.

Виды памяти - двигательная, образная, эмоциональная и так далее.
Рекомендация для запоминания - мелкая моторика, доски и маркеры, механическая клавиатура, беседа с уточкой, организация офиса (дартс, пинг-понг, турник, xbox). Виды внимания: непроизвольное, произвольное-волевое, послепроизвольное...

Follow ups - необходимость, иначе мысли размазываются и несфокусированные. Не только по встречам и созвонам, но и обсуждению с чатиками. Потому что когнитивные искажения, несосредоточенное внимание.

Примеры по повышении зарплаты, квалификации, премии - много примеров когда сотрудник уверен, когда после пары книг гарантированно повысят, а руководитель уверен, что внятно объяснил, что ему столько еще надо сделать, что будет не скоро.

Юрий Дручинин. Поддержка принятия решений в продуктовом стартапе. Обзорный доклад про особенности разработки продуктов. Много интересного, часть слайдов - для подробного разглядывания и гуления, их проскакивали в рассказе.

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

* Каждый шаг - деньги - нужно основание
* лучшее основание - валидные цифровые данные
* решение исполнено - надо оценить результат
* лучшее оценка исполнения - рост цифр
* Decision Execution Management - DXM - это очень дорого
* Минутки и заметки со встреч - DXM на минималках

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

В докладе фокус на гипотезе решения. Распадается на две: What (какую фичу реализуем) и How (как ее реализуем).
* What. Часто очевидные шаги, то что есть у конкурентов - не аргумент, большие рискованные шаги. Но быстро понятно, когда идете не туда.
* How - можно сделать по-разному, формально и просто, либо большой проработкой пользовательского опыта. Это влияет на имидж продукта. И они дают кумулятивный эффект. Аналитик тут может помогать и подсвечивать слепые зоны. У него mindset копать в детали даже простую фичу и из-за этого могут не попадать в сроки.

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

Контексты решений
* Активности продукта: поиск, проектирование, разработка и поставка, развитие
* Жизненный цикл разработки: анализ, дизайн, разработка, релиз, поставка, эксплуатация. И мониторинг
* Жизненный цикл продукта

SWOT-анализ и PESTEL. Делаются, но игнорируются, и потому делаются поверхностно. Когда наняли продукта, решение о стартапе принято. Хотя это была гипотеза, и ее стоит проверять. Но для этого от продукта нужна смелость. И надо копать в недостатки и Угрозы, Преимущества и Возможности Продукт прокапает сам.

Product Vision как артефакт. Нужно для решения о деньгах. Надо собрать основания. На слайде - конкретное содержание, 10 пунктов, включая Lean canvas.

CJM и USM.
* На действующем продукте строим CJM - продукт есть. И вокруг него USM, выделяя активности и провалы.
* На стадии стартапа наоборот, строим USM, и дальше на основе опросов пользователи конкурирующего продукта делаем CJM.

Основной источник фич - USM. Но дальше надо позиционировать фичи, с учетом реализации конкурентов, ожиданий пользователей, объемов реализации.

Гипотезы - HADI-циклы
* Очень плохо работает на старте, так как не видна разница между проверкой гипотезы и разработкой.
* Наиболее эффективно - на growth
* Плохо проверяет What, хорошо How

Roadmap. Когда напилили на фичи - декомпозировали по ролям и раскладываем. Product increment у них 6 спринтов. Но! На старте нет требований, нет понимания в деталях. Поэтому резервируем место. А далее попадаем в сроки через варьирование бантиков.

Сегментация аудитории - только тогда, когда понимаем состояние продукта, которое можем транслировать в рынок. Понятно, что гипотезы были. ABCX сегментации. Понимайте, что сегмент X может убить продукт. Не дай бог продукт вашего self-made стартапа захочет на ранней стадии купить госбанк, которому нужно ИБ и много другого - это угробит незрелый продукт.

Квадраты по определенности для продукта, стейкхолдера и клиента.

Сущности и скоуп продукта. Диаграмма классов - первое, что просит от аналитика. Оно хорошо обрисовывает скоуп продукта.

UX-концептинг 101. Берем сценарий, и описываем по шаблону

Бюджет, сроки, маркетинг. Режем скоуп, меняем позиционирование, ходим в рынок.

Продуктовая аналитика: экономические метрики и поведенческие метрики CJM - как пользователи реально ходят по продукту.

Презентация моего доклада выложена на моем сайте https://mtsepkov.org/DocStateTaskflow

Ирина Ремизова. Есть проблема? Нет проблем! Инструменты принятия решений. Доклад начался с выбора добровольцем из зала между яблоком и грушей, после которого вскрывалась дополнительная информация, которая, возможно, влияла на решение. И которая заставляла сожалеть о решении. Почему сложно принимать решения? Неопределенность, вариативность, влияние других людей, боязнь неверного решения.

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

Как работать с проблемой? Есть много workflow, она делится своим.
* Определение проблемы или задачи без оценочных суждений, как цель.
* Массив возможных вариантов - все записываем на бумагу. Например, все варианты поездки в отпуск, даже если сходу отвергаем
* Оценка - вычеркните непригодное, от чего отказаться
* Выбор из оставшихся альтернатив (это дальше)
* Внедрение решения - сразу, не уходить вподбор и поиск новых вариантов. Нет аналитическому параличу.
* Анализ внедряемого решения и изменение в случае не обходимости

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

1. Квадрат Декарта. Каждое решение оцениваем с 4 сторон.
* Мотивация. Что будет, если сделаю.
* Не хочу терять. Что будет, если не сделаю
* Цена решения. Что НЕ будет, если сделаю.
* Что мешает. Что НЕ будет, если НЕ сделаю.
В каждом квадранте выписываем последствия - положительные и отрицательные. Там есть плюсы и минусы. Можно посчитать плюсы и минусы по каждому решению.

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

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

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

Алексей Зуев. Чайка-анализ. Колесо баланса и BACCM для сил добра. В докладе два метода: (1) рисуем колесо баланса жизни или работы и (2) применяем модель базовых бизнес-понятий BACCM для принятия личных решений. Кажется, что это интересно, но способ принятия решений до конца не проявлен. Может быть потому, что это был блиц, и просто не успел раскрыть. Если кратко изложить то, что я понял, будет следующее. Модель выявления бизнес-понятий при применении к личным ситуациям позволяет выявить ценности и факторы, которые важны именно для тебя в какой-то области, например, касающихся ведения проектов. И дальше построить в Excel матрицу оценки, применить ее для прошлых проектов и для будущих. Разглядывание матрицы может позволить увидеть корреляцию и сделать кластеризаци.

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

Анастасия Прохорова из Райффайзенбанк. Event happens. Переход на Event Driven архитектуру глазами аналитика. Рассказ на простом примере "Хочу пиццу", по которому надо принять оплату, приготовить пиццу и ее доставить. В сервисной архитектуре это отдельные сервисы, которым надо дать команды: Прими оплату, Приготовь, Привези. Но Потребитель не хочет управлять, он хочет сказать "Хочу пиццу" и все. Это одно событие, на которые должны среагировать все сервисы.

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

Как вести документацию? По стримам разработки - им соответствуют процессы от начала и до конца.
* Бизнес: цели и гипотезы, не требования
* Объекты: жизненный цикл и событийный ряд
* Архитектура: схемы и зависимости
* State machine diagram и sequence diagram
* Документация - не со стороны отправителя, а со стороны получателя, их цели. Страничек - много, но они маленькие.

Как организовать события? Персонаж хочет пиццу. У разных подписчиков - разные вопросы по этому поводу.
* Notification: событие только сообщает про изменении объекта, а дальше потребитель спрашивает что ему нужно. Можно пакетировать - несколько изменений. Нагрузка на источник - повышенная.
* Event-carried state transfer - передача атрибутов в событии. В расчете на то, что их будет достаточно для всех подписчиков.

Правило проектирование
* Одним событием пользуется максимальное количество потребителей - стараемся угодить большинству
* Одно действие - одно событие. Получается не всегда.
* Атрибутов должно быть достаточно, но не избыточно.
Связь кто и что получает - полезно фиксировать.

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

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

Event storming. Коллаборация бизнес-пользователей и ИТ по исследованию области бизнеса. И помимо разбора бизнес и ИТ вырабатывают общий язык. Там выделяют Событие, Команда, Правило, Агрегат. Начинают с события - что произошло? Дальше команды как реакция на события и агрегаты, с которыми работаем. И в конце - выделяем ограниченные контексты.

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

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

Предыдущий стандарт системного аналитика делала группа под руководством Дениса Бескова в 2014, а новый - группа под руководством Сергея Нужненко, в которой около 140 человек и 40 экспертов. Организует ВНИИ Труда. Ирина в этом активно участвовала, а в докладе - рассказывала об изменениях в стандарте. Основное - изменили содержание работы аналитика, вместо формулировки "Содержание работ: разработки требований" стала формулировка "Миссия: координация на уровне проектных решений". То есть меняется разделение труда. Такое изменение - не их произвол, оно проявлено в индустрии, например, это видно по изменениям требований к позиции на HH. При этом написано разграничение со смежным ролями: бизнес-аналитик проектирует организацию; системный выявляет рамки автоматизации, собирает требования, включая атрибуты качества и проектирует; архитектор создает конструкцию, реализующая атрибуты качества и детальные требования; есть границы с техническим писателем, разработчиком, тестировщиком. Правда, открытый вопрос - отражено ли это изменение в смежных профессиональных стандартах?

Содержание работы системного аналитика определено через трудовую функцию, включающую трудовые действия, необходимые умения и необходимые знания. По сравнению с предыдущим стандартом добавлена защита информации, интеграция и API, распределенные системы - в 2014 это было сильно менее актуально. А также навыки программирования. Доработан и уточнен глоссарий. Уровни квалификации: младший - работа с требованиями, средний - разработка техпроекта, старший - концепция ТЗ и ведущий - управление группой. При этом после среднего уровня - развилка, а не линейное развитие: руководить группой можно без навыков старшего аналитика. Но я подозреваю, что на практике эту развилку не воспримут. По уровням расписаны не только профессиональные компетенции, но и ответственность, работа с неопределенностью и другие, в презентации были примеры. Интересно, насколько это соотносится с аналогичными уровнями в других профессиональных стандартах. На мой взгляд, тут интересен опыт британского стандарта SFIA, где семь уровней определены сквозным образом для всех специализация с точки зрения ответственности, самостоятельности и ряда других характеристик, при этом некоторые специализации заканчиваются на 4-5 уровне, в то время как другие, руководящие - начинаются с 3-4 или выше.

Стандарт находится в стадии предчистовика, идет окончательное согласование и утверждение в Минтруда, и он доступен в интернете - в презентации были ссылки, и можно будет посмотреть - презентации скоро выложат. Быстрым поиском в официальных материалах я нашел только реестр пересматриваемых профстандартов, но не их проекты.