#highload Максим Павлов. Совмещаем потоковые и пакетные процессы в Camunda BPM. Доклад был про архитектурные шаблоны использования Комунды для оркестрации работы сервисов. Embeded версия, хранение в PostgreSQL, интеграция с внежними системами через Kafka. Две задачи вокруг кредитов: обработка потока заявок на кредиты, которая идет в автоматическом режиме с точечным включением импортных операций; подготовка предодобренных заявок на кредиты по большому количеству данных ежемесячно в пакетном режиме. Задачи разные, но в обоих - сложная схема обработки из полутора десятков шагов, которые выполняются параллельно, но есть зависимости. В докладе были базовые шаблоны: вычислительный элемент, сообщения, конструкции управления процессами, тайминг и ожидание событий и более сложные элементы из них: запуск параллельных процессов, синхронизация потоков для обработки зависимостей, шаблоны для обработки ошибок - экземпляр не прерывается. а приостанавливается и может быть продолжен после решения проблемы, например, если интеграция почему-то приостановилась и ее запустили, шаблоны для включения ручных шагов, исполняемых пользователями. Примеры - со схемками, скриптами.
Ценный опыт использования: уменьшайте контекст процесса, пакуйте его в меньшее число переменных, не забывайте про локальную или глобальную видимость переменных, важно для многопоточного исполнения. Простую логику можно писать в скриптах, сложную - отдельными скриптовыми задачами. А еще комунда пишет много логов, они это отключили - им хватает логов Kafka.
Ценный опыт использования: уменьшайте контекст процесса, пакуйте его в меньшее число переменных, не забывайте про локальную или глобальную видимость переменных, важно для многопоточного исполнения. Простую логику можно писать в скриптах, сложную - отдельными скриптовыми задачами. А еще комунда пишет много логов, они это отключили - им хватает логов Kafka.
👍4
#highload Анастасия Тушканова из Ozon. Feature store: как мы совместили высокую производительность и безграничные потребности data scientist’ов. Рассказ про доработку архитектуры для обеспечения производительности и обеспечения A/B-тестирования. Feature store - хранилище характеристик, которые используются поиском для сортировки товаров после того, как нижний поиск выдал 2000 товаров, релевантных текстовому запросу. Сортировка учитывает характеристики товаров, включая популярность в заказах и предпочтения конкретного пользователя. Эти характеристики считают аналитики в Hadoop, а дальше их надо переложить в redis для эффективной сортировки.
Проблемы были с производительностью, увеличением числа нод и реплик они не решались. Поэтому пошли на доработку архитектуры, в докладе было несколько решений. Во-первых, сделать шардирование товарных характеристик по категориям товаров, потому что шардирование по товару приводило к тому, что 2000 товаров каждого запроса распределены по всем нодам, а если будет лежать по категориям, то нод будет мало. Но управление надо делать вручную, так как категории содержат разное число товаров, надо разложить равномерно. При этом потребовалось отдельный механизм обновления категорий на Kafka - категории у товара меняются. Во-вторых, сделали отдельное холодное хранилище на реляционке, в которое перенаправили запросы сервисов, которым время ответа не критично, и на котором работают аналитические запросы. Оптимизация запросов позволило уменьшить число реплик с 18 до 3, необходимых для устойчивости работы. И это позволило сделать несколько экземпляров для A/B тестов. И не только для аналитиков, но и для самих моделей приоритизации.
Проблемы были с производительностью, увеличением числа нод и реплик они не решались. Поэтому пошли на доработку архитектуры, в докладе было несколько решений. Во-первых, сделать шардирование товарных характеристик по категориям товаров, потому что шардирование по товару приводило к тому, что 2000 товаров каждого запроса распределены по всем нодам, а если будет лежать по категориям, то нод будет мало. Но управление надо делать вручную, так как категории содержат разное число товаров, надо разложить равномерно. При этом потребовалось отдельный механизм обновления категорий на Kafka - категории у товара меняются. Во-вторых, сделали отдельное холодное хранилище на реляционке, в которое перенаправили запросы сервисов, которым время ответа не критично, и на котором работают аналитические запросы. Оптимизация запросов позволило уменьшить число реплик с 18 до 3, необходимых для устойчивости работы. И это позволило сделать несколько экземпляров для A/B тестов. И не только для аналитиков, но и для самих моделей приоритизации.
❤3
#highload Андрей Парамонов из Додо. Use actors, Luke. На мой взгляд, очень хороший доклад. В нем - интересный обзора концепции и истории Акторной модели. Потому что модель появилась давно, в 1970-х. Андрей говорит про статью 1973 года Carl Hewitt, Peter Bishop и Richard Steiger "A Universal Modular Actor Formalism for AI", и там - теоретическое обоснование, которое дальше было развито в нескольких научных работах.
Замечу, что если смотреть от практики, то может быть другой взгляд - что акторная модель была реализована в Smalltalk, который вышел на год раньше и среди авторов которого был Ален Кей. Его высказывание, что основой замысла ООП были именно акторы как изолированные объкты, а пошла развивать наследование и полиморфизм, тоже было в докладе. Так или иначе, модель опередила время, акторы стали востребованными в современной архитектуре мультиядерных процессовров, исполняющих множество потоков. А история развития ООП пошла от C к С++ и далее к Java и C#, где многопоточность не была реализована на уровне языка совсем. Хотя в 1986 появился Erlang с легковесными потоками, которые очень удачно реализуют акторную модель. Как сказал Андрей, интересно, авторы не были знакомы с научными работами по подходу, хотя фактически его реализовали. Но все равно, это было вне основного пути.
Актор - примитив параллельного, вернее, конкурентного, вычисления, который обрабатывает сообщения из своей входной очереди и посылкает их другим акторам. При этом в статье были важные полагания: одно сообщение обрабатывается полностью, нет гарантий порядка отправки сообщений, сообщения могут теряться и нет никаких синхронных вызовов. У актора есть состояние, которое влияет на обработку сообщений, при обработке он может посылать сообщения другим, менять состояние, создавать других акторов. И, кроме обмена сообщениями, никакого взаимодействия между акторами нет, что как раз обеспечивает возможности масштабирования.
Модель отношений акторов: иерархическая и одноранговая. В иерархической - родитель создает, решает что делать при ошибке, можно восстановить, в том числе с сохранением очереди. В одноранговой акторами управлет run-time, создавая акторы по необходимости для обработки сообщений и удаляя при отсутствии активности.
Usecase: pipeline proicessing, transaction application, стриминг данных (реактивные системы, event-based, чаты), multi-user concurency, приложения с распределенным состояниям, для которых не хватает одной машины, IoT - сообщения от датчиков и состояния, Timers - много таймеров по разным условиям.
И дальше был их пример. Dodo работает в 20 странах и в каждой надо интегрироваться с местным эквайрингом для приема платежей, никакого стандарта нет. Они использовали Microsoft Orleans, фреймворк появился в 2015, потом заснул и перспективы были неясны, но сейчас вроде проснулся и будет развиваться. Дальше было ряд рекомендаций: не забыть про observability (логи метрики трейсы); помнить что ресурсы не бесконечны, хотя актор и легковесен, и mailbox не бесконечный. Продумать восстановление состояния и балансировку нагрузки. А еще написание в синхронном стиле async/await приводит к тому, что между потоками могут возникать deadlock.
И выводы: акторы - простая абстракция, сильно упрощает код, хорошо масштабируется. Уместность - решаем конкретно, простые приложения с crud - не нужно. Что есть: Akka, Orleans, Proto.Actor, Darp (распределенные акторы). И был слайд со списком книг.
Замечу, что если смотреть от практики, то может быть другой взгляд - что акторная модель была реализована в Smalltalk, который вышел на год раньше и среди авторов которого был Ален Кей. Его высказывание, что основой замысла ООП были именно акторы как изолированные объкты, а пошла развивать наследование и полиморфизм, тоже было в докладе. Так или иначе, модель опередила время, акторы стали востребованными в современной архитектуре мультиядерных процессовров, исполняющих множество потоков. А история развития ООП пошла от C к С++ и далее к Java и C#, где многопоточность не была реализована на уровне языка совсем. Хотя в 1986 появился Erlang с легковесными потоками, которые очень удачно реализуют акторную модель. Как сказал Андрей, интересно, авторы не были знакомы с научными работами по подходу, хотя фактически его реализовали. Но все равно, это было вне основного пути.
Актор - примитив параллельного, вернее, конкурентного, вычисления, который обрабатывает сообщения из своей входной очереди и посылкает их другим акторам. При этом в статье были важные полагания: одно сообщение обрабатывается полностью, нет гарантий порядка отправки сообщений, сообщения могут теряться и нет никаких синхронных вызовов. У актора есть состояние, которое влияет на обработку сообщений, при обработке он может посылать сообщения другим, менять состояние, создавать других акторов. И, кроме обмена сообщениями, никакого взаимодействия между акторами нет, что как раз обеспечивает возможности масштабирования.
Модель отношений акторов: иерархическая и одноранговая. В иерархической - родитель создает, решает что делать при ошибке, можно восстановить, в том числе с сохранением очереди. В одноранговой акторами управлет run-time, создавая акторы по необходимости для обработки сообщений и удаляя при отсутствии активности.
Usecase: pipeline proicessing, transaction application, стриминг данных (реактивные системы, event-based, чаты), multi-user concurency, приложения с распределенным состояниям, для которых не хватает одной машины, IoT - сообщения от датчиков и состояния, Timers - много таймеров по разным условиям.
И дальше был их пример. Dodo работает в 20 странах и в каждой надо интегрироваться с местным эквайрингом для приема платежей, никакого стандарта нет. Они использовали Microsoft Orleans, фреймворк появился в 2015, потом заснул и перспективы были неясны, но сейчас вроде проснулся и будет развиваться. Дальше было ряд рекомендаций: не забыть про observability (логи метрики трейсы); помнить что ресурсы не бесконечны, хотя актор и легковесен, и mailbox не бесконечный. Продумать восстановление состояния и балансировку нагрузки. А еще написание в синхронном стиле async/await приводит к тому, что между потоками могут возникать deadlock.
И выводы: акторы - простая абстракция, сильно упрощает код, хорошо масштабируется. Уместность - решаем конкретно, простые приложения с crud - не нужно. Что есть: Akka, Orleans, Proto.Actor, Darp (распределенные акторы). И был слайд со списком книг.
❤5
#highload Станислав Богатырев из YADRO. Как мы переживаем сплит-брейн и продолжаем писать данные по S3-протоколу. Доклад был про архитектуру FrontFS. Это объектное хранилище, рассчитанное на установку по всему миру в интернете, вне защитных контуров. При такой установке нет гарантий связности между узлами сети. И им важно, чтобы узлы продолжали работать в этом случае на чтение и запись данных, а после восстановления связи решение конфликтов происходило без участия человека. Следствем этого требования является работа без какого-либо центрального узла хранения метаданных. В самом хранилище объекты являются неизменными и адресуются собственным хэшем. И с этим нет особых проблем.
Но для удобной работы необходимо поддержать адресацию по протоколу S3, в котором объекты раскладываются в аналог файловой системы и при этом разрешена их модификация через порождение новых версий. И если при нарушении связности в разных частях системы были созданы новые версии объектов, то надо уметь определить последнюю версию. При этом модификация, в том числе, предполагает перемещение объекта по иерархии - как файлы перекладываются в другую папку. И о том, как обеспечить связь имен с объектами и был доклад. Для этого используют технологию блокчейн, которая заодно дает локальное время в системе, измеряемое номерами блоков. Он обеспеивает распределенное хранение без центрального узла и слияние с разрешением конфликтов с упорядочиванием по локальному времени, а при совпадении - по возрастанию хэша версии объекта. Основой послужила статья про CRDT-дерево Martin Kleppmann, который обосновывает, что дерево может быть описано как последовательность операций добавления и перемещения узлов, при чем они являются коммуникативными, что как раз дает возможность слияние. Реально задача нетривиальная, в докладе было несколько простых вариантов, которые не работают. И было на примерах показано, как работает их алгоритм в сложных случаях решения конфликтов. Тот же алгоритм можно было сделать на распределенной БД, но у нас открытый интернет, распределенная БД не дает защищенности.
FrontFS можно пользоваться, исходный код выложен в git, есть enterprise-версия Tatlin.Object в несколько меньшим масштабированием, но большей управляемостью, она платная.
Но для удобной работы необходимо поддержать адресацию по протоколу S3, в котором объекты раскладываются в аналог файловой системы и при этом разрешена их модификация через порождение новых версий. И если при нарушении связности в разных частях системы были созданы новые версии объектов, то надо уметь определить последнюю версию. При этом модификация, в том числе, предполагает перемещение объекта по иерархии - как файлы перекладываются в другую папку. И о том, как обеспечить связь имен с объектами и был доклад. Для этого используют технологию блокчейн, которая заодно дает локальное время в системе, измеряемое номерами блоков. Он обеспеивает распределенное хранение без центрального узла и слияние с разрешением конфликтов с упорядочиванием по локальному времени, а при совпадении - по возрастанию хэша версии объекта. Основой послужила статья про CRDT-дерево Martin Kleppmann, который обосновывает, что дерево может быть описано как последовательность операций добавления и перемещения узлов, при чем они являются коммуникативными, что как раз дает возможность слияние. Реально задача нетривиальная, в докладе было несколько простых вариантов, которые не работают. И было на примерах показано, как работает их алгоритм в сложных случаях решения конфликтов. Тот же алгоритм можно было сделать на распределенной БД, но у нас открытый интернет, распределенная БД не дает защищенности.
FrontFS можно пользоваться, исходный код выложен в git, есть enterprise-версия Tatlin.Object в несколько меньшим масштабированием, но большей управляемостью, она платная.
👍4
#highload Павел Велихов из TigerGraph. Распределенные графовые СУБД — будущее для аналитики на Больших Данных? В докладе был верхнеуровневый обзор - что такое графовые базы данных, чем отличаются от реляционных, и для каких задач применяются. Лично мне в докладе не хватило глубины, получалось, то графовые базы данных - это тоже самое, что реляционные, только эффективно работает большое количество join, и это - чисто техническая разница, она под капотом и от пользователя скрыта. У меня есть подозрение, что это - не так, что есть какая-то более глубокая разница. Во всяком случае, был пример, что свертка аналитики по графамм устроена как-то иначе, чем агрегация с group by в sql, но на уровне принципов эта разница, к сожалению, развернута не было. А может быть, и нет особой разницы, о всяком случае, в моем представлении - потому что я всегда смотрел на написание join в SQL как на путешествие по графу ER-диаграммы. Но это - мое мышление, из общения с людьми я знаю, что так мыслят далеко не все, и в учебниках по SQL учат не так. И, вполне возможно, что такое поверхностное изложение было адекватно аудитории, во всяком случае, реакция была заинтересованная и позитивная.
Был интересный пример антифрода - прослеживание путей перевода денег по транзакциям для отмывания. На чистой реляционке это делается действительно сложно, если пути длинные. Впрочем, для графовой БД, запрос со всеми условиями нам не показали, отослали к книге. И это - один из примеров алгоритмов, которые на графовой базе решаются лучше, чем в реляционной. В TigerGraph, где работал Павел, есть открытая библиотека из 50 алгоритмов, которые можно использовать для прикладных своих задач: кратчайшие пути, community detection, кластеризация. Но на другие БД ее надо портировать, так как, к сожалению, единого стандарта на на язык запросов к графовым БД нет, стандарт ожидается в 23-24 годах, при этом уже понятно, что туда войдет небольшое ядро, а у каждой БД будут свои расширения. Помимо алгоритмов, способ применения - ML на графах, там это получается проще, чем на реляционке, как раз потому что можно легче вытаскивать объекты по связям. Области применения: finantial fraud, risk, monitoring, customer journey, рекомендации, supply chain analysis, energy management (трубопроводы и электросети), network resource optimization...
По имеющимся БД обзора не было, в основном рассказ был про TigerGraph, которая закрытая и работает в американских облаках, но с которой можно бесплатно поиграться. Neo4j - открытая, но есть ограничения по производительности. Впрочем, это - старое сравнение от Tiger, так что надо смотреть конкретные цифры, эти ограничения могут быть несущественны для вашей задачи. Еще есть NebulaDB - китайский open source, она послабее Tiger, но интенсивно развивается. Почему-то не упомянул ArangoDB.
И сейчас есть тренд на гибридные базы данных, встраивание графового движка в реляционки. Павел считает, что это - более перспективно, чем развитие чисто графовых до соразмерных с реляционками объемов и функций. Выходит расширение SQL/PGQ для работы с графами, драйвит это Oracle, у которого, кстати, уже очень давно есть конструкция start with - connect by, позволявшая ходить по деревьям в реляционке, в частности, задача нахождения цепочки транзакций для антифрода через нее решается. Так что. возможно, гибриды действительно будут эффективнее. Посмотрим.
Был интересный пример антифрода - прослеживание путей перевода денег по транзакциям для отмывания. На чистой реляционке это делается действительно сложно, если пути длинные. Впрочем, для графовой БД, запрос со всеми условиями нам не показали, отослали к книге. И это - один из примеров алгоритмов, которые на графовой базе решаются лучше, чем в реляционной. В TigerGraph, где работал Павел, есть открытая библиотека из 50 алгоритмов, которые можно использовать для прикладных своих задач: кратчайшие пути, community detection, кластеризация. Но на другие БД ее надо портировать, так как, к сожалению, единого стандарта на на язык запросов к графовым БД нет, стандарт ожидается в 23-24 годах, при этом уже понятно, что туда войдет небольшое ядро, а у каждой БД будут свои расширения. Помимо алгоритмов, способ применения - ML на графах, там это получается проще, чем на реляционке, как раз потому что можно легче вытаскивать объекты по связям. Области применения: finantial fraud, risk, monitoring, customer journey, рекомендации, supply chain analysis, energy management (трубопроводы и электросети), network resource optimization...
По имеющимся БД обзора не было, в основном рассказ был про TigerGraph, которая закрытая и работает в американских облаках, но с которой можно бесплатно поиграться. Neo4j - открытая, но есть ограничения по производительности. Впрочем, это - старое сравнение от Tiger, так что надо смотреть конкретные цифры, эти ограничения могут быть несущественны для вашей задачи. Еще есть NebulaDB - китайский open source, она послабее Tiger, но интенсивно развивается. Почему-то не упомянул ArangoDB.
И сейчас есть тренд на гибридные базы данных, встраивание графового движка в реляционки. Павел считает, что это - более перспективно, чем развитие чисто графовых до соразмерных с реляционками объемов и функций. Выходит расширение SQL/PGQ для работы с графами, драйвит это Oracle, у которого, кстати, уже очень давно есть конструкция start with - connect by, позволявшая ходить по деревьям в реляционке, в частности, задача нахождения цепочки транзакций для антифрода через нее решается. Так что. возможно, гибриды действительно будут эффективнее. Посмотрим.
👍2
#highload Сергей Прийменко. Продуктовая платформа исполнителей в Яндекс Go. Рассказ был про приложение Яндекс Про, которое родилось из приложения для таксистов, в котором водитель принимал заказ. В ковид интенсивно пошла Яндекс-доставка и Яндекс Еда и было решено использовать для курьеров доработанное приложение. Все делали быстро, и в целом оно работало, но появился ряд проблем
* Фейковые сущности. Например, ровер на велосипеде, фейковые машины и водительские удостоверения для пеших курьеров.
* Не все сервисы из коробки понимали расширения: на заказ такси приезжает велокурьер, или в чеки заказа таксиста попадают чеки курьеров.
* Сильная функциональная связность. Например, от профиля водителя-курьера все зависит. При этом профиль используется в критических точках.
* Множество интерфейсов сервиса с нюансами. Например, смена водительского удостоверения для водителя такси и для курьера доставки.
* При увеличении трафика от сторонних сервисов возникает вопрос - а кто платит за масштабирование.
* Стабильность. Если проводим учения - ломаются все сервисы, и это усложнение процесса.
* Любая ошибка, случайный скрипт может поломать соседний сервис, потому что не учитывает особенности.
Поэтому была идея сделать реинжиниринг. Они посмотрели на опыт Uber, который проходил аналогичные проблемы в 2018, и их решение - domain oriented microservice architecture: разложить сервисы по доменам, и дальше разлить домены по слоям. Слои Presentation - Product - Business platform - Microservice infrastructure - Low-level infrastructure. Если взглянуть через эту схему, то получается что они развивали слой Product, смешивая в одних сервисах много продуктов, вместо того, чтобы выделить общие части в слое Business platform и над ними - настройки с точками кастомизации. И они пошли этим путем, но постепенно, то что работает, пока оставлено. Первый шаг был с Яндекс-маркетом, были выделены сервисы профилей пользователей и авторизация, при этом профили имеют кастомизацию для разных продуктов. Workflow выполнения задачи пока обобщить не получается, там различается набор статусов и логика, при этом часть статусов может приходить от сервиса. Хотя лично я не очень понимаю, в чем проблема. Может, там бизнес-логика местами сильно повторяется, а местами - наоборот, различается, и хочется больше повторного использования, и требуется сильная реструктуризация кода (но это - чисто моя гипотеза).
Выделили на уровень платформы вознаграждение исполнителю, при этом принципиально поменяли архитектуру: раньше за вознаграждением шло обращение в бизнес-сервисы, а теперь бизнес-сервисы посылают события начисления вознаграждений, а сервис их хранит и показывает. При этом отражение детализации может различаться, это точка кастомизации и там не только текстовое представление, но и могут быть карты.
* Фейковые сущности. Например, ровер на велосипеде, фейковые машины и водительские удостоверения для пеших курьеров.
* Не все сервисы из коробки понимали расширения: на заказ такси приезжает велокурьер, или в чеки заказа таксиста попадают чеки курьеров.
* Сильная функциональная связность. Например, от профиля водителя-курьера все зависит. При этом профиль используется в критических точках.
* Множество интерфейсов сервиса с нюансами. Например, смена водительского удостоверения для водителя такси и для курьера доставки.
* При увеличении трафика от сторонних сервисов возникает вопрос - а кто платит за масштабирование.
* Стабильность. Если проводим учения - ломаются все сервисы, и это усложнение процесса.
* Любая ошибка, случайный скрипт может поломать соседний сервис, потому что не учитывает особенности.
Поэтому была идея сделать реинжиниринг. Они посмотрели на опыт Uber, который проходил аналогичные проблемы в 2018, и их решение - domain oriented microservice architecture: разложить сервисы по доменам, и дальше разлить домены по слоям. Слои Presentation - Product - Business platform - Microservice infrastructure - Low-level infrastructure. Если взглянуть через эту схему, то получается что они развивали слой Product, смешивая в одних сервисах много продуктов, вместо того, чтобы выделить общие части в слое Business platform и над ними - настройки с точками кастомизации. И они пошли этим путем, но постепенно, то что работает, пока оставлено. Первый шаг был с Яндекс-маркетом, были выделены сервисы профилей пользователей и авторизация, при этом профили имеют кастомизацию для разных продуктов. Workflow выполнения задачи пока обобщить не получается, там различается набор статусов и логика, при этом часть статусов может приходить от сервиса. Хотя лично я не очень понимаю, в чем проблема. Может, там бизнес-логика местами сильно повторяется, а местами - наоборот, различается, и хочется больше повторного использования, и требуется сильная реструктуризация кода (но это - чисто моя гипотеза).
Выделили на уровень платформы вознаграждение исполнителю, при этом принципиально поменяли архитектуру: раньше за вознаграждением шло обращение в бизнес-сервисы, а теперь бизнес-сервисы посылают события начисления вознаграждений, а сервис их хранит и показывает. При этом отражение детализации может различаться, это точка кастомизации и там не только текстовое представление, но и могут быть карты.
#highload Андрей Комягин из STM Labs. Квест по синхронизации аналитического и оперативного хранилищ в реальном времени без потерь, когда у тебя сотни терабайт данных. Рассказ о том, как выносили отдельно аналитическое хранилище и налаживали перегрузку в него оперативных данных. Логистика, трекинг движения товаров. Оперативные системы - на MongoDB. И первоначально аналитические запросы и отчеты писали прямо на ней. Смесь OLAP и OLTP нагрузку держала плохо, с заказчиком договорились про отдельное аналитическое хранилище. А в него надо перегружать.
Начали с ETL, помучались с ними, потому что ориентировались на бизнес-дату операции, а не на реальную дату изменения, и не видели удаления, поэтому перегрузка была с ошибками, данные сверялись, расползались и перегружались вручную. Поэтому решили сделать на CDC, у Mongo это oplog, есть API MongoDB Change Stream и есть готовый Mongo Connector, который позволяет читать CDC и писать в Kafka. Они Mongo Connector, потому что он дает много функционала из коробки, в докладе было много подробностей настройки.За Kafka стоит CDC processing, который делает преобразования и пишет в Kafka потребителям, которые забирают online и пишет в аналитическую MongoDB. Сделана дополнительная штука для ручных перегрузок - необходимость не пропала, но их можно сделать технологично, перечитав СDС с заданного места.
Начали с ETL, помучались с ними, потому что ориентировались на бизнес-дату операции, а не на реальную дату изменения, и не видели удаления, поэтому перегрузка была с ошибками, данные сверялись, расползались и перегружались вручную. Поэтому решили сделать на CDC, у Mongo это oplog, есть API MongoDB Change Stream и есть готовый Mongo Connector, который позволяет читать CDC и писать в Kafka. Они Mongo Connector, потому что он дает много функционала из коробки, в докладе было много подробностей настройки.За Kafka стоит CDC processing, который делает преобразования и пишет в Kafka потребителям, которые забирают online и пишет в аналитическую MongoDB. Сделана дополнительная штука для ручных перегрузок - необходимость не пропала, но их можно сделать технологично, перечитав СDС с заданного места.
👍3
Вслед за #highload - #teamlead. Богдан Гаркушин. Эволюция управления в зависимости от размера команды и масштаба проекта. Интересный доклад про управления командами от 2 до 40 человек. Про большие он тоже говорил, но сослался, что нет опыта руководства, только наблюдение. А вот на начальном этапе - интересная эволюция того, как меняется управление по мере роста команды. Про привязку решений к конкретному числу людей можно поспорить, ко пункты - важны.
* Внушить, вновь приходящим, которые говорят, что надо все переделать и именно они знают, что нужно пользователю, что команда - тоже пользователь и именно от работы на команду ты получаешь зарплат. Но про пользователя тоже не забывать.
* Будут приходить с доп.задачами - чтобы отвлекался максимум один, а лучше решать силами смежных команд. Но я бы тут дополнил, что не надо превращать задачи в пинг-понг на смежников, это аукнется.
* С 5 человек должна быть полноценная замена. Ему - операционку, вам - развитие. Страх - а вдруг он займет ваше место - лишний, да, человек займет, а вы пойдете дальше. И далее надо поделить: 5 человек ведут основной поток, core-часть, а вы с 2-3 - делаете перспективные проекты. Вы руководите меньше частью команды.
* Команда 12-17 человек еще остается цельной, но появляются уже отдельно продукт и проджект с разными фокусами управления, делим Discovery и Delivery. Меньшая часть - discovery, product, а большая часть delivery, project. Важно их разделить. Очень большой соблазн, когда product вмешивается в текучку project. И задачами в Jira должен управлять project, чтобы не ломалось планирование. В докладе было жестче - ставить, но это вопрос workflow, буфер будущих работ можно формироdать, важен момент запуска.
* А потом команды делятся. Важно, чтобы команды были самостоятельными рабочими единицами, которые должны запускать функционал. Нанимать продуктов и проджектов: человек, который умеет работать с аудиторией и человек, который умеет вести проекты технологично. Надо сохранить эффективность, а она зависит не только от вас, но и от тимлидов: они должны подруливать там, где ты не рулишь. Схема - матричная, есть продукты и есть лиды front-back и другие.
При этом на всех этапах основная задача руководителя - заниматься стратегией. Процессы - важно, чтобы не все стало процессами, заняв все время. У него - одна встреча с лидами про точки эффективности. Если точку можно решить в существующем - решаем. Если нет - новый процесс.
Инструменты:
* Цели - горизонт год, называться моет по-разному, например, инициативы. Изменение некоторого параметра
* Роадмап - способ достижения цели
* Проекты/фичи - Это то, чем идем по роадмапу. Scrum или Kanban - не важно.
* Daily/Weekly - единственный плюс от стендапа - чтобы собирались к 12 на работе, остальное - через чатики. А вот еженедельно - надо. Фокусировка, проблемы, обратная связь что делает. Каждый пишет мини-отчет - это дает взаимную ответственность.
Про встречи отмечу, что это как раз про влияние мессенджеры, которые принципиально изменили коммуникацию. Фреймворки под это пока методологически не пересобраны, это делают практики в своей работе.
Про удаленку. Для некоторых команда - семья, работа в офисе - способ получить общение. Надо кому-то удаленка - хорошо, кому-то - нет, учитывайте это, не ориентируйтесь только на себя.
* Внушить, вновь приходящим, которые говорят, что надо все переделать и именно они знают, что нужно пользователю, что команда - тоже пользователь и именно от работы на команду ты получаешь зарплат. Но про пользователя тоже не забывать.
* Будут приходить с доп.задачами - чтобы отвлекался максимум один, а лучше решать силами смежных команд. Но я бы тут дополнил, что не надо превращать задачи в пинг-понг на смежников, это аукнется.
* С 5 человек должна быть полноценная замена. Ему - операционку, вам - развитие. Страх - а вдруг он займет ваше место - лишний, да, человек займет, а вы пойдете дальше. И далее надо поделить: 5 человек ведут основной поток, core-часть, а вы с 2-3 - делаете перспективные проекты. Вы руководите меньше частью команды.
* Команда 12-17 человек еще остается цельной, но появляются уже отдельно продукт и проджект с разными фокусами управления, делим Discovery и Delivery. Меньшая часть - discovery, product, а большая часть delivery, project. Важно их разделить. Очень большой соблазн, когда product вмешивается в текучку project. И задачами в Jira должен управлять project, чтобы не ломалось планирование. В докладе было жестче - ставить, но это вопрос workflow, буфер будущих работ можно формироdать, важен момент запуска.
* А потом команды делятся. Важно, чтобы команды были самостоятельными рабочими единицами, которые должны запускать функционал. Нанимать продуктов и проджектов: человек, который умеет работать с аудиторией и человек, который умеет вести проекты технологично. Надо сохранить эффективность, а она зависит не только от вас, но и от тимлидов: они должны подруливать там, где ты не рулишь. Схема - матричная, есть продукты и есть лиды front-back и другие.
При этом на всех этапах основная задача руководителя - заниматься стратегией. Процессы - важно, чтобы не все стало процессами, заняв все время. У него - одна встреча с лидами про точки эффективности. Если точку можно решить в существующем - решаем. Если нет - новый процесс.
Инструменты:
* Цели - горизонт год, называться моет по-разному, например, инициативы. Изменение некоторого параметра
* Роадмап - способ достижения цели
* Проекты/фичи - Это то, чем идем по роадмапу. Scrum или Kanban - не важно.
* Daily/Weekly - единственный плюс от стендапа - чтобы собирались к 12 на работе, остальное - через чатики. А вот еженедельно - надо. Фокусировка, проблемы, обратная связь что делает. Каждый пишет мини-отчет - это дает взаимную ответственность.
Про встречи отмечу, что это как раз про влияние мессенджеры, которые принципиально изменили коммуникацию. Фреймворки под это пока методологически не пересобраны, это делают практики в своей работе.
Про удаленку. Для некоторых команда - семья, работа в офисе - способ получить общение. Надо кому-то удаленка - хорошо, кому-то - нет, учитывайте это, не ориентируйтесь только на себя.
👍2
#teamlead Алексей Пименов. Работа с узкими звеньями процессов и ресурсами непостоянной доступности. Работа с узкими звеньями - Теория ограничений Голдратта, 40 лет назад книга Цель. Алгоритм: (1) найти узкое звено, (2) поставить на 100% загрузку, (3) подчинить весь поток ему, (4) устранить узкое звено. Узкое звено - ресурс ограниченной мощности. Только один в каждый момент в системе. Его нельзя устранить, будет перемещаться. И по каждому шагу есть нюансы.
Для начала про метрики. Скорость работы: это пропускная способность или время производства? Они относительно независимы. Чаще всего хотят сократить время, хотя формально "скорость" - это про пропускную способность. Узкое звено ограничивает пропускная способность - количество элементов, покидающих систему. При этом далеко не всегда оно использовано на максимум. А время производства, если не работать с узкими звеньями, будет постоянно расти, будет копиться незавершенная работа.
Про то, как найти узкое звено регулярно слышит одну и ту же хрень: это место, где скопилось больше всего работы. Это НЕ так, вполне может быть, что скопилось там, где много людей. А тут работа скапливается ПЕРЕД ним. Но тоже не факт. Реально в статике, посмотрев на визуализацию увидеть узкое звено. Надо посмотреть в динамике.
Для динамики используем накопительную диаграмму потока. Набор срезов доски на каждый день. И там есть зона, которая постоянно расширяется. И если там - буфер, то именно там накопление ПЕРЕД узким звеном. Но если мы смотрим на такой график, то таких зон роста может быть МНОГО. В этом случае определяющим пропускную способность является последний - перед которым в буфере постоянно растет количество элементов. Могут разгребать, но дальше растет.
Обеспечить узкое звено 100% загрузкой: оно должно работать на узкоспециализированную работу, которой занимаются только они. У него могут быть сопутствующие задачи. Например, у тестировщика - написание тестовых сценариев, их прогон, разворачивание сред... И если узкое звено - в написании тестовых сценариев, то остальное - отдаем.
Подчинить производственные процесс узкому звену. Как? Например, через ограничение запуска в работу. Есть WIP-лимиты. И лимит должен быть такой, чтобы у узкого звена должна быть работа. WIP-лимиты пропускную способность НЕ увеличивают, но могут уменьшить. Они работают на время производства. На узкое звено тоже надо ставить WIP-лимит - чтобы ограничить количество переключений, утомляемость и т.п. Надо ли стаивть WIP-лимит после узкого звена? Ресурсов там хватает, но вот задержки могут возникать - и WIP-лимит фокусирует на завершении работы, а не на запуске.
Расшить узкое звено. Наем людей, расширение мощностей, автоматизация... Как только расшили в одном месте - оно перемещается. Можно гонять так, что либо упретесь в заказчику (но это незагруженная команда разработки), либо в рынок, которые не готов хранить. Поэтому не надо расшивать полностью, им надо управлять.
Где лучше иметь узкое звено? Большой процесс discovery-delivery? в середине красная линия, где фича идет в реализацию. Если есть процесс исследований, 100 гипотез, производство может быть 10 фич. Отбрасывание 90%. И узкое звено держать в discovery - не эффективно. Можно держать в начале производства или в конце. Если оно в начале - управлять процессом легко, только надо договориться с продуктом. Если в конце - управлять сложнее. А по экономике: в реализации тоже есть отказ от идей, и шанс, что отвалится после первого этапа производства выше, чем в конце. И экономически его наоборот, выгоднее поставить в конце. Нужен баланс.
Ресурс непостоянной доступности. Например, архитектор, который приходит рандомно или по пятницам и делает ревью. Или казначей, который раз в месяц согласует бюджет, или сервис, используемый разделемо. Он приходит и разгребает. Если фичу подготовил в понедельник, а ревью в пятницу - лежит неделю, а в пятницу - быстро. Время производства увеличивается, но оно не столь страшно.
Для начала про метрики. Скорость работы: это пропускная способность или время производства? Они относительно независимы. Чаще всего хотят сократить время, хотя формально "скорость" - это про пропускную способность. Узкое звено ограничивает пропускная способность - количество элементов, покидающих систему. При этом далеко не всегда оно использовано на максимум. А время производства, если не работать с узкими звеньями, будет постоянно расти, будет копиться незавершенная работа.
Про то, как найти узкое звено регулярно слышит одну и ту же хрень: это место, где скопилось больше всего работы. Это НЕ так, вполне может быть, что скопилось там, где много людей. А тут работа скапливается ПЕРЕД ним. Но тоже не факт. Реально в статике, посмотрев на визуализацию увидеть узкое звено. Надо посмотреть в динамике.
Для динамики используем накопительную диаграмму потока. Набор срезов доски на каждый день. И там есть зона, которая постоянно расширяется. И если там - буфер, то именно там накопление ПЕРЕД узким звеном. Но если мы смотрим на такой график, то таких зон роста может быть МНОГО. В этом случае определяющим пропускную способность является последний - перед которым в буфере постоянно растет количество элементов. Могут разгребать, но дальше растет.
Обеспечить узкое звено 100% загрузкой: оно должно работать на узкоспециализированную работу, которой занимаются только они. У него могут быть сопутствующие задачи. Например, у тестировщика - написание тестовых сценариев, их прогон, разворачивание сред... И если узкое звено - в написании тестовых сценариев, то остальное - отдаем.
Подчинить производственные процесс узкому звену. Как? Например, через ограничение запуска в работу. Есть WIP-лимиты. И лимит должен быть такой, чтобы у узкого звена должна быть работа. WIP-лимиты пропускную способность НЕ увеличивают, но могут уменьшить. Они работают на время производства. На узкое звено тоже надо ставить WIP-лимит - чтобы ограничить количество переключений, утомляемость и т.п. Надо ли стаивть WIP-лимит после узкого звена? Ресурсов там хватает, но вот задержки могут возникать - и WIP-лимит фокусирует на завершении работы, а не на запуске.
Расшить узкое звено. Наем людей, расширение мощностей, автоматизация... Как только расшили в одном месте - оно перемещается. Можно гонять так, что либо упретесь в заказчику (но это незагруженная команда разработки), либо в рынок, которые не готов хранить. Поэтому не надо расшивать полностью, им надо управлять.
Где лучше иметь узкое звено? Большой процесс discovery-delivery? в середине красная линия, где фича идет в реализацию. Если есть процесс исследований, 100 гипотез, производство может быть 10 фич. Отбрасывание 90%. И узкое звено держать в discovery - не эффективно. Можно держать в начале производства или в конце. Если оно в начале - управлять процессом легко, только надо договориться с продуктом. Если в конце - управлять сложнее. А по экономике: в реализации тоже есть отказ от идей, и шанс, что отвалится после первого этапа производства выше, чем в конце. И экономически его наоборот, выгоднее поставить в конце. Нужен баланс.
Ресурс непостоянной доступности. Например, архитектор, который приходит рандомно или по пятницам и делает ревью. Или казначей, который раз в месяц согласует бюджет, или сервис, используемый разделемо. Он приходит и разгребает. Если фичу подготовил в понедельник, а ревью в пятницу - лежит неделю, а в пятницу - быстро. Время производства увеличивается, но оно не столь страшно.
👍6
Ресурс неподходящей доступности может быть узким звеном, а может и НЕ быть. Вопрос - разгребает ли он накопленные задачи. Если он - узкое звено, надо расшивать. Но даже если он - не узкое звено, рекомендуется несколько эвристик.
* Если ресурс доступен рандомно - сделайте доступным регулярно
* Если регулярно - увеличьте частоту. Не 1 раз в неделю 100 задач, а два раза в неделю по 50 задач
* Повышение автономности. Поговорить и часть задач перестать пропускать через них. Был ейс, когда маркетологи согласовывали бюджет все изменения бюджета - сделали порог согласования.
* Попробуйте забрать себе внутрь.
Должны ли люди знать, что они - узкое звено? Зависит от зрелости команды. Если вы не хотите, чтобы беспокоились - можете не говорить, но если команда зрелая, и вовлечена в работу на цели, то лучше рассказать и пусть они сами ищут решения.
При применение. Узкое звено влияет на две метрики. Если они не важны, а важно качество - то узкое звено не при чем.
Про переключение хаотичного процесса с перегрузками. Это умирание. Не надо так работать, надо разбираться.
* Если ресурс доступен рандомно - сделайте доступным регулярно
* Если регулярно - увеличьте частоту. Не 1 раз в неделю 100 задач, а два раза в неделю по 50 задач
* Повышение автономности. Поговорить и часть задач перестать пропускать через них. Был ейс, когда маркетологи согласовывали бюджет все изменения бюджета - сделали порог согласования.
* Попробуйте забрать себе внутрь.
Должны ли люди знать, что они - узкое звено? Зависит от зрелости команды. Если вы не хотите, чтобы беспокоились - можете не говорить, но если команда зрелая, и вовлечена в работу на цели, то лучше рассказать и пусть они сами ищут решения.
При применение. Узкое звено влияет на две метрики. Если они не важны, а важно качество - то узкое звено не при чем.
Про переключение хаотичного процесса с перегрузками. Это умирание. Не надо так работать, надо разбираться.
👍5
#teamlead. Андрей Смирнов. Как нейросети могут помочь руководителю. У меня это уже третий доклад про использование ChatGPT за последнее время, в тех было про использование аналитиками, в конце поста будут ссылки. А Андрей рассказывал из позиции руководителя управления в X5tech, и это руководитель достаточно высокого уровня. Оказывается, там очень много можно использовать. Собственно, в одной из компаний есть инструмент ассистирования руководителю: минимизировать трудозатраты, убрать рутину: суммаризация писем, автопланирование встреч, автопротоколирование, авторешения - вплоть до увольнения по метрикам. Все это практически можно возложить на нейронку.
Начинал он с попытки использовать ChatGPT чтобы единообразным образом поменять много должностных инструкций. Оно не получилось, вручную поправить быстрее, но зато заметил: можно попросить сделать инструкцию с нуля, и получается черновик, который отредактировать.
Получается рутинная генерация креатива. И он пошел копать. Сразу замечание: работать на русском - невероятная мука, DeepL для перевода. Что можно сделать?
*
Матрица компетенций. Можно попросить сделать матрицу для FrontEnd. B если уточнить стек и что нужно, что нет - то получится качественно.
* Вопросы для собеседований. Надо придумать новое для таких-то. А если ты глава разных специализация - тоже можно попросить вопросы. Но на вопросы дальше надо получить ответы - самому в инете, по каким-то темам можно спросить AI. Например, у Mozilla есть AI с ответами на браузер. Спрашиваешь его и сравниваешь ответ на собеседовании.
* Долго собеседуете лидов, люди выучили кейсы - можно попросить придумать новые кейсы.
* Новое парное программирование на собеседовании. С кандидатом садимся с ChatGPT, версию постарее, чтобы ответ похуже. Получаем ответ, и обсуждаем, как улучшить.
* Генерация писем. Вообще вау, там кайфный фильтр эмоций. Тебе заказчик рассказал, и ты просишь переделать сотрудникам без эмоций. Или на вас накричали в письме - ты в ответ пишешь с криком и просишь переписать по-существу. Или пишут иностранные вендоры канцелярским языком - нейросеть может написать. Потом можно еще Grammrly прогнать.
* Решение сложной человеческой проблемы. Например, "мне кажется, руководитель не ценит", смотришь список, а ты пишешь "что-то недостаточно креативно" - и она порождает.
* Сделать мотивирующую речь сотрудникам. Особенно когда сам в депрессии и у тебя и так все плохо.
* Идеи для тимбилдинга, когда уже се делали, а повторяться не хочется.
* Идеи подарков. А не по кругу дарить друг другу деньги.
Суммируя все это. Если у вас нет ассистента, то ChatGPT может быть помощником, коллегой-компаньоном. На каждый вопрос нейросеть порождает много ответов, и вам выдает случайный - полезно варьировать вопросы.
Еще идея. А если записывать one2one, расшифровывать и сохранять чтобы смотреть год за годом. И интересно порождать summary встреч.
* Расшифровка: whisper.cpp - он не базовый, а на C++, ему нужен правильный аудио-файл, а расшифровать можно у себя локально.
* Текст - огромный. Есть несколько надстроек, которые разбивают на части, можно даже с помощью ChatGPT написать скрипт на питоне. И дальше в Pipedream можно написать промпт, который все свяжет, и на выходе будет summary.
Правда все это долго и муторно. Но есть guide, как из голоса генерить текст в notion. B еще есть несколько шоткатов.
Есть минусы.
* Не понимает полилог - когда разговор 3-4 людей, даже при расшифровке.
* Очень долго. Пока разобьешь, пока она обработает. У него часовой файл за пять минут, а у кого-то за час.
* Есть неточности. Русский в английский и обратно - меняется смысл.
Начинал он с попытки использовать ChatGPT чтобы единообразным образом поменять много должностных инструкций. Оно не получилось, вручную поправить быстрее, но зато заметил: можно попросить сделать инструкцию с нуля, и получается черновик, который отредактировать.
Получается рутинная генерация креатива. И он пошел копать. Сразу замечание: работать на русском - невероятная мука, DeepL для перевода. Что можно сделать?
*
Матрица компетенций. Можно попросить сделать матрицу для FrontEnd. B если уточнить стек и что нужно, что нет - то получится качественно.
* Вопросы для собеседований. Надо придумать новое для таких-то. А если ты глава разных специализация - тоже можно попросить вопросы. Но на вопросы дальше надо получить ответы - самому в инете, по каким-то темам можно спросить AI. Например, у Mozilla есть AI с ответами на браузер. Спрашиваешь его и сравниваешь ответ на собеседовании.
* Долго собеседуете лидов, люди выучили кейсы - можно попросить придумать новые кейсы.
* Новое парное программирование на собеседовании. С кандидатом садимся с ChatGPT, версию постарее, чтобы ответ похуже. Получаем ответ, и обсуждаем, как улучшить.
* Генерация писем. Вообще вау, там кайфный фильтр эмоций. Тебе заказчик рассказал, и ты просишь переделать сотрудникам без эмоций. Или на вас накричали в письме - ты в ответ пишешь с криком и просишь переписать по-существу. Или пишут иностранные вендоры канцелярским языком - нейросеть может написать. Потом можно еще Grammrly прогнать.
* Решение сложной человеческой проблемы. Например, "мне кажется, руководитель не ценит", смотришь список, а ты пишешь "что-то недостаточно креативно" - и она порождает.
* Сделать мотивирующую речь сотрудникам. Особенно когда сам в депрессии и у тебя и так все плохо.
* Идеи для тимбилдинга, когда уже се делали, а повторяться не хочется.
* Идеи подарков. А не по кругу дарить друг другу деньги.
Суммируя все это. Если у вас нет ассистента, то ChatGPT может быть помощником, коллегой-компаньоном. На каждый вопрос нейросеть порождает много ответов, и вам выдает случайный - полезно варьировать вопросы.
Еще идея. А если записывать one2one, расшифровывать и сохранять чтобы смотреть год за годом. И интересно порождать summary встреч.
* Расшифровка: whisper.cpp - он не базовый, а на C++, ему нужен правильный аудио-файл, а расшифровать можно у себя локально.
* Текст - огромный. Есть несколько надстроек, которые разбивают на части, можно даже с помощью ChatGPT написать скрипт на питоне. И дальше в Pipedream можно написать промпт, который все свяжет, и на выходе будет summary.
Правда все это долго и муторно. Но есть guide, как из голоса генерить текст в notion. B еще есть несколько шоткатов.
Есть минусы.
* Не понимает полилог - когда разговор 3-4 людей, даже при расшифровке.
* Очень долго. Пока разобьешь, пока она обработает. У него часовой файл за пять минут, а у кого-то за час.
* Есть неточности. Русский в английский и обратно - меняется смысл.
👍2👌2
Согласования. Хотел бы делегировать, особенно в отпуске, но не может. Проблема: нельзя скормить в ChatGPT всю почту. Но можно развернуть какую-то LLM локально. Например llama.cpp - локальный ChatGPT. Откуда брать модели - есть ссылки. А ответы в письма можно отправлять автоматически.
Пригождается и в жизни тоже.
* Ненавидит писать тексты. С появлением нейросетей наговаривает на микрофон то, что надо сделать. Расшифровывает whisper, убирает слова-паразиты - и все, есть текст.
* Доклады. Вбивает тему и аннотацию - и она делает тезисный план, и эти тезисы наталкивают на правильный план самого.
Взгляд в будущее.
* Аудиокнига на 10 языках. Есть схема, и он получает деньги.
* Auto-GPT 0.4.3 - группа нейронок, которые как команда на тебя работает. Локально разворачиваешь и говоришь "представь, что ты - такой-то, и делаешь это". Каждой ставишь задачу, они сами ходят в интернет, обмениваются данными, приносят результат.
* Два месяца общения с нейронками. И это повлияло на собственное поведение: лучше формулируешь свою роль, лучше ставишь цели людям.
тветы на вопросы
* Применение точно не ведет с деградации руководителю, он точно поумнел. Потому что надо более понятно объяснять, и это развивает.
* Из зала: многие используют и обучают. И при этом письма, порожденные ChatGPT видно, это вызывает негатив. Ему тоже видно, поэтому надо черновик реально дорабатывать, не просто исправлять, а переписывать. Но без основы было бы не столь разнообразо и богато.
* Из зала: а можно ли, чтобы проверял тоже не человек. Он проверял вручную. Но можно попросить ChatGPT cамому проверить, он часть ошибок уберет.
* Из зала: теперь твои сотрудники узнают, как ты работаешь. Как изменится компания и отношения? Ответ: я это исследую, но не использую в работе. Пока? Я отмечу, что Юра Куприянов в работе аналитика реально использует.
И, как обещал, несколько ссылок по теме: https://analystdays.ru/ru/talk/106715 доклад Юры Куприянова, [https://habr.com/ru/news/704392/ статья Юры Куприянова на хабре, https://medium.com/smysloteka/thinking-with-chatgpt-9616ce6abb6e статья Сергея Гевлича, https://ailev.livejournal.com/1678426.html пост Анатолия Левенчука и https://lleo.me/dnevnik/2023/04/11 прикольный опыт Леонида Каганова (надо раскрыть ссылку "умилиться").
Пригождается и в жизни тоже.
* Ненавидит писать тексты. С появлением нейросетей наговаривает на микрофон то, что надо сделать. Расшифровывает whisper, убирает слова-паразиты - и все, есть текст.
* Доклады. Вбивает тему и аннотацию - и она делает тезисный план, и эти тезисы наталкивают на правильный план самого.
Взгляд в будущее.
* Аудиокнига на 10 языках. Есть схема, и он получает деньги.
* Auto-GPT 0.4.3 - группа нейронок, которые как команда на тебя работает. Локально разворачиваешь и говоришь "представь, что ты - такой-то, и делаешь это". Каждой ставишь задачу, они сами ходят в интернет, обмениваются данными, приносят результат.
* Два месяца общения с нейронками. И это повлияло на собственное поведение: лучше формулируешь свою роль, лучше ставишь цели людям.
тветы на вопросы
* Применение точно не ведет с деградации руководителю, он точно поумнел. Потому что надо более понятно объяснять, и это развивает.
* Из зала: многие используют и обучают. И при этом письма, порожденные ChatGPT видно, это вызывает негатив. Ему тоже видно, поэтому надо черновик реально дорабатывать, не просто исправлять, а переписывать. Но без основы было бы не столь разнообразо и богато.
* Из зала: а можно ли, чтобы проверял тоже не человек. Он проверял вручную. Но можно попросить ChatGPT cамому проверить, он часть ошибок уберет.
* Из зала: теперь твои сотрудники узнают, как ты работаешь. Как изменится компания и отношения? Ответ: я это исследую, но не использую в работе. Пока? Я отмечу, что Юра Куприянов в работе аналитика реально использует.
И, как обещал, несколько ссылок по теме: https://analystdays.ru/ru/talk/106715 доклад Юры Куприянова, [https://habr.com/ru/news/704392/ статья Юры Куприянова на хабре, https://medium.com/smysloteka/thinking-with-chatgpt-9616ce6abb6e статья Сергея Гевлича, https://ailev.livejournal.com/1678426.html пост Анатолия Левенчука и https://lleo.me/dnevnik/2023/04/11 прикольный опыт Леонида Каганова (надо раскрыть ссылку "умилиться").
👍4🙏2
#teamlead Руслан Остропольский. Тимлид как психолог. Основная идея доклада - все люди разные, тимлиду надо это понимать и уметь подстраиваться под людей, а для этого надо быть психологом. И это противоречит подходу через стили руководства Адизеса или ситуационного лидерства (поддерживающий, директивный, делегирование, коучинговый), которые предполагают единообразный отношение к команде.
Что разные - понятно, один на "как дела" стабильно отвечает "все хорошо", другой "все плохо", а третий рассказывает два часа. Как же понимать людей? Про это было четыре пункта.
* Слушать, внимание слушать, чувствовать
* Понимание личности и группы
* Как формируется ответственность
* Понимание реальной мотивации.
Слушать - записывать, что услышал. Карточка сотрудника:
* Все навыки и способности, не только профессиональные
* Особенности человека
* Сильные стороны
* Сслабые, проблемные моменты
* Мысли из общения и ситуация, особенно в кризисе.Подсветки из 360 и матрицы компатенций.
По мере накопления надо делать резюме. Дальше - много примеров конкретных карточек.
Поведение. 6 принципов
* Принцип взаимности обязательств и возмещений. Человек устал - дать отгул но ожидать, что при необходимости он тоже пойдет навстречу компании.
* Обязательность и последовательность: убеждения соответствуют ценностям. Как сочетать увольнения и человчный подход?
* Социальное доклазательство - сила того, что делают другие
* Власть и авторитет: желание подчиняться ответственным людям. Когда говорим человеку "ты побудь тимлидом, а команде говорить не будем" - команда не понимает.
* Симпатия: обязательства в дружбе
* Дефицит: страстное желание того, что может быть недоступно. Например, хочет выступить на митапе или съездить на конференцию
Как формируется ответственность
* Результаты исходят от людей, которые сами принимают ответственность. Сроки тоже ставят сами люди.
* Невозможно наделить ответственностью сверху
* Восприятие и причастность. Антипаттерн, когда смотрят "наверху делают странное"
* Не работает без полномочий
Понять реальную мотивацию.
* Не все хотят расти и развиваться
* Не все хотят быть лидами и менеджерами
* Не все готовы работать сверхурочно
* Не всем нужно, чтобы работа была как семья.
Интерес помимо работы.
* life work balance. Книги прикольны, но надо выбирать, что вам подойдет.
* спорт - пробежки, простая зарядка
* хобби
* семья
* друзья не только коллеги
* путешествия
* обучение другой профессии
Я тут отмечу, что все - правильно. Но получается, что с каждым человеком надо разбираться персонально. Как, собственно делают психологи при индивидуальной работе. Но есть инструменты технологичного разбора, например, разные типологии. Про них в докладе ничего не было. И, на мой взгляд, это неправильно. Это как с написанием кода: код, который ты пишешь - уникален, но эффективно писать с помощью шаблонов, и шаблонам стоит учить в самом начале обучения, а не потом. Или я ошибаюсь?
Что разные - понятно, один на "как дела" стабильно отвечает "все хорошо", другой "все плохо", а третий рассказывает два часа. Как же понимать людей? Про это было четыре пункта.
* Слушать, внимание слушать, чувствовать
* Понимание личности и группы
* Как формируется ответственность
* Понимание реальной мотивации.
Слушать - записывать, что услышал. Карточка сотрудника:
* Все навыки и способности, не только профессиональные
* Особенности человека
* Сильные стороны
* Сслабые, проблемные моменты
* Мысли из общения и ситуация, особенно в кризисе.Подсветки из 360 и матрицы компатенций.
По мере накопления надо делать резюме. Дальше - много примеров конкретных карточек.
Поведение. 6 принципов
* Принцип взаимности обязательств и возмещений. Человек устал - дать отгул но ожидать, что при необходимости он тоже пойдет навстречу компании.
* Обязательность и последовательность: убеждения соответствуют ценностям. Как сочетать увольнения и человчный подход?
* Социальное доклазательство - сила того, что делают другие
* Власть и авторитет: желание подчиняться ответственным людям. Когда говорим человеку "ты побудь тимлидом, а команде говорить не будем" - команда не понимает.
* Симпатия: обязательства в дружбе
* Дефицит: страстное желание того, что может быть недоступно. Например, хочет выступить на митапе или съездить на конференцию
Как формируется ответственность
* Результаты исходят от людей, которые сами принимают ответственность. Сроки тоже ставят сами люди.
* Невозможно наделить ответственностью сверху
* Восприятие и причастность. Антипаттерн, когда смотрят "наверху делают странное"
* Не работает без полномочий
Понять реальную мотивацию.
* Не все хотят расти и развиваться
* Не все хотят быть лидами и менеджерами
* Не все готовы работать сверхурочно
* Не всем нужно, чтобы работа была как семья.
Интерес помимо работы.
* life work balance. Книги прикольны, но надо выбирать, что вам подойдет.
* спорт - пробежки, простая зарядка
* хобби
* семья
* друзья не только коллеги
* путешествия
* обучение другой профессии
Я тут отмечу, что все - правильно. Но получается, что с каждым человеком надо разбираться персонально. Как, собственно делают психологи при индивидуальной работе. Но есть инструменты технологичного разбора, например, разные типологии. Про них в докладе ничего не было. И, на мой взгляд, это неправильно. Это как с написанием кода: код, который ты пишешь - уникален, но эффективно писать с помощью шаблонов, и шаблонам стоит учить в самом начале обучения, а не потом. Или я ошибаюсь?
❤4
#teamlead Алексей Обровец. Три кита истинного лидера: эмпатия, рефлексия и инициатива. Очень вдохновляющий доклад, как сказали в вопросах "вы - Данко. который зажигает". Речь шла о том, что если хочешь команду мечты - становись лидером мечты. И тут важно, что тимлид - не просто профессия, это большая жизнь, которую живешь в дома и в профессии. Людям нужно лидерство, люди хотят идти за чем-то важным, за кем-то интересным. И это то, чем каждый из нас должен стать, чтобы вдохновлять. Лидер - проводник, за которым хочется идти. Я хочу быть таким. Получается ли - можно сказать оглядываясь назад, если оглядываясь - никого не вижу или вижу недовольные лица - надо что-то менять.
Чтобы стать лидером - нет лайфхака. Лайфхак - получить результат быстрее, а в жизни - надо просто жить. Да, надо проявлять инициативу, эмпатию, рефлексию. Все умеют. Но дальше надо просто быть, а не казаться. Как со спикерами: есть инструменты, чтобы не волноваться. Их можно применить. Но все равно, надо выйти на сцену и быть.
Из мира индивидуальности западной психологии в мир работы с людьми, которые меня окружают. И сейчас на те, кто на прошлом шаге давали образования, возможно, пришли вместе со мной строить команду. Говорят что есть великие люди, которые сделают сами - но реально рядом с ними кто-то стоял, они не в вакууме. Если вчера коллеги, заказчики, руководители - инструмент достижения цели, то сейчас это люди, рядом с которыми могу быть счастлив, и которые могут быть счастливы.
Эмпатия - не доброе лицо, и не "ура, мы вместе, я соскучился", в том, что я, как лидер, понимаю что нужно людям вокруг, чтобы они были счастливы. Иногда - долить воду в кофемашину. Нужно знать, когда у многодетных коллег дни рождения детей. И у кого идет ремонт, и он живет с тещей. Интересоваться, как происходит у людей, а не просто, чтобы перформили. На следующем шаге - знаю, что прокачать, кому не хватает компа, а кому - пары книг, которые прочел я, а не по аннотации. В итоге эмпатия дает прозрачность коммуникаций. Не только я интересуюсь людьми, они интересуются друг другом, и мной тоже, и новый человек приходит в команду - проникается.
Много задач - норма, вопрос - в какой атмосфере мы работаем, какую выстраиваем для оппонентов и врагов. Болельщик Спартака и Зенита могут работать за столами. Когда интересуемся, то деврел знает, что архитектора нельзя отвлекать.
После митапа подошел человек "слушай, ты так говоришь, как будто я обязан их полюбить, а они старше, многодетные, другая культура - не хочу". Лидер не обязан любить, не обязан в полную силу вовлекаться, но знать - да, нужно. И это - первый шаг. Интересоваться, не когда хочешь получить, а чтобы вместе жить и работать. И если прихожу на жесткие переговоры - то ты знаешь, что нужно миру от меня и что нужно мне.
Рефлексия. Становится популярно. Инструментов - дофига. Но вообще - это способность время от времени останавливаться и думать про свою жизнь - хочу ли я продолжать эту жизнь, или стоит что-то переделать. Контролировать мышление, оценивать обосновывать, логичность поступков. Что легко, что тяжело, что в себе исправить. Человек, который умнее может дать неожиданный ответ. Ретро жизни. Какими я хочу, чтобы выросли дети. И какими я хочу, чтобы были коллеги. Про коллег многое можно поменять - настроение и многое другое.
Рефлексия - избавляет от невозможности делать выбор - потмоу что уже подумал. Про профессиональную жизнь, про личную жизнь. И если подерсусь с девопсом - будет запланирвоанная драка. Рефлексия: личностная, коммуникативная, интеллектуальная (прокурчивание в голове сценариев). Подростка часто надо оставить впокое - гормоны бушуют. И коллегу тоже надо оставить в покое - эмоции, другие факторы. Рефлексия - свобола разговаривать: получать обратную связь, задавать любые вопросы, спокойно относитсья к чужим слабостям - потмоу что знаю свои. Не сотрудники, не коллеги, а Люди, и они хотят на работу.
Чтобы стать лидером - нет лайфхака. Лайфхак - получить результат быстрее, а в жизни - надо просто жить. Да, надо проявлять инициативу, эмпатию, рефлексию. Все умеют. Но дальше надо просто быть, а не казаться. Как со спикерами: есть инструменты, чтобы не волноваться. Их можно применить. Но все равно, надо выйти на сцену и быть.
Из мира индивидуальности западной психологии в мир работы с людьми, которые меня окружают. И сейчас на те, кто на прошлом шаге давали образования, возможно, пришли вместе со мной строить команду. Говорят что есть великие люди, которые сделают сами - но реально рядом с ними кто-то стоял, они не в вакууме. Если вчера коллеги, заказчики, руководители - инструмент достижения цели, то сейчас это люди, рядом с которыми могу быть счастлив, и которые могут быть счастливы.
Эмпатия - не доброе лицо, и не "ура, мы вместе, я соскучился", в том, что я, как лидер, понимаю что нужно людям вокруг, чтобы они были счастливы. Иногда - долить воду в кофемашину. Нужно знать, когда у многодетных коллег дни рождения детей. И у кого идет ремонт, и он живет с тещей. Интересоваться, как происходит у людей, а не просто, чтобы перформили. На следующем шаге - знаю, что прокачать, кому не хватает компа, а кому - пары книг, которые прочел я, а не по аннотации. В итоге эмпатия дает прозрачность коммуникаций. Не только я интересуюсь людьми, они интересуются друг другом, и мной тоже, и новый человек приходит в команду - проникается.
Много задач - норма, вопрос - в какой атмосфере мы работаем, какую выстраиваем для оппонентов и врагов. Болельщик Спартака и Зенита могут работать за столами. Когда интересуемся, то деврел знает, что архитектора нельзя отвлекать.
После митапа подошел человек "слушай, ты так говоришь, как будто я обязан их полюбить, а они старше, многодетные, другая культура - не хочу". Лидер не обязан любить, не обязан в полную силу вовлекаться, но знать - да, нужно. И это - первый шаг. Интересоваться, не когда хочешь получить, а чтобы вместе жить и работать. И если прихожу на жесткие переговоры - то ты знаешь, что нужно миру от меня и что нужно мне.
Рефлексия. Становится популярно. Инструментов - дофига. Но вообще - это способность время от времени останавливаться и думать про свою жизнь - хочу ли я продолжать эту жизнь, или стоит что-то переделать. Контролировать мышление, оценивать обосновывать, логичность поступков. Что легко, что тяжело, что в себе исправить. Человек, который умнее может дать неожиданный ответ. Ретро жизни. Какими я хочу, чтобы выросли дети. И какими я хочу, чтобы были коллеги. Про коллег многое можно поменять - настроение и многое другое.
Рефлексия - избавляет от невозможности делать выбор - потмоу что уже подумал. Про профессиональную жизнь, про личную жизнь. И если подерсусь с девопсом - будет запланирвоанная драка. Рефлексия: личностная, коммуникативная, интеллектуальная (прокурчивание в голове сценариев). Подростка часто надо оставить впокое - гормоны бушуют. И коллегу тоже надо оставить в покое - эмоции, другие факторы. Рефлексия - свобола разговаривать: получать обратную связь, задавать любые вопросы, спокойно относитсья к чужим слабостям - потмоу что знаю свои. Не сотрудники, не коллеги, а Люди, и они хотят на работу.
❤3👍2
Инициатива - шило в одном месте. Который никогда не сидит, который все попробовал м уже рассказывает про то, что вы только узнали. Шило, любознательность и еще - особая форма ответственности. Хочу пить большими глотками, терпеть не могу будущее, в котором все знаю, но никому не нужен. И чтобы там не оказаться - учусь кайфовать. И если человек хочет писать код - не вытаскивайте на митапы. А есть те, кто накопил много знаний, а его не берут на митапы, потому что куча текучки - освободите. Если отправляем человека учиться - чтобы его не отвлекали во время учебы.
Нужно ли меня выпинывать из зоны комфорта, чтобы расти, или я выхожу сам? Этот вопрос задаешь, это меняется со временем. В новой сфере первое время может быть тяжело, потмоу что много информации. Но в любой сфере есть кайф от результата - потом. Серфер - много раз падает, захлебывается. А потом впервые едет на доске с небольшой скорости. И так же ты впервые выходишь с инициативой, сам и тебе легко, оно получается.
До тех пор, пока центр жизни - я, я буду ничтожен. А вот когда мир людей, а ты - часть - энергия бесконечна. Когда приходишь домой после многих дней без выходных, и ты счастлив, потому что сделал. Друзья и коллеги - синонимы, потому что это люди, с которыми делю свой кайф.
Это все дает особую образованность: есть данные, их проанализировал, знаю когда говорить, когда молчать, когда делать, когда думать, когда ждать. Пока жизнь не любит - значит не прочитал доку. Потому что следование доке делает тебя счастливым. Никто не Стив Джобс. Мы простые люди. Но если мы будем пить жизнь большими глотками - жизнь будет норм.
Вопрос: надо ли нанимать психолога, чтобы разбираться с ошибками. Ответ: я ненавижу современную психологию, потому что она эгоцентрична. Если психолог реально поможет строить команды - да. Но вообще надо идти самому. История семьи: в 22 года женился на женщине своей мечты, и они сделали семью, и это было тяжело, и был год, когда думал, может остановиться, и психологи говорили "не мучьте друг друга" - их нафиг, он шел за помощью.
В тяжелый момент жизни: рефлексия, планирование: кто такой, что могу, кого могу позвать на помощь. Верующие - других верующих, математики - баттл решения задач, фанаты природы - палатки, топоры и поехали.
Про смирение: есть моменты, когда надо проявить инициативу заткнуться, всех выслушать. А второй повод - есть цели команды, и если эго мешает - надо его заткнуть. Наша цель - не сделать меня великим, а поработать так, чтобы сделать проект, работа через мы.
Страдание не дает останавливать - при учебы неизбежны падения. Удовольствие - тоже не центр, команда идет и достигает, и ты - на своем месте.
Как не выгорать? Ответ: выгорание чаще всего от того, что тебя впинывали. Выгорают те, кого заставляли работы или дома фигня. Надо идти самому. Это тяжело. Но там не будет выгорания.
Нужно ли меня выпинывать из зоны комфорта, чтобы расти, или я выхожу сам? Этот вопрос задаешь, это меняется со временем. В новой сфере первое время может быть тяжело, потмоу что много информации. Но в любой сфере есть кайф от результата - потом. Серфер - много раз падает, захлебывается. А потом впервые едет на доске с небольшой скорости. И так же ты впервые выходишь с инициативой, сам и тебе легко, оно получается.
До тех пор, пока центр жизни - я, я буду ничтожен. А вот когда мир людей, а ты - часть - энергия бесконечна. Когда приходишь домой после многих дней без выходных, и ты счастлив, потому что сделал. Друзья и коллеги - синонимы, потому что это люди, с которыми делю свой кайф.
Это все дает особую образованность: есть данные, их проанализировал, знаю когда говорить, когда молчать, когда делать, когда думать, когда ждать. Пока жизнь не любит - значит не прочитал доку. Потому что следование доке делает тебя счастливым. Никто не Стив Джобс. Мы простые люди. Но если мы будем пить жизнь большими глотками - жизнь будет норм.
Вопрос: надо ли нанимать психолога, чтобы разбираться с ошибками. Ответ: я ненавижу современную психологию, потому что она эгоцентрична. Если психолог реально поможет строить команды - да. Но вообще надо идти самому. История семьи: в 22 года женился на женщине своей мечты, и они сделали семью, и это было тяжело, и был год, когда думал, может остановиться, и психологи говорили "не мучьте друг друга" - их нафиг, он шел за помощью.
В тяжелый момент жизни: рефлексия, планирование: кто такой, что могу, кого могу позвать на помощь. Верующие - других верующих, математики - баттл решения задач, фанаты природы - палатки, топоры и поехали.
Про смирение: есть моменты, когда надо проявить инициативу заткнуться, всех выслушать. А второй повод - есть цели команды, и если эго мешает - надо его заткнуть. Наша цель - не сделать меня великим, а поработать так, чтобы сделать проект, работа через мы.
Страдание не дает останавливать - при учебы неизбежны падения. Удовольствие - тоже не центр, команда идет и достигает, и ты - на своем месте.
Как не выгорать? Ответ: выгорание чаще всего от того, что тебя впинывали. Выгорают те, кого заставляли работы или дома фигня. Надо идти самому. Это тяжело. Но там не будет выгорания.
👍3❤2
#teamlead Олег Федоткин. Как руководителю внедрять изменения, чтобы двигать команду вперед и ускорять работу. Доклад начался с примеров резкого внедрения инноваций "с первого числа", сверху TopDownб которые часто проваливаются. И рассказ про Теорию диффузии инноваций, которая позволяет придти к успеху. Придумал Evetett Rogers, идея в том, чтобы разделить на пять групп вовлечения: инноваторы (3), ранние последователи (13), раннее большинство (34), позднее большинство (34), лаггарды (16). Если рассмотреть IDE, то инноваторы сидят на beta, ранние последователи (адоптеры) видят инновации как средство достижения успеха и обновляются сразу после релиза, раннее большинство узнает из новостей и обновляется около месяца, позднее большинство узнает от коллег и обновляется за 3-4 месяца, а лаггарды сидят на старом до последнего, пока могут. И надо последовательно захватывать эти группы, а не внедрять сразу для всех. Тогда инновация действует в отдельных командах, отдельные сотрудники разделяют и поддерживают, есть обратная связь.
У этих групп - разная логика принятия решений об инновации. Предположим, есь новый фреймворк вместоRuby of Rails. Инноваторам надо придти, показать что есть, и там должно быть что-то новое, чего нет у остальных. Ранним адоптерам - что обновлась стабильная версия, и неплохо, если фреймворк в инфополе представляют как новый шаг. Чтобы привлечь раннее большинство, надо прокатиться на пару конференций, выпустить статьи и позиционировать как возможную замену. А позднее большинство пойдет, когда фреймворк уже его активно используют, и люди боятся отстать от поезда. Лаггардов тащить не надо, придут сами когда-нибудь. Инноваторам и ранним адоптерам важнее суть иннвации, а для большинства работает пhедставление, а не суть, и надо по-другому представлять.
Если рассмотреть более системно, то есть атрибуты инновации.
* Сравнительное преимущество - что я получу.
* Совместимость - от чего придется оказаться
* Сложность - сколько времени потратить на обучение и начать использование
* Пробуемость, traiability - как сложно попробовать
* Заметность - сколько людей вокруг используют
Разным сегментам важны разные атрибуты.
* Инноваторы и ранние: сравнительное преимущество и trialability. Go взлетел, потому что много нового и можно попробовать в браузере
* Ранее большинство - разумная Сложность и Заметность
* Позднее большинство: Заметность и Совместимость.
В докладе был ряд примеров внедрения инноваций - до того как Олег узнал об этой системе, в подходе op-Down с разными вариациями, и уже после этого, про успешное внедрение системы тестирования производительности на базе k6.
Подход применим почти всегда, но надо учитывать, что он медленный. Так что если у вас жесткие сроки, например, от безопасников, то тут надо директивно.
У этих групп - разная логика принятия решений об инновации. Предположим, есь новый фреймворк вместоRuby of Rails. Инноваторам надо придти, показать что есть, и там должно быть что-то новое, чего нет у остальных. Ранним адоптерам - что обновлась стабильная версия, и неплохо, если фреймворк в инфополе представляют как новый шаг. Чтобы привлечь раннее большинство, надо прокатиться на пару конференций, выпустить статьи и позиционировать как возможную замену. А позднее большинство пойдет, когда фреймворк уже его активно используют, и люди боятся отстать от поезда. Лаггардов тащить не надо, придут сами когда-нибудь. Инноваторам и ранним адоптерам важнее суть иннвации, а для большинства работает пhедставление, а не суть, и надо по-другому представлять.
Если рассмотреть более системно, то есть атрибуты инновации.
* Сравнительное преимущество - что я получу.
* Совместимость - от чего придется оказаться
* Сложность - сколько времени потратить на обучение и начать использование
* Пробуемость, traiability - как сложно попробовать
* Заметность - сколько людей вокруг используют
Разным сегментам важны разные атрибуты.
* Инноваторы и ранние: сравнительное преимущество и trialability. Go взлетел, потому что много нового и можно попробовать в браузере
* Ранее большинство - разумная Сложность и Заметность
* Позднее большинство: Заметность и Совместимость.
В докладе был ряд примеров внедрения инноваций - до того как Олег узнал об этой системе, в подходе op-Down с разными вариациями, и уже после этого, про успешное внедрение системы тестирования производительности на базе k6.
Подход применим почти всегда, но надо учитывать, что он медленный. Так что если у вас жесткие сроки, например, от безопасников, то тут надо директивно.
👍2
#teamkead Мира Петрунько из Аурига. Работа с китайскими партнерами: культурные особенности. Доклад - эмпирика кросскультурного общения с китайскими коллегами. Там многое по-другому, и сначала вызывает возмущение. В презентации- много текстов и объяснений, если тема интересует - есть смысл ее выкачать и читать, презентации скоро будут опубликованы. В начале - сравнительная таблица Запад - Китай, которую я разворачиваю в текст и привожу в сокращении.
* Цель: Запад - результат, путь - второстепенен; Китай - главное поиск пути, результат - побочное следствие правильного процесса (пути)
* Процесс: Запад - доказательство правоты, победа; Китай - поиск истины тяжел, надо полагаться на торг. Процесс может быть не коротким, его нельзя резко обрывать для ускорения. Вопрос сохранения лица, эта концепция пронизывает все. Даже в сложной ситуации "позволь сохранить свое лицо", реализуется через торг. Нельзя позволить радикальных утверждение и рациональных утверждений. Вперед, назад, по диагонали - варьруют позицию.
* Восприятие картины мира: Китай - через систему в целом, Запад - детали. Есть эксперименты, показывали картинки и снимали движение зрачков: западный человек начинает с центра ,потом вокруг, а китайцы - как раз вокруг, а не в центре.
* Роль в социуме: Запад - персональные достижения; Китай - служение, хорошо то, что хорошо для группы, даже если вредит личным интересам.
* Связи в обществе: Запад - социальный капитал, Китай - guanxi, принадлежность группы
* Выстраивание отношений: Запад - презумпция доверия, Уитай - презумпция недоверия, то, что достоин доверия - надо доказать
guanxi - связь между людьми на основе доверия, в ходе которой оказывают услуги друг другу и помощь не в ущерб другим, тем более государству. Принадлежность к определенной группе и большая зависимость, родственные связи, отношения с множеством людей. Имеет значение не только количество рекомендаций, но и многообразие. Отличается от системы социального капитала или даже блата - потому что мы рассуждаем в категорий индивидуальных целей.
Посредник - принципиально важная роль. Надо его найти, и важно, чтобы посредником был китаец или кто-то долго живущий, кто чувствует людей на уровне мимики и другой эмпирики. Посредник лучше, если знает китайский. Если вы на встрече с несколькими китайцами, они могут перейти с английского на китайский и разговаривать о чем угодно, и хорошо, если посредник его знает, но не афиширует.
Встречи и позиционирование коллег
* Формирование делегации с учетом состава с китайской стороны
* визитные карточки, начинается с обмена в начале встречи. Присть только на английском, переводы фамилий и имен на китайский - очень тонкая тема, перевод идет через образы, и это создает коннотации.
* максимум своих регалий, которые есть, вплоть до "грамотность с детского сада" (утрировано).
* когда знакомитесь, ктиаец хочет услышать не как вас зовут, а какая должность.
* всегда "господин директор Иванов"
* сначала фамилия, потом имя
* костюм, строгий, даже в жару 40, иначе - пренебрежение
* приветствие - аккуратно
Китайцы для облегчения могут менять имена на английские, они могут быть созвучны их настоящим именам, и иногда бизнес-имя присваивается не человеку, а должности. Безопаснее обращаться к партнеру по бизнес-имени. Обращаться на китайском - только если уверены, что правильно произносите. А там будет плохо, там 4 тона. Не поленитесь десяток раз переспросить правильно ли вы произносите. Китаец будет слышать неправильно, но он не будет поправлять - это не принято, потому что тот, кого поправляют - теряет лицо, и кто поправляет - тоже теряет лицо, но вычитать баллы из кармы отношений они будут.
Ужин - неотъемлемая часть оффлайн-коммуникации. Отказ - оскорбление. Заказывают - на всех, любят спаивать, надо быть готовым много постов. Во второй половине начинают курить, и предложение сигареты - признак доверия, а если сигарету бросили - это переход "на ты".
* Цель: Запад - результат, путь - второстепенен; Китай - главное поиск пути, результат - побочное следствие правильного процесса (пути)
* Процесс: Запад - доказательство правоты, победа; Китай - поиск истины тяжел, надо полагаться на торг. Процесс может быть не коротким, его нельзя резко обрывать для ускорения. Вопрос сохранения лица, эта концепция пронизывает все. Даже в сложной ситуации "позволь сохранить свое лицо", реализуется через торг. Нельзя позволить радикальных утверждение и рациональных утверждений. Вперед, назад, по диагонали - варьруют позицию.
* Восприятие картины мира: Китай - через систему в целом, Запад - детали. Есть эксперименты, показывали картинки и снимали движение зрачков: западный человек начинает с центра ,потом вокруг, а китайцы - как раз вокруг, а не в центре.
* Роль в социуме: Запад - персональные достижения; Китай - служение, хорошо то, что хорошо для группы, даже если вредит личным интересам.
* Связи в обществе: Запад - социальный капитал, Китай - guanxi, принадлежность группы
* Выстраивание отношений: Запад - презумпция доверия, Уитай - презумпция недоверия, то, что достоин доверия - надо доказать
guanxi - связь между людьми на основе доверия, в ходе которой оказывают услуги друг другу и помощь не в ущерб другим, тем более государству. Принадлежность к определенной группе и большая зависимость, родственные связи, отношения с множеством людей. Имеет значение не только количество рекомендаций, но и многообразие. Отличается от системы социального капитала или даже блата - потому что мы рассуждаем в категорий индивидуальных целей.
Посредник - принципиально важная роль. Надо его найти, и важно, чтобы посредником был китаец или кто-то долго живущий, кто чувствует людей на уровне мимики и другой эмпирики. Посредник лучше, если знает китайский. Если вы на встрече с несколькими китайцами, они могут перейти с английского на китайский и разговаривать о чем угодно, и хорошо, если посредник его знает, но не афиширует.
Встречи и позиционирование коллег
* Формирование делегации с учетом состава с китайской стороны
* визитные карточки, начинается с обмена в начале встречи. Присть только на английском, переводы фамилий и имен на китайский - очень тонкая тема, перевод идет через образы, и это создает коннотации.
* максимум своих регалий, которые есть, вплоть до "грамотность с детского сада" (утрировано).
* когда знакомитесь, ктиаец хочет услышать не как вас зовут, а какая должность.
* всегда "господин директор Иванов"
* сначала фамилия, потом имя
* костюм, строгий, даже в жару 40, иначе - пренебрежение
* приветствие - аккуратно
Китайцы для облегчения могут менять имена на английские, они могут быть созвучны их настоящим именам, и иногда бизнес-имя присваивается не человеку, а должности. Безопаснее обращаться к партнеру по бизнес-имени. Обращаться на китайском - только если уверены, что правильно произносите. А там будет плохо, там 4 тона. Не поленитесь десяток раз переспросить правильно ли вы произносите. Китаец будет слышать неправильно, но он не будет поправлять - это не принято, потому что тот, кого поправляют - теряет лицо, и кто поправляет - тоже теряет лицо, но вычитать баллы из кармы отношений они будут.
Ужин - неотъемлемая часть оффлайн-коммуникации. Отказ - оскорбление. Заказывают - на всех, любят спаивать, надо быть готовым много постов. Во второй половине начинают курить, и предложение сигареты - признак доверия, а если сигарету бросили - это переход "на ты".
На первых встречах не принято делать подарки, даже формальные. Желательно на ужин позвать партнера-европейца, знающего китаец, но не афишировать. Если китайская сторона пригласила на ужин, то можно незаметно, без явного предложения, его оплатить. Не соглашаться на массаж, специальный массаж, караоке - это с женщинами. А это - уголовно наказуемо.
Переговоры
* Только с руководителями, которые имеют право принимать решения. Это далеко не так, хотя человек может делать вид, это - часть торга.
* Строгая субординация, соразмерный при коммуникации.
* В Ките роль начальников размыто, но малая часть людей могут реально принимать решения
* Двойные стандарты для своих и чужих
* Сохранить лицо. Китайцы не любят крайностей, открытого антагонизма, открытой конфронтации. Очень резко могут заявлять негативно. Хотя может быть часть торга, но тогда это делают НЕ топы. И можно торговаться. И нельзя самим быть категоричными.
* Имя и репутация превыше всего, даже денег.
* Плохой и хороший полицейский
* Не покупаться на вежливость
* Не взывать к эмоциям и не быть мягкими. Призыв к эмоциям - признак слабости.
* Не поддавайтесь на эмоции, весьма часто можно наблюдать, как два китайца вступают в конфликт, а реально идет разговор.
* Всегда будут пытаться передоговориться, попробовать выйти за рамки и посмотреть реакцию, сдвинуть какой-то баланс. И тут - никакого злого умысла, это просто инструмент торга.
* Они стараются манипулировать чувством вины.
* Никогда не скажут "нет", признаком может быть ужесточение позиции.
* Не стоит использовать цифру 4. Даже 4 этажа может не существовать в доме.
* Сиеста. Не во всех компаниях это есть, но часто встречается и лучше уточнить - есть варианты, обычно 13-15 и до 16
* Бесконечный чай.
Вопрос: если рядовой сотрудник саботирует - это он карьеру строит, как индусы? Ответ: нет, чаще всего сценарий согласован руководителем, это способ передоговориться.
Когда китайцы видят, что делаешь им шаг навстречу - то они это оценивают.
Что делать, если не совпадают уровни делегаций? В две стороны: неожиданно приехал высокий босс, или принимает клерк. Ответ: по ситуации, но явно это осознанно, могут "подержать в предбаннике", либо наоборот, показать что интерес ушел.
Вопрос: а как всякие раскачки соотносится с сохранением лица? Ответ: есть фактор кто кому нужнее. А еще сценарий провокации: вызвать реакцию, а потом наказать. Создать ситуацию, которая в рамках, вызвать эмоциональную реакцию - чтобы лицо потеряли вы. Но вообще детально пояснить, что вкладывается в понятие "потерять лицо", и что полагается допустимым, а что - нет - не просто.
Переговоры
* Только с руководителями, которые имеют право принимать решения. Это далеко не так, хотя человек может делать вид, это - часть торга.
* Строгая субординация, соразмерный при коммуникации.
* В Ките роль начальников размыто, но малая часть людей могут реально принимать решения
* Двойные стандарты для своих и чужих
* Сохранить лицо. Китайцы не любят крайностей, открытого антагонизма, открытой конфронтации. Очень резко могут заявлять негативно. Хотя может быть часть торга, но тогда это делают НЕ топы. И можно торговаться. И нельзя самим быть категоричными.
* Имя и репутация превыше всего, даже денег.
* Плохой и хороший полицейский
* Не покупаться на вежливость
* Не взывать к эмоциям и не быть мягкими. Призыв к эмоциям - признак слабости.
* Не поддавайтесь на эмоции, весьма часто можно наблюдать, как два китайца вступают в конфликт, а реально идет разговор.
* Всегда будут пытаться передоговориться, попробовать выйти за рамки и посмотреть реакцию, сдвинуть какой-то баланс. И тут - никакого злого умысла, это просто инструмент торга.
* Они стараются манипулировать чувством вины.
* Никогда не скажут "нет", признаком может быть ужесточение позиции.
* Не стоит использовать цифру 4. Даже 4 этажа может не существовать в доме.
* Сиеста. Не во всех компаниях это есть, но часто встречается и лучше уточнить - есть варианты, обычно 13-15 и до 16
* Бесконечный чай.
Вопрос: если рядовой сотрудник саботирует - это он карьеру строит, как индусы? Ответ: нет, чаще всего сценарий согласован руководителем, это способ передоговориться.
Когда китайцы видят, что делаешь им шаг навстречу - то они это оценивают.
Что делать, если не совпадают уровни делегаций? В две стороны: неожиданно приехал высокий босс, или принимает клерк. Ответ: по ситуации, но явно это осознанно, могут "подержать в предбаннике", либо наоборот, показать что интерес ушел.
Вопрос: а как всякие раскачки соотносится с сохранением лица? Ответ: есть фактор кто кому нужнее. А еще сценарий провокации: вызвать реакцию, а потом наказать. Создать ситуацию, которая в рамках, вызвать эмоциональную реакцию - чтобы лицо потеряли вы. Но вообще детально пояснить, что вкладывается в понятие "потерять лицо", и что полагается допустимым, а что - нет - не просто.
❤1👍1
#teamlead Евгений Идзиковский. Прикладная осознанность. Рассказ о том, как в цепочку быстрых реакций вставить осознанную оценку ситуации. При том, что осознанность не должна быть включена постоянно, на это не хватит ресурсов, и возможности - нельзя быть таким медленным все время. Но вот если есть проблемные ситуации, то их надо анализировать, понимать где в них баг и дальше - что с этим багом делать.
Лучшая метафора для осознанности - диспетчер задач. И там много процессов, на слайде пример: Хочу спать, Мысли о еде, Воспоминания о бывшей, Украли велосипед из детства, Работа, Ипотека, Птица за окном, навязчивая песенка. И хотелось бы этим управлять, что-то выключать, что-то включать.
Проблемные ситуации.
* Что-то делать нужно, и ты даже как бы хочешь - но не делаешь. Прокрастинируешь.
* Чего-то НЕ хочется, но залипаешь. И бросать люди не хотят, но хотят поменьше, управляемо. Понимаешь, что сейчас - не время. Но делаешь.
* Не то: делаешь работу, но не ту, говоришь, но не то.
Все задачи - не переходе от мыслей к действию. Есть модель: Сигнал -> Эмоции и Мысли (2 квадратика) -> Поведение. Задача психики - обработать входящие сигналы и превратить в действия. Животные - не мыслят - так как мыслим мы - не образуют текстовые конструкции. Кошка не мыслит "вот хозяин пришел". Идет сигнал, классифицирует, ставит тэг - чувство, потом выбирает стандартную реакцию по паре (категория, чувство) и реагирует. Реакции не прошиты, формируется обучением. Психика умеет обучаться в режиме реального времени. И отклики - они стандартные. Страх, Вина, Интерес, Обида - как отклик на стандартные ситуации.
Мы думаем, что "возникла опасная ситуация - я испугался". Реально происходит наоборот: мы не боимся, потому что столкнулись с опасностью. Наоборот, мы столкнулись с ситуацией, проанализировали, повесили ярлык "страх" - и узнали, что ситуация опасная. А потом идет рационализация. Например, есть друг, который боится маленьких собак. Вы идете с ним по улице, увидели, он испугался, вы спрашиваете "Почему?" - он по разному рационально отвечает, все вроде правильно, но не цепляет. Аналогично с обидами - мы обиделись не потому что кто-то нам нанес обиду, а потому, что ситуация была классифицирована как обидная. "Да, они не хотели обидеть, но мне обидно" - потому что на ситуацию повесили ярлык чувства.
Какие проблемы? Психика ошиблась и повесила неверное чувство. Или выдала неверную мысль. Человеку закрадывается мысль "я - еж" и куча доказательств - черная одежда, люблю мясо и т.п., но ежом не станешь. А вот если мысль "я некомпетентен" - вполне можеim поверить в рационализацию.
Это механизм на дикую природу. Если из пещеры может быть медведь, не надо проверять, надо убегать. Если увидел еду - ешь, а то другие съедят. Его нельзя изменить, но на него можно влиять. Автомобиль, по трассе, лампочка "проверить двигатель". Если не знаешь про автомобиле - то быстро в сервис, мало ли что. Мастер открывает капот, смотрит, говорит "с двигателем все прекрасно, только проводок коротит, тут поменять не могу". И вы едете дальше, лампочка горит, но вы спокойны. Так и с психикой. Когда вы поймали психику на ошибке категоризации, то чувство не пропадет, но влияние на выбор поведения - ослабнет, можно выбрать другое.
Вторая ситуация: чувство - верное, но неверное поведение. Например, вас хвалят, а вы вместо "спасибо" говорите "да нет, я ничего не сделал". Это проще, надо найти альтернативу, и дальше сознательно так пробовать, постепенно будет автомат.
Лучшая метафора для осознанности - диспетчер задач. И там много процессов, на слайде пример: Хочу спать, Мысли о еде, Воспоминания о бывшей, Украли велосипед из детства, Работа, Ипотека, Птица за окном, навязчивая песенка. И хотелось бы этим управлять, что-то выключать, что-то включать.
Проблемные ситуации.
* Что-то делать нужно, и ты даже как бы хочешь - но не делаешь. Прокрастинируешь.
* Чего-то НЕ хочется, но залипаешь. И бросать люди не хотят, но хотят поменьше, управляемо. Понимаешь, что сейчас - не время. Но делаешь.
* Не то: делаешь работу, но не ту, говоришь, но не то.
Все задачи - не переходе от мыслей к действию. Есть модель: Сигнал -> Эмоции и Мысли (2 квадратика) -> Поведение. Задача психики - обработать входящие сигналы и превратить в действия. Животные - не мыслят - так как мыслим мы - не образуют текстовые конструкции. Кошка не мыслит "вот хозяин пришел". Идет сигнал, классифицирует, ставит тэг - чувство, потом выбирает стандартную реакцию по паре (категория, чувство) и реагирует. Реакции не прошиты, формируется обучением. Психика умеет обучаться в режиме реального времени. И отклики - они стандартные. Страх, Вина, Интерес, Обида - как отклик на стандартные ситуации.
Мы думаем, что "возникла опасная ситуация - я испугался". Реально происходит наоборот: мы не боимся, потому что столкнулись с опасностью. Наоборот, мы столкнулись с ситуацией, проанализировали, повесили ярлык "страх" - и узнали, что ситуация опасная. А потом идет рационализация. Например, есть друг, который боится маленьких собак. Вы идете с ним по улице, увидели, он испугался, вы спрашиваете "Почему?" - он по разному рационально отвечает, все вроде правильно, но не цепляет. Аналогично с обидами - мы обиделись не потому что кто-то нам нанес обиду, а потому, что ситуация была классифицирована как обидная. "Да, они не хотели обидеть, но мне обидно" - потому что на ситуацию повесили ярлык чувства.
Какие проблемы? Психика ошиблась и повесила неверное чувство. Или выдала неверную мысль. Человеку закрадывается мысль "я - еж" и куча доказательств - черная одежда, люблю мясо и т.п., но ежом не станешь. А вот если мысль "я некомпетентен" - вполне можеim поверить в рационализацию.
Это механизм на дикую природу. Если из пещеры может быть медведь, не надо проверять, надо убегать. Если увидел еду - ешь, а то другие съедят. Его нельзя изменить, но на него можно влиять. Автомобиль, по трассе, лампочка "проверить двигатель". Если не знаешь про автомобиле - то быстро в сервис, мало ли что. Мастер открывает капот, смотрит, говорит "с двигателем все прекрасно, только проводок коротит, тут поменять не могу". И вы едете дальше, лампочка горит, но вы спокойны. Так и с психикой. Когда вы поймали психику на ошибке категоризации, то чувство не пропадет, но влияние на выбор поведения - ослабнет, можно выбрать другое.
Вторая ситуация: чувство - верное, но неверное поведение. Например, вас хвалят, а вы вместо "спасибо" говорите "да нет, я ничего не сделал". Это проще, надо найти альтернативу, и дальше сознательно так пробовать, постепенно будет автомат.
Итак. Если что-то пошло не так, то
* Что я чувствую, что я думаю? В 90% вы знаете, в 10% будут проблемы, но это навык, которому можно научиться - видеть процессы.
* То, что происходит внутри эмоционально - соответствует реальности или нет? Вы привыкли, что да, но может быть и нет, в этом помогают разобраться. Если проблема, то 95% ошибка именно на этом шаге. Мозг не умеет мыслить вероятностями, и научить его в автомате нельзя, только считать, и много ошибок из неверной оценке вероятностей, по разовым прецедентам с эмоциональными маркерами.
* Соответствует ли моя реакция моим целям? Если не соответствует - берем паузу и меняем.
И идет медленная схема: сигнал - эмоциональная категоризация - осмысление - принятие решения - реакция - поведение.
Проблемы:
* Это медленно, только одна ситуация в день. Но если каждый день, то 14 ситуаций за две недели, а их не больше.
* В мозгу - ад, ты всякие воспоминания о ситуациях. Эта техника не для того, чтобы вычищать. Но ты постепенно учишься блокировать неуместные мысли.
* Чувство все равно перетягивает канат. Если по 10-бальной шкале, то осознанность работает, пока чувство силы 6-7, если больше - тяжело.
* Что я чувствую, что я думаю? В 90% вы знаете, в 10% будут проблемы, но это навык, которому можно научиться - видеть процессы.
* То, что происходит внутри эмоционально - соответствует реальности или нет? Вы привыкли, что да, но может быть и нет, в этом помогают разобраться. Если проблема, то 95% ошибка именно на этом шаге. Мозг не умеет мыслить вероятностями, и научить его в автомате нельзя, только считать, и много ошибок из неверной оценке вероятностей, по разовым прецедентам с эмоциональными маркерами.
* Соответствует ли моя реакция моим целям? Если не соответствует - берем паузу и меняем.
И идет медленная схема: сигнал - эмоциональная категоризация - осмысление - принятие решения - реакция - поведение.
Проблемы:
* Это медленно, только одна ситуация в день. Но если каждый день, то 14 ситуаций за две недели, а их не больше.
* В мозгу - ад, ты всякие воспоминания о ситуациях. Эта техника не для того, чтобы вычищать. Но ты постепенно учишься блокировать неуместные мысли.
* Чувство все равно перетягивает канат. Если по 10-бальной шкале, то осознанность работает, пока чувство силы 6-7, если больше - тяжело.
👍4❤1
#teamlead Татьяна Гаврилова. Ошибки визуального мышления: диагноз или точка роста? Визуальное мышление - способность ясно концептуально выражать свои знания, это не про картины, которые рисуют художники. И это был замечательный доклад, как делать визуальные представления, схемы, делать их ясными. Фокус был на mind map и концептуальные карты, но было много других диаграмм. И в большом количестве были примеры диаграмм с ошибками, которые Татьяна комментировала. Понятно, что примеры без картинки пересказывать бесполезно, так что дальше - записанные тезисы, и они не дадут впечатление о полном содержании доклада. А еще в презентации много содержательных слайдов, которые Татьяна не рассказвала, ее можно использовать как справочник. Например, типы диаграмм для разных видов знаний.
Два режима работы мозга: сфокусированный - когда сосредотачиваешься на задаче, фрагменте и Рассеянный - о том, чтобы увидеть картину в целом, не углубляться.
Рисование - способ нарисовать картину в целом. Рисование - способ сжатия информации. Легко рисовать очевидное. Но вот есть неявные знания tacit knowledge - их рисовать и прояснять сложнее. Картинка не заменяет язык, она является подставкой, помощью, палочкой для языка.
Картинки - чтобы пояснять неоднозначность. Концептуальная карта - разметка предложения. Правда, не все понимают. На встрече с теми, кто слушал курс: "Применяете визуальные модели? - Да. - А что так невесело? - Да пришлось двоих уволить, дураками оказались." Я тут отмечу, что есть такая компетенция - разметка текста, когда ты читаешь текст и превращаешь его в структуру: выделяешь понятия, присваиваешь им типы, различаешь характер взаимоотношений между объектами, не путаешь типы и экземпляры и так далее. И у одних людей она есть, а другие воспринимают тексты просто как нарратив, историю, последовательность слов. Концептуальная карта - она проявляет эту разметку, и помогает обсуждать с другими.
Любая карта, даже плохая - лучше, чем отсутствие. Она все равно показывает, что вы имели ввиду.
Важно не только что нарисовали, но и что и как написали: число слов, размер шрифта, цвета, образы.
Разбиение понятие - равновеликое, одна гранулярность. Тут прокалываются. 7+-2 уровней. А теперь оперативная память стала работать хуже, 5+-2. Концептуальный баланс: один тип отношений, глубина ветвей одинакова, картинка - симметрична.
Ошибки. 1 рода, серьезные: семантические, смысловые - вы неверно или неполно видете область, к которой рисуете карту, и систеные - вы плохо структурируете область. Ошибки 2 рода синтаксические и эргономические - это погрешности, они ухудшают восприятие.
Строить можно сверху-вниз, от классификации, или снизу-вверх - от перечня объектов.
Глубина понимания
* охватывать все элементы, а не выборочные фрагменты
* хорошее обобщение
* логика и прозрачность замысла
* правила бьюзена - об оформлении
* бритва Оккама - не множить сущности без необходимости, не перегружайте 3-5 исходящих
Принцип хорошего гештальта. Закон прегнантности Макс Вертгеймер. Организация любой структуры должна быть так хороша, как только можно. Законы близости, сходства, включения.
Почему знания - диаграмма Ишикавы. Это вывернутая интеллект-карта. Тоже иерархична. Как-знания - блок схемы. Деревья решений - подумать какие есть варианты.
Скрайбинг - красиво оформлено, каждый фрагмент сделан нормально, но в целом - не структурировано.
8 типов интеллекта. Картинки позволяют использовать лингвистический и визуальный.
Разное восприятие в разных культурах. Она читала лекции в Катаре, преподавала китайским студентам. У арабов - европейское мышление. А вот у китайцев из-за иероглифического мышления все сложно, она не понимает их карты.
Разница мужчин и женщин. У мужчин - выше поленезависимость, выделить главное из шума. А у женщин - лучше детализация. Можчины стремятся к новому, женщины - лучше сохраняют старое, умеют с ними работать.
В mindmap лучше избегать связей, это взгляд сверху. А вот для тонкостей - концептуальные карты, там сложнее.
Два режима работы мозга: сфокусированный - когда сосредотачиваешься на задаче, фрагменте и Рассеянный - о том, чтобы увидеть картину в целом, не углубляться.
Рисование - способ нарисовать картину в целом. Рисование - способ сжатия информации. Легко рисовать очевидное. Но вот есть неявные знания tacit knowledge - их рисовать и прояснять сложнее. Картинка не заменяет язык, она является подставкой, помощью, палочкой для языка.
Картинки - чтобы пояснять неоднозначность. Концептуальная карта - разметка предложения. Правда, не все понимают. На встрече с теми, кто слушал курс: "Применяете визуальные модели? - Да. - А что так невесело? - Да пришлось двоих уволить, дураками оказались." Я тут отмечу, что есть такая компетенция - разметка текста, когда ты читаешь текст и превращаешь его в структуру: выделяешь понятия, присваиваешь им типы, различаешь характер взаимоотношений между объектами, не путаешь типы и экземпляры и так далее. И у одних людей она есть, а другие воспринимают тексты просто как нарратив, историю, последовательность слов. Концептуальная карта - она проявляет эту разметку, и помогает обсуждать с другими.
Любая карта, даже плохая - лучше, чем отсутствие. Она все равно показывает, что вы имели ввиду.
Важно не только что нарисовали, но и что и как написали: число слов, размер шрифта, цвета, образы.
Разбиение понятие - равновеликое, одна гранулярность. Тут прокалываются. 7+-2 уровней. А теперь оперативная память стала работать хуже, 5+-2. Концептуальный баланс: один тип отношений, глубина ветвей одинакова, картинка - симметрична.
Ошибки. 1 рода, серьезные: семантические, смысловые - вы неверно или неполно видете область, к которой рисуете карту, и систеные - вы плохо структурируете область. Ошибки 2 рода синтаксические и эргономические - это погрешности, они ухудшают восприятие.
Строить можно сверху-вниз, от классификации, или снизу-вверх - от перечня объектов.
Глубина понимания
* охватывать все элементы, а не выборочные фрагменты
* хорошее обобщение
* логика и прозрачность замысла
* правила бьюзена - об оформлении
* бритва Оккама - не множить сущности без необходимости, не перегружайте 3-5 исходящих
Принцип хорошего гештальта. Закон прегнантности Макс Вертгеймер. Организация любой структуры должна быть так хороша, как только можно. Законы близости, сходства, включения.
Почему знания - диаграмма Ишикавы. Это вывернутая интеллект-карта. Тоже иерархична. Как-знания - блок схемы. Деревья решений - подумать какие есть варианты.
Скрайбинг - красиво оформлено, каждый фрагмент сделан нормально, но в целом - не структурировано.
8 типов интеллекта. Картинки позволяют использовать лингвистический и визуальный.
Разное восприятие в разных культурах. Она читала лекции в Катаре, преподавала китайским студентам. У арабов - европейское мышление. А вот у китайцев из-за иероглифического мышления все сложно, она не понимает их карты.
Разница мужчин и женщин. У мужчин - выше поленезависимость, выделить главное из шума. А у женщин - лучше детализация. Можчины стремятся к новому, женщины - лучше сохраняют старое, умеют с ними работать.
В mindmap лучше избегать связей, это взгляд сверху. А вот для тонкостей - концептуальные карты, там сложнее.
❤2