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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(начало)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(начало)

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Если в компании уже есть готовые процессы для этого — отлично. Мой совет для ситуаций, когда желание есть — а процесса нет.

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

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

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

Ваша задача — продемонстрировать, что 1) вы хорошо работаете и быстро учитесь 2) вы понимаете как работает компания 3) с учетом всего этого шансы научить вас за разумный срок продакт-менеджменту выше, чем шанс того, что новый человек с улицы будет хорошо работать и поймёт что к чему; и 4) вас и ваше желание должны вспомнить на этапе поиска нового человека в продуктовую команду.

Для того, чтобы это продемонстрировать вы должны сами предложить и сделать проект, который 1) интересен и важен продуктовой команде 2) у продуктовой команды есть доверие и некоторая уверенность, что вы его сами(!) сделаете хотя бы на 80% от нужного качества (!).

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

Если этому не следовать, то с вами или не будут вообще вместе что-то делать("да мне проще самому всё сделать, чем объяснять и переделывать") или же, что вероятнее, дадут какую-то ненужную бесполезную задачу "чтобы занять". Эта задача вас к цели не приведёт и вы потеряете время.

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

И очевидно, что вы эти проекты делаете в свободное время и ваша основная работа не должна пострадать.

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

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

Вот уже два года наша продуктовая команда раз в месяц пишет документ "Новости прошлого месяца". Этот документ имеет три секции:
— Что мы выпустили за прошлый месяц
— Над чем мы сейчас работаем
— Над чем мы будем работать на горизонте 2-3 месяцев

В каждой секции описаны изменения («фичи») и проекты. Описание любого изменения тоже имеет чёткую структуру:
— What: описание изменения и нового изменения, что мы сделали.
— Why & Problem: какую проблему решало это изменение, почему мы решили его сделать.
— Outcome: какой результат мы ожидаем или уже получили.

Документ этот писать никто не любит. И не каждой компании этот документ в этом же виде был бы полезен (особенно на ранних этапах развития).

Но у него есть и заметные плюсы. И один из главных достоинств такого документа тот же, что и в продуктовых питчах. Когда пишешь связный текст "вот что мы делаем, вот почему и вот что ожидаем", то в нём сразу видны все слабые точки: неубедительные доводы, слабая аргументация, непродуманные ожидания, отсутствие фокуса. Всё то, что не видно в формате "слайда" или "строчки в таблице" — видно в связном тексте. Неудивительно, что в Амазоне так любят свои "шестистраничники" (6-pagers).

И самая частая и самая проблемная точка — секция "Why & Problem", "зачем и почему".

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

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

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

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

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

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

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

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

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

И так далее. У каждого отдела есть вопросы к продуктовой команде и это нормально. Если продукт в сердце компании, то любые изменения продукта влияют на всех. Отсюда вопросы. Проблема не в вопросах, проблема в том, что 1) это одинаковые вопросы от разных людей 2) у вас будут просить заранее ответы с детализацией, которая не нужна

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

— А что вы делаете? А зачем? → Вот документ со свежим списком и объяснением, не согласны — пишите в комментариях к документу.
— А когда будет сделана моя штука? А почему не скоро? → Вот тут список того, над чем мы собираемся работать, почему и какой прогноз по датам. Если вы считаете, что надо делать что-то другое — давайте обсуждать, почему ваша штука приоритетней текущего плана.
— А что интересного планируете выпускать? Нам надо для плана анонсов → А вот план.
— А пишите нам, когда выпускаете новые штуки — мы будем партнёров оповещать → Мы будем публиковать ссылку на документ в публичном канале, который все читают. Это наш публичный чейндждог, используйте его как хотите.
— А расскажите про это вот изменение, нам надо маркетинговые материалы по ней готовить → А вот тут в документе описано что, зачем и почему.
— А давайте каждое изменение в фичах, доступных на линейке планов, обсуждать с командой. Приходите к нам с каждым изменением для аппрува. → Вот документ с описанием изменений. Читайте, обсуждайте внутри, если с чем-то не согласны — приходите обсуждать конкретную штуку.

Паттерн один и тот же ("push/pull стратегии" или "тянитолкай" это всё примерно про то же). Такой подход не убирает вопросы на 100%(особенно если в деле завязаны игры статуса — "нет пусть ВЫ ко мне придёте"), но всё же облегчает жизнь. И самое интересное, что на практике мало кому нужно столько информации, сколько они запрашивают. Человек, который с радостью будет хотеть учавстовать в обсуждение каждого изменения ("хочу всё знать") на деле может не читать публичный документ и не обсуждать ничего (то есть не так уж это было ему/ей важно).

Помимо изучения латинского одно из моих развлечений — открыть Свод законов Российской империи и почитать какую-то случайную главу. Этот свод — издание всех законов страны (Российской Империи), от основного закона до там лесного или пожарного устава.

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

Эту штуку сложно объяснить, но я попытаюсь её продемонстрировать на примере.

Вот так сейчас начинается Лесной кодекс Российской Федерации:
> Лесное законодательство и иные регулирующие лесные отношения нормативные правовые акты основываются на следующих принципах:
> 1) устойчивое управление лесами, сохранение биологического разнообразия лесов, повышение их потенциала;
> 2) сохранение средообразующих, водоохранных, защитных, санитарно-гигиенических, оздоровительных и иных полезных функций лесов в интересах обеспечения права каждого на благоприятную окружающую среду;
> 3) использование лесов с учетом их глобального экологического значения, а также с учетом длительности их выращивания и иных природных свойств лесов;
> 4) обеспечение многоцелевого, рационального, непрерывного, неистощительного использования лесов для удовлетворения потребностей общества в лесах и лесных ресурсах;
[и ещё семь похожих пунктов]

А вот так лесной устав Российской Империи:
> 1. Лѣса раздѣляются на государственные и на состоящіе въ общественной и частной собственности.
> 2. Государственные лѣса суть тѣ, которые составляютъ собственность казны.
> 3. Государственные лѣса раздѣляются на казенные и на имѣющіе особое предназначеніе.

Или вот ещё про Государственный Совет:
> 52. В том случае, когда заседание Государственного Совета не
состоится по неприбытию положенного числа его Членов (ст.31), подлежавшее рассмотрению дело, если оно признается внесшим его Министром или Главноуправляющим отдельной частью неотложным, назначается к новому слушанию не позднее двух, после несостоявшагося заседания, недель. При таком слушании, дело рассматривается, каково бы ни было число прибывших в заседание Членов Совета.

Или про министерства:

> 153. Министерства установлены на тотъ конецъ, чтобъ непрерывнымъ дѣйствіемъ ихъ и надзоромъ доставить законамъ и учрежденіямъ скорое и точное исполненіе.
> 154. Существо власти, ввѣряемой Министрамъ, принадлежитъ единственно къ порядку исполнительному: никакой новый законъ, никакое новое учрежденіе,или отмѣна прежняго, не могутъ быть установляемы властію Министра.

...

> 156. Власть Министровъ состоитъ въ томъ, что они могутъ понуждать всѣ подчиненныя имъ мѣста и лица къ исполненію законовъ и учрежденій.
> 157. Послѣдствія, отъ сей власти проистекающія, суть: 1) опредѣленіе и увольненіе высшихъ чиновниковъ по представленіямъ Министровъ, а нижнихъ собственнымъ ихъ утвержденіемъ; 2) надзоръ надъ дѣйствіемъ всѣхъ подчиненныхъ мѣстъ и лицъ; взысканіе отъ нихъ отвѣтовъ въ случаѣ бездѣйствія или неправильнаго исполненія; удаленіе отъ должностей и преданіе ихъ суду, въ случаѣ важныхъ преступленій; 3) разрѣшеніе, силою существующихъ законовъ и учрежденій, всѣхъ затрудненій, встрѣчающихся при исполненіи; 4) принятіе всѣхъ мѣръ, нужныхъ къ дѣйствію законовъ или учрежденій, когда они утверждены и обращены къ исполненію Министра.

...

> 166. Въ обширномъ кругѣ дѣлъ, въ разнообразной связи разныхъ нуждъ и пользъ, нельзя не встрѣтить въ исполненіи разныхъ затрудненій и неудобствъ; но не всѣ неудобства могутъ быть принимаемы поводомъ къ новымъ постановленіямъ. Министръ долженъ испытать прежде всѣ способы исправленія, не выходя изъ порядка существующаго, и потомъ, измѣривъ и сравнивъ неудобства, кои и отъ новаго закона, по самой новости его, произойти могутъ, приступать къ его предложе нію. Во всѣхъ Министерствахъ, особливо же въ тѣхъ, коихъ предметомъ есть государственное хозяйство и общая промышленность, должно наблюдать, чтобъ мѣрами излишняго надзора и многосложностію правилъ не стѣснить частной предпріимчивости. Истинные способы сего управленія должны состоять болѣе въ отвращеніи препятствій, нежели въ точномъ и понудительномъ предписаніи путей, коими должна шествовать промышленность. Здѣсь скорѣе найти и указать ихъ можетъ частная польза, нежели законъ.

Закон это попытка кодифицировать, описать нужное поведение. Но тут делается дополнительное усилие, чтобы это описание было не только точным, но и ясным. Эта ясность сложно объяснима, но чувствуется. Это что-то, что является антонимом типичного legalese в юридических документах.

Задача ясной прямой понятной коммуникации меня интересует давно. Поэтому интересно понять — в чем же секрет этой ясности? Как её воспроизвести? (еще не понял, кстати)

Так что если вам тоже интересны примеры прекрасного ясного русского языка, которым просто рассказываются сложные вещи — читайте Свод законов Российской Империи.

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

Мы устроены так, что получаем удовольствие, когда понимаем как всё устроено. Но мы также устроены так, что смешиваем понимание как всё устроено с более удобным управлением этим "всем".

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

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

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

> The secret to this clarity might lie in several factors:
> — Precision: The texts are precise in their language, leaving little room for ambiguity. Each word seems to be chosen carefully to convey a specific meaning.
> — Simplicity: Despite dealing with complex matters, the language used is relatively simple and direct. This makes the texts more accessible to a broader audience.
> — Structure: The texts are well-structured, with clear divisions and subdivisions. This helps to organize the information and make it easier to understand.
> — Contextual Relevance: The texts seem to be written with a deep understanding of the context in which they will be applied. This allows them to address specific issues and needs effectively
> To reproduce this clarity, one might focus on these factors, aiming for precision, simplicity, good structure, and contextual relevance in their writing.

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

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

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

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

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

Существует постоянное давление на усложнение продукта ("наши пользователи хотят вон то!"). Но как правило нет давления на упрощение, удаление, убирание штук.

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

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

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

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

У нас эту роль играет выделенная команда, чья цель описывается как: "Make it easy, save time and bring delight". Их задача делать сложноизмеримые вещи:
— Делать сложные вещи — проще ("не мог разобраться сам → теперь могу")
— Находить области, где автоматизация и изменения могут увеличить эффективность и высвободить время ("делал эту штуку обычно полчаса → теперь 5 минут")
— Сделать так, чтобы использование продукта приносило удовольствие, убирать мелкие занозы и неудобства. ("страница грузилась медленно и дергалась → грузится быстро и гладко")

Результаты радуют. Вот вам пример одной решенной проблемы.
Продакт-менеджер(привет, Матвей) смотрит записи сессий пользователей и обнаруживает что-то необычное. Посмотрите на запись сами.

Пользователь редактирует товар. Появляется плашка о несохраненных изменениях, которая предлагает или сохранить или уйти назад. Пользователь жмёт Back и тут происходит странное — что-то мигает на экране про несохраненные изменения и все снова становится как было. Плашка не убралась. Пользователь пробует снова, снова и снова — результата нет. Кнопка не работает? Бесит! В чём же дело? Тут предлагаю остановится и попытаться угадать причину проблемы.

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

(начало)

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

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

И когда знаешь в чём проблема — её уже просто решить, отслеживаем быстрые двойные клики, не закрываем попап, если второй клик произошёл слишком быстро после первого. Был пользователь, который считал, что продукт бесит и не работает. Стал счастливый пользователь, который может дабл-кликать в своё удовольствие.

Вот такая история.

Ещё в законах Российской Империи, про которые я писал в прошлом, можно найти вот такие интересные пункты:

> 158. Въ обстоятельствахъ чрезвычайныхъ, требующихъ высшаго
разрѣшенія, когда не можетъ оно быть отлагаемо безъ важнаго вреда или государственнаго ущерба, Министры уполномочиваются дѣйствовать всѣми ввѣренными имъ способами, не ожидая сего разрѣшенія; но они обязаны доносить въ то же время о принятыхъ ими мѣрахъ и о причинахъ ихъ настоятельности.
...
> 210. Hе считать также превышеніемъ власти, когда Министръ въ
чрезвычайныхъ какихъ либо случаяхъ приметъ рѣшительную мѣру и по принятію ея окажется: 1) что она въ видахъ общей безопасности была необходима; 2) что, по настоятельности случая,не могъ онъ,не попустивъ видимой опасности, отлагать сію мѣру до высшаго разрѣшенія.

Любые правила суть неполные. Они пытаются описать нужное поведение во всех ситуациях. Предусмотреть все ситуации. Так как жизнь заведомо сложнее, то это сделать невозможно, а попытка создать правила, в которых учтено всё-всё, приводит к излишне сложным и длинным результатам с которыми сложно управляться.

То есть мы хотим с одной стороны иметь достаточно простые правила, а с другой — сделать так, чтобы люди в любой ситуации поступили правильно (согласно правилам).

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

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

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

(начало)

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

Вокруг нас много неписанных правил, условностей и ограничений. ("принято так", "надо так", "по другому не получится"). Эти правила созданы не на пустом месте, они имеют причину, они нужны и важны ("забор Честертона")

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

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

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

И вот умение хотеть достичь цели так сильно ("нет варианта не сделать"), что начинаешь какие привычные правила можно отменить — важное (хоть для продукта, хоть для компаний).

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

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

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

Мы обычно плохо видим паттерны в числах, если специально не тренировались для этого. Другое дело — лица. Их мы распознаем и отличаем автоматически и очень хорошо. Поэтому, кстати, есть подход, когда числовые данные превращают в лица для дальнейшей обработки (называется identicon или hash avatars, примеры, а ещё есть лица Чернова)

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

Как же правильно презентовать данные? Хорошая новость в том, что есть набор простых правил и идей, которым можно достаточно механически следовать.

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

(начало)

Две главные идеи:
1. Когда хороший руководитель смотрит на число, то он/она всегда задаёт вопрос:
— Всё хорошо? Должны ли мы продолжать делать то, что мы делаем и побольше? — Всё плохо? Должны ли мы как-то изменить наш курс?

2. Факт или число сами по себе не значат ничего. А иногда могут даже повредить: они создают фальшивое ощущение понимания ситуации.

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

Шесть базовых приёмов для этого.

I. Никогда не иметь только абсолютные значение или только проценты. В большинстве случаев вам надо показать и то и то.

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

Примеры:
а) Презентовано: использование фичи выросло на 30%. Ура!
Реальность: 100 пользователей из 10,000 использовало фичу, а стало 130.
б) Презентовано: спустя полгода 800 платных пользователей использует эту штуку. Ура!
Реальность: штука доступна 150,000 платным пользователям, её использует 0.5%.

II. Всегда сравнивать с целым или с большой картиной.

Плохо: наш объём оплат через СБП превысил 100млн.₽.
Хорошо: наш объём оплат через A СБП превысил 100млн.₽, это 10% от всех оплат.

III. Cравнивать с историчными данными.

Плохо: наш объём оплат через СБП превысил 100млн.₽.
Хорошо: наш объём оплат через A СБП превысил 100млн.₽, в прошлом месяце было 70млн. — рост на 43%.

IV. Сравнивать с похожими элементами.

Плохо: наш объём оплат через СБП превысил 100млн.₽.
Хорошо: наш объём оплат через A СБП превысил 100млн.₽, а вот оплаты через карточки — 150млн.₽ Оба метода примерно одинаково популярны.

V. Сравнивать с целью.

Плохо: наш объём оплат через СБП превысил 100млн.₽.
Хорошо: наш объём оплат через A СБП превысил 100млн.₽. Это 125% от нашей цели на год в 80млн.

VI. Когда и как считались данные.
Это опциональная, но полезная привычка. Рядом с расчитанными данными полезно указать когда они были расчитаны и как, указать ссылку на отчёты, репорты откуда они были взяты.

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

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

Если нарезать текущие данные по разным признакам (по времени, по стране, по браузеру и т.д. и т.п.), то это тоже может привести к неожиданным инсайтам.

Это, разумеется, не полный список. У вас, в вашей специфике и индустрии будут свои особенности. Но посыл и цель показа данных, главный вопрос — вряд ли будет другим:
— Всё хорошо или нет? Должны ли мы продолжать делать то, что мы делаем или надо что-то поменять?

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

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

> It is a profoundly erroneous truism, repeated by all copybooks and by eminent people when they are making speeches, that we should cultivate the habit of thinking of what we are doing. The precise opposite is the case. Civilization advances by extending the number of important operations which we can perform without thinking about them.

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

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

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

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

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