Сегодня была последняя лекция Петра Щедровицкого про деньги https://mtsepkov.org/PG-money-2023-7 и на ней была интересная схема, которая описывала пространство денег.
🥰3👍1
Тема осмысления денег на Школе напомнила, что у меня есть статья по сопоставлению деятельности компаний и банков, если рассматривать ее через призму учета. Учет - отражение деятельности в виде потоков материальных и денежных ресурсов. Статья не завершена, потому, что показалось. что нет потребителя: специалисты по учету работают каждый в своей области, а остальные про учет не думают, им сначала надо погружаться. Но я решил вытащить статью на свой сайт https://mtsepkov.org/AccBankVsCompany Если кому-то покажется интересным - я готов сотрудничать в этом направлении.
🐳1
20 сентября участвовал и выступал в Казани на конференции Up!date, в рамках форума Kazan Digital Week. Мои впечатления https://mtsepkov.org/Update-2023 Форум - событие федерального уровня, а Up!date - IT-конференция, которую в рамках форума организует группа Барс Груп. В целом программа интересная, и я жалею, что у меня не получилось посмотреть выставку, и побывать на других секциях.
👍7
На рубеже октября и ноября 30.10-03.11 будет идти Podlodka Teamlead Crew - интересный формат, когда конференция online идет всю неделю по утрам и вечерам. Тема этой конференции - стратегия. Я выступаю в среду вечером (01.11 19:00), будет обзор школ стратегирования и приземление на современные условия, в которых главное - готовность к неожиданностям и вызовам. А кроме меня всю неделю - много хороших спикеров, включая Славу Панкратова и Анну Обухову. Это, конечно, платно, но не слишком дорого.
P.S. F на следующей неделе 27-28.10 будет AnalystDays, на ней я выступаю с рассказом про рациональное и системное мышление и тоже будет много интересных спикеров, в том числе Анатолий Левенчук.
P.S. F на следующей неделе 27-28.10 будет AnalystDays, на ней я выступаю с рассказом про рациональное и системное мышление и тоже будет много интересных спикеров, в том числе Анатолий Левенчук.
podlodka.io
Онлайн-конференция Podlodka Teamlead Crew, сезон #16
Недельное мероприятие от команды Podlodka: ежедневные интерактивные сессии в Zoom по актуальным проблемам тимлидства, нон-стоп общение с экспертами и звёздами индустрии, закрытое профессиональное сообщество в Telegram.
🔥5👍3
На этой неделе прошла конференция High Performance Systems, и мне было интересно посмотреть, что происходит в enterprise-мире. Я выступал с докладом про гибкую архитектуру, слушал других, как всегда, записывал впечатления и опубликовал конспект https://mtsepkov.org/HPS-2023 Читайте! А уже завтра выступаю и слушаю на AnalystDays.
🔥3
#AnalystDays Презентация моего доклада Рациональное и системное мышление: практики и компетенции аналитика - на моем сайте https://mtsepkov.org/SysThink-AD23 Это была попытка вместить очень много доклад, она не очень получилась. Но можно на слайдах посмотреть примеры, рассказать которые не получилось и попробовать прикинуть, как бы аналогичный пример выглядел на материалах вашего проекта. А я буду развивать тему.
👍8🐳1
#AnalystDays Polina Latypova из Evocargo. Как мы столкнулись с тщеславной метрикой и победили её. История из мира беспилотной логистики. Очень интересный доклад по предметной области — беспилотные грузовики, которые уже активно работают на закрытых территориях, обычно складах. Автономные, электрические, 2 тонны, средняя скорость 20 км/ч, зарядка от розетки 6 часов на 200 км. На той же площадке могут ездить трактора, управляемые людьми, и ходить люди. Хотя грузовики — автономные, в особых ситуациях требуется вмешательство оператора с диспетчерского пункта. Речь не идет о срочной остановке, просто машина по какой-либо причине не может продолжать движение из-за каких-то препятствий и, например. может запросить разрешение на объезд по встречной полосе или сигнализировать о проблеме. В докладе были примеры и для других автороботов, например, застрявший в сугробе доставщик или массовый сбой Cruise, когда много машин приехали в одно место создали пробку.
Метрика disengagement rate — число вмешательств оператора на км. И это метрика, в которой соревнуются компании. Был график с сайта therobotreport.com — в Калифорнии публикация этих данных обязательна. И они тоже начали собирать эту метрику. Однако, в исходном виде — число вмешательств на км — ничего не говорит. Уменьшение значения — не говорит, что технология стала лучше. Кроме того, автомобили — в разных погодных условиях, поэтому сравнение этих метрик по разным складам или разным дням тоже не информативно. Потребовалась дополнительная аналитика, в частности деление по причинам вмешательства: ошибка автопилота, физическая неисправность, изменение задачи уже в процессе движения и внешние обстоятельства, например, полная блокировка разрешенного участка дороги. При этом есть нюанс квалификации. Машины умеют объезжать препятствия. Но могут быть тупики, когда автомобиль окружили фуры, и проехать реально нельзя. Далее Обогащение данных: время вмешательства, в какой режим из автоматического переключаешься, что использовал оператор для вмешательства, версия релиза и так далее, и не только из автопилота, но и из других систем. И на обогащенных данных получилась возможность ловить реальные проблемы и разбираться. В докладе было несколько примеров, связанных с частыми остановками или ручными вмешательствами в определенном месте. И дальше выявляется и устраняется причина. В одном случае это был маленький человечек на разметке, которого автопилот принимал за человека, в другом — после обновления автопилот перестал доезжать несколько сантиметров до гейта, а на конкретном складе это было важно и потребовалось дообучить, и так далее. В целом это аналогично любому анализу инцидентов, но сама предметная область — интересная.
Метрика disengagement rate — число вмешательств оператора на км. И это метрика, в которой соревнуются компании. Был график с сайта therobotreport.com — в Калифорнии публикация этих данных обязательна. И они тоже начали собирать эту метрику. Однако, в исходном виде — число вмешательств на км — ничего не говорит. Уменьшение значения — не говорит, что технология стала лучше. Кроме того, автомобили — в разных погодных условиях, поэтому сравнение этих метрик по разным складам или разным дням тоже не информативно. Потребовалась дополнительная аналитика, в частности деление по причинам вмешательства: ошибка автопилота, физическая неисправность, изменение задачи уже в процессе движения и внешние обстоятельства, например, полная блокировка разрешенного участка дороги. При этом есть нюанс квалификации. Машины умеют объезжать препятствия. Но могут быть тупики, когда автомобиль окружили фуры, и проехать реально нельзя. Далее Обогащение данных: время вмешательства, в какой режим из автоматического переключаешься, что использовал оператор для вмешательства, версия релиза и так далее, и не только из автопилота, но и из других систем. И на обогащенных данных получилась возможность ловить реальные проблемы и разбираться. В докладе было несколько примеров, связанных с частыми остановками или ручными вмешательствами в определенном месте. И дальше выявляется и устраняется причина. В одном случае это был маленький человечек на разметке, которого автопилот принимал за человека, в другом — после обновления автопилот перестал доезжать несколько сантиметров до гейта, а на конкретном складе это было важно и потребовалось дообучить, и так далее. В целом это аналогично любому анализу инцидентов, но сама предметная область — интересная.
🔥4👍1
#AnalystDays Павел Германов из НОТА. Плагинизация. Выделение функций системы в подключаемые плагины. Основная идея - вынести изменяемый и дополнительный функционал системы в плагины. В общем, давно известная конструкция, в массовых продуктов она появилась, наверное, в Mozilla Firefox, в котором с самого начала было множество плугинов, в отличие от IE. А в enterprise типичным плугином является форма печати, которые даже часто отдаются клиентам, потому что там есть большое разнообразие и механизмов настройки по шаблонам часто не хватает. Они выделяют плагины в своих системах, но их разработку держат сами, клиентам не отдают. При этом основа процесса остается в core-системы. И в этом отличие подхода плагинов от подхода оркестрации сервисов или компонентов внешним средством, как это делает comunda или аналогичные движки. К сожалению, глубокого погружения в выделение плагинов не было, был лишь слайд с принципами выделения.
👍3
AnalystDays_17_ailev-4.jpg
153.9 KB
#AnalystDays Анатолий Левенчук. Интеллект-стек для инженеров и менеджеров. Интеллект стек - комплексное представление о наборе дисциплин/умений/практик мышления, которые требуются для эффективной деятельности, позволяют строить модели и обеспечивать изменения в реальном мире на их основе. Конечно, это не стек, а сложный граф с зависимостями, но там есть логическая последовательность базовых практик, над которыми далее вырастают практики инженера, практики менеджера, как это показано на слайде, и еще практики инженерии личности, которые пока не нарисованы.
👍4❤1
AnalystDays_17_ailev-5.jpg
235.7 KB
А на этом слайде - раскрытие названий практик, которые представлены на предыдущем слайде. И по ним надо брать современное содержание, потому что развитие ИИ опрокинуло многие старые представления, касающиеся языка и мышления, стало ясно, что устроено все сильно не так.
❤1
А дальше были комментарии к отдельным практикам. Школа этим практикам не учит, вернее учила лишь косвенно. В теории детей надо подготовить к жизни, чтобы они могли себя прокормить, но на этом в школе фокуса нет, и в ВУЗе тоже. Раньше жизни учила улица и подъезд, а сейчас эта часть социальной жизни отвалилась, так что все - сами.
Но сначала - совершенно роскошная метафора. Очень многие люди, почему-то не думают о воплощении модели в реальном мире, они считают, что написали документ, сделали модель - и мир изменится сам. Это - магическое мышления, подобное магу вуду, который полагает, что достаточно воткнуть булавки в куклу - модель человека и у реального человека что-то изменится. Практика говорит, что это - не так.
Понятизация. Картинка - дайте имя объекту. И эо когда вы приходите к клиенту - и каждые два дня понимаете, что имя не то и объект не тот. А можно ощутить дребезг в теле, кинестетика, ощущение. И у всех кто на высоком уровне есть та или иная телеска для того, чтобы чуять - правильно или нет. Что ты выделяешь, когда смотришь на оратора. Можешь ли поменять фигуру и фон.
Собранность. Кривая забывания и компьютерная память. Мнемотехники. Удержания понятий. Список работает до 400 строк, а дальше - заведи базу данных. А до 400 - все равно написать, начиная с 2 строк, а лучше - с одной. У организации тоже есть собранность: либо коллектив помнит, каким проектом занимался вчера, или не помнит.
Понятия - математика, предметы окружающего мира - физика. Математическому мышлению не учат, учат отраслям математики. Так же как и физическому мышлению вообще.
Семантика. Нагружение знаков смыслом, связь их с реальным миром.
Теория понятий - теория прототипов или образцов, и это экспериментально подтверждено. Логики там нет. Объяснить нейросети, что такое двуручный меч?
Онтология - машинка типов. 5 уровней: foundation ontology - типы систем, практик - типы объектов труда, деятельности - типы объектов прикладных дисциплин - модель экземпляров объектов.
Алгоритмика. 1.0 - то, что все деляют, 2.0 - ИИ и обучение, 3.0 - когда онтологии и программы пишут нейронные сетки.
Логика. А чо такова? Реагировать на ошибки в рассуждениях. 2*2=5 - ну и что?
Рациональность.
Эстетика, как естественная наука.
Этика - многоуровневая.
Риторика - должна быть этична. И переводит между разными теориями понятий.
Методология - схема, как устроено предприятие. Она дает объекты внимания, альфа, которые меняются в ходе проекта.
Системная инженерия, то есть обобщенная инженерия систем. С 2017 года требований нет, архитектура - нечто другое. Инженерия платформ вместо devops.
А дальше пошли надстройки: инженерия конкретных систем, менеджмент - инженерия организация и инженерия личности.
Но сначала - совершенно роскошная метафора. Очень многие люди, почему-то не думают о воплощении модели в реальном мире, они считают, что написали документ, сделали модель - и мир изменится сам. Это - магическое мышления, подобное магу вуду, который полагает, что достаточно воткнуть булавки в куклу - модель человека и у реального человека что-то изменится. Практика говорит, что это - не так.
Понятизация. Картинка - дайте имя объекту. И эо когда вы приходите к клиенту - и каждые два дня понимаете, что имя не то и объект не тот. А можно ощутить дребезг в теле, кинестетика, ощущение. И у всех кто на высоком уровне есть та или иная телеска для того, чтобы чуять - правильно или нет. Что ты выделяешь, когда смотришь на оратора. Можешь ли поменять фигуру и фон.
Собранность. Кривая забывания и компьютерная память. Мнемотехники. Удержания понятий. Список работает до 400 строк, а дальше - заведи базу данных. А до 400 - все равно написать, начиная с 2 строк, а лучше - с одной. У организации тоже есть собранность: либо коллектив помнит, каким проектом занимался вчера, или не помнит.
Понятия - математика, предметы окружающего мира - физика. Математическому мышлению не учат, учат отраслям математики. Так же как и физическому мышлению вообще.
Семантика. Нагружение знаков смыслом, связь их с реальным миром.
Теория понятий - теория прототипов или образцов, и это экспериментально подтверждено. Логики там нет. Объяснить нейросети, что такое двуручный меч?
Онтология - машинка типов. 5 уровней: foundation ontology - типы систем, практик - типы объектов труда, деятельности - типы объектов прикладных дисциплин - модель экземпляров объектов.
Алгоритмика. 1.0 - то, что все деляют, 2.0 - ИИ и обучение, 3.0 - когда онтологии и программы пишут нейронные сетки.
Логика. А чо такова? Реагировать на ошибки в рассуждениях. 2*2=5 - ну и что?
Рациональность.
Эстетика, как естественная наука.
Этика - многоуровневая.
Риторика - должна быть этична. И переводит между разными теориями понятий.
Методология - схема, как устроено предприятие. Она дает объекты внимания, альфа, которые меняются в ходе проекта.
Системная инженерия, то есть обобщенная инженерия систем. С 2017 года требований нет, архитектура - нечто другое. Инженерия платформ вместо devops.
А дальше пошли надстройки: инженерия конкретных систем, менеджмент - инженерия организация и инженерия личности.
👍5❤2
#AnalystDays Айгуль Габдрахимова. Стресс, адаптация, гибкость: как аналитику сохранить нервы и мозги. Доклад из двух частей: стресса и про теорию множественного интеллекта Говарда Гарднера. И у меня этот доклад вызвал печальку по поводу современного уровня мышления, это как раз иллюстрация того, о чем говорил Левенчук и я в своих докладах. И я хочу разобрать, с чем эта печалька связана.
Первое. Про стресс, со ссылкой на научпоп модель было сказано, чо он возникает как реакция на изменения, естественный, и ничего с ним сделать нельзя. Но стоит проверить физиологию, потому что связан уровнем кортизола, и он может просто плохо выводиться почками. И стоит посмотреть на базовые потребности по Маслоу, потому как если вы стабильно не высыпаетесь, что-то в жизни надо менять. Так вот, современная наука знает о стрессе достаточно много, там 5-6 разных вариантов, со своими причинами и способами управления. И надо сначала диагностировать, что именно у вас, а потом - работать над устранением конкретных причин. Как при любых нарушениях. Если кому интересны подробности, то можно посмотреть доклады Обуховой, у нее их много, она профи - среди ее шести высших есть биология и нейрофизиология.
Второе, тоже про стресс. Спикер - аналитик, но эту лапшу про стресс из книги приняла как теорию. Хотя эта лапша аналогична следующему ответу разработчиков на претензии по поводу большого количества инцидентов в программе: инциденты связаны с ошибками, а ошибки могут возникать при любых изменениях в программах, и потому всегда будут если программы развивать, а еще может быть ненадежная связь с сервером, вы проверьте, у вас сетевой кабель хорошо воткнут или нет. Понятно, что это - непрофессиональный ответ, что с инцидентами надо разбираться: кластеризовать, выявлять распространенные и проводить анализ их причин, а затем - придумывать, как их можно исключить. И вот тут то же самое: получен фиговый ответ общего характера, значит надо искать другие ответы. Конечно, он получен в чужой области, но критическое мышление - оно от области не очень зависит, его стоит применить.
Третья печалька - про теорию множественных интеллектов, которая признана как актуальная теория в современной педагогике. Говард Гадрнер выделил 9 видов интеллекта: Внутриличностный, Вербальный (или лингвистический), Логико-математический, Экзистенциальный, Пространственный, Музыкальный, Межличностный, Телесно-кинестетический, Природоведческий, позднее добавил еще несколько. Причина появления этой теории понятна - социальный заказ объяснить, что все люди - ценны, независимо от их IQ. Он выполнен, IQ меняет только 3 из них, а есть вот еще сколько.
Но дело в том, что эта классификация - это типология Борхеса, она не имеет оснований. Если смотреть на реальные конструкции, то надо исследовать системы мозга и обосновывать. И как-то отделать системы нейронов в мозгу, ответственные за конкретные типы интеллекта. Восприятие целостно, это хорошо иллюстрирует восприятие фрагмента От улыбки станет всем светлей, которому еще подтанцовывали - там музыка, движения тела, текст, да еще культурный контекст. При этом культурная составляющая играет существенную роль. В той же музыке - западная музыка, основанная на приятном нотном стане сильно отличается от имеющих другие лады. Да и языковые интеллект карты у китайцев сильно отличаются от западных, арабских и других алфавитных письменостей, потому что в Китае сильное влияние описывают конструкции иероглифов из конкретных образов. Отдельная вишенка на торте тут экзистенциальный интеллект, который отвечает за осознание смысла жизни, а вкладывают в него умение наслаждаться текущим моментом, достигаемое через медитации, направленные на осознание своих ощущений. Понятно, что это тоже социальный заказ, человек, реально задумывающийся о смысле жизни в деятельном залоге, стремящийся сделать мир лучше - опасен для современного общества. Поэтому объявим правильным смыслом жизни умение наслаждаться текущим моментом. Отмечу, что тут к спикеру - никаких претензий, она адекватна изложила теорию, я погуглил другие краткие изложения и сопоставил.
Первое. Про стресс, со ссылкой на научпоп модель было сказано, чо он возникает как реакция на изменения, естественный, и ничего с ним сделать нельзя. Но стоит проверить физиологию, потому что связан уровнем кортизола, и он может просто плохо выводиться почками. И стоит посмотреть на базовые потребности по Маслоу, потому как если вы стабильно не высыпаетесь, что-то в жизни надо менять. Так вот, современная наука знает о стрессе достаточно много, там 5-6 разных вариантов, со своими причинами и способами управления. И надо сначала диагностировать, что именно у вас, а потом - работать над устранением конкретных причин. Как при любых нарушениях. Если кому интересны подробности, то можно посмотреть доклады Обуховой, у нее их много, она профи - среди ее шести высших есть биология и нейрофизиология.
Второе, тоже про стресс. Спикер - аналитик, но эту лапшу про стресс из книги приняла как теорию. Хотя эта лапша аналогична следующему ответу разработчиков на претензии по поводу большого количества инцидентов в программе: инциденты связаны с ошибками, а ошибки могут возникать при любых изменениях в программах, и потому всегда будут если программы развивать, а еще может быть ненадежная связь с сервером, вы проверьте, у вас сетевой кабель хорошо воткнут или нет. Понятно, что это - непрофессиональный ответ, что с инцидентами надо разбираться: кластеризовать, выявлять распространенные и проводить анализ их причин, а затем - придумывать, как их можно исключить. И вот тут то же самое: получен фиговый ответ общего характера, значит надо искать другие ответы. Конечно, он получен в чужой области, но критическое мышление - оно от области не очень зависит, его стоит применить.
Третья печалька - про теорию множественных интеллектов, которая признана как актуальная теория в современной педагогике. Говард Гадрнер выделил 9 видов интеллекта: Внутриличностный, Вербальный (или лингвистический), Логико-математический, Экзистенциальный, Пространственный, Музыкальный, Межличностный, Телесно-кинестетический, Природоведческий, позднее добавил еще несколько. Причина появления этой теории понятна - социальный заказ объяснить, что все люди - ценны, независимо от их IQ. Он выполнен, IQ меняет только 3 из них, а есть вот еще сколько.
Но дело в том, что эта классификация - это типология Борхеса, она не имеет оснований. Если смотреть на реальные конструкции, то надо исследовать системы мозга и обосновывать. И как-то отделать системы нейронов в мозгу, ответственные за конкретные типы интеллекта. Восприятие целостно, это хорошо иллюстрирует восприятие фрагмента От улыбки станет всем светлей, которому еще подтанцовывали - там музыка, движения тела, текст, да еще культурный контекст. При этом культурная составляющая играет существенную роль. В той же музыке - западная музыка, основанная на приятном нотном стане сильно отличается от имеющих другие лады. Да и языковые интеллект карты у китайцев сильно отличаются от западных, арабских и других алфавитных письменостей, потому что в Китае сильное влияние описывают конструкции иероглифов из конкретных образов. Отдельная вишенка на торте тут экзистенциальный интеллект, который отвечает за осознание смысла жизни, а вкладывают в него умение наслаждаться текущим моментом, достигаемое через медитации, направленные на осознание своих ощущений. Понятно, что это тоже социальный заказ, человек, реально задумывающийся о смысле жизни в деятельном залоге, стремящийся сделать мир лучше - опасен для современного общества. Поэтому объявим правильным смыслом жизни умение наслаждаться текущим моментом. Отмечу, что тут к спикеру - никаких претензий, она адекватна изложила теорию, я погуглил другие краткие изложения и сопоставил.
❤3🔥2👍1
#AnalystDays Светлана Дергачева. Применение ТРИЗ для решения задач с предельным уровнем неопределенности. Тема ТРИЗ на ИТ-конференциях возникает регулярно, я слушал много докладов и хочу отметить, что это - замечательный доклад. Он - на основе большого практического опыта, а не просто на основе первоначального знакомства. При этом достигнуть такого уровня у Светланы получилось только с третьего раза, на первых попытках отпугивала инженергая сложность и приземление на совершенно другой материал - ведь подход Альтшулер создавал в 50-е. Но потом появилась сложная задача - определять, читерит ли студент на экзамене, при том, что нейронные сетки выдавали ответ с достоверностью 50%, там ТРИЗ помог и пошло развитие. Еще я отдельно хочу отметить оформление презентации и сквозной игровой пример с канарейкой, которой надо добыть еду зимой - это наряду с примерами из ИТ.
ТРИЗ - ощущение тупика, когда мы не знаем куда идти. Теодюль Рибо в своих исследованиях показал, что креативность линейно растет с возрастом ребенка, достигает пика в 12-15, а потмо идет на спад. Дети умеют рисовать картинки, которые не видели в реальной жизни, а инженеры уже преимущественно копируют. Я тут хочу отметить, что есть зефирный эксперимент (marshmallow Peter Skillman, русское описание), который показал, что креативность падает не сама по себе, ее подавляет система образования.
Проблемы на пути поиска решения.
* Полное отрицание новой идеи
* принятие на веру положений, высказанных авторитетом
* применение старых принципов действия в новых устройствах
* не умение перенести в новую область
* использование предметов только по назначению
Что рекомендует ТРИЗ.
Для начала перейти от проблемы к задаче. Проблема - тупик: "нет еды" - ложись и умирай. "где птице достать еду зимой" - уже задача. Методы: Отказ от терминов, если мешают и переформулировать с акцентами на выхлоп, на процесс, на актора.
Акцент на выхлоп - когда нужен результат: Идеальный финал, экстра-результаты 2-3 известных фактора, ограничения. Не "у нас нет пользователей" а "в нашем приложении за полгода нужен двухкратный прирост пользователей, в идеале - приходили и покупали платную подписку при ограниченном бюджете..."
Акцент на актора - работа с ресурсами, с простоями (нет задач у тестировщиков), с мотивацией, подход к людям в маленькой компании. Изолируем ресурс, расписываем как систему, 3 сильные стороны, формулировки "существует в среде", как добиться ситуации.
Акцент на процесс - оптимизация, бутылочное горлышко (архитектор-тимлид), стимуляция к поиску. Изолировать главный процесс, описать пошагово: кто - что делает - с кем, как устранить препятствия.
Дальше - поиск решения.
Системное мышление. Хороший инженер видит объект и вариации, а АРИЗ-инженер видит надсистему - систему - подсистему, все это в прошлое-настоящее-будущее и еще антиподы систем. И в презентации был хороший пример, эволюция faq -> чат-бот -> AI-помощник с соответствующей эволюцией надсистемы и подситемы.
Поиск противоречия - несколько видов
* Нужно что-то сделать, а как - неизвестно - административное
* Улучшения одной части ухудшает другую - техническое
* К одной части системы противоположные требования - физическое.
Другое деление: явное - пришли пользователи, авторизация упала, неявное - хотим сделать.
Для формулирования противоречий хорошо помогает SWOT-анализ, их формулируют слабости и угрозы .
ТРИЗ - ощущение тупика, когда мы не знаем куда идти. Теодюль Рибо в своих исследованиях показал, что креативность линейно растет с возрастом ребенка, достигает пика в 12-15, а потмо идет на спад. Дети умеют рисовать картинки, которые не видели в реальной жизни, а инженеры уже преимущественно копируют. Я тут хочу отметить, что есть зефирный эксперимент (marshmallow Peter Skillman, русское описание), который показал, что креативность падает не сама по себе, ее подавляет система образования.
Проблемы на пути поиска решения.
* Полное отрицание новой идеи
* принятие на веру положений, высказанных авторитетом
* применение старых принципов действия в новых устройствах
* не умение перенести в новую область
* использование предметов только по назначению
Что рекомендует ТРИЗ.
Для начала перейти от проблемы к задаче. Проблема - тупик: "нет еды" - ложись и умирай. "где птице достать еду зимой" - уже задача. Методы: Отказ от терминов, если мешают и переформулировать с акцентами на выхлоп, на процесс, на актора.
Акцент на выхлоп - когда нужен результат: Идеальный финал, экстра-результаты 2-3 известных фактора, ограничения. Не "у нас нет пользователей" а "в нашем приложении за полгода нужен двухкратный прирост пользователей, в идеале - приходили и покупали платную подписку при ограниченном бюджете..."
Акцент на актора - работа с ресурсами, с простоями (нет задач у тестировщиков), с мотивацией, подход к людям в маленькой компании. Изолируем ресурс, расписываем как систему, 3 сильные стороны, формулировки "существует в среде", как добиться ситуации.
Акцент на процесс - оптимизация, бутылочное горлышко (архитектор-тимлид), стимуляция к поиску. Изолировать главный процесс, описать пошагово: кто - что делает - с кем, как устранить препятствия.
Дальше - поиск решения.
Системное мышление. Хороший инженер видит объект и вариации, а АРИЗ-инженер видит надсистему - систему - подсистему, все это в прошлое-настоящее-будущее и еще антиподы систем. И в презентации был хороший пример, эволюция faq -> чат-бот -> AI-помощник с соответствующей эволюцией надсистемы и подситемы.
Поиск противоречия - несколько видов
* Нужно что-то сделать, а как - неизвестно - административное
* Улучшения одной части ухудшает другую - техническое
* К одной части системы противоположные требования - физическое.
Другое деление: явное - пришли пользователи, авторизация упала, неявное - хотим сделать.
Для формулирования противоречий хорошо помогает SWOT-анализ, их формулируют слабости и угрозы .
👍3🔥3❤2
Способы решения противоречия:
* Симбиоз с системой. Что надо изменить внутри, чтобы соответствовать надсистеме, что в надсистеме мешает развитию, что надо изъять. Задача про экзамен студента - надо подружиться с LMS, а они все разные. Оказалось, что LMS не любят открывать в iframe. Они написали плугин, он изолирует и разрешает, и заодно куки решили.
* Обратная связь. Если обратная связь есть - изменить ее, если она не решает проблему.
* Конструктор - соединение разные элементы. Когда ломается узел, уходит человек, сложно заменить - представим его по частям, а не целиком.
* Применяем роль - де Боно взглянуть на задачу как ученый (факты), художник (эмоции), критик (риски), оптимист (плюсы), креатор (нестандартно, начальник (координация).
* Метод одноразового стаканчика - заменяем дорогой набором дешевых. Worker - их можно запускать много.
* Экстрадетализация. Когда нет никаких идей. Просто расписываешь задачу как маньяк, синонимы, прилагательные, глаголы, ассоциации - пока не щелкнет.
* Вред в пользу: использовать вредные факторы для положительного эффекта, устранить вредный за счет сложения с другим вредным, усилить вредный, чтобы перестал быть вредным. У них - 5 нейросетей-распозновалок до 300 мб (лицо, голос и так далее). Они перенесли загрузку на самое начало и пустили параллельно с административными шагами - проверить оборудование, сфотографировать документ и т.п. И они в конце вставили экран с правилами, и пока человек читает, кнопка "продолжить" не горит, они дают время человеку и себе.
* Инверсия. Глаголов, прилагательных, смыслов, меняем объекта и субъекта, инверсия актора, цели, порядка действий в процессе... Freemium и trial версии - сначала пользуйся, потом плати.
* Посредник - использовать промежуточный объект передающий или переносящий действие, на время присоединить легко удаляемый объект. Вынесение частей из монолитов.
* Дробление - декомпозиция: разделить на части, выполнить разборным, увеличить степень дробления. Модульность, микросервисы
* Вынесение лишнего. Отделить мешающее или выделить нужное. Живо-чат - вынесли чат из сервис-деска и можно прикрепить куда угодно, и еще контекст пишешь.
* Чуть меньше или чуть больше, если трудно точно нужное. Готовые библиотеки, пусть там есть не нужное, или наоборот, не хватает, но мало.
* Самообслуживание: объект должен сам себя обслуживать, выполняя вспомогательные или ремонтные операции. Использовать отходы.
Интеграция - когда даем клиенту сделать все самому.
* Копирование. Вместо недоступного сложного дорогого использовать дешевые копии. Использовать изменение масштаба.
* Сумасшедший микс - де Боно. Накидываем самые разные слова по ассоциациям, случайные. Накидали производных слов - кенгуру - накидали всплывашки "сделай перерыв - есть приложение для медитации". Или автомобиль - фиксация что пользователь в автомобиле, за рулем и что-то адаптируем.
* Замена. Замещаем актора: делают не разработчики, а дети, алкоголики или врачи. Замещаем других акторов: разработка делает интерфейс совместно с конкурентами. Можно замещать среду, объект, цели
* Выше скорость - меньше ям. Ускорить негативные процессы, адекватно оценить как ускорить. Фаст-фуды - снижение качества пищи в обмен на скорость. Картинка в плохом качестве на плохом интернете. Скелетон первой страницы, если там долгая загрузка элементов.
* Метод вируса - подселение агента во враждебную часть среды, чтобы сделать управляемой. Выписать агенты проблемной зоны - акторы, субъекты живые и неживые, можно ли заменить? Удаленный рабочий стол.
Дальше Отбор идей. Как генерить - методы ТРИЗ. Линия рациональности - выгоды против затрат.
Подводя итог. Мнемоника ЗППП: Задачи из проблемы; Подсистемы (и надсистемы); подбираем метод; приоритизируем фичи. И в конце довольно большой список литературы по ТРИЗ и смежным темам.
* Симбиоз с системой. Что надо изменить внутри, чтобы соответствовать надсистеме, что в надсистеме мешает развитию, что надо изъять. Задача про экзамен студента - надо подружиться с LMS, а они все разные. Оказалось, что LMS не любят открывать в iframe. Они написали плугин, он изолирует и разрешает, и заодно куки решили.
* Обратная связь. Если обратная связь есть - изменить ее, если она не решает проблему.
* Конструктор - соединение разные элементы. Когда ломается узел, уходит человек, сложно заменить - представим его по частям, а не целиком.
* Применяем роль - де Боно взглянуть на задачу как ученый (факты), художник (эмоции), критик (риски), оптимист (плюсы), креатор (нестандартно, начальник (координация).
* Метод одноразового стаканчика - заменяем дорогой набором дешевых. Worker - их можно запускать много.
* Экстрадетализация. Когда нет никаких идей. Просто расписываешь задачу как маньяк, синонимы, прилагательные, глаголы, ассоциации - пока не щелкнет.
* Вред в пользу: использовать вредные факторы для положительного эффекта, устранить вредный за счет сложения с другим вредным, усилить вредный, чтобы перестал быть вредным. У них - 5 нейросетей-распозновалок до 300 мб (лицо, голос и так далее). Они перенесли загрузку на самое начало и пустили параллельно с административными шагами - проверить оборудование, сфотографировать документ и т.п. И они в конце вставили экран с правилами, и пока человек читает, кнопка "продолжить" не горит, они дают время человеку и себе.
* Инверсия. Глаголов, прилагательных, смыслов, меняем объекта и субъекта, инверсия актора, цели, порядка действий в процессе... Freemium и trial версии - сначала пользуйся, потом плати.
* Посредник - использовать промежуточный объект передающий или переносящий действие, на время присоединить легко удаляемый объект. Вынесение частей из монолитов.
* Дробление - декомпозиция: разделить на части, выполнить разборным, увеличить степень дробления. Модульность, микросервисы
* Вынесение лишнего. Отделить мешающее или выделить нужное. Живо-чат - вынесли чат из сервис-деска и можно прикрепить куда угодно, и еще контекст пишешь.
* Чуть меньше или чуть больше, если трудно точно нужное. Готовые библиотеки, пусть там есть не нужное, или наоборот, не хватает, но мало.
* Самообслуживание: объект должен сам себя обслуживать, выполняя вспомогательные или ремонтные операции. Использовать отходы.
Интеграция - когда даем клиенту сделать все самому.
* Копирование. Вместо недоступного сложного дорогого использовать дешевые копии. Использовать изменение масштаба.
* Сумасшедший микс - де Боно. Накидываем самые разные слова по ассоциациям, случайные. Накидали производных слов - кенгуру - накидали всплывашки "сделай перерыв - есть приложение для медитации". Или автомобиль - фиксация что пользователь в автомобиле, за рулем и что-то адаптируем.
* Замена. Замещаем актора: делают не разработчики, а дети, алкоголики или врачи. Замещаем других акторов: разработка делает интерфейс совместно с конкурентами. Можно замещать среду, объект, цели
* Выше скорость - меньше ям. Ускорить негативные процессы, адекватно оценить как ускорить. Фаст-фуды - снижение качества пищи в обмен на скорость. Картинка в плохом качестве на плохом интернете. Скелетон первой страницы, если там долгая загрузка элементов.
* Метод вируса - подселение агента во враждебную часть среды, чтобы сделать управляемой. Выписать агенты проблемной зоны - акторы, субъекты живые и неживые, можно ли заменить? Удаленный рабочий стол.
Дальше Отбор идей. Как генерить - методы ТРИЗ. Линия рациональности - выгоды против затрат.
Подводя итог. Мнемоника ЗППП: Задачи из проблемы; Подсистемы (и надсистемы); подбираем метод; приоритизируем фичи. И в конце довольно большой список литературы по ТРИЗ и смежным темам.
👍3❤2
#AnalystDays Валерий Разномазов. Объектно-ориентированный подход в построении архитектуры решений. Глубокий доклад о применении DDD. И в нем противопоставление между опорой на бизнес-объекты и опорой на бизнес-процессы, которые автор называет "функциональным подходом" (от бизнес-функций). Аргумент за объект - они более стабильны и легче проявляются, и дальше на них можно строить разные процессы. А еще в докладе было очень классное определение архитектуры, отличающееся от обычного "важные, ключевые решения": система - большее, чем совокупность отдельных фич, и архитектура - это то, за счет чего система работает как целое. За это - отдельное спасибо Валерию.
Дальше конспект. Потребность в архитектуре порождается семантическим безумием, многообразием и вариативностью представления данных в разных системах. И как средство от этого - корпоративная архитектура данных, единый язык. Раньше это было относительно просто, на основе EBS и Global business objects by IBM - он давал общий формат xml ваших данных. А сейчас при построении экосистем на основе open api требуется объединить очень разное, например, продажу бургеров, онлайн кинотеатр и выдачу кредитов. А грядет интернет вещей, где объединять все со всем. Он астрофизик, и мыслит аналогиями: смысл сущностей - новая гравитация, туманность сведений о заемщике и галактика продуктов.
Доклад был на двух примерах: Событийно-ориентированная производственная систем Amanita, для которых был предварительный анализ и CRM психологов - понятная практика, в ней было рамочное пожелание заказчика без предварительного анализа.
Основой является разметка бизнес-объектов предметного поля - получение онтологии, которая будет основой для DDD. ООП ставит в основу бизнес-объекты и связи между ними, процессы и правила строят вокруг них. В отличие от функционального подхода, когда сначала выделяем процессы и функции, а объекты и правила их обслуживают и выделяют внутри них. Преимущества ООП: набор объектов и субъектов мы можем предсказать, и кластеризовать тоже. А процессы - нет, там больше разнообразие. Поэтому стартуем с объектов, а не процессов.
Теорема бизнес-анализа: любой бизнес-процесс можно представить как описание связей между субъектами и объектами которые могут участвовать в других бизнес-процессах. Задача бизнес-аналитика - определять это. Системный аналитик далее делает отражение в реализацию.
Есть два варианта развития проектов: от бизнеса к ИТ и наоборот, от ИТ к бизнесу. Внедрение вендорского решения - от ИТ к бизнесу, перекраиваем бизнес под возможности ИТ. Бизнес может рухнуть, примеры есть. SaaS - тоже самое, натягиваем одно решение на другое.
Первоначальные требования: легаси, существующий проект или новый проект.
* Легаси - чужое. И часто без комментариев, и с атрибутным хранением.
* Если проект есть - можно сделать лингвистический анализ и частотный - можно построить граф.
* Принципиально новый проект, а заказчик не очень понимает что делает - то agile и UI/UX макетирование - можно стартовать.
Декомпозиция: как из первоначальных требований строить архитектуру. Если идею разделить на мелкие фичи - но дальше надо слепить в целое, бизнес-архитектура - и дальше ИТ-архитектура.
Онтология - не патентуется, а воплощение в виде классов - патентуется. Бизнес-объект: DTO, Json (xml), таблица как проекции друг друга. Платформа дает json, а интеграция - xml с xsd.
При реализации событийно-ориентированная производственная система Amanita опирались на производственные журналы в цехах - там готовая модель событий, его можно сразу переносить в данные.
А у психологов: надо сопровождать клиентскую практику, что - неясно. Они сначала рисовали карандашами, потом Figma - и там они сами рисовали, и дальше сделали и оно заработало. Психологи сами смогли разобраться и навести порядок в своей практикой.
Ontology driven MSA. Границы микросервиса - границы домена. Микросервисы и цитадели: в цитаделях те объекты, которые относительно статичны и изменения не меняются. Еще в цитадель попадают данные, которые надо защищать.
Дальше конспект. Потребность в архитектуре порождается семантическим безумием, многообразием и вариативностью представления данных в разных системах. И как средство от этого - корпоративная архитектура данных, единый язык. Раньше это было относительно просто, на основе EBS и Global business objects by IBM - он давал общий формат xml ваших данных. А сейчас при построении экосистем на основе open api требуется объединить очень разное, например, продажу бургеров, онлайн кинотеатр и выдачу кредитов. А грядет интернет вещей, где объединять все со всем. Он астрофизик, и мыслит аналогиями: смысл сущностей - новая гравитация, туманность сведений о заемщике и галактика продуктов.
Доклад был на двух примерах: Событийно-ориентированная производственная систем Amanita, для которых был предварительный анализ и CRM психологов - понятная практика, в ней было рамочное пожелание заказчика без предварительного анализа.
Основой является разметка бизнес-объектов предметного поля - получение онтологии, которая будет основой для DDD. ООП ставит в основу бизнес-объекты и связи между ними, процессы и правила строят вокруг них. В отличие от функционального подхода, когда сначала выделяем процессы и функции, а объекты и правила их обслуживают и выделяют внутри них. Преимущества ООП: набор объектов и субъектов мы можем предсказать, и кластеризовать тоже. А процессы - нет, там больше разнообразие. Поэтому стартуем с объектов, а не процессов.
Теорема бизнес-анализа: любой бизнес-процесс можно представить как описание связей между субъектами и объектами которые могут участвовать в других бизнес-процессах. Задача бизнес-аналитика - определять это. Системный аналитик далее делает отражение в реализацию.
Есть два варианта развития проектов: от бизнеса к ИТ и наоборот, от ИТ к бизнесу. Внедрение вендорского решения - от ИТ к бизнесу, перекраиваем бизнес под возможности ИТ. Бизнес может рухнуть, примеры есть. SaaS - тоже самое, натягиваем одно решение на другое.
Первоначальные требования: легаси, существующий проект или новый проект.
* Легаси - чужое. И часто без комментариев, и с атрибутным хранением.
* Если проект есть - можно сделать лингвистический анализ и частотный - можно построить граф.
* Принципиально новый проект, а заказчик не очень понимает что делает - то agile и UI/UX макетирование - можно стартовать.
Декомпозиция: как из первоначальных требований строить архитектуру. Если идею разделить на мелкие фичи - но дальше надо слепить в целое, бизнес-архитектура - и дальше ИТ-архитектура.
Онтология - не патентуется, а воплощение в виде классов - патентуется. Бизнес-объект: DTO, Json (xml), таблица как проекции друг друга. Платформа дает json, а интеграция - xml с xsd.
При реализации событийно-ориентированная производственная система Amanita опирались на производственные журналы в цехах - там готовая модель событий, его можно сразу переносить в данные.
А у психологов: надо сопровождать клиентскую практику, что - неясно. Они сначала рисовали карандашами, потом Figma - и там они сами рисовали, и дальше сделали и оно заработало. Психологи сами смогли разобраться и навести порядок в своей практикой.
Ontology driven MSA. Границы микросервиса - границы домена. Микросервисы и цитадели: в цитаделях те объекты, которые относительно статичны и изменения не меняются. Еще в цитадель попадают данные, которые надо защищать.
👍3🥰1
Объектно-ориентированные RESTfull - привязываем к объектам. И дальше SCRUD.
Модель поставщик-потребитель. Объекты, и взаимодействие: синхронное или асинхронное
Интеграция по Фаулеру: File transfer, shared database, remote procedure invocation, messaging.
Amanita. Мониторинг брака - видеокамера - json - обработка данных - и два потока: нормально и отклонение. Kafka, она была известна. Но между Kafka и RabbitMQ - большая разница, зависит от того, нужна ли будет обработка.
Messaging: JSONSchema или XSD. И проверка в шлюзе API Gateway. В Amanita шлюз между фронтом и бэком. В современных проектах бизнес-логика - не SQL, а Java. Декомпозиция бизнес-идеи - выделяем субъекты и объекты - строим граф - строим json-схему - строим базу данных.
Сложности: У одного объекта бывает много хозяев, несколько мастер-систем, отсутствует корпоративная модель данных и глоссарий. Я отмечу, что тут должны работать ограниченные контексты из DDD.
Модель поставщик-потребитель. Объекты, и взаимодействие: синхронное или асинхронное
Интеграция по Фаулеру: File transfer, shared database, remote procedure invocation, messaging.
Amanita. Мониторинг брака - видеокамера - json - обработка данных - и два потока: нормально и отклонение. Kafka, она была известна. Но между Kafka и RabbitMQ - большая разница, зависит от того, нужна ли будет обработка.
Messaging: JSONSchema или XSD. И проверка в шлюзе API Gateway. В Amanita шлюз между фронтом и бэком. В современных проектах бизнес-логика - не SQL, а Java. Декомпозиция бизнес-идеи - выделяем субъекты и объекты - строим граф - строим json-схему - строим базу данных.
Сложности: У одного объекта бывает много хозяев, несколько мастер-систем, отсутствует корпоративная модель данных и глоссарий. Я отмечу, что тут должны работать ограниченные контексты из DDD.
❤2
#AnalystDays Ольга Подолина. Расширение нотации BPMN: использование совместно с DMN (управление решениями) и CMMN (кейс-менеджмент). BPMN хорошо описывает процессы, особенно если дополнять его описанием орг.структуры и объектов данных, для которых есть отдельные нотации. Но есть отдельные этапы процессов, исполнение которых плохо описываются с помощью BPMN, потому что не представляют собой структурированный процесс. Диаграммы получаются запутанными и не проясняют содержание. И для отражения таких функций можно использовать две другие нотации.
Рассказ был на конкретном кейсе, проект генеральной прокуратуры по надзору за исполнением законов. Рамочно он хорошо описывается BPMN: Поступление, регистрация, назначение исполнителя - и дальше проверка или обоснованный отказ от нее. Операция назначения исполнителя: на ней надо выбрать человека с учетом тематики, квалификации и текущей занятости, и возможны сложные решения, когда назначают исполнителя и куратора. Эти факторы рассматриваются в совокупности. И для описания такого процесса удобно использовать DMN - decision model and notation. В простейшем варианте такое решение - просто таблица выбора исполнителя по критериям, а в сложном алгоритма нет, а схема фиксирует те данные, которые нужны для принятия решений - и они, во-первых, должны быть в системе а, во-вторых - представлены исполнителю для принятия решения, собраны совместно на экране. Элементы DMN: решение, модель бизнес-знаний, источник знаний, входные данные.
Далее был рассмотрена операция проведения проверки в рамках надзора. D рамках проверки может быть большое количество разных мероприятий и подготовлены различные документы, но их проведение - на усмотрение ответственного. И в финале тоже есть опциональная часть - обращение в суд. Для этого хорошо подходит нотация CMMN - Case management model notation. В ней акцент - не на процессе, а на информации по конкретному случаю. Цель процесса - ясна, а путь - вариативен и определяется исполнителем. Элементы CMMN: Сцена, этап, задача с критериями входа и выхода, веха. Строится так. (1) Папка "Проведение проверки". (2) Входные критерии - с чего начинается кейс. (3) Этапы проведения проверки: свернутые или развернутые. Дискреционный этап - не обязательный, выполнение зависит от исполнителя. (4) Критерии входа и выхода для каждого этапа, и артефакты, связанные с критерием. (5) Фрагментация плана. Для рассматриваемого примера: обязательный этап изучения дела и законодательства, даальше дискреционные этапы проведения мероприятий и подготовки документов реагирования, а потом - финальный обязательный этап - акт проверки, и снова дискреционный - работа с судом, а дальше выходные критерии.
В презентации были примеры диаграмм, их опубликуют быстро - можно смотреть. В Comunda есть работа с DMN, CMMN еще нет, обещают. Есть шаблоны для visio, в презентации были ссылки.
Рассказ был на конкретном кейсе, проект генеральной прокуратуры по надзору за исполнением законов. Рамочно он хорошо описывается BPMN: Поступление, регистрация, назначение исполнителя - и дальше проверка или обоснованный отказ от нее. Операция назначения исполнителя: на ней надо выбрать человека с учетом тематики, квалификации и текущей занятости, и возможны сложные решения, когда назначают исполнителя и куратора. Эти факторы рассматриваются в совокупности. И для описания такого процесса удобно использовать DMN - decision model and notation. В простейшем варианте такое решение - просто таблица выбора исполнителя по критериям, а в сложном алгоритма нет, а схема фиксирует те данные, которые нужны для принятия решений - и они, во-первых, должны быть в системе а, во-вторых - представлены исполнителю для принятия решения, собраны совместно на экране. Элементы DMN: решение, модель бизнес-знаний, источник знаний, входные данные.
Далее был рассмотрена операция проведения проверки в рамках надзора. D рамках проверки может быть большое количество разных мероприятий и подготовлены различные документы, но их проведение - на усмотрение ответственного. И в финале тоже есть опциональная часть - обращение в суд. Для этого хорошо подходит нотация CMMN - Case management model notation. В ней акцент - не на процессе, а на информации по конкретному случаю. Цель процесса - ясна, а путь - вариативен и определяется исполнителем. Элементы CMMN: Сцена, этап, задача с критериями входа и выхода, веха. Строится так. (1) Папка "Проведение проверки". (2) Входные критерии - с чего начинается кейс. (3) Этапы проведения проверки: свернутые или развернутые. Дискреционный этап - не обязательный, выполнение зависит от исполнителя. (4) Критерии входа и выхода для каждого этапа, и артефакты, связанные с критерием. (5) Фрагментация плана. Для рассматриваемого примера: обязательный этап изучения дела и законодательства, даальше дискреционные этапы проведения мероприятий и подготовки документов реагирования, а потом - финальный обязательный этап - акт проверки, и снова дискреционный - работа с судом, а дальше выходные критерии.
В презентации были примеры диаграмм, их опубликуют быстро - можно смотреть. В Comunda есть работа с DMN, CMMN еще нет, обещают. Есть шаблоны для visio, в презентации были ссылки.
👍2🔥1
#AnalystDays Ярослав Кучеров из Газпромбанка. Матрица сценариев - инструмент бизнес-анализа. Матрица сценариев - способ представить варианты реализации. Мы выбираем бинарные параметры, которые конфигурируют поведение приложения, и дальше для каждого варианта приложения с их помощью определяем конфигурацию. Например, если надо сделать систему лояльности, то параметрами будет реализация конкретных фич: начислить баллы, списать баллы, посмотреть свои баллы, предложить клиенту списать баллы. И дальше для каждого канала взаимодействия с клиентом: авторизованный заказ на сайте, быстрый заказ без авторизации, мобильное приложение, официант в ресторане, колл-центр - определяем, какие сценарии в них должны быть реализованы. Получаем матрицу, согласуем с заказчиком и именно это делаем. Матрица дает наглядное представление, и в презентации было несколько вариантов и примеров из реальных проектов, помимо модельного.
👍1
Быстро собрал отчет https://mtsepkov.org/AnalystDays-2023b по конференции AnalystDays, дополнив посты, которые публиковал в ходе конференции, заметками с еще нескольких докладов. За два для я было много хороших докладов: Анатолий Левенчук про Интеллект-стек, лучший доклад про ТРИЗ из тех, что я слышал, глубокий доклад про ООП с хорошим определением архитектуры, узнал про нотации DMN и CMMN, дополняющие BPMN для не-процессных бизнес-функций и много других. Я сам рассказывал про рациональное и системное мышление и, по отзывам, получилось хорошо. И, как всегда, качественное общение. До новых встреч на других конференциях!
👍12🔥8
Выступил вчера на Podlodka Teamlead Crew Работа со стратегией в реалиях современного мира https://mtsepkov.org/StratPodlodka - теоретический экскурс про 10 школ стартегирования по стратегическому сафари Минцберга и принципы гибкой архитектуры, которые позволяют быстро делать проекты из собственного опыта с кейсами. После выступления почти час отвечал на вопросы, тема оказалась актуальной и востребованной
🔥10👍4
Как обычно, в начале сентября был на #festpir - большой конференции тренеров и коучей. Как всегда - феерия выступлений и общения. Для меня эта конференция - чувствительный индикатор времени и место встречи с интересными людьми. Как обычно, публиковал впечатления о наиболее запомнившихся выступлениях в телеграм-канале, но многое осталось только в заметках из-за насыщенной программы. Поэтому публикация отчета затянулась, но, наконец, сегодня я публикую заметки, дополненные впечатлениями о других выступлениях https://mtsepkov.org/PIR-2023 Я надеялся успеть до отчета посмотреть записи выступлений, которые были online, но то пока в будущем, надеюсь, что получится и тогда я дополню отчет. А сам я тоже выступал на ПИР с докладом "Я и мои аватары в спектакле жизни" про модель личности, видео уже опубликовано, а продолжение будет в конце ноября на Teamlead.
👍1