Дайджест за 6 сентября 2026

Broadcom резко повысила прогноз AI-выручки до $230 млрд на FY28

ИИ и агенты · App Economy Insights · 9/10

Broadcom опубликовала отличные результаты Q3 с выручкой $29,6 млрд (+86% Y/Y) и резко повысила прогнозы по AI-полупроводникам. AI-выручка компании выросла на 221% Y/Y до $16,7 млрд, превысив ожидания в $16 млрд. Компания теперь ожидает $115 млрд AI-выручки в FY27 (против разочаровавших рынок $100 млрд в Q2) и экстраординарные $230 млрд в FY28 – это означает почти четырёхкратный рост за два года.

Главные клиенты Broadcom – Anthropic (станет крупнейшим покупателем кастомных XPU в FY27), OpenAI (потенциально второе место), Google (десятки миллиардов ежегодно) и Meta, которая наращивает закупки по разным поколениям чипов. Спрос четырёх крупнейших AI-клиентов превышает производственные мощности компании.

Это побуждает Broadcom к вертикальной интеграции: запуск производства субстратов в Сингапуре в FY27 и масштабирование сетевых решений, включая новый коммутатор Tomahawk 7 с пропускной способностью 200 Tbps.

Выводы автора:

• Спрос на AI-полупроводники продолжает превышать предложение Broadcom, что указывает на критическую нехватку мощностей в отрасли
• Прогноз FY28 в $230 млрд демонстрирует убежденность компании в долгосрочном росте AI-спроса от крупных технологических игроков

Спрос от четырёх крупнейших AI-клиентов продолжает превышать то, что Broadcom физически может поставить

Оригиналы:Подробнее на App Economy Insights

Как LLM помогла создать алгоритм кластеризации за пару часов

ИИ и агенты · Habr · 7/10

Статья рассказывает о практическом опыте использования LLM для быстрого прототипирования идеи без написания кода. Автор, тимлид аналитиков в Авито Владислав Козлов, столкнулся с задачей выделения кластеров пользователей с аномальным поведением для обнаружения мошеннических схем. Вместо долгой предварительной обработки данных, он обсудил с LLM идею, основанную на принципе работы Isolation Forest: случайно разбивать признаки и смотреть, как часто два объекта попадают в одно подмножество. LLM предложила подход с вычислением уникальных идентификаторов ячеек и расстояния на основе расстояния Хэмминга. За 5 минут обсуждения получилась работающая библиотека ForestClusterer без единой строчки собственного кода. На датасете Титаника алгоритм выделил понятные кластеры (женщины с семьёй, пассажиры 1 класса, мужчины из низших классов), и показал устойчивость к выбросам лучше, чем KMeans и другие алгоритмы из sklearn при добавлении шума. Статья вдохновляет на смелое экспериментирование и демонстрирует, как LLM может ускорить итерационную разработку.

Выводы автора:

• LLM может быть полноценным партнёром в быстром прототипировании идей, позволяя за пару часов создать работающий инструмент без написания кода
• Алгоритм Forest Clustering, разработанный совместно с нейросетью, показал большую устойчивость к выбросам и пропускам данных по сравнению с классическими методами
• Не стоит откладывать идеи в долгий ящик — имея время и доступ к LLM, можно быстро проверить их жизнеспособность и получить полезный инструмент

Имея пару часов времени и LLM, можно между делом проверить идею, не написав ни строчки кода.

Оригиналы:От «когда-нибудь» к работающему прототипу: как LLM дала идее шанс

Nvidia PAIR: утилита для распределения AI-задач между несколькими ПК

ИИ и агенты · Habr · 7/10

Nvidia выпустила открытый инструмент PAIR (Personal AI Router), который объединяет несколько компьютеров в локальной сети и автоматически распределяет между ними задачи по запуску AI-моделей. Утилита работает поверх Ollama или LM Studio и позволяет подключить ПК с видеокартами Nvidia, системы DGX Spark и Mac в единый кластер без необходимости предварительной адаптации моделей под распределённую архитектуру. При выборе устройства PAIR анализирует наличие в сети, наличие требуемого движка и модели, а также текущую загруженность GPU, автоматически перенаправляя новые запросы на свободные компьютеры. Важное ограничение: программа не объединяет видеопамять разных устройств и не создаёт единый виртуальный GPU, поэтому каждый запрос выполняется полностью на одном компьютере. Компьютеры обнаруживают друг друга через mDNS, все запросы и данные остаются в локальной сети без обращения к облаку. PAIR поддерживает Windows 11, Linux и macOS на архитектурах x64 и Arm64, с поддержкой видеоускорителей RTX 20+, RTX PRO, DGX Spark и Mac с чипами M4+. Код доступен на GitHub под лицензией Apache 2.0.

Выводы автора:

• PAIR позволяет использовать несколько ПК в локальной сети как единую систему для распределения AI-нагрузок, не требуя изменения моделей и работая поверх существующих фреймворков Ollama и LM Studio.
• Утилита не объединяет видеопамять устройств, поэтому каждый запрос выполняется целиком на одном компьютере, а её основная функция — умная маршрутизация задач в зависимости от доступности и загруженности узлов.

Благодаря этому модели можно использовать без предварительной адаптации под распределённую систему.

Оригиналы:Nvidia представила PAIR — утилиту для распределения AI-задач между несколькими ПК

MCP, RAG и AI-агенты: различия и применение

ИИ и агенты · ByteByteGo · 7/10

Материал объясняет разницу между тремя ключевыми подходами в современной разработке ИИ-систем.

наглядно демонстрирует эти различия. MCP (Model Context Protocol) — это открытый стандартный протокол, позволяющий ИИ-моделям подключаться к внешним инструментам и источникам данных (API, БД, приложениям вроде Gmail, Slack, GitHub) единообразным способом без необходимости отдельной интеграции для каждого сервиса. RAG (Retrieval-Augmented Generation) работает иначе: при поступлении запроса модель извлекает свежую информацию из внешних источников (документы, PDF, базы данных), что позволяет ей давать актуальные ответы вместо генерирования потенциально ложной информации. AI-агенты — это автономные системы, которые самостоятельно выполняют задачи и принимают решения в ходе работы, в отличие от чатботов, работающих по принципу запрос-ответ. Каждый подход решает свою задачу в экосистеме ИИ-приложений.

Выводы автора:

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

MCP даёт вам стандартный способ подключения к этим системам вместо того, чтобы писать интеграцию отдельно для каждого приложения

Оригиналы:ByteByteGo

Анатомия граблей: типы багов в игровом движке и методы их отладки

Разработка и архитектура · Habr · 8/10

Статья опытного разработчика игровых движков рассматривает классификацию типичных ошибок в C++ коде и стратегии их обнаружения. Автор начинает с того, что реальная кодовая база движка далека от учебных примеров: там текут утечки памяти, потоки конфликтуют, а физический движок отправляет персонажей на орбиту. Далее разбираются восемь основных категорий багов: опечатки (когда дрогнула рука при копипасте), логические ошибки (off-by-one, редкие ветки if/else), переполнение буфера фиксированных массивов, утечки ресурсов (текстуры, мьютексы, дескрипторы), повреждение памяти (use-after-free, запись за пределы), race conditions в многопоточности, спешные пятничные фиксы и гейзенбаги (баги, исчезающие под отладчиком из-за неинициализированной памяти или оптимизаций). Автор демонстрирует конкретные примеры кода для каждого типа и рекомендует инструменты: clang-tidy с bugprone-флагами, AddressSanitizer, метод сравнения снимков памяти при выгрузке уровня. Завершает статья фичебагами — ошибками, превратившимися в геймплейные механики: комбо в Street Fighter II, прыжки в Quake, и хотя история про агрессивного Ганди в Civilization — это миф, разработчики пятой части сделали её реальной.

Выводы автора:

• Отладка — недооценённый инженерный навык; каждый разработчик вырабатывает собственный набор техник, но существует классификация типичных ошибок, которые полезно знать.
• Инструментация кода (clang-tidy, ASan, кастомные аллокаторы с логированием) эффективнее, чем слепой анализ краш-дампов; проактивное обнаружение дороже, чем реактивное лечение.
• Некоторые баги становятся фичами: если ошибка создаёт интересный геймплей, её полируют вместо исправления.

Функция A где-то в модуле физики слегка затерла край соседнего массива, но где-то неправильно отрисовался виджет UI, и ты сидишь над краш-дампом UI, не понимая, при чем тут вообще интерфейс.

Оригиналы:Анатомия граблей

9 шаблонов распределённых систем и основы ИИ-агентов

Разработка и архитектура · ByteByteGo · 8/10

Выпуск ByteByteGo охватывает ключевые паттерны проектирования распределённых систем и концепции современных ИИ-приложений. В разделе по ИИ объясняется разница между MCP (открытый стандарт для подключения моделей к внешним инструментам и данным), RAG (получение свежей информации из внешних источников при каждом запросе) и AI агентами (автономные системы, выполняющие задачи и принимающие решения, в отличие от обычных чат-ботов). Далее рассмотрены девять фундаментальных паттернов распределённых систем: репликация данных, шардирование, консистентное хеширование, PubSub для асинхронной коммуникации, circuit breaker для обработки сбоев, retry с backoff для отказоустойчивости, выборы лидера в кластерах, quorum read/write для согласованности данных и Saga для управления распределённые транзакциями. Материал также объясняет различия между виртуализацией (полная ОС на каждую машину, медленный старт, полная изоляция) и контейнеризацией (общее ядро ОС, быстрый старт в миллисекунды, но требование совместимости ядра). Завершает выпуск разбор HTTPS: TCP handshake, проверка сертификата, асимметричное шифрование для обмена сеансовым ключом и затем симметричное шифрование данных.

Выводы автора:

• MCP предоставляет стандартный способ интеграции ИИ-моделей с внешними инструментами и данными, RAG обеспечивает актуальность информации, а AI агенты действуют автономно в отличие от чат-ботов.
• Репликация, шардирование, consistent hashing, quorum и Saga — это проверенные паттерны для масштабирования и надёжности распределённых систем.
• Контейнеризация превосходит виртуализацию по скорости и эффективности, но требует совместимости ядра ОС, в то время как виртуализация обеспечивает полную изоляцию разнородных ОС.

Контейнеры запускаются за миллисекунды, потому что вы не загружаете ОС, а просто запускаете процесс.

Оригиналы:EP224: MCP vs RAG vs AI Agents

Автоматизация UI-тестов Android на облачной ферме устройств

Разработка и архитектура · Habr · 7/10

Статья QA-специалиста Selectel описывает путь от ручного к полностью автоматизированному тестированию Android-приложений с использованием облачной мобильной фермы из ~400 устройств. Первый этап охватывает создание простого Compose UI-теста (приложение с кнопкой, меняющей текст) в Android Studio, добавление ADB-ключа для подключения к устройству фермы через консоль и запуск теста командой ./gradlew connectedAndroidTest. Второй этап описывает полную автоматизацию подключения через открытый API мобильной фермы: создание сервисного пользователя с нужными правами (mobile_farm.user или mobile_farm.admin), генерацию уникального ADB-ключа и написание Python-скрипта для авторизации, получения списка всех Android-устройств в проекте, их захвата и запуска ADB-сессий. Автор подробно разбирает код авторизации через токены, методы работы с REST API мобильной фермы и логику подключения к множеству устройств одновременно. Ферма совместима с популярными инструментами (Appium, Espresso, Compose UI, Paparazzi) и позволяет запустить один тест на любом количестве реальных девайсов без переделки кода.

Выводы автора:

• Compose UI-тесты для Android можно интегрировать в облачные фермы устройств через API и запускать на сотнях девайсов одновременно с минимальной ручной работой
• Автоматизация тестирования требует правильной настройки доступа (ADB-ключи, сервисные пользователи, области доступа) и Python-скриптов для управления жизненным циклом подключений

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

Оригиналы:От ручного тестирования к автоматизированному: пишем compose UI-тест под Android

Google использует б/у DDR4 в AI-серверах для экономии

Разработка и архитектура · Habr · 7/10

Google столкнулась с критическим узким местом в ИИ-инфраструктуре: память теперь составляет около 75% стоимости комплектующих современного AI-сервера. Чтобы снизить капитальные затраты и обойти дефицит полупроводников, компания разработала систему переработки вычислительных узлов, извлекая модули DDR4 из списанных серверов и повторно интегрируя их в актуальную инфраструктуру.

Новые чипы TPU8i (для инференса) и TPU8t (для обучения) имеют многоуровневую архитектуру памяти: 288 ГБ быстрой HBM3e с пропускной способностью 8,6 ТБ/с, 384 МБ встроенной SRAM для KV-кеша. Хост-процессоры Google Axion на архитектуре Arm первоначально проектировались под DDR5, но инженеры адаптировали их под DDR4 из-за экономических и логистических причин. Прямой монтаж модулей DDR4 невозможен из-за различий в физических и электрических спецификациях, поэтому Google разработала специальные аппаратные адаптеры-конвертеры для подключения RDIMM DDR4 к современным платформам. Параллельно компания оптимизирует программное обеспечение: перерабатывает системное ПО для минимизации задержек и внедряет алгоритмы сжатия и стриминга данных, чтобы медленный обмен с DDR4 не снижал производительность. Такой подход позволяет высвободить бюджет на дорогостоящие стеки HBM3e, критические для работы ускорителей.

Выводы автора:

• Память стала главным узким местом и драйвером стоимости AI-инфраструктуры, превысив 75% бюджета комплектующих
• Google разработала систему вторичной переработки DDR4 с аппаратными адаптерами и оптимизацией ПО для повторного использования старых модулей в новых серверах
• Повторное использование DDR4 в хост-сегменте позволяет перенаправить средства на покупку критичных для производительности HBM3e без потери стабильности

Память окончательно стала основным узким местом ИИ-инфраструктуры, формируя порядка 75% стоимости комплектующих современного AI-сервера

Оригиналы:Google ставит б/у плашки DDR4 в новые AI-серверы

Как Яндекс управляет доступами к 1500 системам через IDM без перегруза

Кибербезопасность · Habr · 9/10

Рассказ руководителя IDM (Identity Manager) Яндекса о том, как система централизованного управления доступами выросла из внутреннего инструмента в масштабную платформу. Первая версия IDM быстро стала узким местом: очередь на подключение превысила количество подключённых систем, а запросы на доработки от каждой системы копились быстрее, чем их могли реализовать. Команда перешла от модели сервиса (где они сами подключали системы) к модели self-service платформы, определив чёткий контракт из 4 основных методов (add-role, remove-role, info, get-roles). Решили проблему множественности ролей через параметризацию: вместо сотен тысяч комбинаций ролей системы теперь могут предоставлять произвольные параметры, которые IDM использует для генерации форм запроса. Для согласования доступов внедрили Policy as Code на Python, исполняемый в изолированных контейнерах (sandbox) с ограничениями по времени и памяти. Запустили открытый API, позволяющий командам автоматизировать свои процессы: запросы, подтверждения, отзыв ролей. Сейчас в IDM подключено более 1500 систем, через неё проходит около 9 млн запросов в месяц от 30 тыс сотрудников, более 98% обрабатывается автоматически. Команда столкнулась с новой проблемой — сверкой данных о ролях между IDM и подключёнными системами для гарантии консистентности.

Выводы автора:

• Self-service интеграция решила проблему масштабирования: вместо того чтобы команда IDM сама подключала системы, она определила чёткий контракт и позволила командам подключаться самостоятельно.
• Policy as Code на Python в изолированных контейнерах позволил гибко задавать правила согласования для разных сценариев без риска сломать основную платформу.
• Открытый API позволил командам строить собственные процессы и автоматизацию поверх IDM, избежав очередей фич-реквестов в команду платформы.

Если мы продолжим всё это делать сами, то наши планы и возможности опять перестанут сходиться. Поэтому следующий шаг — перестать быть сервисной командой и стать платформой.

Оригиналы:IDM на максималках: как управлять доступами к 1500 систем Яндекса

Durev VPN присваивает исследования независимых разработчиков для рекламы

Кибербезопасность · Habr · 8/10

Статья повествует о том, как команда коммерческого сервиса Durev VPN переписывает статьи независимого исследователя в сценарии для YouTube-роликов, убирая любые упоминания об авторе, и монетизирует чужой контент через продажу подписок. Один из роликов «СРОЧНО УДАЛИ СЕРТИФИКАТ МИНЦИФРЫ» собрал 795 тысяч просмотров за два дня; при консервативной оценке конверсии даже в 1% это принесло бы создателям минимум 313 тысяч рублей ежемесячно. Автор провёл детальный разбор четырёх видео, выявив систематическое копирование: замену авторства («мы» на «наши специалисты»), дублирование архитектурных схем, терминов и выводов, повторение даже допущенных ошибок. При попытке диалога владелец сервиса (maxpowertrade) отвечал насмешками, ссылался на «совпадение» и «Fair Use», забыв о требованиях российского и американского законодательства об указании автора. Компания зарегистрирована в Казахстане; при тестировании сервиса обнаружены проблемы с производительностью (пинг 494 мс против 213 мс у конкурента) и ограничениями (рейт-лимиты, блокировка возвратов, произвольное снижение трафика).

Выводы автора:

• Durev VPN систематически присваивает технический контент независимых исследователей, выдавая чужие открытия за работу своих специалистов, и монетизирует плагиат через продажу VPN-подписок на сотни тысяч рублей в месяц.
• При попытке разрешить конфликт владелец сервиса использовал насмешки и необоснованные ссылки на Fair Use, нарушив требования авторского права о указании источника и имени автора.

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

Оригиналы:Как Durev VPN крадут статьи независимых исследователей для рекламы своего сервиса

Как ограничена безопасность ассистента по умолчанию на Android

Кибербезопасность · Habr · 8/10

Статья разбирает, какие возможности получает голосовой ассистент (на примере Алисы AI) при выборе его ассистентом по умолчанию на Android, и главное — какие барьеры безопасности при этом остаются. Вопреки интуиции, назначение ассистента по умолчанию не даёт ему полный доступ к данным телефона. Android автоматически выдаёт только базовые разрешения, а для расширенного функционала требуется явное согласие пользователя на каждую возможность — микрофон, камеру, контакты, геопозицию. Ассистент получает информацию об открытом экране только в момент активации пользователем, но не может следить за переходами между приложениями или работать в фоне. Для управления другими приложениями ассистент может использовать только стандартные интенты Android, публичные API или предусмотренные механизмы — универсального пульта от всех приложений у него нет. Архитектура Android предусматривает три уровня ограничений: песочница приложений, недоступность системных разрешений для сторонних программ и необходимость поддержки со стороны других приложений. Выбор ассистента по умолчанию улучшает удобство использования, но не ослабляет модель безопасности системы.

Выводы автора:

• Назначение ассистента по умолчанию не даёт ему автоматический полный доступ к данным и функциям телефона — все расширенные возможности требуют отдельного согласия пользователя.
• Ассистент может получать информацию об открытом экране только при активации пользователем, но не имеет постоянного мониторинга и фонового доступа к данным.
• Управление другими приложениями возможно только через стандартные интенты, опубликованные функции или API — архитектура Android не предоставляет универсальный механизм контроля.

Назначение по умолчанию делает взаимодействие с Алисой AI удобнее, но не меняет модель безопасности Android: полного доступа к смартфону у неё не появляется.

Оригиналы:Что умеет ассистент по умолчанию на Android — на примере Алисы AI

Норвегия может первой запретить смарт-очки с функциями съёмки

Кибербезопасность · Habr · 7/10

Норвегия рассматривает возможность полного запрета смарт-очков с камерами для фото- и видеосъёмки. Министр цифровизации Карианне Тунг выразила обеспокоенность нарушением приватности и функцией распознавания лиц в общественных местах. Правительство планирует создать экспертную группу для разработки нового законодательства, а защитник прав потребителей призвал ретейлеров заморозить продажи таких устройств. Мета активно разрабатывает функцию Name Tag для смарт-очков Ray-Ban, позволяющую автоматически идентифицировать людей и сопоставлять их лица с профилями. Хотя Мета удалила код системы в июне и не приняла окончательное решение о запуске, компания продолжает инвестировать в эту технологию и даже подала заявку на патент. Вызывают озабоченность инциденты с утечкой данных: сотрудники кенийской компании Sama просматривали видео со смарт-очков Мета для обучения моделей ИИ и видели интимные моменты пользователей. Компания разорвала отношения с Sama. Также Мета разрабатывает прототипы Aperol с постоянно включённой камерой без световой индикации, что ещё больше усугубляет проблемы с приватностью.

Выводы автора:

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

Умные очки оказывают негативное влияние на личную жизнь и её неприкосновенность, вызывает обеспокоенность функция распознавания лиц в общественных местах.

Оригиналы:Норвегия может стать первой страной, запретившей умные очки с функциями съёмки

HTTP vs HTTPS: как работает защита данных в сети

Кибербезопасность · ByteByteGo · 7/10

Материал объясняет фундаментальное различие между незащищённым HTTP и защищённым HTTPS протоколами при передаче данных между клиентом и сервером. HTTP отправляет данные в открытом виде, позволяя перехватить пароли и токены прямо в сети через простое TCP-соединение. HTTPS добавляет четыре уровня защиты: стандартный TCP-handshake, проверку сертификата (клиент верифицирует, что сертификат подписан доверенным Certificate Authority и принадлежит реальному серверу), асимметричное шифрование при обмене ключами (клиент генерирует сеансовый ключ, шифрует его открытым ключом сервера, и только сервер может расшифровать приватным ключом) и финальное симметричное шифрование всех данных этим сеансовым ключом. Таким образом гарантируется конфиденциальность и аутентификация соединения.

Материал содержит наглядное объяснение, полезное для разработчиков и системных администраторов.

Выводы автора:

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

Когда вы открываете веб-сайт, разница между HTTP и HTTPS решает, безопасно ли ваши данные передаются или находятся в открытом виде.

Оригиналы:HTTP vs. HTTPS на Substack

«Финтех-АБС»: микросервисная архитектура как стратегия банковского роста

Финтех и финансы · Б.О: Не банки · 7/10

Материал обсуждает трансформацию банковских систем управления: замену монолитных архитектур на микросервисную платформу «Финтех-АБС», которая позволяет банкам эволюционировать из классических посредников в центры цифровых экосистем. Монолитные АБС — это жёстко интегрированные системы, где любые обновления требуют вмешательства в ядро и влекут риски отказа; микросервисная архитектура позволяет внедрять новые функции без остановки, интегрироваться с внешними сервисами через открытые API и масштабироваться без пропорционального роста затрат. Платформа определяется как «искусство прибыли» — она не только автоматизирует процессы, но создаёт новые источники дохода через персонализацию, аналитику данных и динамическое ценообразование. Технически система строится на принципах модульности, контейнеризации и распределённости, где каждый микросервис отвечает за конкретную функцию (платежи, кредитование, риск-менеджмент). Переход сопряжен с вызовами: перестройкой организационной культуры, интеграцией с устаревшими системами, обеспечением безопасности в распределённой среде. Авторы прогнозируют, что микросервисные АБС станут отраслевым стандартом, а банки, не перестроившиеся, потеряют конкурентные позиции.

Выводы автора:

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

Монолит фиксирует банк в прошлом, а «Финтех-АБС» открывает путь в будущее

Оригиналы:«Финтех-АБС»: стратегическая платформа нового поколения

Почему вы чувствуете себя чудаком в компании, хотя это не совсем так

Продукт и карьера · John Cutler from The Beautiful Mess · 8/10

Джон Катлер разбирает иллюзию однородности в организациях: люди кажутся согласными с корпоративными нормами, но это часто просто адаптация к власти-взвешенным правилам, а не отражение их истинных убеждений. Организации намного более разнообразны в убеждениях, чем это проявляется в поведении. Мы видим три наложенных друг на друга слоя: власть-взвешенные нормы, адаптацию людей к окружающей среде и их подлинные ценности. Лидеры тоже адаптируются к ожиданиям сверху, что создает замкнутый круг — люди видят чужую адаптацию, интерпретируют её как убеждение, и сами адаптируются дальше. Адаптация не равна одобрению; люди могут стремиться к безопасности, амбициям или координации, не делясь этим открыто. Для раскрытия подлинных взглядов нужны три условия: удача в знакомстве, время для доверия и подходящий контекст разговора. LinkedIn усиливает этот эффект норм, так как сотрудники видят друг друга в профессиональном контексте и выражают только «безопасные» убеждения.

Выводы автора:

• Вы видите только адаптированное поведение людей, а не их реальные убеждения и ценности
• В вашей организации куда больше единомышленников и "чудаков", чем кажется, но они скрывают себя из-за рисков
• Видимое согласие с корпоративными нормами часто — результат социального давления и обстоятельств, а не истинной приверженности этим нормам

Организации часто более разнообразны в убеждениях, чем это проявляется в поведении. То, что вы видите, — это не просто то, во что верят люди.

Оригиналы:TBM 438: Единственный ли я в этой компании? · Прочитать полный текст в приложении