Connect with us

Статьи

Секрет сильного искусственного интеллекта следует искать в мозге человека

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

Анна Гуляева

Опубликовано

/

     
     

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

Будущее карт: автомобили, AR и угроза приватности

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

Из-за этих и других ограничений лидеры области считают, что нужен другой подход. Джофф Хинтон, один из самых выдающихся AI-специалистов, недавно сказал, что нам нужно начать все заново, так как он “очень подозрительно” относится к существующим методам: “Я считаю, что нам нужно всё выбросить и начать с начала”. Франсуа Шолле, ведущий практик сетей глубокого обучения, сказал: “Вы не можете достичь сильного интеллекта при помощи масштабирования существующих техник”.

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

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

Естественная глупость опаснее искусственного интеллекта

Недавно ученые, работающие с искусственным интеллектом, обратились за вдохновением к мозгу. Демис Хассибис, сооснователь DeepMind, сказал: “Человеческий мозг — это единственное существующее доказательство того, что общий тип интеллекта, который мы пытаемся создать, возможен, поэтому мы считаем, что стоит попытаться понять, как достичь этих возможностей”.

Я согласен. Я изучаю мозг более тридцати лет. В 2004 я написал книгу On Intelligence, которая предполагала, что изучение мозга пригодится для создания ИИ. И в 2005 я стал сооснователем Numenta, компании по реверсинжинирингу коры головного мозга, самой большой его части, которая чаще всего ассоциируется с интеллектом. Мы хотим понять, как клетки в голове работают вместе, создавая восприятие и поведение.

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

Исследования Numenta раскрыли несколько важных принципов, которые использует мозг и которые придется освоить искусственному интеллекту. Например, у каждого нейрона в мозге есть тысячи синапсов (связей между нейронами). Предназначение многих из синапсов остается загадкой. Мы открыли, что нейроны используют большую часть синапсов, чтобы делать прогнозы. Эти предсказания появляются в клетках и играют решающую роль в наших ожиданиях от будущего. Искусственные нейроны не имеют этой функции и не могут делать такие прогнозы. Мы также обнаружили, почему обучение мозга достигается по большей части при помощи формирования новых синапсов. Это более мощная форма обучения, чем изменение существующих связей, которое происходит в глубоком обучении. Это объясняет, почему мы узнаем новые вещи быстрее.

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

Посмотрите на эту картинку. Очевидно, это кружка. Но, конечно, на самом деле это не кружка, а набор линий на плоской поверхности. Нам сложно увидеть эти линии в плоскости, а не как трехмерный объект. Распространенное убеждение среди нейробиологов гласит, что кора воспринимает изображение от глаз и шаг за шагом она выделяет всё больше свойств, пока не сможет распознать предмет.

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

До недавнего времени никто не понимал, как кора головного мозга трансформирует плоское изображение в ментальную репрезентацию настоящего объекта. Мы поняли, как это происходит. Мы обнаружили, что все входные данные для коры связываются с сигналом, представляющим “локацию”. Когда вы смотрите на изображение кружки, для каждой части картинки и каждого отрезка линии назначается локация, связанная с реальной трехмерной кружкой. Похожим образом компьютеры создают CAD-модели объектов.

Скоро мы перестанем программировать компьютеры. Мы будем обучать их как собак.

Наша теория объясняет, почему вы воспринимаете кружку в трех измерениях и почему вы можете представить, как бы она выглядела с разных сторон. Это также объясняет, почему ваше восприятие кружки является стабильным, хотя ваш взгляд перемещается и останавливается на разных частях изображения. Если для входных данных назначены правильные локации кружки, то неважно, как вы смотрите на изображение.

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

Уже десятилетиями ведутся споры о том, насколько ИИ должен имитировать мозг. Недавний успех глубокого обучения, которое почти не связано с мозгом, укрепил аргумент о том, что ИИ может развиваться без нейробиологии. Но этот успех показал пределы глубокого обучения и сделал очевидной потребность в новых подходах. Мозг — это очевидное место для поиска новых идей. Как недавно сказал Джефф Безос: “Люди фундаментально отличаются от того, что мы сегодня делаем с машинным обучением и машинным интеллектом”.

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

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

 

Комментарии
Если вы нашли опечатку - выделите ее и нажмите Ctrl + Enter! Для связи с нами вы можете использовать info@apptractor.ru.
Advertisement
Click to comment

You must be logged in to post a comment Login

Leave a Reply

Аналитика магазинов

Как iOS и Android разделили мобильный рынок

Ходят легенды, что раньше на рынке мобильных устройств было много операционных систем, и они делили рынок на примерно равноценные части… AppCraft рассказывает о том, как было все на самом деле, и что происходит с платформами сейчас.

AppCraft

Опубликовано

/

Автор:

Беглый поиск в Google позволил найти занимательную информацию о том, что первые изменения начались в недалеком 2010-ом. В августе того года на geektimes опубликовали статью с заголовком “Android вырвался на 3-е место по продажам на рынке мобильных ОС”, и в комментариях помимо баталий начались предсказания даты, когда Android захватит мир.

Выглядел переходный момент вот так:

Распределение операционных систем проданных смартфонов за 2 кв. 2010 года

Диаграмма показывает статистику по проданным смартфонам по всему миру за второй квартал 2010 года от исследователей из Gartner, а к апрелю 2011 года компания Nielsen подбила статистику по США, что позволяет нам сегодня легко определить ту самую отправную точку успеха Android:

Распределение операционных систем проданных смартфонов в США в марте 2011 года:

Распределение операционных систем проданных смартфонов в США в марте 2011 года

И уже в августе 2011 года аналитики Сanalys опубликовали информацию о том, что Android захватил половину рынка, став самой распространенной платформой среди пользователей смартфонов.

Распределение мирового рынка операционных систем в 2011 году

Заканчивая небольшую историческую справку, скажу, что даже сооснователь Apple Стив Возняк в том же 2010 году в интервью De Telegraaf беспристрастно заявил, что Android станет доминирующей платформой, поэтому назвать текущее положение дел на рынке удивительным не получится – тенденция к этому была очень наглядной и устойчивой.

Распределение операционных систем в 2017 году

На сегодняшний день Android сохраняет лидерские позиции по количеству пользователей в мире с большим отрывом от других участников рынка. Однако в ряде стран показатели сильно расходятся со среднестатистическими данными. Статистический сервис StatCounter удобно демонстрирует результаты аналитики рынка мобильных операционных систем с разбивкой по месяцам, странам и другим параметрам. Вот так распределялись платформы по рынку за последний год:

На долю Android приходится 73.54% рынка, на iOS – 19.91%, оставшиеся 6.5% распределены между другими системами.

Но если взять данные за этот же промежуток времени – с декабря 2016 по декабрь 2017, но по Канаде, то мы увидим совсем иное распределение:

Именно такие нюансы нужно учитывать при выборе платформы для разработки вашего приложения. Подобные графики можно посмотреть на StatCounter по миру, Европе, Африке, Азии и некоторым крупным странам за период с 2009 по 2017 год.

Платежеспособность iOS и Android пользователей

Финансовые возможности пользователей двух основных операционных систем регулярно сравнивают практически все аналитические фирмы в сфере IT. Из года в год результаты меняются не кардинально, но проследить некоторую динамику в существующих изменениях можно. Исследовательская компания App Annie наглядно продемонстрировала, что несмотря на рост скачиваний приложений из Google Play, платить за контент пользователи Apple готовы значительно больше.

Количество загруженных приложений

Количество потраченных денег

Говоря о динамике, хочется обратить внимание на разрыв в выручке между App Store и Google Play – он почти не сокращается. Здесь и раскрывается вопрос платежеспособности владельцев девайсов на этих платформах.

Разберемся подробнее:

  1. Число загрузок из App Store за год практически не изменилось, а пользователи Android стали скачивать больше приложений.
  2. За второй квартал 2017 года из Google Play было загружено 17 миллиардов приложений – на 135% больше, чем из App Store за тот же период. Разница в количестве скачиваний между операционными системами по сравнению с прошлым годом увеличилась практически на 30%.
  3. Пользователи iOS при том же количестве загрузок стали платить за контент гораздо больше, а траты владельцев Android увеличились незначительно.

Вывод получается однозначным: пользователи iOS тратят больше денег на покупки в мобильных приложениях, хотя скачиваний на Android больше в 2,5 раза.

Так для какой платформы разрабатывать приложения?

До запуска рекламной кампании сложно предсказать, какая именно платформа принесет больше прибыли для конкретного приложения. Выбор платформы в первую очередь должен быть связан с идеей вашего приложения и его целевой аудиторией. Причем целевой аудиторией в широком смысле: важен не только возраст и интересы, но и регион проживания, ведь где-то соотношение iOS к Android практически 1/1.

Монетизация приложений для двух описанных платформ разная: как мы выяснили, пользователи техники Apple тратят больше денег на покупки в приложениях, поэтому приложения, подразумевающие премиум–аккаунты, внутренние покупки и прямую монетизацию пользователя в приложении, стоит разрабатывать скорее для iOS.

В то же время столбец с доходами Google Play не на нуле. Мы уже писали, что пользовательское внимание сегодня стоит дорого, поэтому самым простым и популярным способом вывода в прибыльность Android–приложений является реклама. Когда ваше приложение скачивают миллиарды пользователей, найти рекламодателей, желающих урвать хотя бы 15 секунд внимания своей целевой аудитории, не сложно.

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

Комментарии
Продолжить чтение

Разработка

Почему структура команды разработки может вас замедлять

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

Анна Гуляева

Опубликовано

/

“Почему мы так медленно выпускаем новые функции так медленно?” — думал я спустя год после присоединения к быстро растущему стартапу. Релиз каждой новой функции был болезненно долгим. Это не то, чего я ожидал — стартапы должны двигаться быстро. Особенно, если вы ещё не нашли свою нишу. В начале моей работы у нас было три команды разработки. Спустя год и несколько миллионов инвестиций у нас в распоряжении было девять команд разработки. Наша способность к разработке утроилась, но новые функции выходили с той же скоростью. В чем же дело? Я думаю, что дело было в законе Брукса, который утверждает, что добавление новых разработчиков в проект на поздней стадии, приводит к ещё большему замедлению проекта. Мы наняли многих отличных разработчиков, но им нужно было понять что замедляло остальных сотрудников.

Наш мотивирующий постер для разработчиков

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

Проблема и урок

Мы только выпустили новую функцию фильтрации по тегам. Поддержка получала жалобы о том, что функция не работает. Первым делом я попытался загрузить картинку и отметить её как “Не хот-дог”. Потом я попробовал отфильтровать картинки по этому тегу и убедился, что фильтрация не работает. Я составил список команд, которые участвовали в создании функции. Каждая команда была ответственна за свой компонент:

  1. Загрузка и обработка изображений.
  2. Elasticsearch.
  3. Фронтенд фотоальбома.
  4. Команда DevOps, ответственная за инфраструктуру и развертывание новых функций в облаке.

Я решил сначала поговорить с командой по загрузке изображений. Я спросил руководителя команды, почему их функция не работала. Он посмотрел, что теги были сохранены и предположил, что они не были проиндексированы, что привело меня к команде Elasticsearch. Разработчик из следующей команды заглянул в Elasticsearch. Тег был проиндексирован, все выглядело отлично. Поэтому он отправил меня к команде фронтенда альбома. Они обнаружили, что фронтенд-библиотека была развернута в более старой версии. Функция фильтрации зависит от этой библиотеки, поэтому это, вероятно, было причиной проблемы. Фронтенд-команда посоветовала мне поговорить с командой DevOps, чтобы они развернули нужную библиотеку. Я устал ходить от одной команды к другой и сказал им, чтобы они сразу исправили эту проблему. Наконец проблема была решена. Я понял, что командам не хватало ответственности за то, что они создавали. Команды были разбиты по компонентам, и никто из них не чувствовал ответственности за функции – каждый работал только над маленьким кусочком пазла. Разбитие команд по компонентам сделала быстрый выпуск новых функций сложным. Все их усилия были тесно связаны. Если одна из четырех команд не работала или задерживалась, это влияло на выпуск всего функционала.

Почему компании начали разбивать команды по компонентам?

В начале разработки продукта команды часто самостоятельно разбиваются по компонентам. Если сам продукт пока не имеет структуры, то технические компоненты для его работы понятны. Поэтому команды проще организовать по этим компонентам. Эта идея довольно проста — каждая команда ответственна за один или более компонентов. Такая структура помогает увеличить продуктивность разработчиков, которые работают над конкретными частями системы. Создание чего-то нового на Amazon RedShift? Только одна команда должна беспокоиться об изучении RedShift. Недостаток таких команд заключается в том, что менеджеры должны беспокоиться о выпуске функций. Границы между командами создают зависимости, которые требуют активного управления. Это возможно, если у вас не так много компонентов или функции не распределены между множеством команд. Представьте, что вы владелец продукта и хотите внедрить Feature 2,  как на картинке ниже. Она зависит от двух компонентов, за которые отвечают разные команды. Функция выйдет, только если обе команды завершат необходимую работу над своими компонентами. Вернемся к примеру с фильтрацией тегов. Так как даже причину неисправности было сложно установить, представьте, как неэффективно было заставлять все эти команды координироваться ради одной маленькой функции. Любая задержка в любом компоненте вызывала задержку релиза функции. Чем больше компонентов и команд вовлекалось в дело, тем больше возникало проблем с координацией и вынужденного ожидания. Если один спринт одной команды проваливается, функция не может быть выпущена.

Альтернатива: команды по функциям

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

Переход к командам по функциям

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

  1. Разработка небольших функций занимает больше времени, чем вы ожидали, потому что они находятся в зонах ответственности разных команд.
  2. При возникновении проблем все показывают пальцем друг на друга. Никто не несет ответственность за функцию.

Если это происходит, вам стоит рассмотреть переход на команды по функциям. Такая работа имеет свои сложности: вам нужно будет придумать лучшее распределение компонентов между командами и подстроить свою архитектуру, чтобы разъединить как можно больше компонентов. Переход к командам по функциям — это самая сложная часть работы с подобной структурой. Как структурировать команды? Как передавать знания? Как убедиться, что организация разрешит вам изменить структуру? Этому будет посвящена уже другая статья.    https://apptractor.ru/develop/myi-uvolili-nashego-luchshego-razrabotchika.html https://apptractor.ru/info/articles/vyi-uvolili-luchshego-razrabotchika-nadeyus-vyi-dovolnyi.html  

Комментарии
Продолжить чтение

Программирование

Создание анимации в 7 строк кода

Android-разработчик Леонардо Пирро рассказывает, как создать простую анимацию при помощи ConstraintLayout и ConstraintSet.

Анна Гуляева

Опубликовано

/

Заниматься анимацией всегда весело, но это довольно сложно, так как вам нужно будет сделать много вычислений, измерений и другой работы с интерфейсом. По той причине создание анимации занимает много времени и усилий.

ConstraintLayout + ConstraintSet

Я хочу поделиться с вами новым способом создания анимаций в приложении при помощи всего семи строк кода, используя Keyframe Animations, ConstraintLayout и ConstraintSet. Эта концепция заключается в создании двух разных макетов: одного для начальной точки и одного для конечной точки анимации. Давайте посмотрим, что мы хотим создать: наша цель — создать плавную анимацию детали, которая будет появляться при нажатии пользователем на экран.

Анимация создается при помощи двух файлов макета: circuit.xml and circuit_detail.xml. Эти макеты очень похожи и различаются только тем, что на первом элементы вынесены за экран, а на втором — находятся в нужной позиции.

Поэтому давайте создадим анимацию и увидим, как просто создавать анимацию при помощи ConstraintLayout и ConstraintSet.

Пусть магия произойдет

Сначала создадим отдельный ConstraintSet, куда мы скопируем ограничения второго макета, вызвав метод clone():

val constraintSet = ConstraintSet()
constraintSet.clone(this, R.layout.circuit_detail)

Теперь создадим объект перехода, используемый для установки интерполятора и продолжительности анимации:

val transition = ChangeBounds()
transition.interpolator = AnticipateOvershootInterpolator(1.0f)
transition.duration = 1200

Сейчас вызовем TransitionManager.beginDelayedTransition(), который используется для осуществления перехода на следующий кадр рендеринга. Затем мы вызываем applyTo(), чтобы начать анимацию.

TransitionManager.beginDelayedTransition(constraint, transition)

constraintSet.applyTo(constraint)

Это действительно семь строк кода. Вот и все! Вы можете посмотреть полный пример в моем репозитории GitHub по этой ссылке.

Комментарии
Продолжить чтение

Статьи

Как лучшие руководители сочетают два подхода к видению мира

Что общего между Генри Фордом и Биллом Гейтсом? Дело в сочетании двух подходов к своей работе, которое могут применять люди любых профессий, считает основатель рассылки Design Luck Зат Рана.

Анна Гуляева

Опубликовано

/

Когда Microsoft впервые представила Windows, это не произвело особого шума. Первая версия вышла в 1985 году и почти не привлекла внимания. В последующие годы популярность начала расти, но только в начале 1990-х система начала набирать обороты.

Несколько первых десятилетий существования Microsoft Билл Гейтс был очень вовлечён в каждый аспект своего бизнеса. Первые пять лет существования компании он просматривал каждую строчку кода лично. Компании несколько раз крупно повезло, но даже если учесть это, то вряд ли люди, отличающиеся от Гейтса, смогли бы развить Microsoft до нынешнего размера.

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

Теперь их подходу во многом следует Илон Маск. Он создал уже не одну компанию, обладающую потенциалом изменить мир. Интересно, что около 80% своего времени он проводит, работая над дизайнерскими и инженерными проблемами.

Фокус на деталях

Безусловно, лидер должен мыслить глобально. Мы предполагаем, что на высшем уровне руководители либо устраняют крупные проблемы, либо заключают крупные сделки. Это часть работы CEO.

Но любопытно, что успех многих самых влиятельных лидеров в истории можно отследить до мельчайших и, казалось бы, неважных вещей. Это относится ко всем людям – от Томаса Эдисона, Альфреда Слоуна и Генри Форда до Гейтса, Джобса и Маска.

Так, например, в биографии Маска Эшли Вэнс рассказывает о письме, которое он лично отправил каждому сотруднику SpaceX. Это было предупреждение о чрезмерном употреблении аббревиатур. Маск посчитал, что это выходит из-под контроля и может в будущем привести к неэффективной коммуникации, если создание новых слов и смыслов продолжится. Этот человек работает от 80 до 100 часов в неделю над революционными проектами, и довольно необычно, что он потратил час или два, чтобы написать о такой небольшой проблеме.

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

Эффект формирующего

Рэй Далио — основатель крупнейшего хедж-фонда в мире Bridgewater Associates. В своей книге он поделился тем, что провел несколько лет за анализом того, что делает некоторых людей более эффективными в достижении больших результатов при управлении крупными компаниями. Многие преемники людей, вроде Джобса или Гейтса, справляются не так хорошо, и чтобы избежать того же для своей компании, он хотел лучше понять, что отличает таких людей. Далио разработал тесты для понимания людей, которых он нанимает, их сильных и слабых сторон.

Чуть позже он пригласил Гейтса и Маска пройти некоторые из этих тестов, как и других людей, достигших уникального успеха. Он обнаружил, что многих из этих людей можно назвать «формирующими», и их особенность заключается в том, что они сильны как в стратегических, так и в тактических вопросах. Они эффективны и в работе над небольшими деталями, и в разработке глобальных планов, которые будут вести их на протяжении долгого времени.

Что это значит?

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

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

 

Комментарии
Продолжить чтение

Постеры для разработчиков

Наша рассылка

Каждому подписавшемуся - "1 час на UI аудит": бесплатный ускоренный курс для разработчиков!

Нажимая на кнопку "Подписаться" вы даете согласие на обработку персональных данных.

Вакансии

Популярное

X
X

Спасибо!

Теперь редакторы в курсе.