Изменения

В пятницу 25.04 был первый раз на конференции Dump в Екатеринбурге. Впечатления в целом позитивные. Один день, много нетворкинга, 12 треков докладов и еще один круглых столов, по сути, это много конференций в рамках одной. Громадное пространство Экспо несколько разобщает, но в целом люди общаются в фойе между докладами, группы секций расположены рядом. Треки готовили отдельные команды, фактически это много конференций в одном пространстве. Фишка конференции - конференции — научный трек. Я очень жалею, что доклад Гельфанда про иммунитет как инженерную проблему шел в одно время с моим докладом, и я не попал на него. И слушал интересный доклад о развитии языка. Кстати, о языке, я засек на конференции слово вайб, которое активно используется, не только в названиях докладов (вайбкодить), но и в рассказах, оно - оно — в активном словаре. А на других конференциях, например, тимлид или sqa, после которой я пишу эти строки, я его не слышал. Любопытно.

На финише конференции я попал на замечательный доклад '''Михаила Толстого «Да он просто...»просто…»''' —  — доклад о моделях, которые помогают понимать людей. В 2019 году я делал доклад [[Модели softskill для тимлида (TeamLeadConf-2019)|Модели softskill для тимлида]] на Teamlead, в нем был обзор 7 моделей, и основной задачей было сформировать отношение к моделям как к шаблонам программирования, просто для людей, а не для кода. Тем не менее, про каждую модель было несколько слайдов, чтобы пояснить - пояснить — о чем она. Михаил модели перечислял по группам, тем не менее в рассказе каждая модель была достаточно представлена, и это - это — замечательно. При этом основная мысль в том, что модели нужны просто чтобы исследовать другого человека, подумать о нем. И абсолютно неважно, какую модель вы применяете, если модель служит исследованию. Хотя астрология - астрология — не катит, потому что она исследует не человека, а какие-то не связанные с его индивидуальностью особенности. Так вот, исследовать - исследовать — полезно. А вот клеить ярлыки - ярлыки — вредно, надо за моделями видеть человека. И еще - еще — бесполезно исследовать просто так, надо держать в фокусе задачу, которую вы решаете. И это - это — актуально, потому что на волне интереса к психологии люди все больше расходятся по полюсам: одни начинают клеить на всех ярлыки, используя поверхностно понятые модели, а другие - другие — считают, что все это просто чушь, и игнорируют. Оба отношения - отношения — неверные. Доклад признан лучшим на DUMP. А у Михаила есть канал https://t.me/tolstoymv, где он пишет на разные темы.

Я выступал в секции бизнес и системного анализа, мой доклад [[Бизнес-анализ на легаси: как погрузиться в проект? (DUMP-2025)|'''Бизнес-анализ на легаси: как погрузиться в проект?''']] фокусировался на понимании работы бизнеса и легаси-системы. Как обычно, конспекта моего доклада не будет, так что ждите запись, она будет, а пока - пока — можно смотреть докдад [[Бизнес-архитектура: от цепочки создания ценности до автоматизации бизнес-процессов (ЛАФ-2022)]] и недавно прошедший длинный вебинар [[Постановка от модели бизнеса до детального дизайна требований: как делать и кому (Вебинар 13.03.2025)]]. Но в этом докладе был отдельный фокус именно на легаси.

А теперь, как обычно, заметки по докладам. Учитывайте, что треков — 13, я мог быть только на одном. И я точно знаю, что пропустил ряд хороших докладов, потому что параллельно шли другие.

В общем, это не про реальный зоопарк из 5-10 технологий, а всего лишь про переписывание основного сайта с Vue на React. Причина - Причина — интересная, сайт на вью плохо индексировался поисковиками, и для основного сайта банка это был критичный недостаток. То, что реакт был основной технологией в банке, а на вью работала только команда сайта - сайта — лишь дополнительное соображение. На старте был супероптимизм: перепишем за квартал, максимум за два. При этом не учитывали, что поток продуктовых фич продолжит идти. И совершенно не оценили, что поток новых фич вместе с фичами по переписыванию существенно превысит мощности команды и потребует системы приоритизации, прозрачной для заказчиков - заказчиков — до переписывания команда достаточно хорошо перерабатывала поток задач и необходимости в системе приоритизации не возникало. То есть о продумывании изменений задумались не на старте переписывания, а когда уже накопилась гора задач.

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

* Охват - Охват — сколько людей затронет фича* Конверсия - Конверсия — сколько придет заявок* Трудозатраты - Трудозатраты — это оценить сложно без макетов и прототипов, поэтому экспертно поделили на мелкие доделки, типовые задачи, не типовые задачи и новые-сложные

* Ограничения системы

Так взлетело. Сейчас регулярно смотрят и пересматривают приоритеты - приоритеты — среда меняется быстро.

В целом доклад - доклад — понятный. Но жаль, что про реальный большой зоопарк я не услышал.

Глитч - Глитч — это ошибка, искажение. Так что доклад был про когнитивные искажения. Я не знаю, почему Елена решила их назвать глитчами - глитчами — по английски принятый термин cognitive biases. Еще хочу отметить, глитчи вовсе не являются прерогативами человека, ChatGPT и другие LLM системы им тоже подвержены, хотя, естественно, набор отличается. Но тема искажений компьтерного компьютерного мышления в докладе раскрыта не была. Дклад Доклад был довольно интересный, с примерами и в высоком темпе, так что пересказывать нет смысла, тем более что часть примеров надо видеть на картинке. Думаю, презентации будут выложены, иможно и можно будет посмотреть. А пока интересующиеся могут почитать [ список в вики], и сходить по статьям или про каждый из них спросить какой-нибудь GPT, попросив ссылки на исследования и другие подробности, чтобы получить качественный ответ.

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

= Владимир Напольских. Язык – Язык — это брод через реку времени =

Развитие языков - языков — точная наука, может быть самая точная из гумантарныхгуманитарных. Она показываает показывает развитие языков, как из одного языка появляется несколько. Язык - Язык — живая система, она меняется непрерывно и любой словарь устаревает за 5-10 лет. При эом этом изменения идут неравномерно в разных ареалах, а дальше переносятся за счет коммуникации. Но если на путях активного общения возникает граница, то языки начинают расходится, и вместо одного появляется два. И в пределах письменной истории этот процесс хорошо зафиксирован, мы можем мерить изменения языков, устанавливать меру схожести на основе систематических изменений, и далее, на основе этого - этого — реконструировать в прошлое языки в прошлое. Так восстанавливается не только праславянский, который был 1500 лет назад и у которого не было письменности, но и прабалтославянский, который был 2500 лет назад, и праиндоевропейский, который был 6000 лет назад. Настолько что на этом праязыке можно составлять фразы. Еще дальше вглубь - вглубь — сложнее, но на сравнительном анализе получается углубиться на 10-15 тысяч лет, до первых языков.

Правда, эту часть доклада Владимир не успел рассказать детально. Потому что в начале он достаточно подробно, с примерами, рассказывал о том, сколь разнообразных бывают языки. Фонетически разные: щелкающие звуки в кoйсанских языках, в которых, возможно, сохранились следы самых древних языков, тональные языки - языки — китайский, вьетнамский, кхмерский и другие. Это не говоря о количестве звуков, в абхазском 80+ согласных.

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

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

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

У Руслана в докладе - докладе — очень интересный ход мысли. Есть две архитектурных характеристики: coupling и cohesion, которые Руслан переводит как связность и прочность, чтобы хорошо различать. Связность (coupling) -  — показывает количество внешних связей системы, количество вызываемых им других компонент, а прочность (cohesion) характеризует количество внутренних связей между составляющими систему подсистемами. И есть статья, написанная 50 лет назад, о том, что хорошая декомпозиция - декомпозиция — это когда подсистемы слубо слабо связаны с другими, имеют низкую coupling, и сильно связаны внутри, cohesion высокий. И все логично, когда мы имеем дело с системами, имеющими физические границы, например, модулями или классами.

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

Тут возникает вопрос, а зачем архитекторы вообще проводят логические границы, выделяя ограниченные контексты или домены? А они таким образом пробуют снизить сложность. И для проверки, снижатеся снижается ли сложность от такой декомпозиции, Руслан предлагает вместо двух метрик, связности и прочности, использовать одну - одну — количество связей объектов с другими. И дальше при любой иерархической группировке признаком хорошей архитектуры будет не возрастание числа связей при подъеме по иерархии. Например, если у нас иерархия компонент - компонент — ограниченный контекст - микросервис - контекст — микросервис — класс, то вызовов из компонента других подсистем компонентов должно быть не больше, чем связей между ограниченными контекстами внутри комопнентакомпонента. И аналогично, если у нас иерархия системы - подсистемы - домены - системы — подсистемы — домены — модули, то объединение доменов в подсистемы выполняется так, чтобы связи между доменами внутри подсистемы было не меньше, чем обращений к доменам других подсистем. Раньше Руслан он говорил, что внешних связей должно быть меньше, чем внутренних, но анализ реальных архитектур побудил смягчить требование - требование — их должно быть не больше.

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

Дальше возникает вопрос - вопрос — а как эти метрики отслеживать? API Gateway позволяет это делать только на два уровня, а интересно больше. Руслан написал свой инструмент и выложил в open source. D презентации была ссылка. Можно загрузить архитектуру в c4 model или в другой нотации, при необходимости написать свой конвертер - конвертер — и дальше будет результат анализа. И там же лежит его каталог шаблонов архитектуры. И на их соблюдение - соблюдение — есть тесты. Сейчас они берут архитектуры с разных международных соревнований и смотрят метрики, разбираются.

Но основное - основное — прикладное применение. Потому что сложность архитектуры напрямую определяет трудоемкость доработок, развития кода. Поэтому важно держать ее под контролем. Этаа метрика - Эта метрика — не единственная, но одна из важных, потмоу потому что метрики взаимосвязаны.

Для архитектуры важен фак факт наличия связей, а не количество end point или rps. И для начала стоит работать с ним. Я отмечу, что тут интересный эффект получается: вот у тебя два сервиса связаны большим количеством связей, при этом вызовы рассредоточены, находятся в разных классах. Ты берешь, и выделяешь интеграционный класс, собирая в него все обращения. На связность между сервисами это не влияет, зато резко повышает количество внутренних связей - связей — появился еще один класс, к которму которому обращается много других. И метрика - метрика — выравнивается. Так что пользу выделения таких интеграционных классов метрика подтверждает. Естественно, метрика - метрика — это отправная точка для анализа, способ выделить объекты внимания, а не безусловное указание к действию. Работать на формальное соблюдение - соблюдение — точно не надо.

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

Машине не важны языки - языки — она исполняет код. А многообразие языков объясняется ограниченностью возможностей человека - человека — языки обеспечивают снижение сложности, облегчая работу с большим объемом кода. Когнитивная сложность кода определяется блоками, основные из которых - которых — циклы и серии if-elsif-else (или switch). Циклы хорошо заменяются на reduce. А вот что делать с if-elsif-else?

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

Для решения таких задач применяются мультиметоды. На уровне языка это есть в closure, Julia, частично в C#. На JS надо писать, но есть достаточно много библиотек с реализациями, Алексею нравится @arrows/multimethod, но это просто личный выбор. А если нужно, то можно написать свою по месту - месту — конструкция укладывается в десяток строк кода. Основная идея - идея — при первом обращении создается объект с парами матчер-обработчик, и оно хранится через замыкание.

В презентации было довольно много примеров - примеров — как это устроено. Для разных кейсов и фреймворков - фреймворков — vanilla, react, angular. В этом - этом — основная ценность доклада. Но пересказывать это невозможно - невозможно — надо смотреть фрагменты кода в презентации. Так что если интересно - интересно — смотрите и используйте шаблон. Профит в том, что отдельно тестируется мультиметод, и отдельно - отдельно — каждая веточка, и изменения в одной из веток не затронут другие, в отличие от больших сборок if-elsif.

Как обычно, плюшки имеют побочные эффекты. Мультиметод может дать проблемы производительности, если это не отрисовка экрана. а код, выполняемый 100-200 100—200 раз в секунду. А еще усложняет отладку - отладку — на веточки if-elsif очень ленко поставить точку останова, с мультиметодом это сложнее. Получается довольно крутая кривая обучения. И есть проблемы со строгой типизацией, в typescript базовая поддержка есть, но есть и проблемы, так как неясно, какой тип вернет матчер из-за позднего связывания. Но тут он сторонник динамики в ущерб типизации. Так чо не надо использовать повсеметно, но стоит знать и использовать там, где уместно.

Еще поскольку реализации мультиметодов использует замыкания, то могут быть проблемы с асинхронной работой. Это надо аккуратно понимать, и использвоать использовать соответствующие реализации, таких как RxJS, где мультиметоды есть.

= Михаил Толстой. «Да он просто...» - просто…» — доклад о моделях, которые помогают понимать людей =

Как я писал в начале отчета, мне очень понравился этот доклад. Основная мысль не стреляйте друг другу в ноги популярной психологией, а используйте ее для исследования людей, в коммуникации или совместной работе с которыми возникли проблемы. Эти модели помогают понять. насколько другой человек может быть не похож на тебя, подумать о нем. И если не клеить ярлыки, а исследовать, то использование моделей - моделей — конструктивно. И большинство моделей не отвергают другие, так что можно выбрать те, которые вам близки и полезных для задач. А задачи - задачи — понятные: как понять, что челвоеку человеку важно, что он хочет, ради чего готов трудиться и как сделать, чтобы он вас услышал.

Я тут хочу дополнить, что, хотя моделей множество и они совместимы, полезно понимать основания конкретных моделей, подобно тому, как используя те или иные шаблоны программирования полезно понимать, для каких классов задач они были разработаны, и в каких предположениях действуют. Есть модели, которые отражают различия в конструкции нашего мышления на уровне нейрофизиологии, есть те, в которых были выделены объективно наблюдаемые кластеры, а есть построенные по умозрительным дихотомиям или просто меняющие соответствие некоторому идеалу. И дальше я буду добавлять свои комментарии по поводу конкретных моделей. Мне как архитектору всегда было интересно построить целостное представление о личности, посмотреть на совместимость разных моделей, поэтмоу поэтому я разбирался с их основаниями, и в результате у меня получилась [[:Категория:Модель личности|серия статей '''Инженерная модель личности''']], опубликованная потом в виде книги. Свои комментарии я буду отделять от конспекта доклада.

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

Итак, для начала - начала — модели энергетического уровня.* Выгорание. Модель-аналогия, люди все-таки не горят. В модели бинарная классификация. Польза - Польза — подумали про человека, Вася стал другой, Минус - Минус — что делать - делать — не понятно, это не гранулярно, заметили, когда сгорел.* Модель батарейка. У каждого есть заряд, на каждом уровне справляетесь с задачей определенной сложности. И можно раньше среагировать на ситуацию, подбирать оптимальню оптимальную задачу. Но недостатки те же - же — не учитывают мотивацию и ти т.п п. Это про бодрость.

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

* DISC. Есть 4 склонности, и по каждой можно оценить человека. Но обычно берут одну букву, а не 4. А полезно задуматься о сколонности склонности по 4 параметрам. Я тут отмечу, что в DISC выделено не четыре объективно существующих склонности, автор нарисовал четыре типовых позиции в орг.структуре: руководитель-стратег, руководитель, ведущий в заданном направлении, автономный исполнитель и исполнитель поручнийпоручений. И дальше описал психологические характеристики. В современном ИТ позиции более разнообразны, поэтому я предпочитаю Белбина, который описывает это разнообразие. Но если вы работаете в корпоративной структуре, то там многое заявзано именно на эти позиции и DISC работает.* MBTI. 4 шкалы, дихотомия, И 16 наборов буковок. Запомнить нереально - нереально — поэтому придумали ярлыки-названия. Пока смотрите на шкалы - шкалы — это полезно. А как привесили архетип - архетип — тут же идет замена раеального реаального человека. Я тут отмечу, что Михаил смешал MBTI и соционику, у них одинаковые истоки - истоки — модель Юнга, но дальше конструкции сильно разошлись. Ярлыки-архетипы - архетипы — в соционике. А в MBTI - MBTI — вполне логичное внутреннее устройство, и не надо запоминать буковки, достаточно работать на шкалах-дихотомиях, о чем, собственнсобственно, михаил Михаил и говорит. Еще отмечу, что дихотомии MBTI, похоже, имеют нейрофизиологические основания, как измерение прокачки различных стркутур структур мышления -подобно тому, как шкала правши-левши меряет соотношение силы и умения рук, но не учитывает абсолютную силу каждой руки. * Астрология как ипология типология плоха, потому что заменяет исследования человека исследвоанием какихто исследованием каких-то формальных параметров. Для которых корреляции рс с реальным поведеним поведением людей не обнаружнообнаружено, это проверяли.* Мемные тесты - тесты — утиные истории, pixar и многое другое. Это работает при условии общего культурного контекста команды. Потмоу Потому что персонажей часто создают, как отражающих распространенные типы людей - людей — чтобы люди узнавали в них себя и знакомых. Такие тесты проще применить в компании, и меньше соблазна всерьез навесить ярлык, а это - это — важно. И сейчас есть много тестов, можно предложить пройти, потом обсудить в команде втемную, а потом обсудить с результатами тестов. Может быть интересный разговор. Но добровольность и безопасность - безопасность — важны, люди могут не принять отждествлениеотождествление, которео которое даст тест, поэтмоу поэтому не надо настаивать и надо соблюдать осторожность. * Big Five - Five — пять шкал, по которым можно оценить человека. Но я хочу отметить, что Big five меряет не нейтральное разнообразие людей без разделения на плохих и хороших, как, например, MBTI, а выдает аттестат соответствия американскому корпоративному идеалу 1980-х.

Применение типологий полезно до тех пор, пока это процесс исследования человека. Именно это прибилжает приближает к пониманию.

Я бы к этому списку добавил еще '''типологию Алексея Кулакова''', построенную на основе компьютерных игр, тем более что Алексей строил ее для объяснения тимлидам своей компании, какие бывают люди. Подробное описание - описание — [https://jetstyle.ru/articles/hexagrammaton/ в этой статье].

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

Тут отмечу, что о нейрофизиологии драйва и мотивации сейчас известно довольно много. Есть модель Хелен Фишер. Ее Михаил не упоминал, а она довольно понятная. Она говорит, что есть четыре нейрофизиологических механизма мотивации, каждой из которых соответствует свой гормон: дофамин дает счастье поиска и исследований, тестостерон - тестостерон — счастье победы и достижения цели, оскитоцин - оскитоцин — счастье эмпатии и взаимоотношенйвзаимоотношений, а серотонин - серотонин — счастье регулярной деятельности, когда ты взял задачу и сделал, потом взял следюющуюследющую. У каждого челвоека человека есть все четыре, но работают в разную силу. Интересно, что механизмам мотивации модели Хелен Фишер соответствуют типы в модели Бартла, разработанной и применяемой для вовлечения и удержания игроков в компьютерные игры задолго до исследований Хелен Фишер, которая выделяет четыре типа игроков: киллер, карьерист, тусовщик, исследователь, и это является независимым подтверждением модели. Модель объясняет, почему одни задачи нас драйвят, а другие - другие — нет. То есть показывает не только мотивацию, но соответствие задачи человеку, о чем у Михаила следующий список.

* Адизес - Адизес — разные типы задач, к которым мы склонны. Он классифицирвоал классифицировал для руководителей, но можно применять не только для них.* Белбин - Белбин — девять типов. Я хочу отметить, что Белбин тоже строиил строил модель для менеджеров, но позднее она была пренесена перенесена на ИТ. И Белбин явно говорит, что у человека есть от одной до трех предпочитаемых ролей, а не одна-единственная.Плюс от моделей в том, что вы вообще подумали о том, подходят ли задачи человеку. А не считаете, что любой может сделать любую задачу. Я, кстати, отмечу, что в ИТ есть типовыая типовая ошибка, которую хорошо описывает модель Белбина: от сотрудника, который любит придумывать свои идеи, требуют поискать решения в интернете. Белбин говорит, что это - это — разные роли, Генератор идей и Исследвоатель Исследователь ресурсов, и они редко совмещаются в одном человеке, Геенратору Генератору важны собственные идеи, когда он смотрит на чужое решение - решение — он обосновывает, почему оно точно не подойдет. Вообще у меня по модели Белбина есть [[ :Категория:Модель Белбина|много докладов и статей]].

* Эрик Берн - транзакnysq Берн — транзактный анализ, позиции родитель-взрослый-ребенок и разные коммуникации между ними.* Квадранты по стилям общения, коучинг или продажа. Если челвоек человек эксперт, а вы - вы — нет, то не советуйте ему, это бесполезно.* Типы восприятия - восприятия — по текстам, схемам, видео, истории. Как работать с 1/3 кому важно ощутить - ощутить — неявно.* Люди - сихронные Люди — синхронные или асинхронные, весь контекст или кусочком, авторизация мнения (не привел директора - директора — с тобой не разговаривают)

Типологии лидерства, помимо Адизеса.* По Левину: командовать, договариваться, ждать что сами договрятьсядоговорятся* Гоулман - Гоулман — эмоциональное лидерство: пример, задаем вопросы, ставим задачу

Итого - Итого — есть много моделей. И часто достаточно просто направить их на человека и поисследовать, проблемы решаются. А если коммуникационных проблем нет - нет — не трогайте.

Если есть задача - задача — возьмите конктерную конкретрную модельку и начинаем собирать фактуру.* ЗаписиывайтеЗаписывайте. Максимально конкретный факт + испытанные чувства + последствия (это - это — разное). Вася сказал А, вас бесит, последствий нет.* Если общаетесь и договариваетесь - договариваетесь — это фиксируйте, потмоу потому что именно тут разное

* Если трекаете известное - известное — можно просто помечать события. Потому что на разборе полетов нужны источники факта.Очень часто все завершается тут: позаписывал, и понятно. А записывать важно, потмоу потому что воспоминания работают плохо, людям свойственно лучше запоминать эмоции,а не факты, а важны именно факты.

Мотивацию. * Спросить человека про мотивацию. Не "чего хочешь"«чего хочешь». Люди иногда знают* Провести тест. ИндивдуальноИндивидуально, или можно пройти за него - него — но это про ваши представления. Можно парно и обменяться. Можно в группе - группе — мемные тесты заходят, сравнить результаты и обсудить, и еще можно сначала предложить предсказать, а потмо потом показать. Массово, от HR. Для любого теста важно, чтобы все понимали, что происходит, что добровольно, и безопасно (и при отказе и при )

* Иногда проще человеку похвалить способом, которым ты думаешь что подействует - подействует — и посмотреть. Если что - что — говоришь это случайный ништяк.

Результат всех этих стараний - стараний — лишь гипотеза, предположения о том, как человек себя поведет. Гипотезу нужно проверять. Можно сразу в бою, но лучше сначала другим способом.* Проверить об коллег. Спросить  Спросить о ваших предположений кого-то другого* Проверить про факты - факты — о записям. Скажу Васе - Васе — и как он поведет* Через "чтобы что" - «чтобы что» — я предположил, а какая задача. Иногда не надо

И не забывайте про эксперимент 2-4-6. Михаил не успел рассказать подробности, я поискал. Суть в том, что челвоекусвойственно человеку свойственно искать подтверждение своей гипотезе, а не опровержение ее. Для вас это тоже верно. Поэтому когда вы выдвинули гипотезу о другом человеке, подумайте не только о способе подтвержеднияподтверждения, но и о том, как можно опровергнуть. Об этом надо думать специально.

Ну и в заключении. Так много моделей. Почему я должен всем этим заниматься? Ответ: это же у вас проблема - проблема — кому же ее решать? Если проблем нет - нет — не занимайтесь.

* Собирайте фактуру и записывайте. "Я «Я подумаю про Петю и все пойму" - пойму» — не работает* Результат - Результат — это гипотеза, гипотезу проверяют