Существуют продукты, которые зависят от других продуктов и должны быть с ними связаны. В этом случае возникает проблема курицы и яйца. Для того, чтобы тебя все заинтегрировали нужно, чтобы ты был известен и популярен. Но для того, чтобы ты стал известен и популярен, нужно, чтобы тебя все заинтегрировали.
Одно из решений этой проблемы — эмуляция существующих API. В этом случае интеграция с твоим продуктом становится очень простой. Достаточно, например, заменить API endpoint.
Есть несколько примеров того, как это используется.
— Первый пример из прошлого — это эмуляция платежной системы Authorize.Net. Любая новая платежная система, которая хотела выйти на US рынок, сталкивалась с проблемой — чтобы платежную систему использовали, она должна работать внутри ecommerce платформ. Но чтобы платформы её заинтегрировали — надо, чтобы её хотели использовать много продавцов, чтобы был запрос на неё.
Поэтому часто платежные системы полностью повторяли API Authorize.Net, который работал везде. Поэтому если продавец хотел новую систему (допустим ему sales команда продала эту штуку как-то) — достаточно было просто заменить ссылку, куда идёт API запрос.
Мы в Эквиде в свое время использовали этот подход для того, чтобы получить на старте сразу какое-то количество платежных интеграций.
— Второй пример это эмуляция AWS S3 API. Существует хранилище файлов от Amazon — S3. С ним все умеют работать, все поддерживают его API. И если появляется новое хранилище, то оно всегда умеет работать с S3 API, чтобы его можно было сразу начать использовать.
Amazon, кстати, и сам использовал этот подход. Например в их попытке заменить бэкапы на кассетах (есть такие), они создают "виртуальные кассеты", чтобы бизнесам было легко переключится.
Одно из решений этой проблемы — эмуляция существующих API. В этом случае интеграция с твоим продуктом становится очень простой. Достаточно, например, заменить API endpoint.
Есть несколько примеров того, как это используется.
— Первый пример из прошлого — это эмуляция платежной системы Authorize.Net. Любая новая платежная система, которая хотела выйти на US рынок, сталкивалась с проблемой — чтобы платежную систему использовали, она должна работать внутри ecommerce платформ. Но чтобы платформы её заинтегрировали — надо, чтобы её хотели использовать много продавцов, чтобы был запрос на неё.
Поэтому часто платежные системы полностью повторяли API Authorize.Net, который работал везде. Поэтому если продавец хотел новую систему (допустим ему sales команда продала эту штуку как-то) — достаточно было просто заменить ссылку, куда идёт API запрос.
Мы в Эквиде в свое время использовали этот подход для того, чтобы получить на старте сразу какое-то количество платежных интеграций.
— Второй пример это эмуляция AWS S3 API. Существует хранилище файлов от Amazon — S3. С ним все умеют работать, все поддерживают его API. И если появляется новое хранилище, то оно всегда умеет работать с S3 API, чтобы его можно было сразу начать использовать.
Amazon, кстати, и сам использовал этот подход. Например в их попытке заменить бэкапы на кассетах (есть такие), они создают "виртуальные кассеты", чтобы бизнесам было легко переключится.
Люди обнаружили, что Самсунг делает хитрый трюк. Если камера обнаруживает луну, то специальная нейронка достраивает изображение до очень чёткого. Не "улучшает" изображение, а буквально создаёт новое, даже если в исходном изображении вообще нет нужных деталей.
Оставим пока в сторону размышления про этичность этого шага, долговременное доверие и симулякры. Самое по себе это интересный продуктовый ход. Отличный пример асимметричной продуктовой реакции.
Представьте, что сегодня полнолуние — на небе замечательная большая полная луна. Вы фотографируете её — на фотографии что-то невнятное. Ваш приятель рядом фотографирует на Самсунг — у него супер-пупер луна с кратерами. Ненастоящесть луны в этот момент значения не имеет.
Если конкурент имеет порядково больше ресурсов или отставание слишком большее — часто не имеет смысла делать то же самое. Надо или сменить игру или кратно повысить ставки.
Другой пример из области асимметричных реакций — история про Cellebrite и защищенный мессенджер Сигнал. Cellebrite это компания которая предоставляет продукты по вытаскиванию данных из различных девайсов. Их обычный покупатель — различные силовики и правоохранительные органы.
Cellebrite анонсировали, что они "взломали" Сигнал. В ответ ребята из Сигнал нашли где-то продукты Cellebrite (их нет в открытом доступе) и обнаружили в них уязвимости о которых же публично заявили. Но и это еще не всё. Они заявили следующее:
> In completely unrelated news, upcoming versions of Signal will be periodically fetching files to place in app storage. These files are never used for anything inside Signal and never interact with Signal software or data, but they look nice, and aesthetics are important in software. Files will only be returned for accounts that have been active installs for some time already, and only probabilistically in low percentages based on phone number sharding. We have a few different versions of files that we think are aesthetically pleasing, and will iterate through those slowly over time. There is no other significance to these files.
Это намёк означает следующее — "На части установок Сигнала мы будем сгружать файлы, которые ничего не делают. Но если их проанализировать через Cellebrite, то этот код воспользуется уязвимостью и как-то изменить результаты анализа Cellebrite. В результате возможно результаты анализа могут не принять в суде и ваш продукт будет бесполезен".
Или ещё короче: "не связывайтесь с нами — будет себе дороже". "Раcсчитываете на выгоду, есть риск потерять сильно больше". Резкое асимметричное повышение ставок (ну и конечно надо быть готовым к тому, что другая сторона тоже может начать повышать ставки и эскалировать).
Оставим пока в сторону размышления про этичность этого шага, долговременное доверие и симулякры. Самое по себе это интересный продуктовый ход. Отличный пример асимметричной продуктовой реакции.
Представьте, что сегодня полнолуние — на небе замечательная большая полная луна. Вы фотографируете её — на фотографии что-то невнятное. Ваш приятель рядом фотографирует на Самсунг — у него супер-пупер луна с кратерами. Ненастоящесть луны в этот момент значения не имеет.
Если конкурент имеет порядково больше ресурсов или отставание слишком большее — часто не имеет смысла делать то же самое. Надо или сменить игру или кратно повысить ставки.
Другой пример из области асимметричных реакций — история про Cellebrite и защищенный мессенджер Сигнал. Cellebrite это компания которая предоставляет продукты по вытаскиванию данных из различных девайсов. Их обычный покупатель — различные силовики и правоохранительные органы.
Cellebrite анонсировали, что они "взломали" Сигнал. В ответ ребята из Сигнал нашли где-то продукты Cellebrite (их нет в открытом доступе) и обнаружили в них уязвимости о которых же публично заявили. Но и это еще не всё. Они заявили следующее:
> In completely unrelated news, upcoming versions of Signal will be periodically fetching files to place in app storage. These files are never used for anything inside Signal and never interact with Signal software or data, but they look nice, and aesthetics are important in software. Files will only be returned for accounts that have been active installs for some time already, and only probabilistically in low percentages based on phone number sharding. We have a few different versions of files that we think are aesthetically pleasing, and will iterate through those slowly over time. There is no other significance to these files.
Это намёк означает следующее — "На части установок Сигнала мы будем сгружать файлы, которые ничего не делают. Но если их проанализировать через Cellebrite, то этот код воспользуется уязвимостью и как-то изменить результаты анализа Cellebrite. В результате возможно результаты анализа могут не принять в суде и ваш продукт будет бесполезен".
Или ещё короче: "не связывайтесь с нами — будет себе дороже". "Раcсчитываете на выгоду, есть риск потерять сильно больше". Резкое асимметричное повышение ставок (ну и конечно надо быть готовым к тому, что другая сторона тоже может начать повышать ставки и эскалировать).
Руслан, CEO и основатель Эквида с прошлой недели уже не в Эквиде.
Несмотря на ожидаемость этого изменения — оно ощущается странно. Я работал в компаниях, которые основал Руслан 19 лет. Вместе с Русланом в Эквиде — 14 лет. Я время от времени получаю вопрос — как так ты смог работать на одном месте так много времени? Ответ прост — это не было одно место. Это было как будто 10 разных работ — каждые 2 года приходилось заниматься новыми штуками и переизобретать себя. Но одна штука оставалась неизменной — люди, с которыми работаешь.
Эта работа вместе с Русланом сформировала меня как профессионала и как личность. Когда так много лет работаешь бок о бок, то вырабатывается невероятный уровень понимания: понимания сильных сторон, особенностей, привычек. Мне сложно описать как именно это влияет на совместную работу — это что-то, что невозможно объяснить людям, меняющим работу раз в 2 года. Я убеждён, что именно этот уровень совместного доверия в команде — одна их причин успеха Эквида. Причина того, что команда достигла так многого в условиях, когда все шансы были против неё.
Понимание и доверие не означает идеалистическую пастораль, где все взялись за руки и идут по радуге. Совместная работа это всегда сложности, споры, несогласия. Это не простой путь, но это всегда увлекательный путь.
В процессе этого пути в команде происходит "переопыление" — люди перенимают взгляды и привычки друг друга. Я решил вспомнить навскидку, какие штуки я перенял у Руслана (на самом деле их сильно больше, напишу самое большое, что приходит в голову).
— Дифференцируйся.
Выбери нишу и будь в ней лучшим. Нет смысла делать всё. Не конкурируй, если не можешь выиграть — меняй игру. Если бой нечестный — надо выигрывать нокаутом.
— Форма и слова.
Форма имеет значение, слова имеют значение, подготовка имеет значение. Важно не только то, что ты говоришь, но и как ты это говоришь. В конце концов решение будут принимать конкретные люди и решение они будут принимать в том числе и по эмоциональным причинам.
Я могу вспомнить много примеров, когда тщательная подготовка, выбор формулировок или доработка слайдов в конце концов окупались хорошими результатами.
— Быть параноиком — нормально!
Одна из задач стартапа — не умереть. И чем больше ты не умираешь, тем больше река рядом проносит тела твоих конкурентов, которых ты опасался в прошлом (в моем старом документе с конкурентами из 2009 года — мертво 99% списка). И тем больше приносит возможностей.
А чтобы не умереть — исключай экзистенциальные риски. Подстраховывайся. Перепроверяй. Имей запас.
— Bias to action
Иногда просто нужно взять и сделать. Несмотря на то, что будет плохо. Несмотря на текущие планы, статус кво, организационную структуру и привычки. Умение в нужном месте и в нужный момент пересилить всё это, создать ощущение срочности и довести изменения до конца — дорогого стоит.
— Команда
В конце концов всё всегда сведётся к команде, к людям вокруг. Идея, личные скиллы, execution и т.д. — важно, спору нет. Но два десятка лет только на них не проедешь. Умение собрать людей, чтобы они работали вместе над общей целью, несмотря на пот-слёзы-боль (а жизнь стартапа это "жевать стекло и смотреть в бездну", причём каждое утро не знаешь, что ждёт тебя сегодня) — это важное умение.
И это умение далеко не только про "убеждение и харизму". Это про откровенность и настоящеcть. Про integrity. Про умение вовремя доверится и отдать, но когда нужно зачелленджить. Про приоритет общих целей и команды над личным. Про возможность учиться у человека. Про заботу, но не опёку.
Вы, возможно, уже вообразили себе сусальный образ, эдакий "тед лассо". Сильные личности — сложные, в коктейле всегда есть и эго и убеждённость в своей правоте и другие крепкие ингредиенты. И это нормально. Когда есть важное, другие штуки уходят на третий план.
(продолжение)
Несмотря на ожидаемость этого изменения — оно ощущается странно. Я работал в компаниях, которые основал Руслан 19 лет. Вместе с Русланом в Эквиде — 14 лет. Я время от времени получаю вопрос — как так ты смог работать на одном месте так много времени? Ответ прост — это не было одно место. Это было как будто 10 разных работ — каждые 2 года приходилось заниматься новыми штуками и переизобретать себя. Но одна штука оставалась неизменной — люди, с которыми работаешь.
Эта работа вместе с Русланом сформировала меня как профессионала и как личность. Когда так много лет работаешь бок о бок, то вырабатывается невероятный уровень понимания: понимания сильных сторон, особенностей, привычек. Мне сложно описать как именно это влияет на совместную работу — это что-то, что невозможно объяснить людям, меняющим работу раз в 2 года. Я убеждён, что именно этот уровень совместного доверия в команде — одна их причин успеха Эквида. Причина того, что команда достигла так многого в условиях, когда все шансы были против неё.
Понимание и доверие не означает идеалистическую пастораль, где все взялись за руки и идут по радуге. Совместная работа это всегда сложности, споры, несогласия. Это не простой путь, но это всегда увлекательный путь.
В процессе этого пути в команде происходит "переопыление" — люди перенимают взгляды и привычки друг друга. Я решил вспомнить навскидку, какие штуки я перенял у Руслана (на самом деле их сильно больше, напишу самое большое, что приходит в голову).
— Дифференцируйся.
Выбери нишу и будь в ней лучшим. Нет смысла делать всё. Не конкурируй, если не можешь выиграть — меняй игру. Если бой нечестный — надо выигрывать нокаутом.
— Форма и слова.
Форма имеет значение, слова имеют значение, подготовка имеет значение. Важно не только то, что ты говоришь, но и как ты это говоришь. В конце концов решение будут принимать конкретные люди и решение они будут принимать в том числе и по эмоциональным причинам.
Я могу вспомнить много примеров, когда тщательная подготовка, выбор формулировок или доработка слайдов в конце концов окупались хорошими результатами.
— Быть параноиком — нормально!
Одна из задач стартапа — не умереть. И чем больше ты не умираешь, тем больше река рядом проносит тела твоих конкурентов, которых ты опасался в прошлом (в моем старом документе с конкурентами из 2009 года — мертво 99% списка). И тем больше приносит возможностей.
А чтобы не умереть — исключай экзистенциальные риски. Подстраховывайся. Перепроверяй. Имей запас.
— Bias to action
Иногда просто нужно взять и сделать. Несмотря на то, что будет плохо. Несмотря на текущие планы, статус кво, организационную структуру и привычки. Умение в нужном месте и в нужный момент пересилить всё это, создать ощущение срочности и довести изменения до конца — дорогого стоит.
— Команда
В конце концов всё всегда сведётся к команде, к людям вокруг. Идея, личные скиллы, execution и т.д. — важно, спору нет. Но два десятка лет только на них не проедешь. Умение собрать людей, чтобы они работали вместе над общей целью, несмотря на пот-слёзы-боль (а жизнь стартапа это "жевать стекло и смотреть в бездну", причём каждое утро не знаешь, что ждёт тебя сегодня) — это важное умение.
И это умение далеко не только про "убеждение и харизму". Это про откровенность и настоящеcть. Про integrity. Про умение вовремя доверится и отдать, но когда нужно зачелленджить. Про приоритет общих целей и команды над личным. Про возможность учиться у человека. Про заботу, но не опёку.
Вы, возможно, уже вообразили себе сусальный образ, эдакий "тед лассо". Сильные личности — сложные, в коктейле всегда есть и эго и убеждённость в своей правоте и другие крепкие ингредиенты. И это нормально. Когда есть важное, другие штуки уходят на третий план.
(продолжение)
(начало)
Я уже говорил спасибо команде. А теперь хороший повод сказать за всё спасибо лично Руслану. Не буду пытаться и снова писать "за что" — как можно вместить в несколько предложений вещи, которые были частью твоей жизни половину прожитых лет? Этих вещей было много. И это было замечательное приключение.
Приключение окончилось — приключение продолжается!
Поэтому не говорю до свидания, говорю — до следующего приключения.
Я уже говорил спасибо команде. А теперь хороший повод сказать за всё спасибо лично Руслану. Не буду пытаться и снова писать "за что" — как можно вместить в несколько предложений вещи, которые были частью твоей жизни половину прожитых лет? Этих вещей было много. И это было замечательное приключение.
Приключение окончилось — приключение продолжается!
Поэтому не говорю до свидания, говорю — до следующего приключения.
Существует такой паттерн о котором важно помнить.
Вот представьте вам надо сделать тягостную, но нужную штуку. Вы эту штуку делать не желаете, она или неприятная или требует сильных усилий. С другой стороны — вы знаете, что должны её сделать. Причем должны не потому что от вас кто-то это требует, а потому что вы сами считаете, что правильный и хороший человек должен это сделать.
Если в этой ситуации вы выберете "не делать"(поддадитесь слабости), то перед вами встанет выбор — считать себя чуть более плохим человеком или же переложить ответственность на окружение. Как правило бессознательно происходит второе.
Например коллега просит вас сделать какую-то штуку, которую вы должны сделать сегодня, но не хотите. Вы откладываете её на завтра. Вы начнете думать, что "а он сам вон не всегда всё вовремя делает", "да тут никто вечером не работает" и т.д.
То есть внутреннее предательство себя или других всегда приводит к тому, что вы начнете считать других хуже чем они есть на самом деле. Эта применимо и к работе и к отношениям с людьми.
Вот представьте вам надо сделать тягостную, но нужную штуку. Вы эту штуку делать не желаете, она или неприятная или требует сильных усилий. С другой стороны — вы знаете, что должны её сделать. Причем должны не потому что от вас кто-то это требует, а потому что вы сами считаете, что правильный и хороший человек должен это сделать.
Если в этой ситуации вы выберете "не делать"(поддадитесь слабости), то перед вами встанет выбор — считать себя чуть более плохим человеком или же переложить ответственность на окружение. Как правило бессознательно происходит второе.
Например коллега просит вас сделать какую-то штуку, которую вы должны сделать сегодня, но не хотите. Вы откладываете её на завтра. Вы начнете думать, что "а он сам вон не всегда всё вовремя делает", "да тут никто вечером не работает" и т.д.
То есть внутреннее предательство себя или других всегда приводит к тому, что вы начнете считать других хуже чем они есть на самом деле. Эта применимо и к работе и к отношениям с людьми.
Доступность (accessibility) эта штука про которую все обычно вспоминают редко. Крупные компании делают ровно столько, чтобы их не засудили. Ребята поменьше вспоминают про доступность только при знаковых событиях(e.g. exit) и спешно адаптируются под закон ADA, чтобы не было проблем в US. И понятно почему — делать не так просто, а "ну сколько у нас там вообще слабовидящих?"
Вот эта статья переопределяет понятие доступности и даёт интересную перспективу, связанную с дизайном для кризиса.
В статье переосмысляется понятие disability. Если по русски, то это смена восприятия disability как инвалидности на восприятия как беспомощности в каких-то областях.
А беспомощность бывает,
— Постоянная (как раз инвалидность, "нет руки")
— Временная ("сломал руку")
— Ситуационная ("в одной руке ребенок")
И продукт с более высокой доступностью помогает людям в ситуации, далекой от идеальной.
Очевидный пример тут — пандусы и лифты. Доступная среда помогает людям в колясках, но еще и родителям с колясками и даже ребятам с чемоданами.
Слишком часто продукт создаётся для идеальной ситуации.
Когда в прошлом мы создавали новую версию витрины Эквида, то все первые скетчи показывали классные витрины с классными картинками товаров. Любая витрина интернет-магазина будет выглядеть неплохо с красивыми стройными одинаковыми картинками. В реальной жизни продавцы загружают всё подряд — ужасные картинки, ужасные пропорции. Поэтому мы нашли десяток реальных магазинов с самыми ужасными картинками (кодовое название "лыжи") и стали тестировать прототипы именно на этих данных. Задача сделать отличный вид с ужасными вводными — сложная и кажется невозможной. Но в итоге команде удалось ее весьма креативно решить и в своей массе витрины стали выглядеть хорошо с любыми данными.
Вот эта статья переопределяет понятие доступности и даёт интересную перспективу, связанную с дизайном для кризиса.
В статье переосмысляется понятие disability. Если по русски, то это смена восприятия disability как инвалидности на восприятия как беспомощности в каких-то областях.
А беспомощность бывает,
— Постоянная (как раз инвалидность, "нет руки")
— Временная ("сломал руку")
— Ситуационная ("в одной руке ребенок")
И продукт с более высокой доступностью помогает людям в ситуации, далекой от идеальной.
Очевидный пример тут — пандусы и лифты. Доступная среда помогает людям в колясках, но еще и родителям с колясками и даже ребятам с чемоданами.
Слишком часто продукт создаётся для идеальной ситуации.
Когда в прошлом мы создавали новую версию витрины Эквида, то все первые скетчи показывали классные витрины с классными картинками товаров. Любая витрина интернет-магазина будет выглядеть неплохо с красивыми стройными одинаковыми картинками. В реальной жизни продавцы загружают всё подряд — ужасные картинки, ужасные пропорции. Поэтому мы нашли десяток реальных магазинов с самыми ужасными картинками (кодовое название "лыжи") и стали тестировать прототипы именно на этих данных. Задача сделать отличный вид с ужасными вводными — сложная и кажется невозможной. Но в итоге команде удалось ее весьма креативно решить и в своей массе витрины стали выглядеть хорошо с любыми данными.
Процессы, которые работают в большой компании, могут быть вредны в компании маленькой.
Когда компания небольшая, многие вещи можно решить разговором (грубо говоря — "все в одной комнате"). У команды высокий общий контекст и большая автономность ("людей не хватает"). Какой-то процесс поверх этого потенциально может замедлить работу, не добавив пользы.
Когда команда растёт, появляется больше связей, cнижается общий контекст — появляется необходимость в процессах и ритуалах.
Например, если у вас один и тот же продукт меняет десяток продакт-менеджеров — они начнут пересекаться. Появится вопрос — а нет ли у нас ситуации лебеди-рака-щуки, двигаем ли мы продукт к одной цели?
Одно из решений тут — продуктовый питч. Еще его называют RFC (request for comment, request for change), PRD (product requirement document), narrative, design doc и другими словами.
На определенном этапе развития компании эта штука позволяет достичь двух вещей:
— Дать фидбэк по будущему изменению до того, как в него начали активно вкладываться. Всех фрустирует ситуация, когда изменение долго в работе, а тут появляется руководитель с "надо делать по другому".
— Получить свежий взгляд и фидбэк на свои решения. Это всегда очень полезно.
В интернете можно найти целую россыпь различных темплейтов таких документов разной степени хорошести. От простых до совершенно монструозных.
В своё время я посмотрел на них все и сделал себе свой: взял из разных документов то, что нравится и выкинул то, что считаю лишним.
Получился вот такой темплейт: https://docs.google.com/document/d/12CaomRINVNlVCTPjPst6zSTe7L5jC6h_Ei_YAjZ4_o4/edit (на английском)
На мой взгляд в этом документе правильный баланс — спрашиваются нужные вещи, но не спрашиваются ненужные.
Особенно хочу обратить ваше внимание, что Problem Alignment и Solution Alignment — разные секции и могут (а часто и должны) писаться отдельно. Одна из частых проблем — готовое решение в голове, которое диктует проблему. Чтобы избавится от этого, проблему стоит описывать отдельно, не пытаясь описывать конкретные решения и изменения.
Когда компания небольшая, многие вещи можно решить разговором (грубо говоря — "все в одной комнате"). У команды высокий общий контекст и большая автономность ("людей не хватает"). Какой-то процесс поверх этого потенциально может замедлить работу, не добавив пользы.
Когда команда растёт, появляется больше связей, cнижается общий контекст — появляется необходимость в процессах и ритуалах.
Например, если у вас один и тот же продукт меняет десяток продакт-менеджеров — они начнут пересекаться. Появится вопрос — а нет ли у нас ситуации лебеди-рака-щуки, двигаем ли мы продукт к одной цели?
Одно из решений тут — продуктовый питч. Еще его называют RFC (request for comment, request for change), PRD (product requirement document), narrative, design doc и другими словами.
На определенном этапе развития компании эта штука позволяет достичь двух вещей:
— Дать фидбэк по будущему изменению до того, как в него начали активно вкладываться. Всех фрустирует ситуация, когда изменение долго в работе, а тут появляется руководитель с "надо делать по другому".
— Получить свежий взгляд и фидбэк на свои решения. Это всегда очень полезно.
В интернете можно найти целую россыпь различных темплейтов таких документов разной степени хорошести. От простых до совершенно монструозных.
В своё время я посмотрел на них все и сделал себе свой: взял из разных документов то, что нравится и выкинул то, что считаю лишним.
Получился вот такой темплейт: https://docs.google.com/document/d/12CaomRINVNlVCTPjPst6zSTe7L5jC6h_Ei_YAjZ4_o4/edit (на английском)
На мой взгляд в этом документе правильный баланс — спрашиваются нужные вещи, но не спрашиваются ненужные.
Особенно хочу обратить ваше внимание, что Problem Alignment и Solution Alignment — разные секции и могут (а часто и должны) писаться отдельно. Одна из частых проблем — готовое решение в голове, которое диктует проблему. Чтобы избавится от этого, проблему стоит описывать отдельно, не пытаясь описывать конкретные решения и изменения.
Одна из главных мыслей для свежеиспечённого менеджера — понять, что его главная команда теперь — другие менеджеры (его peers), а не люди, которые ему репортают.
Когда Эквид был уже достаточно большим, чтобы появились менеджеры и менеджеры менеджеров, но был достаточно мал, чтобы подавляющее большинство людей было в одном городе — у нас был ритуал, который отлично работал.
Каждую пятницу после менеджерской встречи все эти люди шли вместе обедать. Это был просто обед, без повестки разговора. Но само собой на этой агапе обсуждалось разное в более неформальной свободной обстановке: люди рассказывали контекст и интересные штуки, делились проблемами, задавали вопросы, принимали решения и просто общались.
Эта встреча проводилась много лет и была самой полезной встречей за всё это время.
Когда Эквид был уже достаточно большим, чтобы появились менеджеры и менеджеры менеджеров, но был достаточно мал, чтобы подавляющее большинство людей было в одном городе — у нас был ритуал, который отлично работал.
Каждую пятницу после менеджерской встречи все эти люди шли вместе обедать. Это был просто обед, без повестки разговора. Но само собой на этой агапе обсуждалось разное в более неформальной свободной обстановке: люди рассказывали контекст и интересные штуки, делились проблемами, задавали вопросы, принимали решения и просто общались.
Эта встреча проводилась много лет и была самой полезной встречей за всё это время.
То, что люди говорят это не всегда то, что они делают и не всегда то, что подходит именно вам.
Рассказать и дать совет о чём-то просто и в то же время выгодно. Этот сигнал легко сфальсифицировать. Как правило вы не знаете:
— Правда это или нет, а если в целом правда — что исказили
— О чём умолчали
— Привело ли это к нужным результатам
Чем проще и ярче мысль в рассказе, тем более он эмоционально вовлекает: "ого, вот как оно по правде-то!" Поэтому есть стимул не упоминать детали и оттенки. "Мы сделали так и стало круто" всегда массово выиграет по сравнению с "мы сделали так, вот тут стало лучше, вот тут хуже, короче пока непонятно".
Но это только часть проблемы. Даже если вы читаете совет, который дают от чистого сердца и с желанием помочь, важно понимать, что совет всегда зависит от контекста. Разным людям нужно разное в разное время.
Вот, например, Marc Andreessen в 2007 году пишет, как круто не иметь расписание. А в 2020 рассказывает, что полностью поменял подход и теперь все делает в точности наоборот — имеет чётко распланированную структуру дня.
В прошлом широко разошлись статьи про "модель Spotify": автономные команды и всё такое. Как оказалось, всё не так радужно.
Вы можете прочитать много про то, как здорово иметь команды объединённые в кросс-функциональные бизнес-юниты вокруг своих целей, но вот есть пример Apple (компания, которая умеет выпускать выдающиеся продукты) c организацией вокруг функций.
Поэтому всегда стоит смотреть на сигналы, которые сложнее подделать. Меньше на то, что человек говорит, больше на то, что он делает. Советы от людей, которые что-то сделали имеют больший вес, чем советы от людей, которые зажигательно говорят.
Если есть возможность — выяснять конкретику: зачем сделали, что получилось, а что не получилось.
Делать поправку на "яркость" сообщения. Автор, чтобы донести мысль, утрирует и упрощает, чтобы "пробить защиту" обычных мыслей читателя. В жизни обычно всё сложнее.
Ну и конечно, всегда-всегда пропускать совет через себя. Новая информация — это замечательно. Но она будет бесполезна и работать только на ощущение "ох как много я знаю", если её не обдумать и не переработать внутри.
(все вышеописанное, разумеется, относится и к советам в этом канале)
Рассказать и дать совет о чём-то просто и в то же время выгодно. Этот сигнал легко сфальсифицировать. Как правило вы не знаете:
— Правда это или нет, а если в целом правда — что исказили
— О чём умолчали
— Привело ли это к нужным результатам
Чем проще и ярче мысль в рассказе, тем более он эмоционально вовлекает: "ого, вот как оно по правде-то!" Поэтому есть стимул не упоминать детали и оттенки. "Мы сделали так и стало круто" всегда массово выиграет по сравнению с "мы сделали так, вот тут стало лучше, вот тут хуже, короче пока непонятно".
Но это только часть проблемы. Даже если вы читаете совет, который дают от чистого сердца и с желанием помочь, важно понимать, что совет всегда зависит от контекста. Разным людям нужно разное в разное время.
Вот, например, Marc Andreessen в 2007 году пишет, как круто не иметь расписание. А в 2020 рассказывает, что полностью поменял подход и теперь все делает в точности наоборот — имеет чётко распланированную структуру дня.
В прошлом широко разошлись статьи про "модель Spotify": автономные команды и всё такое. Как оказалось, всё не так радужно.
Вы можете прочитать много про то, как здорово иметь команды объединённые в кросс-функциональные бизнес-юниты вокруг своих целей, но вот есть пример Apple (компания, которая умеет выпускать выдающиеся продукты) c организацией вокруг функций.
Поэтому всегда стоит смотреть на сигналы, которые сложнее подделать. Меньше на то, что человек говорит, больше на то, что он делает. Советы от людей, которые что-то сделали имеют больший вес, чем советы от людей, которые зажигательно говорят.
Если есть возможность — выяснять конкретику: зачем сделали, что получилось, а что не получилось.
Делать поправку на "яркость" сообщения. Автор, чтобы донести мысль, утрирует и упрощает, чтобы "пробить защиту" обычных мыслей читателя. В жизни обычно всё сложнее.
Ну и конечно, всегда-всегда пропускать совет через себя. Новая информация — это замечательно. Но она будет бесполезна и работать только на ощущение "ох как много я знаю", если её не обдумать и не переработать внутри.
(все вышеописанное, разумеется, относится и к советам в этом канале)
В US приняли закон о том, что если в товаре или блюде есть кунжут, то про это надо явно писать (в дополнение к другим аллергенам). Разумный ли это закон? Выглядит разумным — он защищает людей с аллергией на кунжут.
Но согласно этой статье эффект был обратный. Компании стали добавлять кунжут в блюда, где его раньше не было.
Когда есть требование писать о кунжуте, то отсутствие записи о кунжуте является обещанием. Если обещание дать затратно (а у многих компаний нет процессов, который гарантирует, что следы кунжута от предыдущих блюд не попадут в новое блюдо;), то проще добавить незначительное число кунжута к блюдам, чтобы на вкус не влияло, но надпись добавить можно, не обманывая. "Да, да, тут кунжут, ничего не можем поделать".
Умение оптимизировать поведение под правила, ограничения и нормы — неотъемлемая наша часть.
Сделали специальную карту, чтобы подростки ходили бесплатно в музеи — возник рынок обналичивания через подставные эвенты.
Вы решили мотивировать найм молодых профессоров через требование увеличения показателя «доля преподавателей в возрасте до 39 лет» — всех старше оставят, но выведут из основного "состава" в консультанты, которые не учитываются.
В театрах люди хлопают, когда нравится — появятся клакёры, которые за деньги могут обеспечить успех или провал. И таких примеров очень много.
Не только у людей, но и у AI (к вопросу о потенциальной опасности AI — оно может и не захочет людей уничтожать специально, но какие будут побочные эффекты на его пути при оптимизации на что-то хорошее?)
И вывод простой. Любой штукой в которой есть деньги и статус будут пытаться злоупотреблять. Любое требование, которое несёт за собой затратное или неприятное изменение, будут пытаться обойти. Это факт. Часть жизни. Надо это просто принять и учитывать.
Но согласно этой статье эффект был обратный. Компании стали добавлять кунжут в блюда, где его раньше не было.
Когда есть требование писать о кунжуте, то отсутствие записи о кунжуте является обещанием. Если обещание дать затратно (а у многих компаний нет процессов, который гарантирует, что следы кунжута от предыдущих блюд не попадут в новое блюдо;), то проще добавить незначительное число кунжута к блюдам, чтобы на вкус не влияло, но надпись добавить можно, не обманывая. "Да, да, тут кунжут, ничего не можем поделать".
Умение оптимизировать поведение под правила, ограничения и нормы — неотъемлемая наша часть.
Сделали специальную карту, чтобы подростки ходили бесплатно в музеи — возник рынок обналичивания через подставные эвенты.
Вы решили мотивировать найм молодых профессоров через требование увеличения показателя «доля преподавателей в возрасте до 39 лет» — всех старше оставят, но выведут из основного "состава" в консультанты, которые не учитываются.
В театрах люди хлопают, когда нравится — появятся клакёры, которые за деньги могут обеспечить успех или провал. И таких примеров очень много.
Не только у людей, но и у AI (к вопросу о потенциальной опасности AI — оно может и не захочет людей уничтожать специально, но какие будут побочные эффекты на его пути при оптимизации на что-то хорошее?)
И вывод простой. Любой штукой в которой есть деньги и статус будут пытаться злоупотреблять. Любое требование, которое несёт за собой затратное или неприятное изменение, будут пытаться обойти. Это факт. Часть жизни. Надо это просто принять и учитывать.
Продукт хороший, если он помогает пользователю достигать своих целей. Лучше (быстрее, качественнее, дешевле, приятней) приводит его к ним. Иногда для этого надо сделать что-то, что пользователь не ждал, иногда просто "оцифровать" и оптимизировать какие-то существующие процессы.
Чтобы это делать хорошо, нужно глубокого понимать область и сами процессы. Штука в том, что иногда невозможно обладать действительно глубоким пониманием, если не попробовать поделать его самому или же не поговорить с пользователем, который способен к глубокой саморефлексии.
Приведу несколько примеров из жизни.
— У ребёнка есть две любимые книжки. Истории про Квака и Жаба. И сказки Сутеева. У этих книг есть разница в вёрстке, которая заметно влияет на меня.
Я читаю ребёнку книжки перед сном. Ребёнок хочет много историй, а спать не хочет. Я же хочу почитать сколько запланировал, а потом убедить ребёнка пойти засыпать. Так вот разница в этих двух книжках — где начинается новая история. В книге о Кваке и Жаба новая история всегда начинается на новой странице слева. Когда я дочитываю одну историю — другая не видна! В книге Сутеева всё наоборот — когда я дочитываю история, следующая всегда видна справа сразу. Соответственно я дочитываю одну сказку и ребёнок сразу видит начало следующей и просит её. В книге про лягух я заканчиваю историю и могу сказать "теперь на этом всё, давай спать". Нет "завлекающей" следующей страницы.
Специально ли это задумывали в книге про лягушек или нет — не знаю. Но это очень удобно. И также очень неочевидно, пока не почитаешь детскую книгу сам настоящему ребёнку.
— То же самое с "детским" режимом на разных приборах. Этот режим защищает от случайных нажатий, но не является по настоящему "детским". Новорождённый первые месяцы может спать очень чутко. Два часа укладывал, потом встал с кровати, хрустнул коленкой и всё по новой. Но при этом подавляющее число бытовых приборов любят 1) светить лампочками, бодро рапортуя, что "я работаю!" 2) пищать при любых изменениях своего состояния.
Вот работает кондиционер, надо тебе его ночью выключить. Будешь выключать — обязательно всё будет пищать. Режима "ни звука" просто нет. То есть приборы для ситуации "новорожденный" вовсе не адаптирован. И такие штуки просто не в картине мира, чтобы понять — надо прочувствовать.
— Возьмем другой пример, рабочий. Я активно использую календарь. На домашнем экране своего телефона я использую виджет, который показывает ближайшие события. Ни одно из приложений календаря не умеет делать так, как мне надо.
Если у меня сегодня нет звонков, то в виджете мне надо об этом сказать ("свободный день, ура!"). Но если я смотрю в телефон поздним вечером — я проверяю, когда у меня первый звонок завтра и мне надо это показать.
Если я смотрю на виджет в выходные, то не не надо мне показывать звонки на понедельник — я хочу отвлечься от работы и не думать про задачи понедельника. Но если я смотрю на виджет вечером воскресенья — я уже проверяю, что у меня завтра.
И таких мелочей много. Большинство же календарей просто показывают N ближайших событий. Чтобы сделать хорошо и гибко, надо разговаривать с людьми у которых много звонков и которые могут отрефлексировать (сами или с вашей помощью) "а как бы было удобно".
— Как ни странно это объединяет хорошие продукты и хороших писателей. Увлекательная книга, как правило, полна конкретных деталей в которые веришь, потому что их нельзя "просто придумать". Если вы пишете киберпанк историю в жарком городе, то в тёмных переулках должны шуметь коробки промышленных кондиционеров, дуть на вас жарким воздухом и капать водой. Но чтобы это описать, надо быть в жарком городе и знать, как внешние коробки кондиционеров себя ведут.
Чтобы это делать хорошо, нужно глубокого понимать область и сами процессы. Штука в том, что иногда невозможно обладать действительно глубоким пониманием, если не попробовать поделать его самому или же не поговорить с пользователем, который способен к глубокой саморефлексии.
Приведу несколько примеров из жизни.
— У ребёнка есть две любимые книжки. Истории про Квака и Жаба. И сказки Сутеева. У этих книг есть разница в вёрстке, которая заметно влияет на меня.
Я читаю ребёнку книжки перед сном. Ребёнок хочет много историй, а спать не хочет. Я же хочу почитать сколько запланировал, а потом убедить ребёнка пойти засыпать. Так вот разница в этих двух книжках — где начинается новая история. В книге о Кваке и Жаба новая история всегда начинается на новой странице слева. Когда я дочитываю одну историю — другая не видна! В книге Сутеева всё наоборот — когда я дочитываю история, следующая всегда видна справа сразу. Соответственно я дочитываю одну сказку и ребёнок сразу видит начало следующей и просит её. В книге про лягух я заканчиваю историю и могу сказать "теперь на этом всё, давай спать". Нет "завлекающей" следующей страницы.
Специально ли это задумывали в книге про лягушек или нет — не знаю. Но это очень удобно. И также очень неочевидно, пока не почитаешь детскую книгу сам настоящему ребёнку.
— То же самое с "детским" режимом на разных приборах. Этот режим защищает от случайных нажатий, но не является по настоящему "детским". Новорождённый первые месяцы может спать очень чутко. Два часа укладывал, потом встал с кровати, хрустнул коленкой и всё по новой. Но при этом подавляющее число бытовых приборов любят 1) светить лампочками, бодро рапортуя, что "я работаю!" 2) пищать при любых изменениях своего состояния.
Вот работает кондиционер, надо тебе его ночью выключить. Будешь выключать — обязательно всё будет пищать. Режима "ни звука" просто нет. То есть приборы для ситуации "новорожденный" вовсе не адаптирован. И такие штуки просто не в картине мира, чтобы понять — надо прочувствовать.
— Возьмем другой пример, рабочий. Я активно использую календарь. На домашнем экране своего телефона я использую виджет, который показывает ближайшие события. Ни одно из приложений календаря не умеет делать так, как мне надо.
Если у меня сегодня нет звонков, то в виджете мне надо об этом сказать ("свободный день, ура!"). Но если я смотрю в телефон поздним вечером — я проверяю, когда у меня первый звонок завтра и мне надо это показать.
Если я смотрю на виджет в выходные, то не не надо мне показывать звонки на понедельник — я хочу отвлечься от работы и не думать про задачи понедельника. Но если я смотрю на виджет вечером воскресенья — я уже проверяю, что у меня завтра.
И таких мелочей много. Большинство же календарей просто показывают N ближайших событий. Чтобы сделать хорошо и гибко, надо разговаривать с людьми у которых много звонков и которые могут отрефлексировать (сами или с вашей помощью) "а как бы было удобно".
— Как ни странно это объединяет хорошие продукты и хороших писателей. Увлекательная книга, как правило, полна конкретных деталей в которые веришь, потому что их нельзя "просто придумать". Если вы пишете киберпанк историю в жарком городе, то в тёмных переулках должны шуметь коробки промышленных кондиционеров, дуть на вас жарким воздухом и капать водой. Но чтобы это описать, надо быть в жарком городе и знать, как внешние коробки кондиционеров себя ведут.
Что нужно делать, чтобы достичь успеха? Вопрос на миллион с кучей возможных ответов — кто-то будет рассказывать про навык и mindset. Кто-то про удачу. Кто-то про команду.
Все эти штуки важны, но вот эти три мне приходят первыми в голову: 1) не сдавайся 2) не умирай 3) пробуй быстро и дёшево.
— "Не умирай" это про управление экзистенциальными рисками, которые могут завершить путь до достижения цели.
— "Пробуй быстро" это про эксперименты и поиск себя без огромных затрат (так как большие затраты это путь к "умиранию") и адаптацию стратегии.
— А "Не сдавайся" это про то, чтобы не опускать руки раньше времени. Про толерантность к стрессу.
В английском языке есть два очень похожих слова, которые описывают "не сдавайся" взгляд на мир: grip и grit.
Где "grip" это "хватка", "контроль", "способность уловить суть", "умение овладеть положением". А "grit" это "твёрдость характера", "выдержка", "стойкость". Вместе это gript, он-то и нужен.
На русский gript перевести сложно. "Настойкость"? (настоять [на своём] + стойкойсть?) "Настойка"? "Настойчествовость"?
И вот для "настойкости", для любого качественного роста важно иметь или выработать определенную толерантность к стрессу. Это важно по двум причинам.
I.
По умолчанию мы избегаем всех стрессовых ситуаций и это нормально! Но эта стратегия не всегда оптимальна.
Избегание стресса приводит к избеганию неприятных ситуаций. А избегание неприятных ситуаций приводит к самообманам.
Обычная ситуация: вечер, конец рабочего дня. Приходит обращение от пользователя, что что-то там у него не работает. И есть развилка: одна дорога обещает простоту ("эта проблема скорее всего у одного пользователя, переспрошу — там видно будет"), другая обещает беспокойный вечер ("а что если это массовая проблема? Надо посмотреть внимательней и если что — поднять тревогу"). Я сотни раз видел, как по дефолту выбирается путь "оптимизма" (да всё будет хорошо), потому что просто не хочется "думать о плохом".
Эта же штука случается везде. "Да тут всё понятно, зачем ещё что-то смотреть", "да и так хорошо, зачем улучшать" и т.д.
II.
Избегание стресса приводит к ранней сдаче. Большие вещи никогда не делаются быстро и спокойно. Это всегда долгий и неспокойный путь. Это "американские горки" — сегодня кризис, завтра кризис, послезавтра — какая-то победа. А потом опять кризис. Без толерантности к стрессу и неопределенности этот путь не пройти до конца.
Понятно, что стоит ещё делать поправку на "ловушку невозвратных затрат". Но тем не менее, если меня спрашивают карьерного совета — одна из моих рекомендаций — "не избегайте стресса и вырабатывайте толерантность к нему".
Все эти штуки важны, но вот эти три мне приходят первыми в голову: 1) не сдавайся 2) не умирай 3) пробуй быстро и дёшево.
— "Не умирай" это про управление экзистенциальными рисками, которые могут завершить путь до достижения цели.
— "Пробуй быстро" это про эксперименты и поиск себя без огромных затрат (так как большие затраты это путь к "умиранию") и адаптацию стратегии.
— А "Не сдавайся" это про то, чтобы не опускать руки раньше времени. Про толерантность к стрессу.
В английском языке есть два очень похожих слова, которые описывают "не сдавайся" взгляд на мир: grip и grit.
Где "grip" это "хватка", "контроль", "способность уловить суть", "умение овладеть положением". А "grit" это "твёрдость характера", "выдержка", "стойкость". Вместе это gript, он-то и нужен.
На русский gript перевести сложно. "Настойкость"? (настоять [на своём] + стойкойсть?) "Настойка"? "Настойчествовость"?
И вот для "настойкости", для любого качественного роста важно иметь или выработать определенную толерантность к стрессу. Это важно по двум причинам.
I.
По умолчанию мы избегаем всех стрессовых ситуаций и это нормально! Но эта стратегия не всегда оптимальна.
Избегание стресса приводит к избеганию неприятных ситуаций. А избегание неприятных ситуаций приводит к самообманам.
Обычная ситуация: вечер, конец рабочего дня. Приходит обращение от пользователя, что что-то там у него не работает. И есть развилка: одна дорога обещает простоту ("эта проблема скорее всего у одного пользователя, переспрошу — там видно будет"), другая обещает беспокойный вечер ("а что если это массовая проблема? Надо посмотреть внимательней и если что — поднять тревогу"). Я сотни раз видел, как по дефолту выбирается путь "оптимизма" (да всё будет хорошо), потому что просто не хочется "думать о плохом".
Эта же штука случается везде. "Да тут всё понятно, зачем ещё что-то смотреть", "да и так хорошо, зачем улучшать" и т.д.
II.
Избегание стресса приводит к ранней сдаче. Большие вещи никогда не делаются быстро и спокойно. Это всегда долгий и неспокойный путь. Это "американские горки" — сегодня кризис, завтра кризис, послезавтра — какая-то победа. А потом опять кризис. Без толерантности к стрессу и неопределенности этот путь не пройти до конца.
Понятно, что стоит ещё делать поправку на "ловушку невозвратных затрат". Но тем не менее, если меня спрашивают карьерного совета — одна из моих рекомендаций — "не избегайте стресса и вырабатывайте толерантность к нему".
Что общего между флиртом и тонкими угрозами?
Общая черта это то, что по-английски называется "plausible deniability" (правдоподобное отрицание). Это способность донести сообщение, но в случае прямой конфронтации или прямого вопроса иметь возможность отказаться от него.
Ну вот когда воображаемый мафиози говорит: "Берегите себя, когда возвращаетесь домой поздно ночью. На улицах сейчас небезопасно", то это однозначно воспринимается как угроза. Но в случае конфронтации всегда можно сделать вид: "Да что вы, я всего лишь беспокоюсь, чтобы у вас все было хорошо".
(Поэтому, кстати, я считаю мнение вида "да тут нет давления, люди сами принимают решения" — наивным. Сложные решения в "серой" и тем более в "чёрной" зоне не будут спускаться "сверху" в конкретных указаниях. Они будут проговариваться в форме намёков, общих слов. "Сами понимать должны")
То же самое с флиртом. Флирт это проявление романтического интереса, но который при необходимости (например при невзаимности флирта) можно объяснить простым приятельственным интересом.
Интересно, что польза юристов и переговорщиков лежит и в этой области тоже.
Когда идут переговоры, достаточно часто от каждой стороны в роли переговорщика выступают специальные люди. Кажется, что у этого есть две цели.
— Во-первых, это убирает возможные эмоции, когда личное отношение к другой стороне влияет на решение. Например, мы обижены на человека и считаем неприемлемым идти на уступки. Если мы согласимся на какие-то условия, значит, что мы уступили и проиграли. А это нельзя допустить. В случае же, когда решение принимает переговорщик, то это его решение. И мы "сохраняем наше лицо".
В том числе это связано с эмоциями после сделки. Результат может быть неприятен для одной из сторон, но в будущем возможно нужно будет вести общие дела. В этом случае так как договаривались посредники, то обе стороны могут продолжать делать вид, что хорошо относятся друг к другу — "plausible deniability".
— Вторая особенность, опять же, связана с этим. Когда переговоры заходят в тупик или, например, допущены какие-то ошибки, всегда можно сменить переговорщика. Сделать вид, что сторона тут ни при чем, а это переговорщик наделал делов. То есть, опять же, возможность донести неприятное сообщение, но с возможностью от него отказаться.
Общая черта это то, что по-английски называется "plausible deniability" (правдоподобное отрицание). Это способность донести сообщение, но в случае прямой конфронтации или прямого вопроса иметь возможность отказаться от него.
Ну вот когда воображаемый мафиози говорит: "Берегите себя, когда возвращаетесь домой поздно ночью. На улицах сейчас небезопасно", то это однозначно воспринимается как угроза. Но в случае конфронтации всегда можно сделать вид: "Да что вы, я всего лишь беспокоюсь, чтобы у вас все было хорошо".
(Поэтому, кстати, я считаю мнение вида "да тут нет давления, люди сами принимают решения" — наивным. Сложные решения в "серой" и тем более в "чёрной" зоне не будут спускаться "сверху" в конкретных указаниях. Они будут проговариваться в форме намёков, общих слов. "Сами понимать должны")
То же самое с флиртом. Флирт это проявление романтического интереса, но который при необходимости (например при невзаимности флирта) можно объяснить простым приятельственным интересом.
Интересно, что польза юристов и переговорщиков лежит и в этой области тоже.
Когда идут переговоры, достаточно часто от каждой стороны в роли переговорщика выступают специальные люди. Кажется, что у этого есть две цели.
— Во-первых, это убирает возможные эмоции, когда личное отношение к другой стороне влияет на решение. Например, мы обижены на человека и считаем неприемлемым идти на уступки. Если мы согласимся на какие-то условия, значит, что мы уступили и проиграли. А это нельзя допустить. В случае же, когда решение принимает переговорщик, то это его решение. И мы "сохраняем наше лицо".
В том числе это связано с эмоциями после сделки. Результат может быть неприятен для одной из сторон, но в будущем возможно нужно будет вести общие дела. В этом случае так как договаривались посредники, то обе стороны могут продолжать делать вид, что хорошо относятся друг к другу — "plausible deniability".
— Вторая особенность, опять же, связана с этим. Когда переговоры заходят в тупик или, например, допущены какие-то ошибки, всегда можно сменить переговорщика. Сделать вид, что сторона тут ни при чем, а это переговорщик наделал делов. То есть, опять же, возможность донести неприятное сообщение, но с возможностью от него отказаться.
Продакт-менеджемент и дизайн это про изменение поведения и ощущения. А это значит это не только про интерфейсы, а про весь опыт.
Хороший пример этого — дизайн API. То, как работает API, как отдаёт данные и так далее — это всё часть дизайна (в широком смысле) продукта.
Но ведь опыт этим же не ограничивается. Если ваш продукт даёт API сторонним разработчикам, но между вами возникает договоренности (явные или неявные). Иногда вам нужно будет закрывать старые версии API и переходить на новые. И вот как вы это делаете — это тоже продукт.
Конечно, для стороннего разработчика идеальный вариант всегда иметь доступ к одной и той же версии API. Нет ни одного продукт-менеджера, который был бы счастлив, что ему надо в ближайшие месяцы обновлять интеграцию и переходить на новый API только потому, что кто-то там что-то обновил. Большие компании с кучей интеграций могут поддерживать старые API десятилетиями. Да, в них не будут добавляться новые возможности. Они могут работать нестабильно. Но они будут работать.
Но вот компания всё же приняла решение отключить старый API и заставить всех переключится на новый. Обычно это делается как "c 1 января старая версия перестанет работать — переключайтесь". И это плохой дизайн. Кто-то обязательно пропустил анонс, не успел перейти на новую версию и 1 января команда вынуждена срочно что-то чинить. Или "30 апреля", но дата выпадает на воскресенье.
Привязанность к красивым датам (новая версия — с нового квартала) никак не связана с конкретными действиями команд и их поведением.
Гораздо более правильный подход — отключать старые версии в понедельник в 10 утра по временной зоне, где находится максимум ваших пользователей. А еще лучше — не отключать старые API совсем сразу. А постепенно выключать на час-два-три и больше в течении нескольких недель, чтобы привлечь внимание тех, кто еще не обновился, но не сломать им ничего сразу.
Подобные технические условия заметно влияют на поведение людей.
Вот другой пример — далёкий от компьютеров. Представьте детскую поликлинику в будний день. Перед прививочным кабинетом очень много людей. Очередь медленно движется. Часть родителей пришла с маленькими детьми — им надо сделать прививку. Часть очереди — школьники, им надо какие-то справки там получить. "Я за вами буду, а за мной женщина в красной шапке, но она ушла пока, будете пока за мной". Часть родителей заняло очередь сразу в несколько кабинетов, поэтому очередь прерывается и возникают параллельные очереди. Кого-то доктора ведут без очереди. Изредка у какого-то родителя сдают нервы и он/она оттирает какого-то скромного школьника и проходит без очереди. Шум, гам, скандал. Это приводит к ещё большему хаосу. Один человек, который нарушил правила приводит к тому, что правила вынуждены нарушать все. Людям неприятно, но все думают, что если не начнёшь сам "пробиваться", то тебя точно "отодвинут" (и я даже не буду описывать, что происходит в поликлинике в очереди к педиатру, когда докторов не хватает, половина людей "по живой очереди", а другая половина по записи на время, но всех записали с шагом в 5 минут. Это неприятное зрелище.)
А ведь эту штуку если уж не получается решить целиком, то как минимум можно сделать сильно более безболезненной. Как это всё работает во всяких банках и так далее. Пришёл, получил талончик с номером. Заходит только тот (и вот за этим надо следить очень жёстко), чей номер. И сразу приятная очередь, тихо, спокойно, нет ссор.
Мы недооцениваем насколько часто неприятные штуки вокруг нас связаны с плохим дизайном жизни и насколько хорошие штуки вызваны хорошим дизайном жизни и внешними ограничениями.
Хороший пример этого — дизайн API. То, как работает API, как отдаёт данные и так далее — это всё часть дизайна (в широком смысле) продукта.
Но ведь опыт этим же не ограничивается. Если ваш продукт даёт API сторонним разработчикам, но между вами возникает договоренности (явные или неявные). Иногда вам нужно будет закрывать старые версии API и переходить на новые. И вот как вы это делаете — это тоже продукт.
Конечно, для стороннего разработчика идеальный вариант всегда иметь доступ к одной и той же версии API. Нет ни одного продукт-менеджера, который был бы счастлив, что ему надо в ближайшие месяцы обновлять интеграцию и переходить на новый API только потому, что кто-то там что-то обновил. Большие компании с кучей интеграций могут поддерживать старые API десятилетиями. Да, в них не будут добавляться новые возможности. Они могут работать нестабильно. Но они будут работать.
Но вот компания всё же приняла решение отключить старый API и заставить всех переключится на новый. Обычно это делается как "c 1 января старая версия перестанет работать — переключайтесь". И это плохой дизайн. Кто-то обязательно пропустил анонс, не успел перейти на новую версию и 1 января команда вынуждена срочно что-то чинить. Или "30 апреля", но дата выпадает на воскресенье.
Привязанность к красивым датам (новая версия — с нового квартала) никак не связана с конкретными действиями команд и их поведением.
Гораздо более правильный подход — отключать старые версии в понедельник в 10 утра по временной зоне, где находится максимум ваших пользователей. А еще лучше — не отключать старые API совсем сразу. А постепенно выключать на час-два-три и больше в течении нескольких недель, чтобы привлечь внимание тех, кто еще не обновился, но не сломать им ничего сразу.
Подобные технические условия заметно влияют на поведение людей.
Вот другой пример — далёкий от компьютеров. Представьте детскую поликлинику в будний день. Перед прививочным кабинетом очень много людей. Очередь медленно движется. Часть родителей пришла с маленькими детьми — им надо сделать прививку. Часть очереди — школьники, им надо какие-то справки там получить. "Я за вами буду, а за мной женщина в красной шапке, но она ушла пока, будете пока за мной". Часть родителей заняло очередь сразу в несколько кабинетов, поэтому очередь прерывается и возникают параллельные очереди. Кого-то доктора ведут без очереди. Изредка у какого-то родителя сдают нервы и он/она оттирает какого-то скромного школьника и проходит без очереди. Шум, гам, скандал. Это приводит к ещё большему хаосу. Один человек, который нарушил правила приводит к тому, что правила вынуждены нарушать все. Людям неприятно, но все думают, что если не начнёшь сам "пробиваться", то тебя точно "отодвинут" (и я даже не буду описывать, что происходит в поликлинике в очереди к педиатру, когда докторов не хватает, половина людей "по живой очереди", а другая половина по записи на время, но всех записали с шагом в 5 минут. Это неприятное зрелище.)
А ведь эту штуку если уж не получается решить целиком, то как минимум можно сделать сильно более безболезненной. Как это всё работает во всяких банках и так далее. Пришёл, получил талончик с номером. Заходит только тот (и вот за этим надо следить очень жёстко), чей номер. И сразу приятная очередь, тихо, спокойно, нет ссор.
Мы недооцениваем насколько часто неприятные штуки вокруг нас связаны с плохим дизайном жизни и насколько хорошие штуки вызваны хорошим дизайном жизни и внешними ограничениями.
У продакт-менеджеров я часто замечаю два убеждения, которые не просто их ограничивают, а попросту вредны.
— Если моя команда разработчиков простаивает, то я не выполняю свою работу до конца
— Если я происследовал что-то и не обнаружил инсайт/возможность, то я сделал свою работу плохо.
Это, конечно, не так.
1) Иногда бывают ситуации, когда у продакт-менеджера нет для команды новых больших задач. Иногда продакт-менеджер воспринимает это как симптом своей плохой работы: "не успел, не занял, люди меня ждут".
Из-за этого в спешке отдаются не те задачи, которые НУЖНО и ВАЖНО делать. А те, которые МОЖНО сделать сейчас. Или в работу отдаются штуки, которые недостаточно продуманы. Это ошибка.
Важно помнить: задача продакт-менеджера не занять на 100% команду разработки. Задача продакт-менеджера — принимать правильные решения для достижения нужных целей.
Поэтому ситуация, когда у команды в работе нет ничего большого — нормальна. В этом случае полезно иметь набор готовых маленьких задач по улучшению "качества жизни", что-то, что сложно приоритизировать, но полезно сделать. Или можно выделать время на исправления багов, до которых не доходили руки. Или попрототипировать какие-нибудь прикольные экспериментальные штуки. Или просто сказать инженерам — вот у вас есть время поделать любое внутреннее улучшение или рефакторинг — делайте эти N недель что хотите (главное не забудьте задать ограничение по времени). Даже просто ничего не делать — будет лучше, чем отдавать в работу какие-то большие вещи, всё достинство которых в том, что мы знаем как их сделать.
2) Иногда бывают ситуации, когда у продакт-менеджера есть идея. Продакт-менеджер начинает исследование, чтобы понять — есть в этой идее здравое зерно, что там можно сделать. Проводит интервью, опросы, смотрит данные. В результате получает ничего. Из-за этого продакт-менеджер или "высасывает из пальца" какие-то бесполезные инсайты ("какой бы не был банан — кожура всегда больше") или страдает, что оказался бесполезным. Это ошибка.
Важно помнить: задача продакт-менеджера не генерировать рабочие инсайты на каждую идею. Задача продакт-менеджера — принимать правильные решения для достижения нужных целей.
Поэтому ситуация, когда идея приводит к ничему — нормальна. Более того — отказ от идеи это будущая польза! Когда мы что-то не делаем, мы освобождаем место для более важного. Поэтому в продукте "не делать" это тоже качественное полезное решение.
Решение "не делать", отказ от идея, исследования, которые не привели ни к чему должны ПРАЗДНОВАТЬСЯ точно так же как и запуски. "Ура, мы тут смотрели эту область и оказалось, что у нас там всё и так хорошо сейчас". Если так не делать, то команда будет склонятся к "выпуску фич ради выпуска фич" (так как именно это поощряется), вместо принятия решений и изменений, которые имеют значение.
— Если моя команда разработчиков простаивает, то я не выполняю свою работу до конца
— Если я происследовал что-то и не обнаружил инсайт/возможность, то я сделал свою работу плохо.
Это, конечно, не так.
1) Иногда бывают ситуации, когда у продакт-менеджера нет для команды новых больших задач. Иногда продакт-менеджер воспринимает это как симптом своей плохой работы: "не успел, не занял, люди меня ждут".
Из-за этого в спешке отдаются не те задачи, которые НУЖНО и ВАЖНО делать. А те, которые МОЖНО сделать сейчас. Или в работу отдаются штуки, которые недостаточно продуманы. Это ошибка.
Важно помнить: задача продакт-менеджера не занять на 100% команду разработки. Задача продакт-менеджера — принимать правильные решения для достижения нужных целей.
Поэтому ситуация, когда у команды в работе нет ничего большого — нормальна. В этом случае полезно иметь набор готовых маленьких задач по улучшению "качества жизни", что-то, что сложно приоритизировать, но полезно сделать. Или можно выделать время на исправления багов, до которых не доходили руки. Или попрототипировать какие-нибудь прикольные экспериментальные штуки. Или просто сказать инженерам — вот у вас есть время поделать любое внутреннее улучшение или рефакторинг — делайте эти N недель что хотите (главное не забудьте задать ограничение по времени). Даже просто ничего не делать — будет лучше, чем отдавать в работу какие-то большие вещи, всё достинство которых в том, что мы знаем как их сделать.
2) Иногда бывают ситуации, когда у продакт-менеджера есть идея. Продакт-менеджер начинает исследование, чтобы понять — есть в этой идее здравое зерно, что там можно сделать. Проводит интервью, опросы, смотрит данные. В результате получает ничего. Из-за этого продакт-менеджер или "высасывает из пальца" какие-то бесполезные инсайты ("какой бы не был банан — кожура всегда больше") или страдает, что оказался бесполезным. Это ошибка.
Важно помнить: задача продакт-менеджера не генерировать рабочие инсайты на каждую идею. Задача продакт-менеджера — принимать правильные решения для достижения нужных целей.
Поэтому ситуация, когда идея приводит к ничему — нормальна. Более того — отказ от идеи это будущая польза! Когда мы что-то не делаем, мы освобождаем место для более важного. Поэтому в продукте "не делать" это тоже качественное полезное решение.
Решение "не делать", отказ от идея, исследования, которые не привели ни к чему должны ПРАЗДНОВАТЬСЯ точно так же как и запуски. "Ура, мы тут смотрели эту область и оказалось, что у нас там всё и так хорошо сейчас". Если так не делать, то команда будет склонятся к "выпуску фич ради выпуска фич" (так как именно это поощряется), вместо принятия решений и изменений, которые имеют значение.
Пару недель назад я пригласил читателей моего канала задать мне любой вопрос. Спрашивали разное, а я с удовольствием на эти вопросы ответил.
Почитать тут: → https://qetz.al/essay/ama-2023-04/
Почитать тут: → https://qetz.al/essay/ama-2023-04/
Я как-то уже описывал историю того, как в Эквид добавили возможность торговать на Фейсбуке. История же возможности торговать в Инстраграме тоже занимательна.
Где-то лет ~5-6 назад Instagram решил добавить возможность показывать товары в своём фиде и в профилях. Штука эта интересная для продавцов, поэтому каждой e-commerce платформе её было интересно поддерживать.
Но команда Instagram была очень заинтересована в качестве продавцов, которые в то время могли этой возможностью воспользоваться. Поэтому возможность показывать товары в Instagram была доступна далеко не всем. Продавец должен был подать заявку и ждать — одобрят или нет. Для платформ ситуация была еще хуже. API для подачки заявки и проверки статуса был в закрытой бете и доступен только для одной самой крупной платформы. Остальным не давали — "мы в закрытой бете, ждите".
Возникла неприятная ситуация. Есть клёвая штука, которую хотят пользователи. Она доступна твоему конкуренту. Её нет у тебя — нужные API просто не доступны тебе. Проблема.
Решили мы эту проблему так. Пользователю же важно, чтобы можно было этот магазин в Инстаграме потенциально создать. Важен сам факт, а гладкость процесса это вторичные качества. Раз у нас не было доступа к нужным API, мы просто решили повторить то, что человек делает при ручной подаче заявки.
То есть мы добавили в интерфейс страницу про "продажи в Инстаграме". На этой странице мы разместили инструкцию как это сделать — сначала сделать магазин внутри Фейсбука (это мы уже умели), чтобы выгрузить товары в экосистему FB. Потом пойди вот по этой ссылке в настройки FB страницы и привяжи к ней Instagram аккаунт. После этого ты автоматически попадёшь в очередь на доступ к "магазину в Инстаграме", надо только ждать.
По сути это была всего лишь текстовая инструкция как это сделать вручную. Можно ли это было бы сделать без Эквида? Да, можно. Мы упрощали немного этот путь и автоматически синхронизировали товары, но само подключение к магазину в Инстаграме делать продавец сам. Были ли у этого пути недостатки? Много! Так как мы не знали статуса заявки — то не могли сказать, находится ли продавец всё ещё в очереди или ему уже отказали. Это вызывало сложности с поддержкой таких продавцов.
Но тем не менее мы помогали нашим пользователям подать заявку и часть из них получала доступ и начинала продавать в Инстаграме. А мы могли заявить, что "мы поддерживаем эту возможность". И эта фича стала одной из самой популярных на платформе.
C тех прошло много времени. Доступ к нужным API мы давно получили и давно улучшили весь процесс. Но до сих пор я вспоминаю это изменение, как один из примеров как минимальные вложения и более гибкий подход принесли невероятный возврат.
Где-то лет ~5-6 назад Instagram решил добавить возможность показывать товары в своём фиде и в профилях. Штука эта интересная для продавцов, поэтому каждой e-commerce платформе её было интересно поддерживать.
Но команда Instagram была очень заинтересована в качестве продавцов, которые в то время могли этой возможностью воспользоваться. Поэтому возможность показывать товары в Instagram была доступна далеко не всем. Продавец должен был подать заявку и ждать — одобрят или нет. Для платформ ситуация была еще хуже. API для подачки заявки и проверки статуса был в закрытой бете и доступен только для одной самой крупной платформы. Остальным не давали — "мы в закрытой бете, ждите".
Возникла неприятная ситуация. Есть клёвая штука, которую хотят пользователи. Она доступна твоему конкуренту. Её нет у тебя — нужные API просто не доступны тебе. Проблема.
Решили мы эту проблему так. Пользователю же важно, чтобы можно было этот магазин в Инстаграме потенциально создать. Важен сам факт, а гладкость процесса это вторичные качества. Раз у нас не было доступа к нужным API, мы просто решили повторить то, что человек делает при ручной подаче заявки.
То есть мы добавили в интерфейс страницу про "продажи в Инстаграме". На этой странице мы разместили инструкцию как это сделать — сначала сделать магазин внутри Фейсбука (это мы уже умели), чтобы выгрузить товары в экосистему FB. Потом пойди вот по этой ссылке в настройки FB страницы и привяжи к ней Instagram аккаунт. После этого ты автоматически попадёшь в очередь на доступ к "магазину в Инстаграме", надо только ждать.
По сути это была всего лишь текстовая инструкция как это сделать вручную. Можно ли это было бы сделать без Эквида? Да, можно. Мы упрощали немного этот путь и автоматически синхронизировали товары, но само подключение к магазину в Инстаграме делать продавец сам. Были ли у этого пути недостатки? Много! Так как мы не знали статуса заявки — то не могли сказать, находится ли продавец всё ещё в очереди или ему уже отказали. Это вызывало сложности с поддержкой таких продавцов.
Но тем не менее мы помогали нашим пользователям подать заявку и часть из них получала доступ и начинала продавать в Инстаграме. А мы могли заявить, что "мы поддерживаем эту возможность". И эта фича стала одной из самой популярных на платформе.
C тех прошло много времени. Доступ к нужным API мы давно получили и давно улучшили весь процесс. Но до сих пор я вспоминаю это изменение, как один из примеров как минимальные вложения и более гибкий подход принесли невероятный возврат.
Любой штукой в которой есть деньги и статус будут пытаться злоупотреблять. Из этого есть практический вывод — если ваш продукт шлёт письма с user generated content, этим рано или поздно воспользуются, чтобы слать спам (точно также как в каждой игре с user generated контентом будут пытаться рисовать пенисы, особенно в играх для более молодой аудитории)
Например за прошедшие годы злодеи пытались у нас слать спам так:
— Создавать новые аккаунты со спам-словом в названии профиля (мы шлём welcome письмо с этим словом)
— Смена email у аккаунта, когда спам-слово уже есть названии профиля (мы шлем письмо, что email сменили)
— Автоматизируют создание новых заказы в фейковом магазине, меняют темплейт письма о создании заказа на спамный (мы шлём письмо "как бы покупателю" о заказе).
— То же самое, но не при создании заказа, а при смене статуса заказа.
— Меняют темплейт письма, используют функцию preview template, чтобы послать себе тестовое письмо. Потом меняют постоянно адрес админа и делают так снова и снова.
— Приглашения staff accounts для управления магазином. В названии магазина — спам-слово, приглашают по спам-листу.
Если с этими штуками не бороться — через вас будут слать спам, что приведёт к падению репутации и недоставке ваших писем, а то и их полной блокировке.
Поэтому приходится вводить защиты — капчи, рейт-лимитинг, проверки, стоп-листы и разные другие более секретные штуки. Это "налог заметного продукта" — люди недооценивают какой процент времени на это тратится.
Например за прошедшие годы злодеи пытались у нас слать спам так:
— Создавать новые аккаунты со спам-словом в названии профиля (мы шлём welcome письмо с этим словом)
— Смена email у аккаунта, когда спам-слово уже есть названии профиля (мы шлем письмо, что email сменили)
— Автоматизируют создание новых заказы в фейковом магазине, меняют темплейт письма о создании заказа на спамный (мы шлём письмо "как бы покупателю" о заказе).
— То же самое, но не при создании заказа, а при смене статуса заказа.
— Меняют темплейт письма, используют функцию preview template, чтобы послать себе тестовое письмо. Потом меняют постоянно адрес админа и делают так снова и снова.
— Приглашения staff accounts для управления магазином. В названии магазина — спам-слово, приглашают по спам-листу.
Если с этими штуками не бороться — через вас будут слать спам, что приведёт к падению репутации и недоставке ваших писем, а то и их полной блокировке.
Поэтому приходится вводить защиты — капчи, рейт-лимитинг, проверки, стоп-листы и разные другие более секретные штуки. Это "налог заметного продукта" — люди недооценивают какой процент времени на это тратится.
Существует убеждение, что открытость фидбэку это безусловная ценность. Что вот есть люди, которые всегда открыты новым идеям и из-за этого растут. И существуют люди, которые закрыты, не меняются и это их сильно ограничивает.
Как и любая заметная громкая идея — она доведена "до абсурда", чтобы побудить людей к ней прислушаться. Как и любая заметная громкая идея — не упоминает деталей, что делает её неполной. Более того, для людей, которые воспринимают её буквально, это может быть ловушкой.
Дело в том, что в мире существует много а́кторов — людей с своими разными целями. Иногда эти цели совпадают с вашими. Иногда нет. А иногда они прямо противоположны вашим.
Эти а́кторы работают на то, чтобы этих целей достичь. Один из подходов для их достижения — убедить окружающих, что этих целей нужно достичь. И имеется в виду не приказ и не прямая просьба сделать так или иначе. А объяснение реальности, предложение такого взгляда на мир, в рамках которого эта цель является самоочевидной.
Даже если вы не слушаете специально кого-то — вы всё равно воспринимаете в какой-то мере чужой взгляд на мир и он будет влиять на вас. Это как с радиацией. Вы можете защищаться от неё хорошо или плохо — но радиация никуда не девается. Она всегда есть, пронизывает всё вокруг и влияет на вас. И если влияет достаточно сильно — мы откажемся от начальных установок и будем считать это хорошей идеей, даже если это кажется плохой идеей вам-сегодняшнему! И возврат к прошлый целям или убеждениям может быть практически невозможен, так как запрет на это будет заложен в новой модели мира.
Иногда это нам полезно, иногда — нет. Вертеться как флюгер под ветрами окружающих мнений — не хочется. Но полный отказ от восприятия новых идея это тоже экстремальное решение, которое несёт в себе проблемы — максимальная негибкость и неумение адаптироваться.
Решение, которое приходит в голову, состоит из двух частей: 1) профилирование источника фидбэка 2) иерархия целей с разным весом.
— Во-первых, ваш уровень восприятия внешнего фидбэка должен соответствовать "силе личности", которая этот фидбэк дает. Если вы доверяете человеку, если вы уверены в его компетенции — вы даёте больше веса этому фидбэку. Если вы не знаете человека, не уверены в его компетенции или не знаете, насколько его цели совпадают с вашими, насколько он заинтересован в том, чтобы вам было хорошо — фидбэк нужно дисконтировать. И чем больше не уверены — тем больше дисконтировать и задавать вопросов. (фио? градус? 😎)
Дисконтировать это не значит сразу отвергнуть. Можно выслушать (хотя начиная с какого-то уровня "токсичности" и расхождения целей — нужно и переставать слушать). Но выслушать не значит "сразу решить что-то менять".
— Во-вторых, убедительность, правдоподобность, конкретность фидбэка (то что я дальше буду называть собирательным словом "вес") должен соответствовать базовости убеждений, которые этот фидбэк просит вас изменить.
Убеждения имеют разную иерархию. Есть убеждения базовые (благополучность вашей семьи, вас и так далее), а есть более "высокого" уровня. Чем более базовое убеждение — тем больше веса вы должны требовать для его смены (причем рост экспоненциальный). А какие-то убеждения (например "моя семья должна быть в безопасности") настолько базовые, что для их смены вы должны получить информацию воистину титанических невероятных размеров.
Надо базовые убеждения держать в голове и с ними сверяться — если информация или фидбэк требует их поменять без достаточно веса — с нею нужно обращаться соответственно.
Ну, утрируя, если к вам подходят и рассказывают, что так как вы плохой — то вам надо продать квартиру, выселить семью в коммуналку и все деньги раздать — то делать так — не умный ход. Если вам рассказывают, что деньги от продажи квартиры за вас правильно вложат и вы своей семье заработаете в сто раз больше — тоже.
Как и любая заметная громкая идея — она доведена "до абсурда", чтобы побудить людей к ней прислушаться. Как и любая заметная громкая идея — не упоминает деталей, что делает её неполной. Более того, для людей, которые воспринимают её буквально, это может быть ловушкой.
Дело в том, что в мире существует много а́кторов — людей с своими разными целями. Иногда эти цели совпадают с вашими. Иногда нет. А иногда они прямо противоположны вашим.
Эти а́кторы работают на то, чтобы этих целей достичь. Один из подходов для их достижения — убедить окружающих, что этих целей нужно достичь. И имеется в виду не приказ и не прямая просьба сделать так или иначе. А объяснение реальности, предложение такого взгляда на мир, в рамках которого эта цель является самоочевидной.
Даже если вы не слушаете специально кого-то — вы всё равно воспринимаете в какой-то мере чужой взгляд на мир и он будет влиять на вас. Это как с радиацией. Вы можете защищаться от неё хорошо или плохо — но радиация никуда не девается. Она всегда есть, пронизывает всё вокруг и влияет на вас. И если влияет достаточно сильно — мы откажемся от начальных установок и будем считать это хорошей идеей, даже если это кажется плохой идеей вам-сегодняшнему! И возврат к прошлый целям или убеждениям может быть практически невозможен, так как запрет на это будет заложен в новой модели мира.
Иногда это нам полезно, иногда — нет. Вертеться как флюгер под ветрами окружающих мнений — не хочется. Но полный отказ от восприятия новых идея это тоже экстремальное решение, которое несёт в себе проблемы — максимальная негибкость и неумение адаптироваться.
Решение, которое приходит в голову, состоит из двух частей: 1) профилирование источника фидбэка 2) иерархия целей с разным весом.
— Во-первых, ваш уровень восприятия внешнего фидбэка должен соответствовать "силе личности", которая этот фидбэк дает. Если вы доверяете человеку, если вы уверены в его компетенции — вы даёте больше веса этому фидбэку. Если вы не знаете человека, не уверены в его компетенции или не знаете, насколько его цели совпадают с вашими, насколько он заинтересован в том, чтобы вам было хорошо — фидбэк нужно дисконтировать. И чем больше не уверены — тем больше дисконтировать и задавать вопросов. (
Дисконтировать это не значит сразу отвергнуть. Можно выслушать (хотя начиная с какого-то уровня "токсичности" и расхождения целей — нужно и переставать слушать). Но выслушать не значит "сразу решить что-то менять".
— Во-вторых, убедительность, правдоподобность, конкретность фидбэка (то что я дальше буду называть собирательным словом "вес") должен соответствовать базовости убеждений, которые этот фидбэк просит вас изменить.
Убеждения имеют разную иерархию. Есть убеждения базовые (благополучность вашей семьи, вас и так далее), а есть более "высокого" уровня. Чем более базовое убеждение — тем больше веса вы должны требовать для его смены (причем рост экспоненциальный). А какие-то убеждения (например "моя семья должна быть в безопасности") настолько базовые, что для их смены вы должны получить информацию воистину титанических невероятных размеров.
Надо базовые убеждения держать в голове и с ними сверяться — если информация или фидбэк требует их поменять без достаточно веса — с нею нужно обращаться соответственно.
Ну, утрируя, если к вам подходят и рассказывают, что так как вы плохой — то вам надо продать квартиру, выселить семью в коммуналку и все деньги раздать — то делать так — не умный ход. Если вам рассказывают, что деньги от продажи квартиры за вас правильно вложат и вы своей семье заработаете в сто раз больше — тоже.