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

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

Признаки Maslush & Juckson: часто смотрим на часы, сопротивляемся выходу на работу, откладываем встречи, избегаем творческого подхода к задачам и так далее - найдите и используйте.

Алгоритм, который советует применить. Шаги - стандартные, а реализация - разная
* Расчет ROI: что приобретем, а что потеряем в случае релокации. С учетом личной важности разных факторов. Часто считают, что переедет - и все наладится. не так. Если тут были проблемами с поиском девушки, то в Англии они усугубятся. Family risk 0 понять за детей и супруги-супруга. Например, в Минске встретить собаку без хозяина почти невозможно, а в Армении или Грузии - их много, они добродушные, но если боишься - будешь бояться гулять и особенно бегать, если увлекаешься. Медицина - если здоров, можно поехать в страну с дорогой или слабой медициной, а если слабое здоровье, или дети болеют - там риски. А еще беременность - там медицина важна. У него были проблемы, спорт их еще местами усугубил - про Белоруссию он знает, что она в топ-3 в мире и у него связи.
* Теоретическое исследование про переезд - истории из разных источников.
* Практическое исследование. Попробовать. А то товарищ решил провести остаток дней у моря и повыше, продал квартиру в Минске и купил там - и тут выяснил, что там зимой по утрам иней, и ему очень некомфортно ходить. Через два года вернулся. А мог снять квартиру на зиму.

Tips и Tricks
* Есть сайты - статистика преступлений по городам и районам. Посмотрите
* Был в Алма-Ате. Оказывается есть подвох. Много ломбардов. Посмотреть, кто туда входит - и увидеть кто входит. Оказывается много групп молодых людей приносят телефоны - откуда они?
* Зайти в любую травму и посмотреть кто. Не разбито лицо и тяжело раздроблена правая рука - значит начали кого-то бить, он увернулся и попали на по асфальту. Значит с детьми туда ехать не стоит.

Что дальше? Есть три книги, которые рекомендуются тем, кто хочет
* Джекобсон Секреты психиатрии
* Маккей, Скин, Фаннинг. Конитивно-поведенческая терапия для преодоления тревожности, страха, беспокойства и паники
* Франц Александр Психосоматическая медицина: принципы и применения

Алексей Романов, Ekaterina Romanova. Разговор Архитектора и Product Owner: Как понять, что нужно переходить на микросервисы? Очень интересная форма подачи доклада - это разговор Product Owner в выдуманной небольшой компании, которая online продавала билеты на offline-мероприятия в регионах, и у которой был монолит, и которая решила стать еще и организатором online-мероприятий с выдачей сертификатов, продажей записей, нужно развивать личный кабинет участника и организатора, да еще выходит на международный рынок, и потребуется интеграция с разными платежными системами, с архитектором, которого позвали на развитие системы. В докладе было про плюсы и минусы перехода на сервисную архитектуру.

В чем проблемы монолита?
* С ростом системы увеличивается сложность.
* Требуются аппаратные ресурсы для увеличения производительности
* Сложность рефакторинга и внедрения новых технологий - будет не хватать производительности стека.
* Любые изменения требуют повторного тестирования и развертывания
* Невозможность параллельной работы большого количества человек с одной кодовой базой - сильная связность, сложные merge
* Большая стоимость архитектурных ошибок - архитектурные ограничения

Если распилить монолит на несколько независимых микросервисов.
* Писать проще, чем большой монолит
* Горизонтальное масштабирование и отказоустойчивость
* Уменьшается вероятность ошибок, так как тестировать маленький функционал проще. Проще понять.

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

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

Минусы
* Время коммуникации по сети на взаимодействие
* Нужна хорошая система деплоя и развертывания новых виртуальных машин. Пока 3-4 можно без них, когда 20 - нет.
* Хорошее описание API между сервисами. Публичный контракт, держим консистентным.
* Отказоустойчивость не только сервисов, но и сети.
* При проектировании обрабатывать разрушения отдельных сервисов.
* Сложность декомпозиции из-за сильной связанности данных.

Вот тут я хочу сказать, что если посмотреть на минусы, то они уничтожают плюсы. Например, остальные части системы работают при падении одного сервиса, но появляется больше точек отказа, включая сеть. А забота о консистентности обработки в случае отказов, если задействуется несколько сервисов сильно увеличивает сложность разработки, и требует понимания межсервисного взаимодействия. Так же увеличивается сложность построения комплексных запросов по данным. которые в монолите лежат в одной базе. Таких пунктов много. И они в докладе, в общем-то не обозначены, а в результате оптимистичные ожидания вполне могут оказаться неверными. Вообще про грабли микросервисной архитектуры неделю назад был хороший доклад Филиппа Дельгядо на Saint Highload, у меня на сайте есть конспект.

Что меняется в разработке?
* Появляется DevOps - отдельная компетенция
* Декомпозиция задачи по сервисам, с ответственностью команд за отдельные сервисы. Нужно согласование API между командами.
* Хотя команды изолированы, есть взаимодействие.

Как переносить? Сохраняем монолит, откусываем кусочке. Поверх - dispatcher, который маршрутизирует запросы. А новое пишем в сервисы.

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

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

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

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

Radik Adiulin. CustDev в B2B: краткий гайд и уроки после 100 проведенных интервью. Перед тем, как разрабатывать - делают CustDev, чтобы убеиться, что продукт будет востребован. Есть Качественные и количественные исследования, разные способы. В докладе - про CustDev интервью - но процесс custdev этим не исчерпывается. Это лишь часть фазы customer exploratory.

Задача интервью: понять как пользователи принимают решения, в области, где вы делаете продукт
* Кто наши пользователи
* Какую проблему решает наш продукт
* Как эти пользователи выбирают продукты

В чем разница b2c и b2b?
* b2b больше обосновывает через рациональные инструменты (деньги, kpi лиц, принимающих решения и т.п.), то b2c - эмоциональная история, лишь сопровождаемая рациональным.
* b2b - чаще пользуются одни, а покупают другие. Как дети родителям.
* b2c - проще разговорить, потому что говорят про себя, а не про компанию
* b2b - проще понять, компании более однообразны, чем люди

Этапы
* Гипотеза - обязательно прописать, даже если идея продукта - мутная.
* Целевая аудитория
* Скрипт - следование ему не догма, но скрипт должен быть.
* Интервью - заметки или запись с последующим прослушиванием, можно проводить вдвоем, в конце вопрос: о чем важном не спросили
* Результаты - фиксируем общую ситуацию, обычно достаточно 8-12 интервью, и но это не догма, а внутренне ощущение, что ты знаешь ответы
* Итоги и артефакты. Документируйте - гипотезу, аудиторию, скрипты, результаты, выводы - потому что вы на этом основании будете принимать решения о продукте, а на разработке будут всплывать вопросы об их основаниях.

Проблемы
* Нет респондентов: network, отдел продаж, конференции, комьюнити, соцсети (но надо прокачать сервисы), отзывы конкурентов, платные сервисы.
* Интервью идут не гладко - ответы не дают понимания ситуации. Надо проверять свою гипотезу, может неверный сегмент аудитории. Если коммуникация не идет - попросите помощи, признайтесь в волнении
* Исследование не дает инсайтов - надо проверить гипотезу, она вполне может быть неверной, надо ее менять, может быть нужен другой инструмент исследований.

Стоит это 30-40 часов, занимает от 2 недель до 2 месяцев.

Кого опрашивать в b2b, пользователя или того, кто платит? Зависит от продукта. Если бухгалтерия или CRM - то того, кто покупает, он построит специалистов, потому что их много. А вот в сегментах, где дефицит квалифицированных специалистов, которые могут уйти, если их построят - то к пользователям надо идти. Можно еще поделить сегменты, про деньги - с одним, а сейла - о том, почему он до сих пор ведет Excel, а не пользуется CRM.

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

Фразы "риск - дело благородное", "кто не рискует - не пьет шампанское" Екатерину всегда смущали. В рисками надо работать, и эта работа очень близка работе с багами, которые тоже случаются. Баг - частный случай риска.

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

Что достигается путем работы с рисками?
* Возможность более точного определения срока и границ проекта. Это не про курсы, где учат "что будет, когда сломает ногу", "что будет, если не хватит финансирование" - не анализ не провели, или команду не набрали. Рисками занимаешься в истории от полугода (в старой реальности)
* Гибкость планирования и построения стратегии - про риски ты думаешь, и у тебя появляются сценарии. И не только на работе, но и в жизни. К сожалению или к радости - непонятно, иногда это как паранойя, а иногда выручает.
* Повышение прозрачности на уровне компании
* Сокращение числа инцидентов - вы об этом подумали
* Качество взаимодействия
* Качество взаимодействия между бизнес-подразделениями и разработкой - увеличивается понимание
* Формирование ценностного подхода на корпоративном уровне

Комикс из Дилберта, по-моему. Я оценил шансы что все пройдет гладко 70%. То есть когда провалится - ты признаешь, что был неправ? Но я только оценил шансы... Если у руководства такое отношение, то работать с рисками бесполезно. Риск менеджмент - это не игра в одни ворота. Риск - у компании, любой риск - твой риск. Нельзя заниматься в позиции эксперта. Риски приводят нас к необходимости анализировать, а это - ретроспективные практики. Самокопание, умение признавать собственные ошибки и далее - права на ошибку.

Типизация рисков. В разных книгах - по-разному, до 12. У нее - 4.
* Нормативно-правовые: законодательство и т.п.
* Ресурсные Прибыль, время, люди, техника. Риски по технике сейчас увеличились, на Кипре месяц нет поставки клавиатур с русскими буквами, с поставкой серверов, ноутбуков.
* Репутационные. По потребителям, пользователям, контрагентам, сообществам. И может быть положительный риск, представьте вы рассказываете о классной трансформации регламента или условиях работы - и репутацию запоминают. Социально-значимый контекст. Шаттлы, трагедия Челленджера - через два часа Рейган выступил с обращением к нации, и впервые начал "Нэнси и я" - семейная тема, и он нивелировал значительную часть рисков. Несоответствие качеству
* Технические риски: интеграционные, инфраструктурные и архитектурные. Внезапно узнаешь, что железка не отдает количество залитого топлива, а true/false.

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

Как работать с рисками? ROAMboard. Табличка, двигаем по доске: Resolved - Owned (есть владелец) - Accepted (принят участниками) - Mitigated (последствия минимизированы). Что классно? В работе с доской вы приучаете компанию к тому, что вы открыто обсуждаете риски и проблемы, что они должны быть видны всем. И вы начинаете разделять (share) ответственность. Есть антифрод или безопасность, вы показываете, за что они отвечают.

Цикл работы с рисками: Периодическая оценка - Выявление риска - Анализ риска - Оценка риска - Принятие решения.

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

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

Атрибуты риска. Не только содержание риска, но название, последствия реализации риска. У одного риска могут быть разные причины - можно раздавать ответственности. Критичность.

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

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

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

Триггер. Ситуация, которая должна наступить, чтобы риски сработали. Не обязательно катастрофа. Триггер обычно тоже риск. Можно в ROAM board - связи между рисками. В некоторый момент перейдете от ROAM board к mindmap. Это - следующий этап.

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

Полторы недели назад был в Ереване на SQAdays и AnalystDays. Влад Орликов сделал площадку общения между ИТ-шниками, которые оказались в разных странах ввиду современной геополитики, на конференции было много международных спикеров. Я хочу отметить не только активное общение, но и спокойную, ламповую обстановку и общий позитив. Публикую отчет https://mtsepkov.org/SQA-Analyst-EA2022 - собрал в него заметки с докладов и добавил общие впечатления.

Первый доклад ArchDays. Сергей Харламов. Архитектура масштабирования: ускоряем обработку и повышаем доступность данных. В современных распределенных системах транзакционность ACID на уровне системы, а не отдельной ноды или процесса практически не поддерживается, фокус на высокой доступности на смену ACID пришел BASE: Base Availability при сбоях, Soft state вместо acid-консистентности, Eventual consistency согласованность в будущем. При этом такие решения часто реализуются поверх старого РДБМСб которое используется как базовое хранилище в legacy- системах, от которых не отказываются. Для достижения используются различные механизмы: репликация баз данных; разные виды кеширования, при которых кэш работает как промежуточная БД, организованная по-другому, чем исходная; стриминг CQRS; CDC (Change Data Capture). Эти механизмы могут быть доступны в виде готовых решений, для других в БД предусмотрены точки расширения, третьи реализуются на уровне кода приложения. Засада в том, что в этих механизмах нужно разбираться для разбора инцидентов пользователей, и так же для понимания рисков при падении и последующем восстановлении. Это - не внутренность разработки, которая была В докладе был обзор шаблонов и разбор плюсов и побочных эффектов. Но рассказывать текстом - бесполезно, надо смотреть схемы на слайдах, так что смотрите презентацию.

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