Я — Максим Цепков приветствую Вас на своем сайте
Now: Коммуникация при различной структуре мышления - таксономия против фолксономии
|
Я буду рад любым комментариям и обсуждениям. Авторизация для этого через регистрацию на сайте или OpenID. При желании, вы можете размещать здесь свои материалы по тематике сайта. MaksWiki содержит 678 статей IT-тематики. | |
|
Последний пост блога 2025-04-27: первый раз на DUMP - интересно В пятницу 25.04 был первый раз на конференции Dump в Екатеринбурге. Впечатления очень позитивные. Один день, много нетворкинга, 12 треков докладов и еще один круглых столов, по сути, это много конференций в рамках одной. Громадное пространство Экспо несколько разобщает, но в целом люди общаются в фойе между докладами, группы секций расположены рядом. Треки готовили отдельные команды, фактически это много конференций в одном пространстве. Фишка конференции — научный трек. Я очень жалею, что доклад Гельфанда про иммунитет как инженерную проблему шел в одно время с моим докладом, и я не попал на него. И слушал интересный доклад о развитии языка. Кстати, о языке, я засек на конференции слово вайб, которое активно используется, не только в названиях докладов (вайбкодить), но и в рассказах, оно — в активном словаре. А на других конференциях, например, Teamlead или SQAdays, после которой я пишу эти строки, я его не слышал. Любопытно. На финише конференции я попал на превосходный доклад Михаила Толстого «Да он просто…» — доклад о моделях, которые помогают понимать людей. В 2019 году я делал доклад Модели softskill для тимлида на Teamlead, в нем был обзор 7 моделей, и основной задачей было сформировать отношение к моделям как к шаблонам программирования, просто для людей, а не для кода, но про каждую модель было несколько слайдов, чтобы пояснить — о чем она. Михаил модели перечислял по группам, тем не менее в рассказе каждая модель была достаточно представлена, и это — замечательно. При этом основная мысль в том, что модели нужны просто чтобы исследовать другого человека, подумать о нем. И абсолютно неважно, какую модель вы применяете, если модель служит исследованию. Хотя астрология — не катит, потому что она исследует не человека, а какие-то не связанные с его индивидуальностью особенности. Так вот, исследовать — полезно. А вот клеить ярлыки — вредно, надо за моделями видеть человека. И еще — бесполезно исследовать просто так, надо держать в фокусе задачу, которую вы решаете. И это — актуально, потому что на волне интереса к психологии люди все больше расходятся по полюсам: одни начинают клеить на всех ярлыки, используя поверхностно понятые модели, а другие — считают, что все это просто чушь, и игнорируют. Оба отношения — неверные. Доклад признан лучшим на DUMP. А у Михаила есть канал https://t.me/tolstoymv, где он пишет на разные темы. Я выступал в секции бизнес и системного анализа, мой доклад Бизнес-анализ на легаси: как погрузиться в проект? фокусировался на понимании работы бизнеса и легаси-системы. Как обычно, конспекта моего доклада не будет, так что ждите запись, она будет, а пока — можно смотреть докдад Бизнес-архитектура: от цепочки создания ценности до автоматизации бизнес-процессов (ЛАФ-2022) и недавно прошедший длинный вебинар Постановка от модели бизнеса до детального дизайна требований: как делать и кому (Вебинар 13.03.2025). Но в этом докладе был отдельный фокус именно на легаси. А теперь, как обычно, заметки по докладам. Учитывайте, что треков — 13, я мог быть только на одном. И я точно знаю, что пропустил ряд хороших докладов, потому что параллельно шли другие. Ирина Колесникова из Точки. Навигация по зоопарку технологий: стратегии эффективного управления технологическим стеком и бэклогом задачВ общем, это не про реальный зоопарк из 5-10 технологий, а всего лишь про переписывание основного сайта с Vue на React. Причина — интересная, сайт на вью плохо индексировался поисковиками, и для основного сайта банка это был критичный недостаток. То, что реакт был основной технологией в банке, а на вью работала только команда сайта — лишь дополнительное соображение. На старте был супероптимизм: перепишем за квартал, максимум за два. При этом не учитывали, что поток продуктовых фич продолжит идти. И совершенно не оценили, что поток новых фич вместе с фичами по переписыванию существенно превысит мощности команды и потребует системы приоритизации, прозрачной для заказчиков — до переписывания команда достаточно хорошо перерабатывала поток задач и необходимости в системе приоритизации не возникало. То есть о продумывании изменений задумались не на старте переписывания, а когда уже накопилась гора задач. Как вышли из ситуации? Во-первых, разумно подошли к переписыванию. Не все по площади, а с учетом конверсии страниц и их сложность. Простые страницы перевели на тильду, это позволило сильно освободить команду. При этом сложные формы, например, форму заявки, вынесли в библиотеку в вариантах для страниц на реакте и тильде. Для повышения квалификации — обратились к комьюнити банка — воркшопы, парное программирование. И система приоритизации. Они посмотрели известные методы: RICE, Cost of delay, Weighted scoring. Не подошли, либо слишком сложно оценивать, либо не учитывали какие-то существенные параметры, из-за чего реально важные задачи не оказывались в топе. В результате они собрали свой метод на основе шести факторов.
Так взлетело. Сейчас регулярно смотрят и пересматривают приоритеты — среда меняется быстро. В целом доклад — понятный. Но жаль, что про реальный большой зоопарк я не услышал. Елена Белова. Глитчи мышления: чем человеческое мышление отличается от компьютерногоГлитч — это ошибка, искажение. Так что доклад был про когнитивные искажения. Я не знаю, почему Елена решила их назвать глитчами — по английски принятый термин 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. И для начала стоит работать с ним. Я отмечу, что тут интересный эффект получается: вот у тебя два сервиса связаны большим количеством связей, при этом вызовы рассредоточены, находятся в разных классах. Ты берешь, и выделяешь интеграционный класс, собирая в него все обращения. На связность между сервисами это не влияет, зато резко повышает количество внутренних связей — появился еще один класс, к которому обращается много других. И метрика — выравнивается. Так что пользу выделения таких интеграционных классов метрика подтверждает. Естественно, метрика — это отправная точка для анализа, способ выделить объекты внимания, а не безусловное указание к действию. Работать на формальное соблюдение — точно не надо. А еще аналогичную метрику стоит применять и к коммуникациям в организациях. И сразу будет понятно, что кроссфункциональные команды — более эффективный способ организации по сравнению с функциональными отделами: люди в рамках общего проекта взаимодействуют чаще, чем между проектами по профессиональным вопросам. Алексей Золотых из МойОфис. Мультиметоды и полиморфизм в JavaScript: мощные техники для гибкого кодаМашине не важны языки — она исполняет код. А многообразие языков объясняется ограниченностью возможностей человека — языки обеспечивают снижение сложности, облегчая работу с большим объемом кода. Когнитивная сложность кода определяется блоками, основные из которых — циклы и серии if-elsif-else (или switch). Циклы хорошо заменяются на reduce. А вот что делать с if-elsif-else? В чем, собственно, проблема? Есть много обобщенных действий, например, рендеринг на интерфейсе, сохранение в файл или сериализация или просто преобразование в строку, например, для формирования сообщения. И каждая веточка в таком действии зависит от типа объекта, а иногда — от каких-то дополнительных параметров, например разрешения экрана при рендеринге или типа сохраняемого файла, а не только типа объекта, который сохраняется. И хочется уметь для действия писать обобщенную реализацию для основных типов, а вот всю специфику писать отдельно, вместе со специфическими типами, а не увеличивать до бесконечности серию if-elsif для действия. Если у нас реализация зависит только от типа, то механизм есть: можно написать метод, а дальше — отдельно писать его расширения, extend, для конкретных типов. Но если зависимость более сложная, параметров несколько, то такой конструкции недостаточно. Для решения таких задач применяются мультиметоды. На уровне языка это есть в closure, Julia, частично в C#. На JS надо писать, но есть достаточно много библиотек с реализациями, Алексею нравится @arrows/multimethod, но это просто личный выбор. А если нужно, то можно написать свою по месту — конструкция укладывается в десяток строк кода. Основная идея — при первом обращении создается объект с парами матчер-обработчик, и оно хранится через замыкание. В презентации было довольно много примеров — как это устроено. Для разных кейсов и фреймворков — vanilla, react, angular. В этом — основная ценность доклада. Но пересказывать это невозможно — надо смотреть фрагменты кода в презентации. Так что если интересно — смотрите и используйте шаблон. Профит в том, что отдельно тестируется мультиметод, и отдельно — каждая веточка, и изменения в одной из веток не затронут другие, в отличие от больших сборок if-elsif. Как обычно, плюшки имеют побочные эффекты. Мультиметод может дать проблемы производительности, если это не отрисовка экрана. а код, выполняемый 100—200 раз в секунду. А еще усложняет отладку — на веточки if-elsif очень ленко поставить точку останова, с мультиметодом это сложнее. Получается довольно крутая кривая обучения. И есть проблемы со строгой типизацией, в typescript базовая поддержка есть, но есть и проблемы, так как неясно, какой тип вернет матчер из-за позднего связывания. Но тут он сторонник динамики в ущерб типизации. Так чо не надо использовать повсеметно, но стоит знать и использовать там, где уместно. Еще поскольку реализации мультиметодов использует замыкания, то могут быть проблемы с асинхронной работой. Это надо аккуратно понимать, и использовать соответствующие реализации, таких как RxJS, где мультиметоды есть. Михаил Толстой. «Да он просто…» — доклад о моделях, которые помогают понимать людейКак я писал в начале отчета, мне очень понравился этот доклад. Основная мысль не стреляйте друг другу в ноги популярной психологией, а используйте ее для исследования людей, в коммуникации или совместной работе с которыми возникли проблемы. Эти модели помогают понять. насколько другой человек может быть не похож на тебя, подумать о нем. И если не клеить ярлыки, а исследовать, то использование моделей — конструктивно. И большинство моделей не отвергают другие, так что можно выбрать те, которые вам близки и полезных для задач. А задачи — понятные: как понять, что человеку важно, что он хочет, ради чего готов трудиться и как сделать, чтобы он вас услышал. Я тут хочу дополнить, что, хотя моделей множество и они совместимы, полезно понимать основания конкретных моделей, подобно тому, как используя те или иные шаблоны программирования полезно понимать, для каких классов задач они были разработаны, и в каких предположениях действуют. Есть модели, которые отражают различия в конструкции нашего мышления на уровне нейрофизиологии, есть те, в которых были выделены объективно наблюдаемые кластеры, а есть построенные по умозрительным дихотомиям или просто меняющие соответствие некоторому идеалу. И дальше я буду добавлять свои комментарии по поводу конкретных моделей. Мне как архитектору всегда было интересно построить целостное представление о личности, посмотреть на совместимость разных моделей, поэтому я разбирался с их основаниями, и в результате у меня получилась серия статей Инженерная модель личности, опубликованная потом в виде книги. Свои комментарии я буду отделять от конспекта доклада. Итак, есть две категории: (а) применяют что попало и (б) говорят, что это все чушь. Надо пройти посередине. А еще пройдет 5 лет, начнут приходить те, кто родился после 2010-х, и с ними надо будет находить контакт. И они — другие. А вы сейчас с зумерами не можете справиться. Впрочем, отмечу, что далеко не факт, что существующие модели справятся с ними, подобно тому, как старые шаблоны разработки запросто оказываются не эффективными в новых архитектурах, ведь они были эмпирически построены на другом материале. Итак, для начала — модели энергетического уровня.
Я отмечу, что у модели-батарейки есть реальные физиологические основания, через которые идет измерение у гаджетов. Меряется активность вегетативной нервной системы, показывающая расход энергии на поддержание состояния организма, это отражает уровень стресса. И через нее оценивается потенциальный доступный ресурс, который может быть направлен на мышление. То, что потенциал есть — не значит, что он может быть израсходован, дальше уже срабатывают внутренние механизмы системы подкрепления внутри мозга, которые говорят, что размышлять — бесполезно, лучше пойти посмотреть прикольные клипы и получить прямое удовольствие, и на этом уровне надо работать отдельно, там есть свои методы. Но вот если потенциал вообще отсутствует, то эти методы будут бесполезны, и надо работать на уровне физиологии. А еще про депрессию и выгорание стоит понимать, что клиническая депрессия — это когда человек вообще не хочет есть и ходит под себя, потому что ему все безразлично, а в мягких вариантах это все может оказаться просто отсутствием подкрепления. Возвращаясь к докладу. Есть типологии личности.
Применение типологий полезно до тех пор, пока это процесс исследования человека. Именно это приближает к пониманию. Я бы к этому списку добавил еще типологию Алексея Кулакова, построенную на основе компьютерных игр, тем более что Алексей строил ее для объяснения тимлидам своей компании, какие бывают люди. Подробное описание — в этой статье. Теории мотивации. Мотивация — это о том, что человек будет самостоятельно делать. Не про стимулы.
Теорий много, они все разные и не противоречат друг другу. Тут отмечу, что о нейрофизиологии драйва и мотивации сейчас известно довольно много. Есть модель Хелен Фишер. Ее Михаил не упоминал, а она довольно понятная. Она говорит, что есть четыре нейрофизиологических механизма мотивации, каждой из которых соответствует свой гормон: дофамин дает счастье поиска и исследований, тестостерон — счастье победы и достижения цели, оскитоцин — счастье эмпатии и взаимоотношений, а серотонин — счастье регулярной деятельности, когда ты взял задачу и сделал, потом взял следющую. У каждого человека есть все четыре, но работают в разную силу. Интересно, что механизмам мотивации модели Хелен Фишер соответствуют типы в модели Бартла, разработанной и применяемой для вовлечения и удержания игроков в компьютерные игры задолго до исследований Хелен Фишер, которая выделяет четыре типа игроков: киллер, карьерист, тусовщик, исследователь, и это является независимым подтверждением модели. Модель объясняет, почему одни задачи нас драйвят, а другие — нет. То есть показывает не только мотивацию, но соответствие задачи человеку, о чем у Михаила следующий список. Модели соответствия задач человеку
Плюс от моделей в том, что вы вообще подумали о том, подходят ли задачи человеку. А не считаете, что любой может сделать любую задачу. Я, кстати, отмечу, что в ИТ есть типовая ошибка, которую хорошо описывает модель Белбина: от сотрудника, который любит придумывать свои идеи, требуют поискать решения в интернете. Белбин говорит, что это — разные роли, Генератор идей и Исследователь ресурсов, и они редко совмещаются в одном человеке, Генератору важны собственные идеи, когда он смотрит на чужое решение — он обосновывает, почему оно точно не подойдет. Вообще у меня по модели Белбина есть много докладов и статей. Вы поговорили, а он ничего не понял. Это про подачу информации.
Типологии лидерства, помимо Адизеса.
Итого — есть много моделей. И часто достаточно просто направить их на человека и поисследовать, проблемы решаются. А если коммуникационных проблем нет — не трогайте. Как узнать о моделях подробнее? Популярные изложения, которые выдает поиск, часто сильно упрощают и искажают. Читайте книги. В этом я с Михаилом совершенно согласен. Книги Михаил не называл, я тут дополню по тем моделям, которые знаю. По MBTI есть хорошие книги Отто Крегера, это практик, и у него ориентация на бизнес. По Белбину - книги самого Белбина «Команды менеджеров. Как объяснить их успех или неудачу» и «Типы ролей в командах менеджеров», читать их стоит именно в таком порядке. Хотя половина контекста там перекрывается, они про разное: первая больше про историю исследований, а вторая — про подбор и формирование команды. В своих своих статьях и книге [«Инженерная модель личности» я описываю довольно много моделей со ссылками на источники. И, на мой взгляд, в списке моделей не хватает Спиральной динамики. Эта модель хорошо дифференцирует людей по отношению к важным для работы понятиям: что такое ответственность, надо ли проявлять инициативу и когда именно, стоит ли соблюдать правила, нужно ли помогать другим при выполнении их обязанностей, что такое - успешный проект, как должно быть устроено справедливое вознаграждение и так далее. Она говорит, что ответы на эти вопросы не произвольны, а собраны в устойчивые непротиворечивые конструкции, зафиксированные в культуре общества. И эти конструкции легли в основу книг по менеджменту и организации работы - авторы опираются на свою картину устройства мира и транслируют ее, и спорят с другими. Практически Спиральная динамика сильно расширяет модель Адизеса, включая не только аспекты менеджмента, а картину мира в целом, и показывая ее основания. Особенно она ценна, когда вы общаетесь в компаниям другой культуры, например, с заказчиком, или когда ищете место работы, а также при общении ч сотрудником, который недавно пришел в компанию и несет иную культуру, внутри компании представления выравниваются, хотя в большой корпорации могут сильно различаться в разных подразделениях. К сожалению, по ней нет хороших компактных описаний, я в свое время читал книгу Бека и Кована «Спиральная динамика», там 130 страниц подробного описания, в которое надо погрузиться. У меня довольно много материалов и докладов с краткими описаниями, в том числе ориентированных на ИТ-аудиторию. И возвращаюсь к докладу. Если есть задача — возьмите конкретную модельку и начинаем собирать фактуру.
Очень часто все завершается тут: позаписывал, и понятно. А записывать важно, потому что воспоминания работают плохо, людям свойственно лучше запоминать эмоции, а не факты, а важны именно факты. Мотивацию.
Результат всех этих стараний — лишь гипотеза, предположения о том, как человек себя поведет. Гипотезу нужно проверять. Можно сразу в бою, но лучше сначала другим способом.
И не забывайте про эксперимент 2-4-6. Михаил дал ссылку и не успел рассказать подробности, я поискал. Суть в том, что человеку свойственно искать подтверждение своей гипотезе, а не опровержение ее. Для вас это тоже верно. Поэтому когда вы выдвинули гипотезу о другом человеке, подумайте не только о способе подтверждения, но и о том, как можно опровергнуть. Об этом надо думать специально. Ну и в заключении. Так много моделей. Почему я должен всем этим заниматься? Ответ: это же у вас проблема — кому же ее решать? Если проблем нет — не занимайтесь. Выводы
У Михаила есть канал https://t.me/tolstoymv, где он пишет на разные темы. |
Я в сетиhttp://www.facebook.com/mtsepkov http://www.linkedin.com/in/mtsepkov http://www.slideshare.net/mtsepkov/ e_mail M.Tsepkov@custis.ru
|
Обо мнеМоя основная работа — проектирование корпоративных и банковских систем. Я верю, что автоматизация открывает новые возможности развития, поэтому создавая ИТ-системы мы открываем путь прогрессу и делаем мир лучше. Я делаю это, работая главным архитектором дирекции развития решений компании CUSTIS. Я верю в эффективность командной работы и профессиональных сообществ, вхожу в программные комитеты конференций SECR и AnalystDays, и открыт к общению с коллегами по ИТ на различных площадках и в соц.сетях. А еще я люблю путешествовать, об этом и о других идеях вне профессиональной деятельности я пишу в своем ЖЖ. |
Блоги друзей |
