#AgileDays Максим Фролов. Как снять организационное изменение с ручника. Руководство агенту изменений. В докладе - фокусы внимания при проведении изменений и инструменты для этого. Дисклеймер: это - личный опыт и инструменты, ваш контекст применения будет отличаться.

Основное: помните о цели изменения, используйте воображение чтобы ее достичь. Без чего изменение не поедет? Цель изменения, спонсор изменений (кто-то на достаточно высоком уровне драйвит) и видение результата. Цель - зачем, видение результата - как оно будет выглядеть. Без видения легко можно начать, но потом оно остановится.

Как понять, что что застряло? Читайте и смотрите документы, записи встреч, тикеты, файлы. Общайтесь с участниками: топ, мидл, стейкхолдеры. И сопоставляйте с документами. Измеряйте численно - ADKAR и другие системы метрик. ADKAR меряет принятие изменений по уровням Понимание - Желание - Знание - Способность - Закрепление.

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

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

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

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

Перебрендирование. Если был провал OKR - нельзя второй раз внедрять, это кино уже было. Делали орг.изменение - его обозначили как первый шаг в давно существовавшем проекте - отношение изменилось. Что-то достаточно поменять косметически. Важно: образ результата и явная работа над ошибками. Вообще предыдущие провалы можно признать успехом, просто частичным, и объявить, что идем дальше.

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

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

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

Еще инструменты
* FAQ
* итеративность и итерации, пилоты, опережающие метрики
* кричалки - масштабирование смыслов. "думать не людьми, а командами", "чем правее - тем важнее".

Есть скептики во всем. Может быть, был прошлый опыт. А может, им просто скучно. Таких надо вовлекать внутрь команды изменений. Что он может сделать. И даже когда будет отказ, он изменится. И когда директор не может нормально управлять и блокировать критику позовет в команду - он может сменить отношения. Но это - тяжело, человек уже стал врагом, а надо встречаться и вовлекать. Но вовлекать надо на своих условиях, в рамках - чтобы не получить саботаж внутри команды.

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

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

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

И не забывайте о себе:
* работайте в паре
* критикуют не вас, а вашу работу
* вас могут уволить - знайте об этом заранее, ведение изменений - риск, но вы сами это выбрали

В пятницу был на 20 конференции #AgileDays и, совершенно неожиданно, увидел, что Agile-методы получили новый импульс развития. Это требовало осмысления, поэтому сразу выложить впечатления с докладов Асхата Уразбаева и Ильи Павличенко не получилось. Так же как конспект доклада Павла Алферова о влиянии национальной культуры на использование Agile, затрагивающий не только западные культуры, но и Китай, Японию, Индию, Саудовскую Аравию со ссылками на источники исследований. Но за выходные я это сделал, ловите полный отчет https://mtsepkov.org/AgileDays-2025 со всеми докладами, которые я услышал на очном дне конференции. Громадное благодарность организаторам за такой контент. Вау!

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

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

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

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

В 2007 на конференции Software Best Practice мы узнали про Agile-методы и в результате притащили их в компанию. Сначала нашли и прочитали Книберга, еще по-английски, перевода не было, а потом — решили попробовать внедрить, и, в целом — успешно. Это было самое начало Agile в России, ScrumTrek еще не существовал, а Асхат Уразбаев работал в Люксофт. Но он консультировал нашу компанию, когда мы начали использовать Scrum. А отчет Software Best Practices-2007 — первый мой отчет о конференциях.
В 2012 на осенней SQAdays было несколько докладов, которые вместе дали мне целостных фреймворках тестирования, собираемых по частям, подобно сборке технологий под Java-стек. Вот отчет, где я об этом пишу. И, что интересно, на следующих SQAdays такого комплексного представления темы не было.
В 2014 на GoToCon в Копенгагене (отчет) я засек тренд реактивного программирования. И еще засек, что вендорские продукты перестали быть драйверами развития: библиотеки для реактивного программирования были open source и люди развивали их в рамках основной работы над проектом, дорабатывая функции, которые в нем были нужны.
Список можно продолжать, но я не буду. Отмечу только, что представление о возможностях ИИ за 2023—2024 годы я тоже получил на конференциях, при этом несколько особенно интересных докладов я услышал на региональных конференциях — возможно, сейчас они лучше отбирают контент.

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

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

На этом я закончу. А зачем ходите на конференции вы, и что полезного вы из них получаете?

25.04 (пятница вечер) в Москве пройдет бесплатный митап, и организаторы, команда Ви.Tech (ИТ из ВсеИнструменты) попросили разместить анонс на моем канале. Бесплатный митап - это хорошо, тем более когда на нем хорошие спикеры, а на этом митапе будет Дима Безуглый и Денис Бесков, которых я знаю очень давно, и некоторых других я тоже слышал на конференциях. Но вот формат выступления: 10 минут на спикера, при этом он должен за это время представить конкретный инструмент. Организаторы говорят, что 10 минут на выступление - такая фишка митапа, и они специально со спикерами работают, чтобы те уложились в тайминг. Как бы все хорошо: вы за полтора часа послушали пять спикеров, и если вас выступление зацепило, предложенный инструмент заинтересовал - то можете потом спикера подробно допросить. А если нет - то там будет тусовка с караоке. Но, с другой стороны, темы-то заявлены серьезные, и у меня есть сомнения, что за 10 минут получится их представить. Мне интересно, как оно будет, я бы и сам, возможно, сходил, но у меня выступление в Екатеринбурге на Dump. Подробнее посмотреть программу и зарегистрироваться можно здесь.

Прочитал книгу Ценностный код личности, авторы - Евгения Громова, Валерия Терентьева и Марина Герасимова. Про модель я услышал околло восьми лет назад от Валерии Терентьевой. Главный интерес - модель объясняет разницу между Россией и США, отправной точкой построения модели послужили исследования, почему американские маркетинговые модели работают в России гораздо хуже. Интересно, что разница состоит не в принципиальном различии ценностей, а лишь в статистическом распределении ценностных типов в населении. Далее исследования были распространены на другие европейские страны, и сейчас в основе модели лежит более 250 тысяч глубинных интервью, проведенных за более 20 лет исследований. Модель довольно сложная, в ней выделено 12 типов, каждый из которых имеет смыслообразующую ценность, драйвер-мотиватор, по-своему черпает энергию, организует процессы, оценивает результат и так далее. В моем отзыве https://mtsepkov.org/GromovaValueCode рассказано несколько больше. Но чтобы погрузиться в модель - надо читать книгу. Или смотреть выступления авторов, в отзыве ссылка тоже есть.

Периодически я вижу статьи, в которых заявляется, что ум, лидерство, альтруизм или какие-то еще личные качества обусловлены генетически, и потому ни воспитанием, ни личным образованием поправить уже ничего нельзя. Чаще это происходит в попсовых изданиях без особых ссылок, и раскапывать детали сложно. Но за последнюю пару месяцев я наткнулся на две информации, подтвержденные ссылками - про альтруизм и про успехи в образовании. А DeepSeek помог мне разобраться в деталях и увидеть проблемы в методиках исследований. Замечу, что содержательного обсуждения текст статьи надо вытаскивать, читать, находить ключевые моменты, и детально обсуждать их с DeepSeek. Просто скормить ему большой текст недостаточно, он ключевые тонкие моменты обходит при кратком изложении, наверное, потому, что авторы тоже их аккуратно обходят. Результаты - в моем посте https://mtsepkov.org/GenAndPerson, а если кратко, то метод, которым вычисляют генетическую обусловленность, может доказать, что длина волос определяется генами, а не ножницами. Или генами определяются эстетические вкусы, а наивные создатели индустрии моды с массовой рекламой этого не знают, и тратят деньги впустую уже сто лет.

Для тех, кто меня читает в Екатеринбурге и в Питере. Я завтра выступаю на Dump в Екатеринбурге, и сегодня уже прилетел, буду на препати спикеров. Если кто хочет встретиться - пишите. А завтра поздно вечером, после афтерпати - лечу в Петербург, где в субботу выступаю на SQAdays. B в воскресенье в первой половине дня тоже еще буду в Питере, так что можно со мной договориться о встрече.

Сегодня на #sqadays. Диана Ахметова и Александр Наумов из SM Lab. Промахи руководителя или как учиться на своих ошибках. Четыре истории ошибок руководителей и уроков из них. И у меня неожиданная ассоциация: истории очень похожи на истории неудачного построения отношений: в одной паре историй - о том, как партнера (команду) пытаются изменять, а он тебя посылает, а в другой паре - о том, как партнер оказывается крутым, но при этом слабо организованным, что напрягает, и развеивает ореол крутизны. Но уроки при этом о приемах, а не о смене отношения: для первой пары - о том, что надо изменять другими приемами, а для второй - что тщательнее отбирать. А значит истории будут повторятьcя, потому что по сути конструкт взаимоотношений не меняется, а именно он является причиной конфликта. Вообще интересно смотреть на истории рабочих отношений с точки зрения создания личных, можно подметить и типовые ошибки и типовые слепые зоны. А вообще - круто услышать рассказ об ошибках.

В пятницу 25.04 был первый раз на конференции Dump в Екатеринбурге. Впечатления - позитивные, 13 треков докладов, много нетворкинга. И замечательный доклад Михаила Толстого о моделях, которые помогают понимать людей. Публикую отчет https://mtsepkov.org/DUMP-2025 с конспектами тех докладов, которые я слышал. Это - малая часть, приходилось выбирать, куда пойти. Видео докладов ожидаются в публичном доступе, но примерно через полгода - буду ждать, некоторые доклады хотел бы посмотреть.

Опубликовал отчет о SQAdays https://mtsepkov.org/SQAdays-2025a - был на ней в субботу. По контрасту Dump — более молодежно-сленговый, например, вайб для описания хорошей атмосферы там в активном словаре, а на SQA — не звучит. Еще я засек, что LLM перестал быть чем-то новым, о чем надо отдельно рассказывать, а превратился в рабочий инструмент. «Мы развернули локальный LLM и научили разработчиков создавать тестовые наборы данных с его помощью» — маркер такого отношения. А один из докладов побудил внимательнее взглянуть на SDLC, и обнаружить, что это метод для исполнения царского указа «пойди туда, не знаю куда, принеси то, не знаю что». Это придумали не авторы доклада, они просто вставили схему из авторитетных источников, а я в нее вгляделся. Ну а завершал конференцию классный доклад про кубернетис на метафорах котиков в квартире. Подробности - в отчете.

19-20 апреля был на конференции Школы системного менеджмента Анатолия Левенчука. Я стараюсь быть на этих конференциях каждый год, чтобы смотреть за развитием школы, периодического чтения блога Анатолия мне не хватает. Публикую отчет https://mtsepkov.org/SysSchool2025 Школа развивается, прямо на конференции придумали смену позиционирования, чтобы подчеркнуть, что на курсах школы не освоение теории из учебника, а работа над рабочими проектами, для которой учебники служат руководством. Так их и решили называть дальше, а курсы превратить в стажировки.

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

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

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

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

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

Ну а 6-8 июня я под Костромой на ЛАФ, и тоже надеюсь, что будет много интересных докладов и нетворкинга. Хотя ЛАФ и AnalystDays - конференции аналитиков, они очень разные по атмосфере. Так было с самого начала, обоим уже полтора десятка лет (AD чуть моложе), и AD проходил как традиционная конференция, а ЛАФ в формате фестиваля, один день всегда был за городом, а теперь так проходят оба дня.

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

Я сегодня #AnalystDays, она в этот раз большая - почти 1300 участников. И сразу замечательный доклад: Артем Кузнецов Топ 15 трендов UX/UI дизайна на 2025-2027 год. Я сомневался, доклады про тренды часто поверхностны, а в этом - был глубокий разбор и содержания тренда и практических действий. Началось с минимализма - это старый тренд, но до сих пор актуальный. Потом были ИИ и ML, персонализация, кроссплатформенный UX, AR и VR, микровзаимодействие, голосовой интерфейс. Подробно пересказывать не буду, смотрите презентацию, орги их публикуют быстро. Тем более, что 15 трендов Артем разобрать не успел, но у него есть статьи и подробная презентация на 100+ слайдов, в презентации были ссылки.

Второй прекрасный доклад #AnalystDays: Ольга Павлова Как аналитику участвовать в проектах по дизайну интерфейсов. Основная мысль: собственно аналитическая работа по извлечению знаний занимает 7% работы аналитика и 99% резюме. Почему так? Потому что важно не просто собрать знания, а эффективно донести их. Люди не читают документы на 10 страниц с UML-схемами, они это игнорируют. Лошадь можно подвести к воде, попробуйте заставить пить - это об этом. Аналитические методы совершенствовать нет смысла, если задача - синтез решений и донесение смыслов.

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

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

3. Баланс сложности. Сложность мира бизнеса и мира технического. Нужна связь, не надо излишне упрощать.

4. Реальность клиентов. Это не про деньги, это про результат - спорт, достижения. В реальности системы и профи никакого спортивного духа достижения результата нет.

И нужен аудит: все виды реальности в результатах работы.

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

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

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

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

В вопросах к докладу была интересная оценка уровня: как случилось, что я сейчас за 20 минут узнала про задачи аналитиков больше, чем за два года обучения в университете...

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

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

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

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

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

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

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

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