Qetzal ad libitum, ad infinitum

Прочитал статью, которой уже почти четверть века, про подход к разработке игры Half-life: The Cabal: Valve’s Design Process For Creating Half-Life.

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

Что мне показалось интересным:

1) Основополагающие принципы.
Команда выработала основополагающие принципы, которые легли в основу всех решений.

— Если игрок продвигается вперёд, то ему/ей надо в течении какого-то времени обязательно показать какую-то интересность — монстра, эффект, часть истории.

> The first theory we came up with was the theory of "experiential density" — the amount of "things" that happen to and are done by the player per unit of time and area of a map. Our goal was that, once active, the player never had to wait too long before the next stimulus, be it monster, special effect, plot point, action sequence, and so on. Since we couldn’t really bring all these experiences to the player (a relentless series of them would just get tedious), all content is distance based, not time based, and no activities are started outside the player’s control. If the players are in the mood for more action, all they need to do is move forward and within a few seconds something will happen.

— Любое действие игрока должно давать обратную связь в каком-то виде

> The second theory we came up with is the theory of player acknowledgment. This means that the game world must acknowledge players every time they perform an action. For example, if they shoot their gun, the world needs to acknowledge it with something more permanent than just a sound — there should be some visual evidence that they’ve just fired their gun. [...] This also means that if the player pushes on something that should be pushable, the object shouldn’t ignore them, it should move. If they whack on something with their crowbar that looks like it should break, it had better break. If they walk into a room with other characters, those characters should acknowledge them by at least looking at them, if not calling out their name. Our basic theory was that if the world ignores the player, the player won’t care about the world.

— В случае проблем, игрок всегда должен винить себя, а не игру. Если игра предупреждает об опасности, то игрок в случае неудачи винит себя. Не должно быть совсем неожиданных проблем.

> A final theory was that the players should always blame themselves for failure. If the game kills them off with no warning, then players blame the game and start to dislike it. But if the game hints that danger is imminent, show players a way out and they die anyway, then they’ll consider it a failure on their part; they’ve let the game down and they need to try a little harder. When they succeed, and the game rewards them with a little treat — scripted sequence, special effect, and so on — they’ll feel good about themselves and about the game.

Внимательный читатель обратит внимание, что эти принципы сильно похожи на общие подходы к хорошему дизайну и вообще сейчас часто встречаются. Я время от времени играю в Зельду на Nintendo Switch (BotW и недавно вышедший TotK) — там те же штуки.

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

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

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

(продолжение)

Если вы делаете вещи, которые влияют на путь компании — вам время от времени нужно презентовать разные штуки: результаты, планы, решения. Вам нужно сделать слайды и их показывать.

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

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

(Про это ещё лучше меня написал Ричард Хэмминг в своём знаменитом эссе "Вы и ваша работа")

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

— Пишите скрипты
Напишите скрипт вашего рассказа — что конкретно вы хотите рассказать. При рассказе просто читайте этот скрипт.

Почему-то много людей считают, что писать скрипт рассказа и потом его читать — "неспортивно". Это ошибка — много харизматичных ораторов и рассказчиков, которых вы видели, читали текст с телепромптера.

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

На Маке есть возможность показать два приложения одновременно в режиме full screen, причем второму приложению дать меньше пространства. То есть можно одновременно шарить презентацию из браузера и читать скрипт.

Одна из частых ошибок: люди читают скрипт как книгу. Получается монотонно, скучно и сразу понятно, что тут именно читают. Чтобы этого не было нужно расставлять паузы и интонацию прямо в скрипте. Вот буквально писать "[тут на 5 секунд замолчать и посмотреть в экран]" или "[вопросительный тон]".

Энергия от рассказа передаётся слушателям. Если вас лично не увлекает ваш же рассказ, почему он должен увлечь слушателей?
Тут правило как в театре — если совсем немного переигрывать для себя, то вот слушателям будет в самый раз. То есть вы должны быть энергичный, чуть экспрессивны, чуть более акцентировать эмоции. В тренировках по речи часто учат делать паузы. Причем держать паузу так, чтобы вам было уже немного некомфортно ("не слишком долго") — это как раз будет в самый раз. Тут тоже самое с энергией и эмоциями.

— Сделать историю
Всё еще самый лучший способ (практически чит) рассказывать про что угодно — это обернуть всё в историю. Если вы не понимаете какая у вас история, то выберите классическую штуку: история вокруг проблемы.

Была вот такая проблема → все страдали и вот как они страдали → мы сделали лучше и проблему решили → все счастливы и вот как они счастливы.

Если построить вокруг этого и слайды и рассказ, то он сразу в 10 станет интереснее.

— Конкретика > абстракция
В любом месте, где вы можете добавить любой конкретики — добавляйте.

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

Если взять любую штуку и сделать ее менее абстрактной, но более конкретной — рассказ станет лучше.

(продолжение)

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

Резюмируя,
— Понимайте иерархию ваших убеждений и целей
— Оценивайте каждый фидбэк и информацию на "вес" и "источник"
— Чем более "базовое" ваше убеждение — чем экспоненциально больший общий "вес" нужен для изменения

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

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

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

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

Даже если вы не слушаете специально кого-то — вы всё равно воспринимаете в какой-то мере чужой взгляд на мир и он будет влиять на вас. Это как с радиацией. Вы можете защищаться от неё хорошо или плохо — но радиация никуда не девается. Она всегда есть, пронизывает всё вокруг и влияет на вас. И если влияет достаточно сильно — мы откажемся от начальных установок и будем считать это хорошей идеей, даже если это кажется плохой идеей вам-сегодняшнему! И возврат к прошлый целям или убеждениям может быть практически невозможен, так как запрет на это будет заложен в новой модели мира.

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

Решение, которое приходит в голову, состоит из двух частей: 1) профилирование источника фидбэка 2) иерархия целей с разным весом.

— Во-первых, ваш уровень восприятия внешнего фидбэка должен соответствовать "силе личности", которая этот фидбэк дает. Если вы доверяете человеку, если вы уверены в его компетенции — вы даёте больше веса этому фидбэку. Если вы не знаете человека, не уверены в его компетенции или не знаете, насколько его цели совпадают с вашими, насколько он заинтересован в том, чтобы вам было хорошо — фидбэк нужно дисконтировать. И чем больше не уверены — тем больше дисконтировать и задавать вопросов. (фио? градус? 😎)

Дисконтировать это не значит сразу отвергнуть. Можно выслушать (хотя начиная с какого-то уровня "токсичности" и расхождения целей — нужно и переставать слушать). Но выслушать не значит "сразу решить что-то менять".

— Во-вторых, убедительность, правдоподобность, конкретность фидбэка (то что я дальше буду называть собирательным словом "вес") должен соответствовать базовости убеждений, которые этот фидбэк просит вас изменить.

Убеждения имеют разную иерархию. Есть убеждения базовые (благополучность вашей семьи, вас и так далее), а есть более "высокого" уровня. Чем более базовое убеждение — тем больше веса вы должны требовать для его смены (причем рост экспоненциальный). А какие-то убеждения (например "моя семья должна быть в безопасности") настолько базовые, что для их смены вы должны получить информацию воистину титанических невероятных размеров.

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

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

Любой штукой в которой есть деньги и статус будут пытаться злоупотреблять. Из этого есть практический вывод — если ваш продукт шлёт письма с user generated content, этим рано или поздно воспользуются, чтобы слать спам (точно также как в каждой игре с user generated контентом будут пытаться рисовать пенисы, особенно в играх для более молодой аудитории)

Например за прошедшие годы злодеи пытались у нас слать спам так:

— Создавать новые аккаунты со спам-словом в названии профиля (мы шлём welcome письмо с этим словом)
— Смена email у аккаунта, когда спам-слово уже есть названии профиля (мы шлем письмо, что email сменили)
— Автоматизируют создание новых заказы в фейковом магазине, меняют темплейт письма о создании заказа на спамный (мы шлём письмо "как бы покупателю" о заказе).
— То же самое, но не при создании заказа, а при смене статуса заказа.
— Меняют темплейт письма, используют функцию preview template, чтобы послать себе тестовое письмо. Потом меняют постоянно адрес админа и делают так снова и снова.
— Приглашения staff accounts для управления магазином. В названии магазина — спам-слово, приглашают по спам-листу.

Если с этими штуками не бороться — через вас будут слать спам, что приведёт к падению репутации и недоставке ваших писем, а то и их полной блокировке.

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

Я как-то уже описывал историю того, как в Эквид добавили возможность торговать на Фейсбуке. История же возможности торговать в Инстраграме тоже занимательна.

Где-то лет ~5-6 назад Instagram решил добавить возможность показывать товары в своём фиде и в профилях. Штука эта интересная для продавцов, поэтому каждой e-commerce платформе её было интересно поддерживать.

Но команда Instagram была очень заинтересована в качестве продавцов, которые в то время могли этой возможностью воспользоваться. Поэтому возможность показывать товары в Instagram была доступна далеко не всем. Продавец должен был подать заявку и ждать — одобрят или нет. Для платформ ситуация была еще хуже. API для подачки заявки и проверки статуса был в закрытой бете и доступен только для одной самой крупной платформы. Остальным не давали — "мы в закрытой бете, ждите".

Возникла неприятная ситуация. Есть клёвая штука, которую хотят пользователи. Она доступна твоему конкуренту. Её нет у тебя — нужные API просто не доступны тебе. Проблема.

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

То есть мы добавили в интерфейс страницу про "продажи в Инстаграме". На этой странице мы разместили инструкцию как это сделать — сначала сделать магазин внутри Фейсбука (это мы уже умели), чтобы выгрузить товары в экосистему FB. Потом пойди вот по этой ссылке в настройки FB страницы и привяжи к ней Instagram аккаунт. После этого ты автоматически попадёшь в очередь на доступ к "магазину в Инстаграме", надо только ждать.

По сути это была всего лишь текстовая инструкция как это сделать вручную. Можно ли это было бы сделать без Эквида? Да, можно. Мы упрощали немного этот путь и автоматически синхронизировали товары, но само подключение к магазину в Инстаграме делать продавец сам. Были ли у этого пути недостатки? Много! Так как мы не знали статуса заявки — то не могли сказать, находится ли продавец всё ещё в очереди или ему уже отказали. Это вызывало сложности с поддержкой таких продавцов.

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

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

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

Почитать тут: → https://qetz.al/essay/ama-2023-04/

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

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

Это, конечно, не так.

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

Из-за этого в спешке отдаются не те задачи, которые НУЖНО и ВАЖНО делать. А те, которые МОЖНО сделать сейчас. Или в работу отдаются штуки, которые недостаточно продуманы. Это ошибка.

Важно помнить: задача продакт-менеджера не занять на 100% команду разработки. Задача продакт-менеджера — принимать правильные решения для достижения нужных целей.

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

2) Иногда бывают ситуации, когда у продакт-менеджера есть идея. Продакт-менеджер начинает исследование, чтобы понять — есть в этой идее здравое зерно, что там можно сделать. Проводит интервью, опросы, смотрит данные. В результате получает ничего. Из-за этого продакт-менеджер или "высасывает из пальца" какие-то бесполезные инсайты ("какой бы не был банан — кожура всегда больше") или страдает, что оказался бесполезным. Это ошибка.

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

Поэтому ситуация, когда идея приводит к ничему — нормальна. Более того — отказ от идеи это будущая польза! Когда мы что-то не делаем, мы освобождаем место для более важного. Поэтому в продукте "не делать" это тоже качественное полезное решение.

Решение "не делать", отказ от идея, исследования, которые не привели ни к чему должны ПРАЗДНОВАТЬСЯ точно так же как и запуски. "Ура, мы тут смотрели эту область и оказалось, что у нас там всё и так хорошо сейчас". Если так не делать, то команда будет склонятся к "выпуску фич ради выпуска фич" (так как именно это поощряется), вместо принятия решений и изменений, которые имеют значение.

Продакт-менеджемент и дизайн это про изменение поведения и ощущения. А это значит это не только про интерфейсы, а про весь опыт.

Хороший пример этого — дизайн API. То, как работает API, как отдаёт данные и так далее — это всё часть дизайна (в широком смысле) продукта.

Но ведь опыт этим же не ограничивается. Если ваш продукт даёт API сторонним разработчикам, но между вами возникает договоренности (явные или неявные). Иногда вам нужно будет закрывать старые версии API и переходить на новые. И вот как вы это делаете — это тоже продукт.

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

Но вот компания всё же приняла решение отключить старый API и заставить всех переключится на новый. Обычно это делается как "c 1 января старая версия перестанет работать — переключайтесь". И это плохой дизайн. Кто-то обязательно пропустил анонс, не успел перейти на новую версию и 1 января команда вынуждена срочно что-то чинить. Или "30 апреля", но дата выпадает на воскресенье.

Привязанность к красивым датам (новая версия — с нового квартала) никак не связана с конкретными действиями команд и их поведением.

Гораздо более правильный подход — отключать старые версии в понедельник в 10 утра по временной зоне, где находится максимум ваших пользователей. А еще лучше — не отключать старые API совсем сразу. А постепенно выключать на час-два-три и больше в течении нескольких недель, чтобы привлечь внимание тех, кто еще не обновился, но не сломать им ничего сразу.

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

Вот другой пример — далёкий от компьютеров. Представьте детскую поликлинику в будний день. Перед прививочным кабинетом очень много людей. Очередь медленно движется. Часть родителей пришла с маленькими детьми — им надо сделать прививку. Часть очереди — школьники, им надо какие-то справки там получить. "Я за вами буду, а за мной женщина в красной шапке, но она ушла пока, будете пока за мной". Часть родителей заняло очередь сразу в несколько кабинетов, поэтому очередь прерывается и возникают параллельные очереди. Кого-то доктора ведут без очереди. Изредка у какого-то родителя сдают нервы и он/она оттирает какого-то скромного школьника и проходит без очереди. Шум, гам, скандал. Это приводит к ещё большему хаосу. Один человек, который нарушил правила приводит к тому, что правила вынуждены нарушать все. Людям неприятно, но все думают, что если не начнёшь сам "пробиваться", то тебя точно "отодвинут" (и я даже не буду описывать, что происходит в поликлинике в очереди к педиатру, когда докторов не хватает, половина людей "по живой очереди", а другая половина по записи на время, но всех записали с шагом в 5 минут. Это неприятное зрелище.)

А ведь эту штуку если уж не получается решить целиком, то как минимум можно сделать сильно более безболезненной. Как это всё работает во всяких банках и так далее. Пришёл, получил талончик с номером. Заходит только тот (и вот за этим надо следить очень жёстко), чей номер. И сразу приятная очередь, тихо, спокойно, нет ссор.

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

Что общего между флиртом и тонкими угрозами?
Общая черта это то, что по-английски называется "plausible deniability" (правдоподобное отрицание). Это способность донести сообщение, но в случае прямой конфронтации или прямого вопроса иметь возможность отказаться от него.

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

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

То же самое с флиртом. Флирт это проявление романтического интереса, но который при необходимости (например при невзаимности флирта) можно объяснить простым приятельственным интересом.

Интересно, что польза юристов и переговорщиков лежит и в этой области тоже.

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

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

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

Что нужно делать, чтобы достичь успеха? Вопрос на миллион с кучей возможных ответов — кто-то будет рассказывать про навык и mindset. Кто-то про удачу. Кто-то про команду.

Все эти штуки важны, но вот эти три мне приходят первыми в голову: 1) не сдавайся 2) не умирай 3) пробуй быстро и дёшево.

— "Не умирай" это про управление экзистенциальными рисками, которые могут завершить путь до достижения цели.
— "Пробуй быстро" это про эксперименты и поиск себя без огромных затрат (так как большие затраты это путь к "умиранию") и адаптацию стратегии.
— А "Не сдавайся" это про то, чтобы не опускать руки раньше времени. Про толерантность к стрессу.

В английском языке есть два очень похожих слова, которые описывают "не сдавайся" взгляд на мир: grip и grit.
Где "grip" это "хватка", "контроль", "способность уловить суть", "умение овладеть положением". А "grit" это "твёрдость характера", "выдержка", "стойкость". Вместе это gript, он-то и нужен.

На русский gript перевести сложно. "Настойкость"? (настоять [на своём] + стойкойсть?) "Настойка"? "Настойчествовость"?

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

I.
По умолчанию мы избегаем всех стрессовых ситуаций и это нормально! Но эта стратегия не всегда оптимальна.

Избегание стресса приводит к избеганию неприятных ситуаций. А избегание неприятных ситуаций приводит к самообманам.

Обычная ситуация: вечер, конец рабочего дня. Приходит обращение от пользователя, что что-то там у него не работает. И есть развилка: одна дорога обещает простоту ("эта проблема скорее всего у одного пользователя, переспрошу — там видно будет"), другая обещает беспокойный вечер ("а что если это массовая проблема? Надо посмотреть внимательней и если что — поднять тревогу"). Я сотни раз видел, как по дефолту выбирается путь "оптимизма" (да всё будет хорошо), потому что просто не хочется "думать о плохом".

Эта же штука случается везде. "Да тут всё понятно, зачем ещё что-то смотреть", "да и так хорошо, зачем улучшать" и т.д.

II.
Избегание стресса приводит к ранней сдаче. Большие вещи никогда не делаются быстро и спокойно. Это всегда долгий и неспокойный путь. Это "американские горки" — сегодня кризис, завтра кризис, послезавтра — какая-то победа. А потом опять кризис. Без толерантности к стрессу и неопределенности этот путь не пройти до конца.

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

То, что люди говорят это не всегда то, что они делают и не всегда то, что подходит именно вам.

Рассказать и дать совет о чём-то просто и в то же время выгодно. Этот сигнал легко сфальсифицировать. Как правило вы не знаете:
— Правда это или нет, а если в целом правда — что исказили
— О чём умолчали
— Привело ли это к нужным результатам

Чем проще и ярче мысль в рассказе, тем более он эмоционально вовлекает: "ого, вот как оно по правде-то!" Поэтому есть стимул не упоминать детали и оттенки. "Мы сделали так и стало круто" всегда массово выиграет по сравнению с "мы сделали так, вот тут стало лучше, вот тут хуже, короче пока непонятно".

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

Вот, например, Marc Andreessen в 2007 году пишет, как круто не иметь расписание. А в 2020 рассказывает, что полностью поменял подход и теперь все делает в точности наоборот — имеет чётко распланированную структуру дня.

В прошлом широко разошлись статьи про "модель Spotify": автономные команды и всё такое. Как оказалось, всё не так радужно.

Вы можете прочитать много про то, как здорово иметь команды объединённые в кросс-функциональные бизнес-юниты вокруг своих целей, но вот есть пример Apple (компания, которая умеет выпускать выдающиеся продукты) c организацией вокруг функций.

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

Если есть возможность — выяснять конкретику: зачем сделали, что получилось, а что не получилось.

Делать поправку на "яркость" сообщения. Автор, чтобы донести мысль, утрирует и упрощает, чтобы "пробить защиту" обычных мыслей читателя. В жизни обычно всё сложнее.

Ну и конечно, всегда-всегда пропускать совет через себя. Новая информация — это замечательно. Но она будет бесполезна и работать только на ощущение "ох как много я знаю", если её не обдумать и не переработать внутри.

(все вышеописанное, разумеется, относится и к советам в этом канале)

Одна из главных мыслей для свежеиспечённого менеджера — понять, что его главная команда теперь — другие менеджеры (его peers), а не люди, которые ему репортают.

Когда Эквид был уже достаточно большим, чтобы появились менеджеры и менеджеры менеджеров, но был достаточно мал, чтобы подавляющее большинство людей было в одном городе — у нас был ритуал, который отлично работал.

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

Эта встреча проводилась много лет и была самой полезной встречей за всё это время.