Qetzal-1UP channel. Страница 12

Очень интересная статья про перевод сказок. "Кто такой Под-Котик и куда он делся": http://shustryakova.ru/%D0%BA%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B9-%D0%BF%D0%BE%D0%B4-%D0%BA%D0%BE%D1%82%D0%B8%D0%BA-%D0%B8-%D0%BA%D1%83%D0%B4%D0%B0-%D0%BE%D0%BD-%D0%B4%D0%B5%D0%BB%D1%81%D1%8F-2/

Оказывается детские знакомые нам сказки в свое время были заметно подчищены и изменены переводчиками, потому что им так показалось правильней. И нам сильно повезло, что был такой человек как Демурова, благодаря которой Алиса в стране чудес у нас более-менее неплохо переведена.

К предыдущему: также я уже писал, что такая же проблема восприятия у нас и про обычную жизнь. Мы думаем, что другие живут интереснее, а скорее всего нет: https://qetz.al/thought-log/2018-01/

Интересная статья "Most Initial Conversations Go Better Than People Think": https://blogs.scientificamerican.com/anthropology-in-practice/most-initial-conversations-go-better-than-people-think/

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

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

В новой Mac OS Mojave (10.14) добавили темный режим. Я неделю поработал в нем, но потом отключил. И вот в чем причина: https://ux.stackexchange.com/questions/53264/dark-or-white-color-theme-is-better-for-the-eyes#53268

> However, most studies have shown that dark characters on a light background are superior to light characters on a dark background (when the refresh rate is fairly high). For example, Bauer and Cavonius (1980) found that participants were 26% more accurate in reading text when they read it with dark characters on a light background.

...
> People with astigmatism (approximately 50% of the population) find it harder to read white text on black than black text on white. Part of this has to do with light levels: with a bright display (white background) the iris closes a bit more, decreasing the effect of the "deformed" lens; with a dark display (black background) the iris opens to receive more light and the deformation of the lens creates a much fuzzier focus at the eye.

Темные буквы на светлом фоне читаются лучше чем светлые на темном. Мои субъективные ощущения это подтверждают (когда темная тема включена я делаю больше опечаток, которые замечаю позже).

Даже сейчас, читая название, я не могу с первого (и второго) раза понять, что же конкретно эта настройка делает 🤦‍♂️

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

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

Сейчас конечно я бы никогда так не сделал.

Десять лет назад, еще до Эквида, я работал в X-Cart в отделе технической поддержки. Я тогда уже влезал в продукт и активно предлагал изменения. Два изменения я помню до сих пор, потому что теперь считаю их очень дурацкими.

Первое изменение связано с процессом апгрейда. X-Cart это downloadable софт, не SaaS, поэтому все происходило на сервере пользователя. По тем временам у X-Cart была весьма продвинутая архитектура апгрейда на новую версию. С cервера скачивалась разница (diffs) между версиями и применялась "на лету" прям на сервере пользователя. Это позволяло апгрейдить на новую версию софт даже если в нем были какие-то нестандартные изменения.

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

Какое-то время назад мне надо было написать гайд по интерфейсам и текстам в Эквиде. В результате появился вот этот манифест, который определяет мое понимание того "как правильно".

1. Explicit is better than implicit. Assume that there are no "defaults" that a user already knows.
2. Obvious wins. Make buttons, links and actions obvious.
3. Show value for users. Not features or characteristics. Value = it makes the merchant’s life better, easier, and saves them time. Brings more revenue (directly or indirectly) while removing hassle and pain from processes.
4. Design for intent. For the user’s motivation to move forward. He/she should see how great their business is going to be once they do what we suggest. Show the "future" merchant who is great and awesome.
5. No technical or e-commerce jargon. Keep in mind that everyone might not know what "URL" is.
6. Interface should be friendly but not unceremonious.
7. Remove FUD: Fear, Uncertainty, Doubt. Fear: "It is too complex. I am not technical person. I cannot do it". Uncertainty: "How can I do it? I don't know what to do". Doubt: "Should I do it?"

Понемногу выкладываю свои старые записи на сайт. Сегодня про продакт-менеджмент (текст из 2015 года): https://qetz.al/essay/product-management-advices/

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

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

Сложно говорить “нет” своим идеям. Сложно говорить “нет” идеям команды. Но если ты не умеешь это делать и говоришь “да” каждому предложению, то ты не сфокусируешься на действительно важных вещах.
Не ищи причины сделать идею. Конечно ты их найдешь, это классический confirmation bias. Ищи возможность и причины не делать идею. Подвергай ее сомнениям, ищи в ней “дырки”.
Хороший продакт-менеджер никогда не говорит сразу “да”. Его первый ответ “по дефолту” всегда “нет”.

Не делай фичу, а решай проблему
Клиенты хотят решений своих проблем и пользы. Фичи им не нужны.
Правильное изменение продукта решает боль и проблемы клиента. Прямо или косвенно увеличивает его продажи.
Если ты не знаешь какую боль клиента решит изменение и какую пользу принесет, самое время сказать этому изменению “нет”.

Меряй успешность в revenue
Revenue и количество активных пользователей — главная мерка успешности продакт-менеджера. Количество выпущеных фич, их оригинальность или радость пользователей не определяют насколько ты хорош.
Если revenue растет — продакт-менеджер молодец. Если не растет — не молодец.

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

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

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

Вот тут отличная подборка технических пост-мортемов: https://github.com/danluu/post-mortems

Отличная презентация с кучей примеров про то, как делать штуки, которые воспринимаются быстрыми: http://assets.eli.wtf/talks/perceived-perf-perfmatters-2018

Видео: https://www.ustream.tv/recorded/114915879

Все сводится к:
- Начинай грузить все заранее (когда понял интент)
- Отвлекай пользователя на развлечения, чтобы он не заскучал

Также весьма понравилась вот эта цитата:

> "Также я попросил Келли позволить мне пройти тринадцатинедельный курс менеджмента в Гарвардской бизнес-школе летом 1969. Это был передовой курс для управленцев, который проходили около ста пятидесяти тщательно отобранных продвинутых руководителей – и Келли написал мне яркое рекомендательное письмо, которое позволило мне попасть туда. Что ещё важно, по одобрению Келли это обучение было оплачено Локхид. Он поддержал меня, хотя и утверждал, что будет пустая трата времени. “Я могу научить тебя всему, что нужно, чтобы управлять компанией, за полдня. Тебе не нужен Гарвард, чтобы понять, что гораздо важнее слушать, чем говорить. Ты можешь получить пятёрки от всех гарвардских профессоров, но ты не станешь хорошим управленцем, пока не станешь решительным: даже неверное решение, сделанное вовремя, лучше отсутствия какого-либо решения. Последнее, что тебе нужно знать: не решай проблемы наполовину, вырывай их с корнем и до конца. Вот и всё. Теперь ты можешь руководить этим проклятым местом. А теперь иди домой и выпей чего-нибудь."

Прочитал воспоминания Бена Рича "Skunk Works" (есть перевод на русский) — это такое обособленное подразделение Lockheed Martin, которое занималось секретными инновационными самолетами. Например они сделали самолет-шпион U-2 или первый стелс F-117 (который выглядит как одно большое черное крыло).

Это такой сборник баек и историй про разработку самолетов. Байки достаточно забавные, но наверное если вам интересны самолеты, то вам книга понравится еще больше (чем мне).

Мне же было интересно почитать про организацию работы — как Skunk Works могли десятилетия делать реально прорывные штуки? Ну оказывается ничего неожиданного: небольшие команды, право принимать решения, быстрая коммуникация, минимум бюрократии. Подробнее можно почитать вот тут: https://en.wikipedia.org/wiki/Kelly_Johnson_(engineer)#Kelly_Johnson's_14_Rules_of_Management (сильное влияние того, что они были аутсорсером для военных)

В книге Харари "Sapiens" есть глава про то, как корпорации открывали и управляли целыми странами. Там есть такая цитата:

> “Наемники захватывали остров за островом, значительная часть Индонезии сделалась колонией VOC. Почти 200 лет компания управляла Индонезией. Только в 1800 году острова перешли под контроль нидерландского государства и еще 150 лет были его колонией.”
(VOC — Dutch East India Company)

Сейчас это кажется диким. Частная компания 200 лет управляла целой страной.

Интересно развернуть этот пример и применить его к Интернету и компаниям. Сейчас Интернет управляется и представлен частными компаниями. И это для нас совершенно нормально. Как знать, может лет через 50 Интернет (или разные отдельные "интернеты") будут напрямую управляться государствами. А потом еще лет через 100 получит независимость (Facebook/Apple/Amazon/Google как отдельные независимые entities, которые сами имеют и землю и армию и своих граждан).

(Еще один пример того, что действие / решение часто может вызывать очень неочевидные и нежелательные последствия)

Есть полностью бесплатные cервисы конференц-связи. Оказываются они используют очень интересную дырку в законе, чтобы зарабатывать деньги.

В US есть закон, который позволяет небольшим сельским телефонным компаниям брать деньги с больших телефонных компаний за доступ к своим сетям. То есть если кто-то со связью от AT&T звонит на номер небольшой телефонной компании из Южной Дакоты, то AT&T заплатит им termination fee за каждую минуту разговора. Этот закон приняли для того, чтобы эти небольшие компании поддержать — им же дорого тянуть в необжитой местности линии, а звонков там немного.

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

Ссылка на английском: https://aaronparecki.com/2012/03/25/8/how-does-freeconferencecall-make-money

Недавно вышла книга "Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs" от Ken Kocienda: https://www.amazon.com/Creative-Selection-Inside-Apples-Process/dp/1250194466 Это чувак, который играл ключевую роль в создании Safari и софта оригинального iPhone (делал клавиатуру).

В книге он описывает процесс создания и полировки этих двух продуктов. Там нет какой-то Правильной Методологии Эппла или же невероятных мыслей, которые откроют Главный Секрет Создания Продуктов. Зато там есть интересные истории и моменты того, как Эппл делает свои штуки.

Что мне запомнилось

1. Когда делали Сафари, было указание от Джобса сделать его самым быстрым браузером на Маке. Поэтому команда сделала тест, который измерял скорость загрузки разных страниц в Сафари и показывала некий счет. Было принято простое правило, что никакие изменения в коде не должны увеличивать этот score. Оставлять таким же или уменьшать. В результате Safari получился быстрым, быстрее всех своих аналогов. (Простые четкие правила рулят!)

2. Маленькие команды: все новые продукты разрабатываются маленькими командами, где у каждого большая ответственность. Каждый человек в команде отвечает полностью за какое-то направление. При этом каждый разработчик в такой команде немного дизайнер, продакт-менеджер и тестер. Например автор отвечал полностью за клавиатуру iPhone. Одной из его задач было сделать звук тапа на кнопки. Он записал стук карандаша по столу, обработал и сделал два варианта. Стив Джобс выбрал один из них и этот звук был в Айфоне лет пять. (чувак — программист!)

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

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

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

5. За простыми штуками скрывается сложная и напряженная работа. То, что кажется очевидным из-за знания "задним числом", на самом деле не очевидно, когда ты это придумываешь.

В книге приводится подробный рассказ, как придумывали клавиатуру iPhone. Это был непростой путь cо странными начальными прототипами и решениями. Был момент, когда неспособность придумать надежную(то есть чтобы можно было быстро набирать без ошибок) софтверную клавиатуру была признана угрозой для выпуска iPhone и ВСЮ команду разработку бросили на придумывание решения.

И Ken Kocienda как раз нашел решение, которое через множество итераций, описанных в книге, привело к тому, что мы видим сейчас. Главная его идея была в том, что надо прощать промахи по кнопках и использовать словари и эвристики, чтобы понять, что хотел ввести пользователь. Именно поэтому зона тапа на кнопках БОЛЬШЕ чем сама кнопка. Телефон автоматически догадывается, куда мы хотели нажать, а на самом деле мы часто промахиваемся. (Так что переделки и мучительные итерации — это нормально.)