Драйв (Drive: The Surprising Truth About What Motivates Us) (Рубрика #Management)

Недавно я прочитал эту классическую книгу Даниэля Пинка (обложки в отдельном посте), которая была написана в конце 2000-х годов. В то время она звучала свежо и бросала вызов традиционным представлениям о мотивации, особенно подходу «кнут и пряник», основанному на вознаграждениях и наказаниях. Дэниель смешал фокус на внутренней мотивации, а не внешних стимулах. Автор хорошо вплетал в свое повествование результаты исследований ученых, таких как Дэниеля Канемана и его книгу "Thniking, Fast and Slow" (подробности в моем посте) или Дэна Ариели и его книгу "Predictably Irrational" (подробности в моем посте).

По-факту, Дэниэль Пинк предлагает модель мотивации 3.0, которая основывается на трех столпах
1) Автономия: Желание контролировать свою работу и принимать собственные решения. Пинк подчеркивает, что автономия способствует вовлеченности и креативности, позволяя людям самостоятельно направлять свои усилия.
2) Мастерство: Стремление улучшать свои навыки и достигать совершенства в значимых задачах. Это требует постоянного обучения и упорства.
3) Цель: Необходимость вносить вклад во что-то большее, чем собственные интересы. Связь работы с более высокой миссией усиливает мотивацию и удовлетворение.

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

В итоге, по Пинку есть 3 модели мотивации
1) Мотивация 1.0 — выживание
2) Мотивация 2.0 — вознаграждения/наказания
3) Мотивация 3.0 - внутренняя мотивация на основе автономии, мастерства и цели
Собственно, надо стремиться с мотивации 3.0, но для этого компании должны «платить достаточно, чтобы убрать деньги с повестки дня», чтобы сотрудники могли сосредоточиться на более значимых стимулах. Чем-то эти уровни мотивации напоминают пирамиду Маслоу

Пинк выделяет два типа поведения у людей
1) Тип X - внешне мотивированные
2) Тип I - внутренне мотивированные.
Поведение типа I более устойчиво, так как опирается на возобновляемые внутренние ресурсы, такие как страсть и любопытство.

Книга Пинка написана очень просто и достаточно популярна, но к ней и ряд замечаний
1) Автор по кругу повторяет мысли про автономию, мастерство и цели без особых изменений и развития темы
2) Автор упоминает исследования, что поддерживают его мысли, но почти не упоминает исследования, которые могли бы опровергнуть его выводы, создавая впечатление предвзятости.
3) Некоторые рецензенты считают описание мотивации на рабочем месте слишком упрощенным. Например, Пинк предполагает, что развитие внутренней мотивации автоматически улучшит производительность, игнорируя такие факторы как обучение сотрудников или различия в индивидуальных целях.
4) Центральный аргумент о переходе к внутренней мотивации кажется некоторым критикам преувеличенным. Они отмечают важность внешних стимулов во многих рутинных или некреативных профессиях, которые Пинк практически не рассматривает.
5) Многие рецензенты указывают на то, что *Drive* лишь популяризирует уже существующие психологические теории (особенно теорию самодетерминации), не добавляя существенных новых идей.
6) Книга критикуется за недостаток конкретных шагов по внедрению идей в реальной практике.
7) Акцент на автономии как ключевом факторе мотивации может быть неактуален для всех культур. Критики отмечают ограниченную применимость модели Пинка в странах с более строгими рабочими структурами или другими культурными нормами. Рекомендую почитать на тему разнообразия культур книгу "The culture map" (подробнее в моем посте)

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

#Psychology #Economics #Brain #SelfDevelopment

[4/4] Software Engineering at Google (Делай как в Google. Разработка программного обеспечения) (Рубрика #Engineering)

Продолжая рассказ про эту крутую книгу, поднятый в постах 1 и 2 и 3, здесь я расскажу про четвертую и пятую часть книги под названием "Инструменты" и "Заключение".

IV. Tools (инструменты)
16. Version control and branch management (Управление версиями и управление ветками)
В этой главе авторы описывают, как Google использует управление версиями, а точнее свой монорепозиторий, для управления огромными объемами кода. Авторы объясняют стратегию управления ветками, которые обеспечивают непрерывную интеграцию и совместную разработку. По-факту, это версия TBD (trunk based development)
17. Code search (поиск кода)
Глава сосредоточена на инструментарии, который делает навигацию по огромному кодовому базису эффективной. Она объясняет, как мощные возможности поиска имеют решающее значение для понимания и поддержки крупных систем
18. Build systems and build philosophy (Системы сборки и философия сборки)
Авторы рассказывают про инфраструктуру сборки и практики, включая инкрементальные сборки и автоматизацию. Этот раздел детализирует, как системы сборки Google спроектированы для скорости и масштаба
19. Critique: Google’s code review tool (критика: инструмент обзора кода Google)
Интересная глава про внутренний инструмент, используемый для облегчения обзора кода. Обсуждение охватывает его сильные и слабые стороны, а также влияние на рабочий процесс и эффективность разработчиков.
20. Static analysis (статический анализ)
В этой глава объясняется, как автоматизированные инструменты анализируют исходный код для обнаружения ошибок или отклонений от стандартов до запуска кода. Этот активный подход является ключевым для поддержания качества кода в масштабе.
21. Dependency management (управление зависимостями)
Эта глава рассказывает про методы обработки зависимостей в огромной кодовой базе. Предоставляет стратегии для минимизации конфликтов и поддержания целостности системы по мере эволюции кода. Подробнее про концепт можно почитать на сайте build системы Bazel
22. Large-scale changes (крупномасштабные изменения)
В этой главе авторы обсуждают методы и инструменты для безопасного применения широкомасштабных изменений по тысячам файлов. Глава сосредоточена на планировании, автоматизации и минимизации рисков при обработке крупномасштабных изменений кода. Ясно, что такие возможности во многом основаны на использовании монорепы.
23. Continuous integration (непрерывная интеграция)
Эта глава детализирует практики и инфраструктуру, которые позволяют интегрировать изменения в коде часто и надежно. Непрерывная интеграция показана как необходимая для раннего обнаружения проблем в процессе разработки. Если хочется описания попроще, то рекомендую книгу "Grokking Continuous Delivery" ("Грокаем continuous delivery") тоже от ребят из Google, про которую я уже рассказывал
24. Continuous delivery (непрерывная доставка)
Здесь речь идет про конвейеры и автоматизацию, которые обеспечивают быструю и надежную развертывание изменений. Эта глава подчеркивает, как оптимизированные процессы доставки поддерживают постоянные инновации, сохраняя при этом стабильность. Книга "Grokking Continuous Delivery" тут тоже отлично подходит
25. Compute as a service (вычисления как сервис)
Описывает, как Google использует масштабируемые вычислительные ресурсы для поддержки разработки, тестирования и развертывания. Объясняет, как эта «инфраструктура как сервис» лежит в основе многих инженерных практик Google.

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

#Engineering #Management #Software #Development #Processes #Leadership #SRE #DevOps

[1/2] Squad Health Check и сравнение его с DORA Metrics, SPACE, DevEx (Рубрика #Management)

Буквально на днях наткнулся на древний инструмент опросов от Spotify. Этот концепт был опубликован в далеком 2014 году, через пару лет после публикации знаменитой модели Spotify со всякими гильдиями, сквадами и другими забавными названиями. Эту модель придумал Henrik Kniberg и популяризировал красивыми мультиками и комиксами, что стали виральными. Несмотря на попытки прикрутить модель в лоб, это мало у кого получалось, а потом и создатели сказали, что сами отошли от нее и адаптировали свои процессы под новую реальность. Собствено, Squad Health Check появился больше 10 лет назад, но он до сих пор используется в Spotify. Если упрощать, то squad health check - это инструмент самооценки, разработанный для agile команд,. Он используется для оценки и улучшения динамики команды, производительности и общей эффективности путем отслеживания различных измерений здоровья команды с течением времени. Основными фичами этой системы являются

1) Traffic light system (светофорная система): члены команды оценивают различные измерения с помощью простых цветных индикаторов, что позволяет легко визуализировать общее состояние команды.
2) Dimensions evaluated (jцениваемые измерения): общие измерения включают доставку ценности, простоту выпуска, веселье, здоровье кодовой базы, моральный дух команды и сотрудничество. Их можно настраивать в соответствии с конкретными потребностями команды.
3) Open discussions (открытые обсуждения): результаты используются для содействия обсуждениям проблем и успехов, помогая командам определять области для улучшения и создавать выполнимые планы.
4) Historical tracking (историческое отслеживание): со временем команды могут отслеживать свой прогресс и определять тенденции или повторяющиеся проблемы.

В общем, этот подход был хорош для 2014 года, но с тех пор успели появиться DORA (DevOps Research and Assesment) metrics (подробности в посте про книгу Accelerate), SPACE framework (подробности в посте) и DevEx (подробности в посте), которые шагнули сильно дальше. Если сравнить их между собой то получим примерно следующее (метод Squad health check я буду для краткости называть SHC)

1) Субъективность vs. Объективность.
- SHC сильно зависит от субъективных самооценок участников команды. Это может привести к предвзятым или непоследовательным результатам, так как разные люди могут по-разному интерпретировать вопросы или не быть полностью честными.
- DORA Metrics предоставляет объективные, количественные данные о параметрах разработки (например, deployment frequence или lead time).
- SPACE: Сочетает субъективные и объективные данные, но благодаря своей структуре минимизирует предвзятость, объединяя такие метрики, как удовлетворенность, с измеримыми показателями производительности, которые можно получить через логи/метрики из систем (activity часть SPACE)
- DevEx: Похожим на SPACE образом пытается сбалансировать субъективность и объективность.
2) Отсутствие фокуса на технических метриках
- SHC делает акцент на моральном духе команды, сотрудничестве и процессах, но не уделяет внимания техническим метрикам, таким как частота развертываний или качество кода.
- DORA Metrics сосредоточены на технических параметрах разработки, что делает его очень полезным для оптимизации DevOps/SRE практик
- SPACE охватывает технические аспекты (например, эффективность и поток) наряду с благополучием команды, предоставляя более целостное представление о продуктивности.
- DevEx прямо рассматривает технические препятствия (например, неэффективность инструментов), которые влияют на производительность и удовлетворенность разработчиков.

Продолжение сравнения этих разных подходов в следующем посте.

#Management #Devops #Management #Leadership #Processes #SRE #Software #Metrics #Productivity

[2/2] Squad Health Check и сравнение его с DORA Metrics, SPACE, DevEx (Рубрика #Management)

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

3) Ограниченная масштабируемость и анализ трендов
- SHC затрудняет агрегацию результатов по нескольким командам - частота опросов, список ответов и многое другое команды могут кастомизировать под себя. Это приводит к проблемам при отслеживании тенденций
- DORA Metrics хорошо масштабируется между командами и предоставляет четкий анализ трендов для оценки производительности с течением времени.
- SPACE разработан для анализа продуктивности как на уровне отдельных сотрудников, так и на уровне всей организации, что делает его масштабируемым и эффективным для анализа трендов.
- DevEx предлагает структурированный подход к измерению опыта разработчиков в разных командах, что позволяет последовательно отслеживать улучшения в таких областях, как состояние потока и обратная связь.
4) Применимость полученных данных
- SHC иногда приводит к выводам, что бывают слишком общими или расплывчатыми для того, чтобы их можно было напрямую преобразовать в конкретные действия. Обсуждения могут сосредотачиваться больше на симптомах, чем на их причинах.
- DORA Metrics: Определяет конкретные област, например, MTTR (mean time to recover), которые можно улучшить с помощью целевых вмешательств, таких как оптимизация CI/CD.
- SPACE предоставляет данные, связывая метрики с конкретными аспектами продуктивности (например, проблемы в коммуникации). Это позволяет легко понять как их использовать для оптимизации
- DevEx сосредоточен на изменениях в инструментах и процессах разработчиков, которые напрямую повышают продуктивность и удовлетворенность.
5) Чрезмерный акцент на моральном духе
- SHC сильно акцентирует внимание на моральном духе команды, удовольствии от работы и сотрудничестве, но может упускать из виду важные бизнес-результаты или техническую эффективность.
- DORA Metrics отдает приоритет метрикам производительности разработки, которые влияют на эффективность разработки, а через нее на бизнес-результаты.
- SPACE уравновешивает моральный дух с другими аспектами (например, эффективностью и потоком), обеспечивая учет как благополучия команды, так и бизнес-целей.
- DevEx фокусируется на улучшении опыта разработчиков в целом при согласовании с организационными целями (например, ускорение вывода продукта на рынок).
6) Ресурсоемкость
- SHC требует подготовки фасилитаторов для эффективного проведения обсуждений. Регулярное проведение оценки может быть трудоемким для команд под давлением сроков.
- DORA Metrics позволяет автоматизировать сбор данных с CI/CD систем, что делает менее ресурсоемким использование системы после внедрения.
- SPACE достаточно сложен из-за многомерной природы данных, которые надо подтянуть из внутренних систем компании, но после первоначального внедрения может работать без супер-больших вложений
- DevEx cосредоточен на автоматизации рабочих процессов и улучшении инструментов разработки, находится где-то посередине между DORA и SPACE.

В заключение можно сказать, что хотя Squad Health Check отлично подходит для обсуждения проблем внутри команды и улучшения межличностных отношений, он уступает DORA Metrics, SPACE Framework или DevEx Framework в объективности измерений, техническом фокусе, масштабируемости и применимости данных. Организации должны выбирать фреймворк исходя из своих целей — будь то улучшение морального духа команды или повышение технической эффективности.

#Management #Devops #Management #Leadership #Processes #SRE #Software #Metrics #Productivity

Я люблю читать канал "Малоизвестное интересное", так как там периодически, бывают очень интересные мысли. Они позволяют мне самому чуть шире взглянуть на происходящее на переднем краю технологических возможностей, а иногда этот взгляд не шире, но как будто под другим углом:) Конкретно в этом посте мне понравилась интересная визуализация и вообще график качество/стоимость для LLMs, а также фронтир возможностей OpenAI, DeepSeek и Gemini моделей.

Кто получит «Мандат Неба»?
Динамика «гонки вооружений» LLM одним слайдом.
«Гонка вооружений» на рынке больших языковых моделей (LLM) определяется просто: все стараются получить максимально высокую точность при минимальной цене. А а «фронтир» отражает лучшие на данный момент варианты по сочетанию этих двух параметров.
Диаграмма показывает [1], как разные версии языковых моделей (от OpenAI, Deepseek, Google «Gemini», Anthropic и др.) соотносятся по:
• стоимости (ось X): цена за миллион токенов - чем правее точка, тем дешевле использование модели (ниже стоимость за миллион токенов).
• качеству (ось Y): рейтинг LMSys Elo - чем выше точка, тем сильнее модель (лучшее качество ответов/результатов).

На диаграмме видны две основные "границы эффективности" (pareto frontier): 
•  Синяя линия от OpenAI, показывающая их модели
•  Оранжевая линия от Gemini 2, которая, судя по надписи, предлагает "лучше, дешевле, круче"
•  Более дорогие и мощные модели в верхней левой части (например, различные версии GPT-4) 
•  Средний сегмент в центре (Claude 3.5, Gemini 1.5) 
•  Более доступные модели в правой части (Amazon Nova Lite, Gemini 1.5 Flash)

Ключевые выводы (по состоянию на февраль 2025)
• Чемпион в соотношении цена-производительность - Gemini 2.0 Flash Thinking (лучше, чем DeepSeek r1 (по ELO) и дешевле
• Стоимость возможностей GPT-4 упала в 1000 раз за 18 месяцев
• Скорость роста возможностей моделей просто немыслимая – так не бывает, … но так есть!

PS Спецы из Google DeepMind полагают, что они близки к получению «Мандата Неба» ("Mandate of Heaven" (天命, Тяньмин)) [2]. Когда говорят, что компания имеет "Mandate of Heaven" в сфере ИИ, это означает, что она занимает лидирующую позицию не просто благодаря рыночной доле, но и благодаря признанию её технологического превосходства и инновационного лидерства.

Но вряд ли конкуренты согласятся 😊

#ИИгонка

[1/2] Behavioral Interview Discussion with Ex-Meta Hiring Committee Member (Рубрика #Management)

Интересное обсуждение поведенческих интервью в бигтех компаниях. Оно само выполнено в виде интервью, которое берет Stefan Mai у Austen McDonald, бывшего senior engineering manager в Meta, а также члена комитета по найму там же. Собственно, в этом интервью Остин делится своим опытом и рассказывает свои мысли относительно поведенческих интервью. Мне эта запись понравилась, так как я часто сам провожу интервью инженеров и руководителей и знаю о чем речь не понаслышке.
Вот что я вынес для себя из этого интервью
1) Остин считает, что поведенческие интервью требуют тщательной подготовки, причем подготовка дает возможность стать лучшим инженером в будущем из-за глубокой рефлексии об опыте и достижениях в прошлых проектах. Мне кажется, что навыки рефлексии - это ключ к ежедневному росту над собой, но это обычно не слишком приятно, поэтому люди избегают таких размышлений, а подготовка к интервью помогает им найти силы для этого дела
2) Поведенческие интервью важных для высоких грейдов, как инженерных, так и менеджерских. Компании оценивают прошлые успехи и поведение и используют это как экстраполяцию будущих результатов кандидата
3) Поведенческие интервью варьируются в зависимости от грейда, в приведенном видео Остин приводит примеры таких различий
4) У компаний есть критерии для оценки кандидатов, например, инициативность, настойчивость, ...
5) Крупные компании стремятся уйти от субъективных решений, поэтому формализуют критерии оценки
6) Как и всегда первое впечатление очень важно, поэтому важно правильно начать интервью и не обосраться. Автор рекомендует подготовить ответы на вопросы, которые с большой вероятностью будут заданы в начале интервью: "Расскажи о себе", "Расскажи о своем любимом проекте". Ответы на эти вопросы позволят задать првильный тон всей встрече.
7) Часто для проведения интервью используют стандартные схемы, например, STAR (Situation - Tasks - Actions - Results) или CARL (Context - Actions - Results - Learning), причем Остину нравится CARL больше STAR за счет последнего пункта про извлеченные уроки, а также он рекомендует меньше тратить времени на рассказ о контексте и больше на само действие и результаты
8 ) Стандартизированный подход (STAR / CARL / ваш любимый) может мешать непринужденной беседе и выглядеть неестественно, это решается тренировкой интервьюеров

Продолжение рассказа во втором посте.

#Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career

[2/2] Behavioral Interview Discussion with Ex-Meta Hiring Committee Member (Рубрика #Management)

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

9) Кандидатам важно уметь правильно презентовать свой опыт, а для этого важно понимать свои достижения и проекты, а также соотнести свои проекты с ценностями компании
10) Важно правильно выбирать проекты для рассказа. Например, автор рекомендует делить проекты по личному участию, влиянию на бизнес и масштабу. Важно, чтобы о выбранных проектах можно было интересно рассказать (рассказ об унылом проекте вгоняет интервьюера в депрессию)
11) На интервью часто задают вопросы об совершенных ошибках. Не стоит отвечать, что их не было - все люди ошибаются, но хорошие кандидаты признают ошибки и учаться на них (а лучшие учатся еще и на чужих ошибка)
12) Помимо ошибок интервьюер может спросить про слабости кандидата. Не стоит отвечать на них, что их нет или "Я - трудоголик", важно признавать свои слабости, а если еще рассказать про извлеченные из них уроки, то будет еще лучше. Но для интервьера важна честность и искренность, наигранные рассказы не принесут вистов
13) При подготовке к интервью важно подумать о том, а как показать, что вы подходите команде и решаете похожие задачи и сможете принести пользу новой компании. Лучше всего показать это через то, чтобы показать как вы добились реальных результатов на прошлом месте и принесли пользу бизнесу
14) При подготовке к интервью будьте готовы рассказать о себе, любимом проекте, а также конфликтной ситуации. В принципе, можно подготовить еще набор историй, привязанных к ценностям компании, а также отсортированных по масштабу, личному участию и импакту. Это поможет вам на интервью проще подбирать примеры из своего опыта под вопросы интервьюера
15) В конце интервью часто есть время на то, чтобы задать вопросы интервьюеру - это важный момент для того, чтобы продемонстировать интересе к компании и команде (если вас смотрят в конкретную команду), например можно задать вопросы про
- О развитии отдела и технологий
- О стиле управления нанимающего менеджера и динамике команды

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

P.S.
Я как-то рассказывл про то, как мы нанимаем
- Технических руководителей
- Staff+ инженеров
В принципе, многие советы Остина полезны и для подготовки к нашим интервью.

#Management #Software #Processes #Project #ProductManagement #Engineering #Processes #Leadership #Staff #Architecture #Career

Digital Nudge (Рубрика #Management)

Полгода назад мне подарили эту книгу, но прочитал я ее на днях. В ней Fabio Pereira рассказывает про базовые принципы поведенческой экономики, которые могут быть применены в цифровом миру для тонкого влияния на решения и поведение пользователей. Автор вводит концепцию digital nudging или цифрового подталкивания, которая представляет собой использование тонких элементов дизайна, информации и взаимодействия в цифровой среде для управления поведением пользователей без ограничения их свободы выбора. По-факту, это адаптация nudge theory Ричарда Талера и Касса Састейна из книги "Nudge". Правда, digital nudge адаптирован к цифровому контексту, например, веб-сайтам, приложениям или онлайн-платформам, и используют элементы интерфейса, такие как настройки по умолчанию, визуальные подсказки, персонализированные рекомендации и своевременные уведомления для влияния на принятие решений.

Оснонвые идеи книги
1) Choice architecture (архитектура выбора): То, как представлены варианты выбора в цифровой среде, может существенно влиять на поведение пользователей. Например, настройки по умолчанию (например, автоматическое продление подписок) часто направляют пользователей к определенным действиям.
2) Behavioral triggers (психологические триггеры): Цифровые "подталкивания" опираются на психологические принципы, такие как социальное доказательство (например, отзывы пользователей), дефицит (например, "Осталось всего 3 товара") и избегание потерь для стимулирования желаемого поведения.
3) Personalization (персонализация): "Подталкивания" могут быть адаптированы на основе данных о пользователях, таких как предпочтения или действия в реальном времени, для повышения их эффективности.
4) Low-cost interventions (дешевые интервенции): Цифровые "подталкивания" недороги и минимально навязчивы, что делает их масштабируемым решением для влияния на поведение в разных областях

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

Эта книга связана с другими
- "Nudge: Improving Decisions About Health, Wealth, and Happiness" Ричарда Талера и Касса Санстейна — основополагающая работа о теории "подталкивания".
- "Hooked: How to Build Habit-Forming Products" ("На крючке") - эта книга Нира Эяля о том, как создавать продукты, которые захватывают пользователей и становятся неотъемлемой частью их повседневной жизни. Я про нее уже рассказывал
- "Thinking, Fast and Slow" ("Думай медленно... решай быстро") Даниэля Канемана — исследует психологические системы принятия решений. Я про нее уже рассказывал
- "Predictably Irrational" ("Предсказуемая иррациональность") Дэна Ариели — объясняет, почему люди принимают иррациональные решения и как на них можно влиять.Я про нее уже рассказывал
- "Inside the Nudge Unit" Дэвида Хэлперна — о практическом применении теории "подталкивания" в государственной политике.
- "Misbehaving: The Making of Behavioral Economics" Ричарда Талера — рассказывает о развитии поведенческой экономики как научной дисциплины.
Эти книги предоставляют более глубокое понимание поведенческой экономики и науки о принятии решений, дополняя темы из Digital Nudge.
А вообще, сама книга "Digital nudge" очень простая и легкая, а поэтому хорошо подходит для того, чтобы познакомиться с этой темой.

P.S.
Я уже рассказывал про пару выступлений Фабио конференциях, из которых можно сложить отличное представление о самой концепции digital nudge
- The Psychology of UX
- Infobesity - How to Cope with the Overload of Information

#Thinking #PopularScience #SelfDevelopment #Brain #Economics #Psychology