#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

Продолжаю рассказ про лекции, сегодня была вторая: Базовые экономические гипотезы политической экономии и экономической теории, мои заметки 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 мой конспект