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

Путь воина (красный): раб-воин; солдат; воин; офицер; полководец; крестоносец; завоеватель-игрок-распространитель культуры (Македонский, Суворов)

Путь политика (синий): Акакий Акакиевич; клерк; взяточник; чиновник; политик - помощник предпринимателя; государственный деятель; ??? (не знают примеров)

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

#featpir Алферов Павел. Национальные особенности управления. Роскошный доклад о национальных особенностях, с юмором и примерами. Которые поясняют, почему конструкции из книг не работают. И это не только личный опыт Павла, это исследования.

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

1) АНКА: Авось, небось, как-нибудь, а если не сработало - Аврал. Злейший враг любой системной деятельности. Все системные изменения проваливаются сквозь это. Придумывать, исполнять - зачем, само сделаем. А для аврала - слишком сложно.

Наблюдение Ву Андерсона, шведа, который руководил ГАЗом, потом АвтоВАЗом. То, что в Европе занимает неделю, в России можно сделать за день. И если дать задачу на неделю, все равно будут делать в последний день.

Модель Ананьина. 3 модели работ с неожиданностями.
* Японская модель: надо напряженно думать, чтобы их не допускать. Много сил и денег на планирование. Условия формирования: Стабильные правила, основанные на национальной традиции.
* Американская - да, подумаем. 5-10 рисков. Остальное неважно, как возник - решаем. Уважение к правилам игры, к изменению правил все быстро приспосабливаются
* Российская: пока не возник кризис - не смотрим, а когда возникло и не рассосалось - делают. И две кучки: часть отползает, другие не могут отползли - решают, и надо решить до катастрофы. -- Правила меняются, правовой нигилизм
Каждая родилась в своих условиях и работает в своих.

Фукусима. Нештатка, не предусмотренная сценарием: затопило дизель-генераторы. И Японцы думали, наши им говорили "делать надо, сейчас взорвется", а они так не могли.

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

2) Авторитарный стиль. Полномочия, ответственность сверху не дают, снизу - не хотят брать.

Наиболее эффективной российской управленческой технологией остается пинок животворящий. На том стояли и стоять будем. - это Шумков, Губернатор Курганской области. И разделяется многими.

Книга Exploring Culture. IBM 70-е. Жесткий дресс-код. Все одинаковы, но дела идет по-разному. Начал исследовать: В России Дистанция власти 93 из 100, одна из самых больших.

Игра Ну погоди: менеджер ловит яйца, которые сотрудники-курочки подкидывают.

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

3) Византийская система, ориентация на личные взаимоотношения.

Игра про эмоциональный интеллект. ИТ директора. Вы очень умные, скрывать не умеет. Это проблемы. Они приносят критерии, выбрали. А поговорить? А выяснить интересы сторон?

Что скажет княгиня Марья Алексевна? - Грибоедов. Или "нельзя отказывать Кузьмичу" - особенности национальной охоты.

3) Эрин Мейер. Culture map. Высокая дистанция власти, принятие решений сверху-вниз, доверие на основе отношений.

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

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

До ковида была история: Проектный олимп, конкурс проектного управления, он ездил на аудит. Одна российская компания ввела на 50 тыс. человек систему расчета зарплаты на основе грейдов, выравнивания и так далее, крутая штука. У них чеклист и там управление заинтересованными сторонами. Показывают большой лист А4, список. А как работали? Мнутся. А потом руководитель показывают только ему реестр заинтересованных сторон в Excel, и там написано то, что никому показывать нельзя. И эта таблица вскрывает эмоциональный рандомайзер.

Западные практики там, где вопрос профессионализма решает.

4) Несоблюдение правил. В России закон - не указатель, это совет. Островский Горячее сердце. Городничий: "Как судить? Если по закону - законы строгие. По ним или по душе?" - "По душе". Всемирный банк. Верховенство закона - Россия 146 место из 180.

Все работают активно, пишут регламенты. Они не работают. Работает управление по поручением. 2019: Президент РФ за 7 лет выпустил 17500 поручений. Все в ручном режиме. Все практики предполагают установку правил. А тут - ручной режим. Асхат Уразбаев. Что больше всего влияет на Agile? Как раз этот пункт. Все считают, что Agile - хаос. Нет Agile - правила, которые команда принимает и должна действовать. А она не действует.

5) Консерватизм и недоверие. Петр I: "Ибо сами знаете: что добро и надобно, а без принуждения не сделают". Круги доверия: семье, знаете лично, встреча в первый раз, другая национальность, всем. Россия - почти только семья.

Проектное управление. Главбух. Я ей "проектное управление..., а она - ты НДС за лучевые трубки поможешь возвращать? Я не про это - иди отсюда."

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

Все рассказанное, это НЕ болезни, а особенности. Анекдот: стоят двое смотрят на рыб, говорят "я бы так не смог, холодно, мокро" Рыбы "а что такое вода?" Вы все в этом живете.

Как сделать в этих условиях успешное проектное управление?
* Драматически важен сильный лидер проекта, пробивать головой
* Заинтересованный топ-куратор, который включен
* Упаковка проекта, первая первичная. 5 вопросов: зачем и для кого, результат, с кем пойдем и когда
* Стартовое совещание обязательно. Баста, кончились танцы, куратор и первое лицо должны сказать: со всех спрошу
* Работа с заинтересованными сторонами внутри
* Фокус на формальных и неформальных обязательствах
* Контрольные точки. Разбор красных: что сделать, чтобы успели
* Каждую неделю статус обязательный.
* Для сложных: управляющий комитет вовлеченных топов и статус на нем.

Литература. Прохоров, Ананьев, Аузан Культурные коды экономики, Хазин Лестница в небо, McKinsey От орг.эффективности к успеху, Эрин Мейер Culture map

#festpir Мужицкая Татьяна. Счастье / Льзя на грани фола. Вау-доклад, искрометный и по делу. Как сделать, чтобы рассказанное доходило? Есть простая БЛЯ-модель из трех пунктов. Дальше пунктирные заметки, что успевал записывать.

#festpir Мужицкая Татьяна. Счастье / Льзя на грани фола. Вау-доклад, искрометный и по делу. Как сделать, чтобы рассказанное доходило? Есть простая БЛЯ-модель из трех пунктов. Дальше пунктирные заметки, что успевал записывать.

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

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

Пирожок: Олег несет добро и счастье, его увидевши жена кричит: куда ты это тащишь, и так весь дом говном забит!

Чтобы увидеть новое - надо вылезти за пределы своего мирка. Не обязательно зону комфорта покинуть - можно форточку открыть.

Три врага, которые мешают восприятию выступления, мешают сделать своим, интериоризировать.

1) Скука. Как поставить цель - о, понятно, тут будет смарт. Хотя там может быть что-то другое. Как только человек понимает, что его зовет в игру эксперт - ученик: интерес пропадает. Запускаем на другой стороне критика. Он уверен, что сам все знает.

2) Сложность. Употребляет сложную терминологию, а людям-то непонятно.

В МГУ была преподавательница Ждан, учебник по истории психологии, и только ее история - правильная. Но пришла на экзамен очень подготовленная: взяла обои, нарисовала дерево психологии по ее учебнику и другим. Она посмотрела и говорит "заберите", а она не забрала, до сих пор жалеет. Сказала ей "Я простила советскую психологию за бесчеловечное отношение к людям" - Это как? - Последний, кто писал русским языком, был Выготский, потом Павлов, а потом - все. Анекдот про темы диплома: "Чем дальше в лес - тем больше дров" меняем на "О нарастании топливных ресурсов с продвижением вглубь лесного массива"; "Нафига попу гармонь" на "О роли музыкальных инструментов в жизни служителя культа". Почему так? Потому что Выготский умер молодым в 1938, остальные - не дураки, они поняли, что надо писать так, что была наука.

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

3) Отсутствие четкого критерия прогресса.

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

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

Когда делаю правильно - надо сказать, что сделал правильно, четко и не загрязняй фон. Если проходишь классическую терапию, прогресс есть? При чем тут мой дедушка? А фитнес - там понятно.

Компактная модель, как с этим быть. БЛЯ.
* Б - безумненько. Времена жесткого дресс-кода, идет на тренинг в серьезном костюме, но на шее - платочек с маленькими черепом и костями, знает кто-то увидит, опознает - есть жизнь. Пирожок: Нет в шоколаде шоколада, давно нет мяса в пирожке и мне становится тревожно - а вдруг и в людях нет людей. Безумненькое рождает надежду, что люди остались. ПИР - соответствует. Не обязательно хулиганство, руководитель бежит Айронмен. Но не безумно!
* Л - должно быть легко. Чтобы сразу начало получатся, чтобы человек понял. Знак судьбы - понятно. Люди замечают хреново, и не замечают, что хорошо. Искусство перевода на человеческий и обратно. Презентация - объяснить визуальными образами сложную информацию. Прирост процента. Автомобиль весит как член кита. Это запоминается без записывания даже.
* Я - ясные критерии. Как поймем, что продвигаемся. Шкала оценки, куда продвинулись. При чем без трактовок, не "качество жизни улучшится": вы думали "больше хорошего настроения", а он "ну и где мои бабки?" Дети хорошо учатся, когда ты показываешь прогресс.

Ребенку: ставим таймер на 45 минут, сколько успеем - столько сделаем. - А если ничего - Ничего, получишь двойку. Дальше делать -мне скучно. И дети сами включались, им было интересно - сколько они успеют за 45 минут. Жаль, я не знал такого метода...

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

Неделю назад выступал на online-части #flowconf, а сегодня offline. Данила Старосек РСХБ. Границы проекта в условиях the roof is on fire. Основной тезис доклада: хаос на проекте в условиях приближающихся сроков - хорошее время для интенсивного, взрывного роста на испытальном сроке. Иллюстрирован собственным кейсом. Ему неудобно говорить от первого лица, поэтмоу аватар-растение Митроша. Он что-то умеет в аналитике, запустил несколько проектов, окунулся в банки, работал с БД, хочет освоить фронт и бэк. Проект Единый фронтальное решение ЕФР - интеграция всей работы операциониста, стартовал с зимы, он пришел летом, команда собралась, но уже приближается первая контрольная точка, а работа не продвигается. При этом команда новая, большая неизвестность по legacy и менеджменту.

Первая неделя - все хорошо: документация, техзадания, инструкции. Потом опытные аналитики уходят в отпуск - лето, и он остается один в команде микросервиса (1 аналитик, 5 разработчиков). И Митроша начинает тушить пожары в эти две недели. Чтобы не тормозился проект.

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

Confluence. Митроша думал, что он есть - а там все сложно. И, в частности, важно не кидать ссылку на статью, а рассказывать структуру оглавления - понимание структуры дает возможность самому искать.

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

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

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

#flowconf Ольга Пономарева Райффайзен. Возможности Миро для работы аналитика. Хороший доклад в интерактиве с участниками про использование Miro. Если кратко, то это Miro - супер-инструмент для быстрых набросков, а вот для дальнейшего оформления - по-разному. Но есть много способов: есть много шаблонов и интеграций, в том числе от сообщества, есть встроенный PlantUML, которым удобно делать sequence-диаграммы и не только их, есть плугин для голосования, и его можно использовать для согласования, и ряд других приемчиков. Но есть альтернативы, например, доски для ретро и дизайна можно ввести в Figma, и тут у аудитории разный опыт. А требования и базы знаний - уже в Confluence, и версии надо отдельно сохранять. Все не перескажешь, надо смотреть. А из ограничений - число бесплатно доступных досок и размер самой доски, и второе - опасно, потому что с некоторого объема доска начинает виснуть, то есть ты добавил кусочек - и доска стала плохо работать.

#flowconf Юрий Куприянов. Скрытая работа аналитика по проектированию систем. Хороший доклад о том, что требования и проектирование неразрывны. Потому что анализ - он про деление на части и описание каждой системы. А системы-то еще нет, как разделить на части то, чего нет? Делается переход: делим на части требования, и аналитик их структурирует, и тогда получаются требования вместо системы, и реализуемость каждой части становится сомнительна. Где граница требований и проектных решений? Например, данные: концептуальная, логическая, физическая - но это про реляционку, а где мы это решили. Аналогично UX: сценарии пользователя описываем на языке форм. А если там не форма, а чат-бот. Или даже в шагах: запросить отчет - получить отчет: почему два шага, может отчет сразу придет без запроса; почему именно отчет. Требования: полные, непротиворечивые: как мы перешли от неполных и противоречивых к полным и непротиворечивым? Это е проверяется только проектировочным решением!

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

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

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

* Взаимодействие пользователя с системой. Главное - не с системой взаимодействовать, система - посредник взаимодействия между людьми и надо именно это проектировать. Заказ такси - взаимодействие с водителем. Редакторы - там все равно описание объектов реального мира и вопрос, как мы с ними работаем. Задача пользователя, шаги, принимаемые решения, какая информация нужна, какими объектами манипулирует. Все сложно, и не часто хочется заниматься. Сполски Руководство по UI дизайну для программистов. Дэн Браун 8 принципов информационной архитектуры, Курс Копылова Дизайн интерфейс для не дизайнеров.
* Хранение данных. Концептуальная, логическая и физическая. Обычно детализируют. Реально все не так. Концептуальная модель - то, что в мире, о чем говорит бизнес, не думая о системы. А дальше смотрим и пытаемся понять, на что похоже: объекты, изменения объектов, журнал работы и так далее. И исходя из природы выбираем подход к хранению, не обязательно реляционный - в Амазоне или другом облfке их множество. И дальше настраиваем в конкретном выбранной продукте хранения.
* Интеграция. Нет там требований, ее надо проектировать. А это других денег стоит. И дальше - набор ссылок, что делать.
* Архитектуры. Самое главное в этом - как команда разработки разбита по отдельным командам - закон Конвея. Архитектурные стили. Способ развертывания - аналитик об этом вообще не думываем, а он влияет на способ независимой доставки частей. Нефункциональные требования критично влияют на архитектуру, и вот этой части аналитик обычно не умеет совсем. Характеристики системы, которым должна отвечать система. А регулярно их просто вставляют в ТЗ, особо не вникая, потмоу что не понимают. Литература: Ричардс и Форд Фундаментальный подход к архитектуре и Современный подход к архитектуре, еще несколько книг. Роль аналитика тут - организатор и фасилитатор работы, чтобы бизнес-заказчики и разработчики искали реальное решение там, где оно нужно.

В дискуссии с Юрой: в ГОСТ был концепт проектирования: эскизный - технический - рабочий проект. И такая этапность гораздо более уместна, чем бизнес-анализ - требования - архитектура - дизайн.

#flowconf Святослав Котусев. Корпоративная архитектура: мифы и реальность. Тут надо сделать преамбулу, которой не было в докладе. Под архитектурой предприятия в докладе подразумевалась практика работы архитектора предприятия, а не описание архитектуры как таковой. И это один источник мифов: фокус на описании, а не на процессе. А второй источник мифов - фокус на инструменте.

Теперь кратко содержание доклада. 7 мифов.
1) Корпоративная архитектура - это план, как ИТ-ландшафт связывается с бизнесом. Продумали, сделали кучу диаграмм, потом реализовали. Так не бывает, в компаниях все динамично меняется, драйверы бизнеса меняются, сам план настолько сложен, что останется на полке. Реально это много документов, которые помогают разным людям принимать решения на разных уровнях. Решения про направления инвестиции денег. Решения про старт проектов. Планы конкретных проектов. И так далее.

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

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

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

5) Миф, что архитектура предприятия - про моделирование, описание в правильной нотации, например, Archimate. Проблема в том, что архитектура решает проблемы согласования бизнеса и ИТ, и руководители должны работать совместно. Руководители бизнеса нотацию Archimate не поймут, нужен PowerPoint и простые диаграммы. Интуитивно понятные диаграммы. А это - отдельное искусство, которым надо владеть. А еще Achimate позиционируется как язык для корпоративной архитектуры, но реально его используют мало, и ниша применения непонятная: для коммуникации с бизнесом не подходит. Хотя для внутреннего документирования архитекторами AsIs - может подойти.

6) Роль фреймворков в архитектуре предприятия. Есть списки, в некоторых до 50 штук? самые известные Захман, TOGAF. И впечатление, что главное в архитектуры предприятия про следование фреймворку. Это не так, ни один фреймворк не имеет успешной реализации, все они - продукт маркетинга, Захман работал маркетологом в IBM... Фреймворки FEF и DOD - есть публичные отчеты о том, что они промотали гигантские деньги, но ничего не сделали - анализ 10-летнего использования.

7) Исторический миф. Что EA предложил Захман в 1987, дальше пошли следующие. Реально все началось раньше, в 1951 первый проект внедрения системы расчета зарплаты, и там был человек Maestro of Technology, и он выполнял роль EA. D 1962 статья Master Plan of Information System в Harvard Business Review: пошаговый план, который мы можем увидеть в TOGAF, все это очень старое. То есть тема архитектуры - очень старая. А Захман - просто большой маркетинг от IBM.

Три верхнеуровневых процесса.
* Стратегия - Взаимодействие с руководителями бизнеса и формирование дорожных карт для инвестиций
* Тактика - Формирование проектов на основе дорожных карт
* Оптимизация - Анализ существующего ландшафта и предложения по его улучшению

И он собрал Enterprise Architect on a Page - то, что используется, можно загуглить по этой фразе.

Набор документов архитектора.
* Business Capacity model
* Technology Reference
* IT Investment roadmaps
* Detailed solution design

Как сочетается с Agile? Все равно есть архитектурные решения: набор технологий, способ встройки системы в ИТ-ландшафт, безопасность. И это - поле действия архитектора.

#flowconf Денис Цветцих. C4 model. Модель для описания архитектуры приложений и частично технологического уровня, сделал Simon Brown. 4 основных диаграммы: контекста - система в окружении пользователей и систем; контейнеры - состав системы из отдельно развернутых частей, например, клиент-сервер-база данных; компоненты - декомпозиция компонента на группы функций, например jar или dll; код - диаграммы классов. И три дополнительных диаграммы: ландшафта показывает более далекое окружение системы, над контекстом; динамическая - взаимодействие при обработке бизнес-процесса, через нумерацию стрелочек и детали сообщений; развертывания - ноды и масштабирование. Диаграмм кода и компонентов обычно строят IDE или EA, а остальные можно строить в разных инструментах: draw.io, Miro, Figma, Lucidchart, IcePanel.io - рисуют картинки, PlantUML и Structurizr - от автора c4 позволяют описывать псевдокодом.

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

Дам часть ссылок. Для кода полезен SOLID, описан у Теплякова "Паттерны проектирования на .Net" - там современное описание, у Эрик и Элизабет Фримен легче, классика Гамма и Хелм Приемы ООП и паттерны - 30 лет назад, уже многое встроено в язык, устарело.

Компоненты - надо знать слои: чистая архитектура, луковая архитектура, best practice для каждого уровня - rich, anemic, event, ORM, аспекты и т.п. Модкульный монолит или микросервисы, способы блокировки и так далее. Фаулер Шаблоны корпоративных приложений. И еще много - DDD, Чистая архитектура, книжки от MS. Но там есть хорошие и вредные советы, надо различать.

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

#flowconf Денис Бесков. Радикальное ускорение аналитических работ методикой Event Storming. Доклад из двух частей: проблемы классического подхода и Event Storming как метод решения этих проблем. Проблемная лично часть для меня - достаточно понятно и давно известна. Тем не менее, классические постановки по цепочке бизнес - модель бизнеса - требования - модель системы - система по-прежнему широко используются, потому что именно они положены в основу многих методологий. Именно поэтому фокусировка на этих проблемах - ценная часть доклада. Проблемы таковы.
1) Длинная цепочка преобразований, которая идет с искажением информации, особенно когда ситуация в бизнесе меняется в ходе проекта и надо изменить уже проработанные постановки.
2) Интервью с заказчиком дают противоречивую информацию, выявление противоречий и согласование - непросто и небыстро, особенно если интервью параллельно ведут несколько специалистов.
3) Описания бизнес-процессов в формальных нотациях (ARIS, IDEF0, BPMN, UML) непонятны заказчикам, они не могут их верифицировать, при этом создается ложное ощущение полноты информации. То же касается структур данных - диаграмм классов и ER-диаграмм. Впрочем, я лично тут не до конца согласен: да. полные нотации действительно непонятны, но если использовать ограниченные нотации и вести коммуникацию, то верификацию можно получить.
4) Требования часто скрытым образом содержат частные проектные решения, выработанные конкретным аналитиком, и неясно, что в них обусловлено предметной областью, а что - доопределено им произвольно. При этом решения являются фрагментарными, локальными.
5) Функциональные требования дают плохую основу для декомпозиции системы, так как не дают представления о структуре системы.

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

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

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

Отметим, что такое представление о предметной области хорошо совместимо с современными шаблонами реализации. основанными на независимых сервисах, управляемой событиями (event sourcing) и сообщениями, и разделяющем чтение информации и команды (CQRS).

Применение начать лучше внутри команды, для синхронизации контекстов и онбординга новичков. А далее можно попробовать с лояльным клиентом на небольшом проекте. получить опыт и расширять использование, делиться с коллегами. Event storming хорошо применим для большинства проектов. В нем нет необходимости для простых систем с CRUD операциями и слабой бизнес-логикой. Для отчетных систем есть модификация model storming - там нужен фокус на данных и их обработке.

Источники на русском - Сергей Баранов и Евгений Пешков, на английском - Брандолини и khononov (в процессе перевода).

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

Но сначала было о трендах развития, и здесь важно впечатление с лекции профессора в американском университете, который говорил слушателям: поймите, глобализация закончилась, сейчас нужна локализация в страну. То есть то, что по-нашему называется импортозамещением. И всем нужно сделать департамент по взаимодействию с государствам. В зале, кроме американцев, были европейцы, китайцы, он - русский. И на реплику китайцам "у вас друзей нет", те тут же ответили "Путин наш друг". Был ряд слайдов с трендами, но это надо смотреть презентацию детально, подробно не рассказывали. Единственное - про роботизацию. Уровень роботизации производства очень высокий, в России тоже есть отдельные примеры, например, на КАМАЗе, где 85% операций по сборке кабин делают роботы. Но в целом статистика печальна: 8 роботов на 10 тыс. работчих в то время как Южная Корея - 932, Китай и Тайвань - 200+, и даже Болгария - 23.

Теперь про ИИ. CharGPT активно проникает в жизнь. Знакомый HR уволил человека, который составляет вакансии, потому что ChatGPT делает лучше. Через 2 недели уволили ее саму. CharGPT умнеет. Сейчас искусственно притормозили, потому что такой как ChatGPT-4 по планам был только 2027, а он появился сейчас.

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

#festpir Выступление Алексея Ситникова. Выступление - осмысление текущей ситуации. Оно очень содержательное, но преимущественно повторяет прошлогоднее выступление Алексея, конспект которого можно прочитать в моем отчете https://mtsepkov.org/PIR-2022 (надо по оглавлению найти). Что не удивительно - big picture ситуации поменялся слабо. Эту часть я повторно излагать не буду.

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

В портфеле конференция JUG.ru появилась новая - конференцию аналитиков #FlowConf. Впечатления - позитивные, много качественного контента. Если сравнивать с AnalystDays, то больше архитектуры и системного анализа, Flow несколько ближе к разработке, конференции дополняют друг друга. Так что у аналитиков появилась еще одна конференция, в дополнение к ЛАФ, AnalystDays и ArchDays. Я публиковал заметки о выступлениях, и собирал их в отчет https://mtsepkov.org/Flow-2023 Он начинается с очень интересного выступления Романа Пионтика Архитектура как код, которое я посмотрел уже после конференции, так что в отчет стоит заглянуть.

Почти два года назад, в ноябре 2021, я делал доклад Модели softskill для тимлида на Infostart-2021. Организаторы сделали на его основе статью Модели softskill для тимлида, так что теперь содержание доклада доступно в удобном текстовом виде. Этот материал до сих пор актуален. С тех пор тема получила развития в сторону самоопределения человека и интегрированной модели личности, смотри доклады и статьи. Следующий такт развития будет на Teamlead в Москве в конце ноября.

Петр Щедровицкий проводит в Бодруме серию лекций по осмыслению денег: Деньги как инструмент углубления разделения труда. В 2016 я в течении года слушал большую серию лекций Петра по системам разделения труда и в своем блоге публиковал заметки по каждой лекции. Оперативная обработка заметки позволяют мне лучше осмыслить содержимое лекции, а публикация - обращаться за подробностями. Поэтому я продолжаю практику, воз заметки первого дня https://mtsepkov.org/PG-money-2023-1