Май 2017: уроки разговоров с полицией, история серийного поджигателя, микроморты смерти и 44 закона разработки

Две интересные статьи для продакт-менеджеров:

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

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

Кто-то может сказать, что это специфика американской системы. А вот видео (две части) из России, где чувак (русский националист) рассказывает про то же самое:

(Около часа, немного затянуто и качество записи не всегда отличное, но интересно. Еще забавно, что чувака все таки посадили)

Что я про это все думаю.

  1. Даже если вы не нарушаете закон, всегда есть небольшая вероятность, что вас посадят: ретвит, который кого-то оскорбил, оказались рядом с митингом, просто ошибка системы. Шанс невелик, зато последствия велики: процент оправдательных приговоров в судах у нас очень мал.
  2. Лучше всего работают тупые простые правила. Чем тупее и проще - тем лучше. Не забудешь, когда стрессовая ситуация.

Поэтому простое правило вида “если спрашивает полиция — говорить как можно меньше, а лучше вообще не говорить” звучит очень разумно.

Потрясающая история про главного серийного поджигателя в истории США: https://www.facebook.com/kalashnikov.mikhail/posts/1597529786925242

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

Очень перекликается с размышлениями о KPI, про которые я писал в прошлом месяце.

Последние несколько недель выдались очень суматошными и напряженными. Поэтому в этом месяце я писал мало

¯\ _(ツ)_/¯

В следующем месяце будет больше!

Интересная единица измерения: “Микроморт”: https://ru.wikipedia.org/wiki/Микроморт

Измеряет риск действия и равна одной миллионной вероятности смерти (вероятность = 0.000001, то есть 0.0001%)

Чтобы понять концепцию – воспринимайте это как, например, облучение. Если единомоментно получил 1M микромортов - умрешь сразу и точно. Если получил 500k — выживешь в 50% случаев.

Также они накапливаются, но неочевидным способом. Если я получил сегодня 500k микромортов (рисковал жизнью c шансами 50 на 50), то если я это сделаю завтра — шансы будут те же (они не суммируются 500k + 500k в 1M, который точно гарантирует смерть). Но они увеличивают общий шанс умереть раньше при накапливании.

Например в примере выше если я два дня подряд рискую с 50% вероятностью (получаю каждый день 500k), то мой шанс умереть за ОБА дня: 75%, то есть общее кол-во микромортов за оба дня 750k. (математика тут в том, что процент не умереть за оба дня это 0.5*0.5 = 0.25) За 10 дней таких экспериментов - 99.9% или 999k.

Вообщем, если вам не интересны вероятности - то понимать надо так: микроморты накапливаются, но не очевидным образом.

Как же это можно применить? Например сравнивать микроморты событий.

Например каждый день в среднем мы получаем 39 микромортов - то есть 1.6 в час.

Остальные штуки увеличивают базовое значение.

“44 engineering management lessons”: http://www.defmacro.org/2014/10/03/engman.html (хорошая подборка)

Конечно она больше для тех, кто управляет инженерами. Но там есть штуки, которые интересны будут всем. Например:

Authority isn’t bestowed freely. It’s earned by making good decisions over time. Don’t make decisions unless you have to. Whenever possible, allow the team to explore ideas and make decisions on its own. Do make decisions when it’s necessary. Few things are as demoralizing as a stalled team.

If you feel something’s wrong, you’re probably right. Don’t let anyone bully you into ignoring your feelings.
If you find yourself blaming someone, you’re probably wrong. Nobody wakes up and tries to do a bad job. 95% of the time you can resolve your feelings by just talking to people.
Your team looks to you for leadership. Have the courage to say what everyone knows to be true but isn’t saying.
Most intellectual arguments have strong emotional undercurrents. You’ll be dramatically more efficient once you learn to figure out what those are.

Don’t judge too quickly; you’re right less often than you think. Even if you’re sure you’re right in any given case, wait until everyone’s opinion is heard.

People will push and prod to discover your boundaries. Knowing when to stand back and when to stand firm is half the battle.
Occasionally someone will push too far. When they do, you have to show a rough edge or you’ll lose authority with your team.
A firm “I’m not ok with that” is usually enough.
Don’t laugh things off if you don’t feel like laughing them off. Have the courage to show your true emotions.
If you have to firmly say “I’m not ok with that” too many times to the same person, it’s your job to fire them.
Unless you’re a sociopath, firing people is so hard you’ll invent excuses not to do it. If you’re consistently wondering if someone’s a good fit for too long, have the courage to do what you know is right.

Серия постов “Four Laws Of Software Economics”, про разработку разных штук.

1. Ваша команда разработки никогда не будет достаточно большой, чтобы сделать все, что вы хотите. Поэтому надо беспощадно приоритезировать: http://www.mironov.com/4laws1/

2. Деньги появляются тогда, когда вы начинаете продавать копии одного и того же. Сделал раз — продал много раз. Когда продаешь уникальный софт, то есть кастомная разработка, то это плохо (если вы не аутсорсер, конечно): http://www.mironov.com/4law2/

3. Продукт должен рассказывать историю и решать проблемы. Фичи не важны сами по себе: http://www.mironov.com/4laws3/

4. Только вы можете понять куда надо двигаться. Никто не может вам сказать это за вас: http://www.mironov.com/4laws4/

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

Я кстати думаю у многих продакт-менеджеров иногда наступает озарение, внутреннее понимание правильных вещей систематизируется и они решают написать “а вот как оно на самом деле”.

Когда такое озарение случилось у меня, я написал этот пост: “Советы самому себе про product management”