#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

Продолжаю рассказ про лекции, сегодня была вторая: Базовые экономические гипотезы политической экономии и экономической теории, мои заметки https://mtsepkov.org/PG-money-2023-2

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

2. За счет своего свойства опосредовать обмен благами, деньги представляют собой семиотическую (знаковую) система, которая обеспечивает координацию сложной совместной деятельности индивидуумов, имеющих различные образы будущего. Наряду с языком, чертежами, схемами и другими системами. Человек может вовлекаться в деятельность, не имеющую прямого отношения к его образу будущего, но дающую возможность получить деньги, с помощью которых он сможет продвинуться к своему образу будущего, если он полагает такой обмен соразмерным. Это — экономический аспект деятельности.

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

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

Я бы сказал, что это — детальное описание тезиса «Деньги — мера всего сущего». Важно, что эту роль может играть многие объекты и все они являются деньгами.

Сегодня на лекции разбирался кейс развития городов в Европе в 1250-1400 годах Конспект https://mtsepkov.org/PG-money-2023-4 Принципиальное изменение позиции человека: от следования традиции к необходимости самоопределения, предпринимательского отношения к самому себе. В городе человек должен стать частью СРТ, занять позицию, продавать свои знания и умения, чтобы купить еду, жилье и все остальное, жизнь монетизирована, в отличие от феодального поместья, в котором было натуральное хозяйство. И особое значение приобретает сбережение заработанного - так как дает возможность не ступать в СРТ на нежелательных условиях.

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

Шестая лекция Петра Щедровицкого показывала сложность процессов - цепочки производства и роль времени, и при этом был ряд интересных тезисов. https://mtsepkov.org/PG-money-2023-6 мой конспект

Сегодня была последняя лекция Петра Щедровицкого про деньги https://mtsepkov.org/PG-money-2023-7 и на ней была интересная схема, которая описывала пространство денег.

Тема осмысления денег на Школе напомнила, что у меня есть статья по сопоставлению деятельности компаний и банков, если рассматривать ее через призму учета. Учет - отражение деятельности в виде потоков материальных и денежных ресурсов. Статья не завершена, потому, что показалось. что нет потребителя: специалисты по учету работают каждый в своей области, а остальные про учет не думают, им сначала надо погружаться. Но я решил вытащить статью на свой сайт https://mtsepkov.org/AccBankVsCompany Если кому-то покажется интересным - я готов сотрудничать в этом направлении.

20 сентября участвовал и выступал в Казани на конференции Up!date, в рамках форума Kazan Digital Week. Мои впечатления https://mtsepkov.org/Update-2023 Форум - событие федерального уровня, а Up!date - IT-конференция, которую в рамках форума организует группа Барс Груп. В целом программа интересная, и я жалею, что у меня не получилось посмотреть выставку, и побывать на других секциях.

На рубеже октября и ноября 30.10-03.11 будет идти Podlodka Teamlead Crew - интересный формат, когда конференция online идет всю неделю по утрам и вечерам. Тема этой конференции - стратегия. Я выступаю в среду вечером (01.11 19:00), будет обзор школ стратегирования и приземление на современные условия, в которых главное - готовность к неожиданностям и вызовам. А кроме меня всю неделю - много хороших спикеров, включая Славу Панкратова и Анну Обухову. Это, конечно, платно, но не слишком дорого.

P.S. F на следующей неделе 27-28.10 будет AnalystDays, на ней я выступаю с рассказом про рациональное и системное мышление и тоже будет много интересных спикеров, в том числе Анатолий Левенчук.