惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
V
V2EX
V
Visual Studio Blog
博客园_首页
Last Week in AI
Last Week in AI
Apple Machine Learning Research
Apple Machine Learning Research
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
S
SegmentFault 最新的问题
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Martin Fowler
Martin Fowler
Recent Announcements
Recent Announcements
J
Java Code Geeks
月光博客
月光博客
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
F
Fortinet All Blogs
P
Privacy & Cybersecurity Law Blog
C
CERT Recently Published Vulnerability Notes
C
CXSECURITY Database RSS Feed - CXSecurity.com
B
Blog RSS Feed
S
Schneier on Security
酷 壳 – CoolShell
酷 壳 – CoolShell
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
W
WeLiveSecurity
A
Arctic Wolf
U
Unit 42
博客园 - 司徒正美
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
有赞技术团队
有赞技术团队
Recorded Future
Recorded Future
Engineering at Meta
Engineering at Meta
Google DeepMind News
Google DeepMind News
大猫的无限游戏
大猫的无限游戏
Microsoft Security Blog
Microsoft Security Blog
Hacker News: Ask HN
Hacker News: Ask HN
量子位
B
Blog
T
The Exploit Database - CXSecurity.com
C
Cisco Blogs
博客园 - 三生石上(FineUI控件)
H
Help Net Security
博客园 - 叶小钗
C
Cyber Attacks, Cyber Crime and Cyber Security
L
LINUX DO - 热门话题
Hugging Face - Blog
Hugging Face - Blog
Google DeepMind News
Google DeepMind News
小众软件
小众软件
雷峰网
雷峰网
TaoSecurity Blog
TaoSecurity Blog
Schneier on Security
Schneier on Security

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания Автономность как точка невозврата: кто будет субъектом в цифровом будущем Обучение ИИ в «диких» условиях: как рутинные действия превращаются в датасеты Как измерить LLM для задач кибербеза: обзор открытых бенчмарков Где хранить код? Сравнение GitHub, GitLab и Bitbucket Математика объясняет, почему нормальное распределение встречается повсюду Почему ваш FinOps не работает: 12 тезисов от практиков Как подписать проектную документацию УКЭП с использованием бесплатных лицензий Pilot Адаптивное администрирование Sigla Vision Я грузил уран в бочки, а потом 20 лет строил ИТ в атомной отрасли Чем позвонить с Эвереста? История и обзор спутниковой связи. Часть 2 Как языковая модель помогает контролировать качество инструктажей по охране труда в металлургии Как не передать на desktop свой IP в РКН Анатомия SAP Privileges: как устроено управление правами в macOS MoneyDev: Сказка про три главных слова Обновлённый токенизатор видео K-VAE 2.0 от Сбера Как сделать диспетчеризацию дома на 1284 квартиры почти бесплатно Как мы разогнали железную дорогу Мы дали агентам рутину. Теперь надо решить — что делать с освободившимся временем Токсичный контент, промпт-хакинг и защита ИИ — всё о Guardrails для LLM Умный город начинается с точного взгляда: как «Фалькон Тех» меняет пространство к лучшему Навайбкодил приложение для анализа графов Почему Дюну так интересно читать? Упрощаем работу с рутиной или как стать Гендальфом Белым Деконструкция Go: CPU, RAM и что там происходит. Go Assembler база. Часть 1.1 Какие профессии исчезнут из-за ИИ, а какие появятся? И что с этим делать Как мы построили IT-отдел, где хочется расти: архитектурные встречи, прозрачные метрики и книжные подарки Rufler: Делаем из Claude Code автономный рой через один YAML-конфиг Sing-box и белый список приложений Как построить надёжный обмен сообщениями в микросервисах: лучшие практики для enterprise OpenAI строит MLM-пирамиду, а McKinsey и Accenture помогают ей в этом Дом, который не построил Фишер (Часть 2) «Сверхзвуковой математик» против «Вдумчивого логиста»: битва алгоритмов 3D-упаковки Мультимодальные модели – грубый и дорогой инструмент Разговоры ничего не стоят. Код тоже Проверки физических лиц: с кого начнет ФНС Топ-10 бесплатных нейросетей для создания видео в 2026 году Первые слои кода: как наши решения сегодня определяют архитектуру ИИ на десятилетия Разработка нового статического анализатора: PVS-Studio JavaScript Поиск уязвимостей ПО: базовый минимум или роскошный максимум Почему оценка персонала не работает как инструмент управления Как мы разработали ИИ-ассистента и сократили рутину продуктовой команды на 50% Как я ушел из найма, нажарил косточек и продал на маркетплейсах на 168 млн в год Когда 1С:ERP уже внедрена, а нормального производственного плана всё ещё нет Как я сделал Claude мультимодальным, подключив к нему Qwen Omni Как приглашение на вакансию мечты превращается в атаку Infrastructure as Code: философия и лучшие практики IaC Тестируем Yandex Code Assistant на задаче, в которой нужно хранить секреты nxs-universal-chart v3.0: новое поколение универсального Helm-чарта Callback Injection: Техника, которая отправила Microsoft Defender в глухой нокаут «Все идеи на стол»: митап как способ вывести проект из тупика Сегодня я узнал нечто новое о GPU благодаря багу в своей игре Как заставить LLM ̶ ̶г̶а̶л̶л̶ю̶ ̶ эволюционировать Карта событий как фундамент аналитики: практический кейс для E-commerce Что выбрать для AI: x86, ARM или RISC-V? Дайджест железа за март Роль соматических мутаций в развитии аутоиммунных заболеваний: путь к избирательной терапии Mythos от Anthropic — тревожный сигнал для всех, а не только для банков Guardrails для LLM на Java: как приручить промпт‑инъекции и токсичные ответы Green-VLA: как мы собрали VLA-модель для реального антропоморфного робота и не потеряли обобщение Финансовая гонка вооружений: почему умные люди добровольно в ней участвуют Эра ИИ-агентов наступила: выбираем лучшего цифрового сотрудника # Практический опыт внедрения WinCC Redundancy на производственном предприятии Сделал MVP за 3 дня, а потом неделю прикручивал оплату. Оно того стоило? Физика против Маска: почему Starship V3 может оказаться ещё одной катастрофой Нефть Венесуэлы: крупнейшие запасы в мире, но не крупнейшая нефтяная держава JPA 4. Переосмысление Hibernate Почему зеркальная фотокамера Nikon D5 десятилетней давности идеально подошла для миссии «Артемида-2» Проект «Уровень-Спутник» или как мы сделали платформу для гидрологов «Замедлиться, чтобы ускориться»: почему ИИ повышает цену ошибок в требованиях и архитектуре Как с нуля поднять трафик IT-компании на 1657% при бюджете 55 тыс. и выжить Pixel-perfect Downsampling — идеальная отрисовка 50 миллионов точек без потерь
Почему ваши «мягкие навыки» не работают — и что я построил вместо них
Ekstrem · 2026-04-27 · via Все публикации подряд на Хабре

Почему ваши «мягкие навыки» не работают — и что я построил вместо них

Уровень сложностиПростой

Время на прочтение11 мин

Охват и читатели0

Взгляните на две ситуации. Узнаёте?

Ситуация первая. Вы приходите к руководителю за решением по важному проекту. Вы подготовили анализ, просчитали риски, принесли варианты. Руководитель кивает, говорит «интересно, давай позже». Через неделю вы узнаёте, что бюджет и людей отдали другому направлению - без обсуждения с вами. Вы злитесь. Думаете: «Я плохо донёс».

Ситуация вторая. Смежное подразделение затягивает предоставление сервиса, от которого зависит ваш проект. Вы пишете письма с аргументами - в ответ тишина. Вы эскалируете. После эскалации ваш руководитель говорит: «Слушай, ну ты слишком жёстко с ними. Надо было мягче». Вы думаете: «Я просто пытался решить задачу, которую ты мне поставил».

В первой ситуации вы можете идеально понять точку зрения руководителя. Он экономит ресурсы. Его KPI - не ваш проект, а квартальные показатели всего отдела. Понять это - полезно. Но что дальше? Эмпатия не даёт вам бюджета. Она не даёт вам аргумента, который перевесит его квартальный план.

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

Что объединяет эти ситуации?

Стандартный ответ - «улучшайте коммуникацию». Корпоративные тренинги учат: слушайте активно, используйте «Я-сообщения», старайтесь понять точку зрения оппонента, проявляйте эмпатию. Мягкие навыки. Soft skills.

И предложения “поработать над коммуникациями” тут не помогут. Дело не в том, что мягкие навыки бесполезны. Дело в том, что их преподают так, будто корпоративный конфликт - это дефицит понимания. Но в реальной организации выше определённого размера большинство конфликтов - это не дефицит понимания. Это столкновение интересов, вшитых в KPI, грейды и цепочки подчинения. Вы можете идеально понимать оппонента и всё равно проигрывать - потому что у него другие вводные, другие стимулы, другая карта местности.

Конфликт - это система, у неё есть структура, входы и выходы. Её можно моделировать. Не «чувствовать» оппонента, а строить его профиль. Не «проявлять эмпатию» к его позиции, а видеть его KPI и предсказывать реакцию. Не «сглаживать» конфликт, а проектировать сценарий с конкретными фразами и прогнозом исхода.

О том, что из этого получилось - дальше.


Другой взгляд: конфликт как система

Инженер, столкнувшись с непредсказуемым поведением системы, не пытается её «почувствовать». Он строит модель: входы, выходы, ограничения, интерфейсы. Он не спрашивает: «Почему система так себя ведёт?» - он спрашивает: «При каких условиях она ведёт себя так, а при каких - иначе?»

Корпоративный конфликт - такая же система. У него есть структура.

Есть участники. У каждого - своя позиция в разделении труда. Эта позиция определяет их KPI. KPI определяют их интересы. Интересы определяют их поведение - часто более жёстко, чем характер или настроение.

Есть среда. Компания - это не плоская сеть равных. Это цепочки подчинения, бюджетные линии, неформальные центры влияния. Решения принимаются не там, где обсуждаются. Власть распределена неравномерно.

Есть системные конфликты. Они заложены в структуру до того, как конкретные люди заняли свои должности. Разработка хочет скорости, безопасность хочет отсутствия рисков, продукт хочет фич, архитектура хочет целостности. Эти интересы противоречат друг другу не потому, что люди плохие - а потому, что их так поставили. Если завтра на эти должности придут другие люди, конфликты останутся теми же.

Что происходит, когда вы смотрите на конфликт как на систему?

Вы перестаёте спрашивать: «Почему он так со мной? Что я сделал не так? Как мне лучше донести свою мысль?» Вы начинаете спрашивать: «Какие у него KPI? Чего он боится? От кого он зависит? В какой точке его интерес пересекается с моим, а в какой - расходится? Кто на самом деле принимает решение по этому вопросу?»

Это смена метода. Вместе с психологией - анализ интересов. Вместе с эмпатией - моделирование. Вместе с «понять человека» - «понять позицию, которую он занимает».

Для такого моделирования нужны три вещи.

Первое. Знать себя. Не в смысле «осознать свои чувства», а в инженерном: знать свои автоматические реакции. Что вас триггерит? Что вы делаете в первые секунды конфликта, ещё до того, как подумали? Ваш автоматический стиль - давить, замыкаться, сглаживать, требовать справедливости? Пока вы этого не знаете, ваша реакция управляет вами. Когда знаете - у вас появляется выбор.

Второе. Иметь модель оппонента. Не гадать о его характере, а зафиксировать наблюдаемое: его должность, его KPI, его типичное поведение в конфликте, что его бесит, что помогает с ним договариваться, какая у вас гипотеза о его реальных мотивах. Это не психологический портрет. Это профиль для предсказания поведения. Как спецификация компонента: «при входном сигнале X реагирует Y».

Третье. Видеть карту среды. Кто принимает решения по продукту, по технологиям, по ресурсам? Где заложены системные конфликты? От кого вы зависите, кто зависит от вас? Без этой карты вы можете годами вкладываться в отношения с человеком, который ничего не решает - и удивляться, почему ничего не меняется.

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

Это не гарантирует победу. Никакой инструмент не гарантирует победу в среде, где решения принимаются наверху, а вас могут просто не позвать на встречу. Но это даёт вам то, чего не дают мягкие навыки: трезвое понимание, где вы можете повлиять, а где - нет. Вы перестаёте тратить энергию на самокопание и начинаете тратить её на расчёт.

В декабре 2025 года я сел и за месяц собрал такой инструмент. Не как академическую модель - а как работающий фреймворк из четырёх шагов, каждый из которых можно пройти за вечер с помощью обычной LLM. О нём - следующий раздел.

Фреймворк: 4 шага

Фреймворк состоит из четырёх шагов. Каждый шаг - это отдельный диалог с LLM. Профили собираются один раз и переиспользуются для любых будущих ситуаций. Система самообучается через ретроспективу.

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

Полные инструкции для каждого шага лежат в репозитории. Здесь я опишу логику и ключевые вопросы.

Шаг 1. Мой конфликтный профиль

Что происходит. Вы открываете новый чат, отправляете инструкцию. LLM задаёт вам 13 вопросов о том, как вы ведёте себя в конфликте. Три конкретные ситуации за последние полгода: когда вас что-то вывело из себя, когда вас публично критиковали или унизили, когда вы не получили заслуженное. Вопросы о вашем стиле в споре. Что вас бесит в людях. Что помогает успокоиться.

Зачем это. В конфликте мы действуем автоматически. У каждого есть повторяющийся паттерн: один в споре давит логикой, другой замыкается, третий сглаживает, четвёртый требует справедливости. Это не характер - это предсказуемая реакция на определённый класс триггеров. Пока вы не знаете свой паттерн, он управляет вами. Когда вы его зафиксировали, у вас появляется пауза между триггером и реакцией. В эту паузу можно выбрать другое действие.

На выходе. Markdown-файл с вашим профилем. Это не психологический автопортрет. Это спецификация: «при входном сигнале X моя система реагирует Y». Вы будете прикладывать этот файл к Шагу 4, чтобы LLM учитывала ваши триггеры при моделировании сценариев.

Шаг 2. Профиль оппонента

Что происходит. Новый чат, инструкция, 12 вопросов. Вы описываете коллегу: должность, частота пересечений, что он сделал, когда вас раздражал, как вы думаете - зачем он это сделал. Что бесит его самого. Что он предъявит вам в конфликте. Что помогает с ним договариваться, а что убьёт отношения. И ключевой вопрос: «Что им движет на самом деле?» - ваша гипотеза. Не истина в последней инстанции, а рабочая модель, которую вы будете проверять и уточнять.

Зачем это. В стандартном подходе вы идёте в конфликт с образом оппонента в голове: «он токсичный», «он тормозит», «ему лишь бы отчитаться». Этот образ - смесь фактов, обид и проекций. Профиль оппонента заменяет этот хаос на структуру. Вы фиксируете наблюдаемое и отделяете его от интерпретаций. Интерпретации помечаете как гипотезы. В следующий раз, когда этот человек сделает что-то неожиданное, вы не думаете: «Он опять!» - а открываете профиль и проверяете: «Ага, сработал его триггер номер 3. Он боится потерять статус. Моя ошибка: я публично поставил его решение под вопрос. Понятно. В следующий раз - приватно».

На выходе. Markdown-файл с профилем этого человека. Для каждого значимого коллеги - свой файл. Как библиотека компонентов: один раз описал - используешь для разных ситуаций.

Шаг 3. Карта компании

Что происходит. Новый чат, инструкция, 11 вопросов. Кто ваш руководитель? Кто его руководитель? Кто принимает решения по продукту, по технологиям, по бюджету? Ключевые люди вне вашего подчинения, от которых зависит ваш результат. Что у них болит. Где заложены системные конфликты - те, что существуют между должностями, а не между людьми.

Зачем это. Большинство сотрудников видят компанию как список лиц: «есть я, есть мой начальник, есть смежники, есть какой-то CIO где-то наверху». Карта компании превращает этот список в структуру. Вы видите: вот здесь заложен конфликт между скоростью разработки и безопасностью. Этот конфликт не личный - он будет существовать при любых людях на этих должностях. Вот здесь - узел власти, где принимаются реальные решения. А вот здесь - человек, у которого нет власти, но есть влияние, и его мнение тянет за собой других.

Когда у вас есть карта, вы перестаёте путать причину и повод. Ваш конфликт с безопасником - не потому что он вредный, а потому что его KPI и ваши KPI противоречат. Ваш конфликт с руководителем - не обязательно личная неприязнь. Возможно, его KPI - сокращение расходов, а ваш проект требует инвестиций.

На выходе. Markdown-файл с картой компании. Вместе с профилями (своим и оппонента) он загружается в Шаг 4.

К слову! Обратите внимание - данный шаг отзывается с картой контекстов, как я описывал её в одной из прошлых статей "Предметно-ориентированное проектирование на самом деле.

Назначение карты контекстов - спрогнозировать возможности по развитию ограниченных контекстов. В условиях Enterprise, такая схема позволит правильно подумать над тем, что может бескровно эволюционировать, а где могут возникнуть существенные проблемы. Так, решая проблемы, где-то необходимо прийти к административному ресурсу, где-то чаще повстречаться (может быть провести ряд meet’апов для повышения вовлечённости вышестоящей команда, а иногда пойти по пути отдельного существования.
Если взглянуть на карту взаимодействия между контекстами с точки зрения экономики, то мы строя карту контекстов получаем план производства в организации.

Шаг 4. Моделирование сценариев

Это сердце фреймворка. На этом шаге собранные данные превращаются в конкретный план действий.

Что происходит. Вы открываете новый чат, загружаете три файла (свой профиль, профиль оппонента, карту компании), отправляете инструкцию. Описываете ситуацию: что должно произойти, кто участвует, чего вы боитесь, какой исход был бы идеальным, что ещё важно учесть. LLM задаёт 6 уточняющих вопросов. Затем на основе всех профилей и ваших ответов выдаёт 2-3 варианта действий.

Что внутри каждого варианта:

  • Конкретные фразы и последовательность шагов - не «будьте дипломатичнее», а «скажите вот это».

  • Прогнозируемая реакция оппонента - на основе его профиля.

  • Риски варианта - при каком условии он сработает, при каком - провалится.

Два режима. Шаг 4 работает в двух режимах.

Режим А - превентивный. Ситуация ещё не произошла. Вы готовитесь к разговору. На выходе - сценарий, с которым вы идёте на встречу.

Режим Б - ретроспектива. Ситуация уже случилась. Вы возвращаетесь в чат и пишете: «Хочу дать обратную связь по той ситуации». LLM спрашивает: что сработало, что нет, что вы теперь знаете о коллеге такого, чего не знали раньше, что изменилось в вас. На основе ответов предлагает скорректировать профили и формирует таблицу острых коммуникаций - короткую запись о ситуации в формате «триггер - проявление - динамика - результат». Эти таблицы копятся и прикладываются к следующим разборам. Система учится вместе с вами.

Четыре шага. Три вечера на сборку профилей. Час на моделирование сценария перед важным разговором. Инженерия коммуникаций: модель среды, спецификация участников, расчёт сценариев.

Почему это работает - следующий раздел.

Кейс: как это выглядит на практике

Вот собирательный пример. Никаких реальных имён и названий.

Ситуация. Сотрудник А спроектировал сервис для внешнего регулятора. Работа шла несколько месяцев. Внезапно он узнаёт: выбрано альтернативное решение, его не позвали на ключевые встречи, сроки сдвинуты. А должен либо молча принять, либо выйти из проекта.

Что дали профили.

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

Профиль руководителя: его KPI - сохранить своё подразделение в ходе реорганизации. Он не будет тратить политический капитал на защиту А в эскалации. Его позиция: «Мне всё равно».

Профиль заказчика: её KPI - сдать проект в срок регулятору. Она не обязана понимать политические мотивы А. Она фиксирует факты в письмах и отчитывается наверх. Если А пишет остро - она дистанцируется и докладывает о «разладе внутри ИТ».

Карта компании: решение о выборе альтернативной системы принято на уровне CDO. Заказчик - не автор решения, а транслятор. Спор с ней не меняет исхода.

Сценарий, который был выбран. А вышел из проекта. Предупредил руководителя заранее. Зафиксировал свой вклад артефактами.

Что произошло. А всё равно написал острое письмо - сработала автоматическая реакция «Праведного Судьи». Заказчик дистанцировалась. Руководитель публично не вступился. А вышел из проекта, но с репутационным следом.

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

Вывод не в том, что «надо было быть дипломатичнее». Вывод - в том, что теперь А знает: решение наверху, заказчик - транслятор, руководитель не вступится. В следующей похожей ситуации он не будет тратить эмоции на эскалацию. Он выйдет тихо, сохранив отношения и репутацию.

Один кейс, одна ретроспектива, три уточнённых профиля. Система учится.

Почему я это публикую

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

В любой организации есть структурный дисбаланс. Руководитель видит картину целиком: бюджеты, планы, расстановку сил, кто с кем в каком конфликте. Сотрудник видит только свой участок, в то время как у руководителя есть карта.

Тренинги по мягким навыкам этот дисбаланс не устраняют. Они учат сотрудников сглаживать углы, а не выравнивать положение. Быть удобным, а не сильным. Адаптироваться к неравенству, а не видеть его структуру.

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

Мой фреймворк - это карта. Профиль оппонента: его KPI, страхи, предсказуемое поведение. Карта компании: кто на самом деле принимает решения, где заложены системные конфликты. Сценарии: конкретные фразы, прогноз реакции, оценка рисков.

Если карта есть только у одной стороны - это не конкуренция. Это предопределённый исход. Я хочу, чтобы такой инструмент был у каждого. Не вместо зарплаты, не вместо коллективного действия - а в дополнение к ним. Чтобы сотрудник шёл в сложный разговор не с надеждой на чужую справедливость, а с расчётом.

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

Все инструкции и промты в открытом репозитории. Берите. Пользуйтесь. Улучшайте. Это не Манхэттенский проект, но создаст для вас такой же эффект.

Как начать сегодня

Всё, что нужно для старта - доступ к LLM и три вечера.

Первый вечер. Откройте новый чат, скопируйте инструкцию для Шага 1 из репозитория. Ответьте на 13 вопросов о своих триггерах и реакциях. На выходе - ваш конфликтный профиль. Сохраните в файл.

Второй вечер. Новый чат, инструкция для Шага 2. Опишите одного значимого коллегу - того, с кем у вас сложнее всего. 12 вопросов. На выходе - его профиль.

Третий вечер. Новый чат, инструкция для Шага 3. 11 вопросов о компании: кто принимает решения, где заложены конфликты, от кого зависит ваш результат. На выходе - карта.

Теперь у вас есть библиотека. Когда предстоит сложный разговор - новый чат, три файла, инструкция для Шага 4. Описываете ситуацию, отвечаете на 6 вопросов. LLM, опираясь на ваши профили и карту, выдаёт сценарии: конкретные фразы, прогноз реакции оппонента, риски.

После разговора - возвращаетесь в чат и включаете режим ретроспективы. Что сработало? Что нет? Что теперь знаете о коллеге такого, чего не знали раньше? Система предлагает скорректировать профили и формирует таблицу острых коммуникаций. Со временем точность растёт.

Если нет времени на три вечера - можно начать с экспресс-режима: сразу Шаг 4 без готовых профилей, описывая себя и оппонента прямо в диалоге. Точность ниже, но в экстренной ситуации лучше, чем ничего.

Репозиторий с инструкциями, промтами и примерами профилей: https://github.com/Ekstrem/Communication-modeling

Три вечера. Потом - другая игра.