Как обычно, по желании обсудить, действует чятик https://t.me/joinchat/B-bfYQrvBssyBCf4D2YjhQ

​​Компания itrex.ru опубликовала на русском языке широко разошедшуюся картинку о разрыве между тем, чего на самом деле хотят сотрудники, и тем, чего их начальники думают, что они хотят. Да, посмотрите на нее внизу. Там зарплата на 5 месте по оценке сотрудников, а на первом признание и на втором роль в делах компании. Просто рай нематериальной мотивации.

Картинка построена на очень известном исследовании 1946 года Foreman Facts from The Labor Relations Institute of NY и несколько противоречит результатам StackOverflow Survey 2018, где
на 1м месте - зарплата
на 2м месте - используемые технологии
а вопрос признания можно условно подразумевать в офисной культуре, которая только на 4м месте.

И кому верить? Во-первых, достаточно неожиданно увидеть такую организационную бирюзовость аж в 1946м году, где не просто поколение X, а прямо таки XXX. Особенно на контрасте с практичностью 2018 года (где у нас generation Z и бирюзовость должна бы прямо цвести). Во-вторых, вопрос очень важен для практического применения.

​​К счастью, западный мир довольно серьезно вкладывается в исследование подобных вопросов, поэтому нашлось много публикаций, из которых особый интерес представляет анализ серии подобных опросов за разные годы (http://s-space.snu.ac.kr/bitstream/10371/1819/1/sjbv12n1_019.pdf)

В нем мы видим, что опрос 1946 года отличается от последующих. Скажем, в 80е на 1м месте была интересная работа, а в 90е места распределились так:
1) зарплата
2) признание
3) надежность (что не сократят)
4) карьерные возможности
5) интересная работа

Таким образом, мы можем уверенно предполагать, что
А) результаты опросов будут зависеть от места и времени, поэтому если такая информация нужна, то надо делать опрос у себя, а не полагаться на чужие картинки. Чужие картинки это только повод задуматься

и менее уверенно предполагать, что
Б) зарплата и признание - оба важны

Обсудить и поспорить можно в чате https://t.me/joinchat/B-bfYQrvBssyBCf4D2YjhQ

Попалась статья про среднее время восстановления после отвлечения на свежее письмо. Компания отмониторила активность 15 своих сотрудников и установила, что
-  70% писем открывались за 6 секунд от появления уведомления
-  после прерывания на письмо работа восстанавливалась в среднем через 64 секунды (но в зависимости от характера работы - до 260 секунд); Это именно потеря уже после обработки и собственно письма (прочтения и ответа)

В этом контексте, переход от проверки почты каждые 5 минут на каждые 30 минут может сохранить полтора часа в день на схлапывании всех восстановлений в одно.

У меня лично попап-уведомления по заветам дорофеева отключены и я просто рефлекторно проверяю почту достаточно регулярно, но в удобные мне моменты времени.

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

https://jamesclear.com/wp-content/uploads/2015/02/email-multitasking-study.pdf

​​В ленте пролетело отличное исследование о влиянии опенспейса на коммуникации. Сейчас индустрия на перегибе - с одной стороны openspace это все ещё считается «модно и современно», а с другой многим оно не нравится и голоса против опенспейса ширятся. Но это мнение, а тут суровые данные.

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

Получилось внезапно, что длительность общения лицом к лицу сократилось на 72%, а объём отправляемой почты вырос на 56%. Во другой компании длительность живого общения упала на 67%, а объём почты вырос где-то между 22 и 50% (две разные модели подсчёта).

http://rstb.royalsocietypublishing.org/content/373/1753/20170239

Обсудить и поспорить можно в чате https://t.me/joinchat/B-bfYQrvBssyBCf4D2YjhQ

​​Сижу на AWS re:Invent, масштабной конференции от Amazon. Пишу прямо из «горящего танка» - с 3х часовой keynote сессии, на которой 33 тысячи человек сидят прямо в главном зале.

В этом году Amazon вдарил по
- файловым хранилищам
- базам данных и data lakes
- инструментам центрального контроля и управления доступом к сервисам и их безопасностью
- блокчейну

Не знаю пока, как относиться к поддержке амазоном блокчейна. С одной стороны - Амазон очень сильно внутри как стартап, а значит - почему бы и не попробовать. Не все сервисы Амазона взлетают одинаково хорошо. С другой стороны, это определенное признание технологии и спроса на неё для прикладных целей. С третьей, сразу за блокчейном Амазон анонсировал Quantum Ledger DataBase - надежную БД для ситуации с central authority, то есть классический инструмент, обратный блокчейну.

Интересными темами кажутся подключение живых людей «как сервис» в machine learning для улучшения качества (SageMaker Ground Truth), создания открытой биржи алгоритмов, обучение с подкреплением (SageMaker RI)

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

Под конец выкатились довольно интересные сервисы типа
- Textract, распознавание текста с учетом столбцов, таблиц и сложно скомпонованных анкет-форм
- Personalize, готовый рекомендатель товаров на основе амазоновского внутреннего решения. Нетепловой самому разбираться с ML
- Forecast, готовый предсказатель спроса, тоже на основе амазоновского внутреннего решения

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

В целом этот год выглядит не таким волшебным, как 2016, где AWS запустила пачку ИИ сервисов, легендарный «камаз с компакт-дисками» и Lightsail (“DigitalOcean” от AWS) и дала возможность делать SQL запросы прямо к файлам в S3.

И не таким, как в 2017, где Amazon подписался за Kubernetes, дал Fargate и дал Machine Learning сервисы.

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

Обсудить и прокомментировать можно в чате https://t.me/joinchat/B-bfYQrvBssyBCf4D2YjhQ

Тут справедливо отмечают, что я незаслуженно обошел внимание AWS Outpost, с его возможностью сделать Amazon прямо в своем  датацентре. Поставится амазоновское железо и будут доступны все амазоновские сервисы.

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

У кого такие гибридные облака? Исключая тех, кто по какой-то причине просто еще не до конца переехал, такая нужда есть из-за
1) требований по быстрому доступу (latency)
2) требований закона. Не только в России, но и в Германии, и в Канаде, есть требования по сохранению определенных данных на територии страны, а в ряде иностранных организаций мне говорили, что они не имеют права хранить данные пользователей вне своих ДЦ

Пока никаких деталей нет, у меня возникла сумасшедшая идея об открытии амазоновских "франшиз" в локациях, где амазоноский ДЦ нет - например в России. Какой-нибудь хостер мог бы развернуть амазоноские стойки у себя и стать "русским Амазоном", а вернее "Амазоном в России".

Основатель гештальт терапии, Фриц Перлз, сказал:  
Человек не в состоянии вынести истины, когда ему ее  сообщают. Истину можно вынести только тогда, когда ты открыл ее сам, потому что только гордость открытия позволяет принять ее горечь.

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

Цитата Фрица Перлза, к счастью, дает не только проблему, что убедить нельзя, но и решение. Решение в том, чтобы
1) дать человеку информацию в усваиваемой форме (чтобы она не была отторгнута мгновенно)
2) заронить сомнение и ждать пока вызреет
3) поддерживать зреющее мнение дополнительной информацией

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

По ссылке Виталий Король объясняет как это применять для борьбы с нездоровыми иллюзиями в организации https://www.youtube.com/watch?v=BebqPispwB8&t=2254s

​​Самые популярные слова в чатике при канале получились вот такие

Сам чатик по ссылке https://t.me/joinchat/B-bfYQrvBssyBCf4D2YjhQ

Продолжая начатую в ФБ мини-серию интересных бизнес-практик, обратил внимание на Леруа Мерлен

Рассмотрим задачу. Дано:
Сеть магазинов, где цена считается настолько низкой, что скидок не предлагается. Это фишка и лозунг.

Надо: внедрить систему слежения за покупательной активностью каждого, что традиционно достигается скидочными картами (а нельзя!)

Как? Изящное решение:
Выдаётся сервисная карта покупателя, по которой можно вернуть ранее купленное без чека.
Купить лишнего для ремонта или какая-то запчасть не подошла - да сплошь и рядом! То есть пользовательская боль найдена и решена, покупатель счастлив.
Затраты? Только на саму систему учета покупок, ради которой все делалось. Выручка сохраняется, принципы и ценности не нарушены.

В чем изящество? ТЕория решения изобретательских задач (ТРИЗ) постулирует, что

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

Таким образом, система учета покупок, которая сама собой стимулирует покупателя пользоваться ею - это «идеальный конечный результат» в терминах ТРИЗ. Моё почтение за наглядную демонстрацию

При решении всех своих задач я стараюсь использовать этот принцип ТРИЗ и не городить сложных и трудных в обслуживании огородов.

Хотя ТРИЗ по определению нельзя применять механически к иным областям, кроме собственно изобретения материальных систем, некоторые её принципы настолько универсальны, что соблазн очень велик. Если кто-то не читал про ТРИЗ, то очень рекомендую и почитать, и упражнения поделать.

Декабрь астрологи объявили месяцем токсичности. Количество публикаций про токсичность утроилось. Интернет был взбудоражен двумя встречнонаправленными публикациями
1. "Я порчу разрабам жизни своими код ревью и больше так не хочу" (https://habr.com/post/432822/?fbclid=IwAR1FKOeXp_ftA7onHZbLly_Qk0R9iDYnNawTfaWVF9mf8MuqNW2UuhGh9dI)
2. "Иди-ка ты на !@# со своей «токсичностью»" (https://m.habr.com/post/432700/)
Были еще сколько-то ответов на эти публикации, но они были слишком конструктивны, градус наброса был невелик и сравнимого внимания они не привлекли (а жаль!)

"Токсичность" здесь рассматривалась в узком контексте злобной критики. Одна сторона соответственно была за "хватит!" и другая за "вы нам рты затыкаете, а ведь мы за дело болеем!".

Поверх наложилось очередное упоминание исследования гуглового исследования о том, что лучшие результаты были в командах, где каждый может открыто высказываться (https://www.facebook.com/helena.sazonova/posts/10211246305587305), которое обе стороны в принципе могли бы воспринимать за аргумент в свою пользу и были бы в каком-то смысле правы.

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

Общий же разумный знаменатель легко найти, если вспомнить, что критика работает не в момент, когда высказана, а в момент, когда услышана;

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

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

Американцы или немцы в среднем высказываться будут в разы аккуратнее, но одновременно легче выслушают замечания по существу. Это позволяет общаться куда более эффективно. Условные диалоги:
(Русский) Твой код говно! - (Русский возмущенно) Сам ты говно!
(Русский) Твой код говно! - (Американец удивленно) А что в нем плохо получилось?

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

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

Довольно подробно о том, как доносить свою критику максимально прямо, но чтобы вас выслушали и поняли, рассказывает популярная книга "Radical Candor" ("Радикальная прямота").

Вобщем, следите за собой, немного усилий и будете услышаны :)

Cпираль смерти от рутины

Как обычно не принимается решение поделать какой-то рефакторинг, оптимизацию или автоматизацию? “У нас эта проблема случается раз в квартал, автоматизация решения займет пару дней, окупится это вложение не скоро, так что ну его нафиг”. Казалось бы логично и рационально, НО…

Что происходит, когда мы откладываем это решение? При условии, что проблему нельзя просто игнорировать, то в этот момент мы автоматически снижаем годовую capacity команды на общую стоимость обхода этой проблемы за год =
<среднее число срабатываний проблемы в год> x <стоимость решения>

Поскольку такие проблемы будут продолжать регулярно поступать, то со временем команда будет 100% своего времени тратить на обход проблем и … 0% времени на развитие.

Ой.

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

Само понятие технического долга в оборот ввел Говард Каннигхем в 1992. Тот самый, который в 1994м придумал wiki. Каннигхем вводил это понятие для “быстрых и грязных решений” (аналог взять в долг), НО нюанс в том, что любые технические решения окажутся “грязными” по мере изменения обстановки. Любой самый продуманный дизайн рано или поздно окажется не адекватен задаче и превратится в проблему сам по себе. Проблема гораздо шире “грязного и быстрого кода”. Более того, тщательно продуманный и аккуратно написанный легаси продукт поддержен ей куда более, чем быстро слепленный MVP. Время превращает почти всю массу кода в один сплошной долг.

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

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

PS
Почему “спираль смерти”? В английском death spiral часто применяется к катастрофической ситуации с финансами компании, когда займы в попытке получить средства для жизни компании обваливают ее стоимость на рынке (и она теряет средства). Фактически подразумевался авиационный “штопор”. На русском термин скалькировали и применили к эффекту зацикливания муравьев в круг, когда они ходят толпой по кругу, пока не умрут (death mill = смертельное кружение). Роднит все эти явления то, что возникает неправильная обратная связь - ответом на неправильную ситуацию становится ее еще большее ухудшение.

Чем больше рутины, ты меньше времени на улучшения. Тем скорее коллапс.

Ваш К.О.

Поднялся вопрос какой должна быть идеальная продуктовая аналитика "как сервис". С моей точки зрения
1) надежной. данные из разных срезов/источников должны друг другу соответствовать. хуже нет ситуаций, когда "почему здесь 2000, а тут уже только 1000. Где скрывается половина?"
2) краткой. верхний уровень метрик должен быть небольшим. 100 показателей для системы это почти тоже самое, что ноль показателей - все равно, ничего не понятно без длительного погружения.
3) углубляемой. при необходимости должно быть легко разложить любой показатель по дополнительным характеристикам. что это у нас за пик? это повышенный приток из того и этого каналов
4) самообслуживаемой. люди, принимающие продуктовые решения должны мочь смотреть основные метрики сами, сужать критерии, углубляться в срезы и тп - без привлечения аналитиков для таких типовых задач
5) проактивной. если случилось отклонение, то сразу же надо раскопать где, и почему, что повлияло. Все вопросы возникнут, как только бизнес увидит ситуацию

Можно обсудить у кого какие фейлы с аналитикой случались в https://t.me/joinchat/B-bfYQrvBssyBCf4D2YjhQ

Уже более 10 лет индустрия топит за простоту как опору usability и user experience. Вы все видели карикатуру, что правильный продукт состоит из одной кнопки "счастье", а неправильный - из много кнопок. Я ее чуть ниже приведу.

В целом это правильный курс, но достаточно часто его понимают и применяют совершенно неверно и я тоже был вынужден через это пройти. Разберем не столь давний дизайнерский пример о стиральной машине с одной кнопкой "стирать". Очень красиво и удобно выглядит. Но как именно она будет стирать? Если вы не в армии, где вся одежда одинаковая - то явно сталкивались, что нужно одним образом стирать шерсть, другим всякие спортивные мембранные одежды, очень многие вещи сейчас требуют стирки на 30 градусах, но одновременно что-то надо стирать и на 40, и на 60, и даже на 90 (если есть маленькие дети). Как эта волшебная машинка это узнает? Концепт такого ответа не дает

Нюанс в том, что сложно не сделать одну кнопку в интерфейсе (это как раз очень легко), сложно сделать, что вся машинерия верно работала по нажатию этой одной кнопки. Не всякая отрасль к этому готова. Если вы помните гугл 15-20 лет назад, то там еще в ходу были советы как пользоваться advanced search language, который уточнял гуглу что именно и как он должен искать. Я таких советов уже давно не видел - гугл довольно неплохо научился сам понимать контекст, что именно вы хотите найти по этим словам. Именно этим поисковое подразделение гугла занималось эти самые последние 15-20 лет. Именно это позволяет избавиться от лишних "кнопок"

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

Да что там авиация - в автомобилях до появления синхронизаторов переключение передач требовало большой кучи движений. Посмотрите внимательно старые фильмы или почитайте старые инструкции. Или пример поновее - карбюраторные советские авто кто-то водил? Нажмите три раза педаль газа, вытяните подсос и тп. А сейчас? кнопка "Push to start" и все дальнейшие операции рассчитаны компьютером.

О чем это все говорит? Однокнопочный интерфейс это не столько проблема дизайна, сколько проблема подлежащей технологии. Однокнопочный интерфейс это не достижение дизайна, это достижение подлежащей технологии.

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