Qetzal ad libitum, ad infinitum

Гео и язык канала: Россия, Русский
Категория: Познавательное

«Открылась бездна звезд полна;
Звездам числа нет, бездне дна»
Всё то, что интересует меня сейчас. Product management, дизайн, стартапы, поведение, книги, этика и другие штуки — https://qetz.al
Рандомный шитпостинг @qetzal_etcetera

Гео и язык канала
Россия, Русский
Фильтр публикаций

Отличный пример применения pre-mortems для управления экзистенциальными рисками от Luca Dellanna (у него кстати есть неплохая книга про неэргодические системы, когда ансамблевые и временные вероятности событий не совпадают)

> Минутное упражнение для снижения рисков в вашей жизни.

> 1) Представьте, что вы проснулись в больнице. Какая бы была наиболее вероятная причина этого? Есть ли что-то, что вы можете сделать сегодня, чтобы предотвратить это?

> 2) Представьте, что ваш партнер с вами расстался. Какая бы была наиболее вероятная причина этого? Есть ли что-то, что вы можете сделать сегодня, чтобы предотвратить это?

> 3) Представьте, что вы потеряли работу. Какая бы была наиболее вероятная причина этого? Есть ли что-то, что вы можете сделать сегодня, чтобы предотвратить это?

> 4) Представьте, что вас подали в суд. Какая бы была наиболее вероятная причина этого? Есть ли что-то, что вы можете сделать сегодня, чтобы предотвратить это?

> 5) Представьте, что вы уехали в командировку и посреди ночи получили пропущенный звонок от своей семьи. Какая наиболее вероятная причина этого? Есть ли что-то, что вы можете сделать сегодня, чтобы предотвратить это?


2) Тестирование на живых игроках
Valve тестировали на живых игроках все изменения, чтобы понять — что работает, а что нет. Но особенно интересна следующая часть:

> Toward the middle of the project, once the major elements were in place and the game could be played most of the way through, it became mostly a matter of fine-tuning. To do this, we added basic instrumentation to the game, automatically recording the player’s position, health, weapons, time, and any major activities such as saving the game, dying, being hurt, solving a puzzle, fighting a monster, and so on. We then took the results from a number of sessions and graphed them together to find any areas where there were problems. These included areas where the player spent too long without any encounters (boring), too long with too much health (too easy), too long with too little health (too hard), all of which gave us a good idea as to where they were likely to die and which positions would be best for adding goodies.

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

3) Все основные штуки, которые есть в Half-life, были придуманы тайным собранием, которое собиралось каждый день по 6 часов в течении 5 месяцев. В результате был создан общий дизайн-документ, который описывал всё.

Создание такого комитета — это попытка обойти ограничения иерархичных структур:

> In order for highly hierarchical organizations to be effective, they require one person who understands everyone else’s work at least as well as the individuals doing the work, and other people who are willing to be subordinates yet are still good enough to actually implement the design. Given the complexity of most top game titles, this just isn’t practical — if you were good enough to do the job, why would you want to be a flunky? On the other hand, completely unstructured organizations suffer from lack of information and control — if everyone just does their own thing, the odds that it’ll all fit together in the end are somewhere around zero.

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

> Through constant cycle of play-testing, feedback, review, and editing, the Cabal process was also key in removing portions of the game that didn’t meet the quality standards we wanted, regardless of the level of emotional attachment the specific creator may have had to the work.

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

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

Прочитал статью, которой уже почти четверть века, про подход к разработке игры 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.

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

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



— Не читать слайды, не проводить на слайде много времени

Если вы читаете слайд (то есть ваша речь на бОльшую часть совпадает с написанным), то как правило что-то не так.

В этом случае вам надо или cильно сокращать текст на слайдах или меньше говорить (люди и так прочитают — "Остальное вы можете прочитать на слайде").

Если вы рассказываете и у вас открыт один слайд больше 1 минуты — что-то не так. Люди этот слайд уже прочитали (спойлер!), им уже стало скучно.

Поэтому бейте слайды на несколько. 5, 10 — не страшно! Не должно быть ситуации, когда вы показываете слайд с сутью и потом 3 минуты подводите к этой сути. Не спойлерите сами себя!

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

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

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

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

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

Я лично наблюдал ситуацию, когда два замечательных человека решили выступить дуэтом на технологической конференции. У них была очень интересная тема, но они совершенно не умели публично говорить. Когда они провели тестовый рассказ небольшой группе коллег — это был мрак и ужас, испанский стыд. Они заперлись в конференц-зале офиса и стали тренировать свой доклад. Рассказали они его, наверное раз 20-30? В итоге на конференции их доклад лучшим.

Если вы плохо рассказываете публично — тренировка вытянет ваш рассказ до "приемлимо".

Если вы хорошо рассказываете публично — тренировка сделает ваш рассказ офигительным.

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

Чем более глобальнее вещи вы делаете, чем больше компания, тем больше вещей зависит от качества вашей презентации. Когда над всем продуктом работает 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 перевести сложно. "Настойкость"? (настоять [на своём] + стойкойсть?) "Настойка"? "Настойчествовость"?

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

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

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

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

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

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

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

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

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

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

— У ребёнка есть две любимые книжки. Истории про Квака и Жаба. И сказки Сутеева. У этих книг есть разница в вёрстке, которая заметно влияет на меня.

Я читаю ребёнку книжки перед сном. Ребёнок хочет много историй, а спать не хочет. Я же хочу почитать сколько запланировал, а потом убедить ребёнка пойти засыпать. Так вот разница в этих двух книжках — где начинается новая история. В книге о Кваке и Жаба новая история всегда начинается на новой странице слева. Когда я дочитываю одну историю — другая не видна! В книге Сутеева всё наоборот — когда я дочитываю история, следующая всегда видна справа сразу. Соответственно я дочитываю одну сказку и ребёнок сразу видит начало следующей и просит её. В книге про лягух я заканчиваю историю и могу сказать "теперь на этом всё, давай спать". Нет "завлекающей" следующей страницы.

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

— То же самое с "детским" режимом на разных приборах. Этот режим защищает от случайных нажатий, но не является по настоящему "детским". Новорождённый первые месяцы может спать очень чутко. Два часа укладывал, потом встал с кровати, хрустнул коленкой и всё по новой. Но при этом подавляющее число бытовых приборов любят 1) светить лампочками, бодро рапортуя, что "я работаю!" 2) пищать при любых изменениях своего состояния.

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

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

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

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

И таких мелочей много. Большинство же календарей просто показывают N ближайших событий. Чтобы сделать хорошо и гибко, надо разговаривать с людьми у которых много звонков и которые могут отрефлексировать (сами или с вашей помощью) "а как бы было удобно".

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

В US приняли закон о том, что если в товаре или блюде есть кунжут, то про это надо явно писать (в дополнение к другим аллергенам). Разумный ли это закон? Выглядит разумным — он защищает людей с аллергией на кунжут.

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

Когда есть требование писать о кунжуте, то отсутствие записи о кунжуте является обещанием. Если обещание дать затратно (а у многих компаний нет процессов, который гарантирует, что следы кунжута от предыдущих блюд не попадут в новое блюдо;), то проще добавить незначительное число кунжута к блюдам, чтобы на вкус не влияло, но надпись добавить можно, не обманывая. "Да, да, тут кунжут, ничего не можем поделать".

Умение оптимизировать поведение под правила, ограничения и нормы — неотъемлемая наша часть.

Сделали специальную карту, чтобы подростки ходили бесплатно в музеи — возник рынок обналичивания через подставные эвенты.
Вы решили мотивировать найм молодых профессоров через требование увеличения показателя «доля преподавателей в возрасте до 39 лет» — всех старше оставят, но выведут из основного "состава" в консультанты, которые не учитываются.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда команда растёт, появляется больше связей, 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 — разные секции и могут (а часто и должны) писаться отдельно. Одна из частых проблем — готовое решение в голове, которое диктует проблему. Чтобы избавится от этого, проблему стоит описывать отдельно, не пытаясь описывать конкретные решения и изменения.

Показано 20 последних публикаций.