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

Тут Apple недавно узнала, что есть компании, которые занимаются тем, что дают аналитику по сессиям пользователей. Записывают экран и передают его на сервер, чтобы дизайнеры и продакты могли анализировать как люди взаимодействуют с приложением. Известные сервисы про это: Appsee и UxCam.

Всем приложениям, которые использовали SDK этих компаний было вынесен ультиматум: убрать SDK в 24 часа или приложение будет удалено из App Store. ТЫДЫЩ и бизнес Appsee и UxCam уменьшился.

Вторая новость про email провайдера из US. Ребята предоставляли email хостинг 18 лет, а потом хакер удалил все данные с их серверов, включая бэкапы: https://krebsonsecurity.com/2019/02/email-provider-vfemail-suffers-catastrophic-hack/ ТЫДЫЩ, бизнес исчез.

Эти две новости наводят на размышления об устойчивости компаний к таким событиям "черного лебедя".

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

Баланс между тем от событий какой вероятности защищаться и что вкладывать в защиту — свой выбор каждой компании. Но вопрос "а что если..?" супер-важный для всех.

Умение устанавливать правильные цены — наука и искусство одновременно. Люди целые книжки пишут и компании организовывают вокруг этого. Я знаю три штуки про цены. Первые две очевидные: скорее всего вам надо сделать цены выше (даже если некомфортно) и цена не равна ценности (отталкиваться надо от создаваемой ценности). Третья штука про цены у SaaS компаний. Я думаю, что хорошие тарифные планы у SaaS компании всегда должны иметь (явно или неявно) две штуки, которые я называю "налог на понты" и "налог на успешность".

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

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

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

Эту штуку обычно делают тремя подходами:
— Плата за единицу использования (за пользователя, за сайт, за потребленные мегабайты чего-то)
— Процент с транзакций (transaction fees, revenue share), если продукт как-то через себя перегоняет деньги
— Ограничения, которые выдавливают успешных ребят на старшие планы.

Вот например Dropbox: https://www.dropbox.com/business/pricing Есть как разные планы для разных клиентов, так и зависимость цены от величины использования продукта (количества пользователей).
Shopify: https://shopify.com/pricing Явно прописали transaction fees, берут процент с оборота.
У BigCommerce интереснее: https://www.bigcommerce.com/pricing/ Они гордо пишут, что не берут процент с оборота, но если промотать ниже, то будет строчка с ограничением по "Online sales per year" — продаешь больше — переходи на старший план.


P.S. Конечно все сложнее и надо учитывать еще и контекст/нюансы: например если задать слишком высокие цены на старшие планы, то это может отпугнуть ваш сегмент пользователей, которые будут думать, что продукт не из их ценовой категории. Низкая цена может быть методом конкурентной борьбы, как например Basecamp, который заявляет, что берет $99/mo без всяких дополнений и хитростей: https://basecamp.com/pricing

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

Так как у выбора может быть несколько исходов, то более полная формула выглядит вот так: U = ∑ w(P)*v(x)
Сумма произведений субъективной вероятности и субъективной ценности каждого возможного исхода у этого выбора

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

Зависимость субъективной вероятности w(P) от объективной P.

Видно, что это не прямая линия, то есть субъективная оценка отличается от объективной:

— Воспринимаемая ценность при ПОТЕРЕ всегда сильно больше чем при приобретении. Видно, что в случае негативной ценности график сразу круто идет вниз, сильное круче чем рост при росте положительной ценности. Радость от получения $100 всегда меньше чем от потери $100. Это вызывает желание избегать рисков.

— Слева график становится приплюснутым. То есть при росте объективностой ценности субъективная ценность перестает расти с такой же скоростью. Мы становимся менее чувствительными к приобритениям. Радость между событиями "получить $0" и "получить $100" сильно больше чем между "получить $1,000" и "получить $1,100" или cильно-сильно больше между "получить $10,000" и "получить $10,100".

— При потерях график тоже становится приплюснутым немного, но совсем не так сильно как с приобретениями. То есть огорчение от между событиями "потерять $0" и "потерять $100" больше чем между "потерять $1,000" и "потерять $1,100", но не сильно.

При этом важно отметить, что "x" и "v(x)" тут именно изменение ценности, то есть разница между было и стало. Мы же реагируем именно на изменение ценности, на разницу, а не на уровень абсолютного результата.

Зависимость объективной ценности x от cубъективной v(x).

Теория перспектив / Prospect theory.

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

1. Воспринимаемая ценность любой штуки, события и выбора всегда зависит от ценности самой штуки и вероятности ее получения. Мы всегда смотрим на обе эти штуки одновременно и оцениваем их вместе. Ценность получения $100 c 100% вероятностью всегда больше чем $100 с 50% вероятностью. Ценность может быть положительная (приобретения) или отрицательная (потери)

2. Наша внутренняя субъективная оценка вероятности события (как мы считаем внутри) отличается от "объективной" вероятности.

3. Наша внутренняя субъективная оценка ценности события отличается от "объективной" ценности.

Получается вот такая формула: U = w(P) * v(x)
То есть ожидаемая ценность это произведение субъективной вероятности и субъективной ценности.
— U — ожидаемая ценность
— P — объективная вероятность, w(P) — субъективная вероятность. Это зависимость / функция перевода объективного значения в субъективное.
— x — объективная ценность, v(P) — субъективная ценность

Особый интерес представляют как раз эти функции перевода объективных значений ценности и вероятности в субъективные.

Они выглядят вот так.

Контринтуитивная штука про видео-звонки с ноутбука: надо смотреть не на собеседника, а на камеру.

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

Начал читать книгу Superforecasting с мыслью "вот сейчас мне расскажут про разные техники прогнозирования". На самом деле про конкретные техники не рассказали, вся книга про образ мыслей, который помогает оценивать будущее. Авторы убедительно рассказывают, что этому образу мыслей можно научить и это, основываясь на данных экспериментов, улучшает качество прогнозов. Можно считать неплохим дополнением книги Black Box Thinking / Принцип "черного ящика".

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

Сама книга переведена на русский. А тут есть отличные и подробные заметки по ней. (английский)

Понравился пост "Недипломированный менеджер": http://www.womanfrommars.com/woman-from-mars/недипломированный-менеджер/

> 5. Самые частые мои управленческие ошибки.
> Путать экстраверсию с социальной адаптивностью. Это прямо моя ахиллесова пята. Я не первый раз нанимаю бурных, энергичных, талантливых, общительных, снова и снова ожидая в них найти гибкость, и снова и снова ее там не нахожу.
> Подозревать за всеми нераскрытые амбиции и пытаться их раскрыть. Я сужу по себе и так и не могу поверить, что кому-то хорошо не в позиции главного.
> Недооценивать роль «души компании». И насколько важного человека можно из него создав, дать ему возможность профессиионального роста, несмотря на отсутствие амбиций.
> Но вот что я научилась делать эффективно, так это обнаруживать отсутствие гибкости, не путать это с отсутствием компетенций, не биться головой в стену, и расставаться.

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

Подробнее про систему от ее авторов можно почитать вот тут https://www.adaptiveinsights.com/sites/default/files/assets/adaptive-insights-A-Better-Way-to-Forecast.pdf (английский).

Например как-то так

Интересный подход к расчету вероятностей и оценке: Subjective Probability Interval Estimates (сокращенно SPIES).

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

Подход SPIES улучшает оценки и судя по экспериментам весьма неплохо. Работает так:
— Сначала разбиваем весь спектр возможных значений на сегменты
— Оцениваем каждый сегмент отдельно
— Исходя из общей таблицы выводим общую оценку.

Такой подход заставляет оценить и учесть каждый исход отдельно.

Например мы прикидываем срок выполнения проекта. Мы точно знаем, что срок больше 0 недель и точно меньше 6 недель (точнее вероятность что выполнение затянется больше чем на 6 месяцев так низко, что им можно пренебречь) Составляем сегменты и прописываем каждому сегменту вероятность:

— 0-1 недель: 3%
— 1-2: 10%
— 2-3: 50%
— 3-4: 30%
— 4-5: 5%
— 5-6: 2%

Получается, что с вероятностью в 90% (доверительный интервал) проект займет от 1 до 4 недель. И с вероятностью в 80% — 2-4 недели.

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

Я уже писал про проблему "сложные интерфейсы — начинающие пользователи".

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

Возвращаясь к книге по переговорам, хочу отметить вот что.

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

Думаю надо детектить три штуки:
— Если ты говоришь сильно больше собеседника — это проблема.
— Если тебе в ответ зеркалят твои слова или задают вопросы вида "Как же я могу это себе позволить?" — тебе на самом деле говорят "нет". Более того, на тебя перекладывают решение проблемы, которую на самом деле решать должен собеcедник. (приятно чувствовать контроль и силу решить чью-то проблему, но здесь ты решаешь чужую проблему за свой счет — ловушка)
— Надо помнить всегда свою цель, держать ее Если чувствуешь, что в течении разговора цель меняется (и ты теперь согласен на что-то другое) — возможно что-то идет не так.

Прочитал "Never Split the Difference: Negotiating As If Your Life Depended On It": https://www.amazon.com/Never-Split-Difference-Negotiating-Depended-ebook/dp/B014DUR7L2

Есть перевод на русский "Никаких компромиссов. Беспроигрышные переговоры с экстремально высокими ставками": https://www.litres.ru/kris-voss/peregovory-bez-kompromissov-vedi-peregovory-tak-slovno-ot-nih-zavisit-tvoya-zhizn/ (но за перевод не ручаюсь, так как читал на английском, судя по быстрому взгляду обороты переводили весьма тяжеловесно — делайте на это поправку)

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

Рекомендации его сводятся вот к какому списку (выжимка из книги):

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

— Хорошо работает зеркалирование: просто повторяешь последние 2-3 слова собеседника. Вызывает эмпатию и люди раскрываются. Это возможность сказать "нет", не говоря прямо "нет". Пример: "Вы должны сделать эту штуку" — "Извините, сделать эту штуку?". После зеркаливания — сделать паузу.

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

— Не надо пушать собеседника на ответ "Да". Вместо "Да", что часто означает "Да-да, отстаньте уже", надо добиваться "Все верно / Все так и есть" (that's right). Другой подход: префразировать одни и те же вопросы, чтобы получить ответ "Да" несколько раз (три раза).

— А еще лучше работает вызывать ответ "Нет". Когда собеседник говорит "нет", он чувствует, что контролирует ситуацию и находится в безопасности. Пример вопроса для почты, если вас игнорят: "Have you given up on this project?". "Нет" можно добиться задав глупый вопрос или специально неправильно залейблить их ситуацию.

— Компромиссы это плохо, надо их избегать. Это часто плохая сделка для обеих сторон.

— Фразы "это будет честно / справедливо" и "это нечестно / несправедливо" очень сильные. Могут сильно помочь, так и навредить. Если применяют их к вам, не поддавайтеcь, спросите разъяснений ("почему вы думаете, что это честно/нечестно").

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

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

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

— Хорошо работает слушать и слушать много. Кто слушает, тот получает информацию. Слушающий контролирует разговор.

— Надо задавать открытые вопросы и избегать закрытых (на которые можно ответить да/нет или просто дать число). Хорошие открытые вопросы начинаются с "Что..?" и "Как.. ?" Вопрос вида "Как же я должен сделать это?"

— Открытые вопросы "Как же я могу себе это позволить?", "Как я смогу это сделать?", "Как же я должен сделать это?" (How can I do that?”, "How am I supposed to do that?") это возможность сказать "нет", не говоря прямо "нет".

— "Почему..?" — надо избегать, так как звучит обвиняющие. Исключение: вопросы, которые побудят собеседника защищать что-то, выгодное нам. "Почему вы вообще можете решить работать с нами?".

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

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

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

— Хорошо работает использовать и называть свое имя: начинают видеть в тебе живого человека.

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

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

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

— Люди больше готовы соглашаться с теми, кто на них похож (культурно или как-то еще). Ищите общие штуки.

— Система Аккермана для того, чтобы торговаться. Установить заранее цель (конечную цену, которую вы готовы заплатить). Предложить сначала 65%, потом 85%, 95% и наконец 100%. Последнее число должно быть не круглое. Опционально в конце можно дать еще что-то нематериальное. Все это создает ощущение, что вас полностью "выжали".

— Другой подход к торговле: просто стоять на своем и не сдвигаться. На возражения и контр-предложения отвечать "Спасибо, предложение очень щедрое. Я так хотел бы согласиться. Мне так жаль, но я не могу себе позволить эту цену".

— К переговорам нужно готовиться: описать цель (best case), что мы знаем о ситуации (что хочет собеседник,почему, зачем мы здесь и так далее). Определить открытые вопросы и лейблы. Какие вопросы нужны, чтобы понять как влияет команда за собеседником на сделку ("Как это повлияет на остальных участников вашей команды?", "Что ваши коллеги считают своей главной задачей в этой области?"). Определить, что может cорвать сделку (Всегда есть, кто против. Надо фокусироваться на возможных потерях собеседника и задавать вопросы вида "Что произойдет, если вы ничего не сделаете?", "Как сделка повлияет на текущее положение вещей?", "В чем ваш самый большой челлендж?"). Определить нематериальные штуки, которые мы можем дать.

В рамках антимонопольного кейса против Microsoft в 2000 году часть внутренних документов стала доступна публике. Один из этих документов — вот этот постмортем разработки первой версии MS Word для Windows: http://antitrust.slated.org/www.iowaconsumercase.org/011607/8000/PX08875.pdf

У MS уже был Word для Mac и они решили сделать версию для Windows. Разработка первой версии заняла 5 лет (c 1984 до 1989) и проект был признан провальным. Пост-мортем посвящен размышлениям, что же пошло не так.

Сам документ достаточно тяжело читать (плохой скан) и я его рекомендую только тем, кто действительно любит почитать чужие пост-мортемы. Выделить же хочу несколько цитат:

> This would have worked out quite well had it not been for the excessive demands of the then
Director of Applications Development, Jeff Harbors. Jeff continually hounded Ford for better schedules and more results. He treated the development schedule as a contract between the deve1opment team and himself and he really let us know when we did not live up to our end of the bargin. To make the situation worse, he questioned every estimate made on the schedule, resulting in a tighter schedule that could not be meet.

...

> During a development team meeting in early March Jeff made perhaps his biggest mistake when he got up and told us that the Opus team was the worst team in Applications Development. This, combined with the long project duration, the continual pressure of being behind schedule, and the upsets in leadership, contributed to destroy the team's spirit. This lack of spirit or team synergy is evident right up through the time when we finally did ship. The team became apathetic and burnt out.

...

> The methods of scheduling used were fatally flawed. A schedule should be considered a tool used to predict a ship date, it should not be considered a contract by development. Because there was so much pressure to meet the schedule, development got into a mode which Chris Mason refers to as "infinite defects". Developers get credit every time they can check a feature off, so they are more inclined to mark off their current feature and go on even though it really is not done. There was a prevailing attitude of the "testers will find it" when thinking about potential bugs in code being developed. In many cases they did find it, and that is what caused our stabilization phase to grow from the expected 3 months (which is a pretty random number anyway), to 13 months. Because every task was cut to the bare minimum, performance work that should have been done was neglected until the very end of the project, reducing what we could do in a reasonable amount of time.

...

> The idea that a schedule is God leads to infinite defects, as explained above. Also, the belief that a schedule must be ambitious so that the development team will work hard is severely misguided.


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

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

Но две вещи я думаю уже стоит обозначить.
— Срок/дедлайн должен быть про "выпустить продукт/фичу", а не про "сделать фичу". Выпустить = сделать доступным для пользователей.
— Должен быть какой-то противовес, который будет задавать планку качества. Если такого противовеса нет,будет сильный крен в "быстро сделать, чтобы хоть как-то успеть".