Про японское “да”

В учебнике японского языка отмечено, что японское «да» («хай») отражает не столько согласие с вашими словами, сколько то, что собеседник вас слышит и признает ваше право на высказанное мнение

Но и в русском языке есть «японское да» и с ним надо быть осторожным. Вот вы увлечённый человек и что-то пытаетесь донести собеседнику, а он кивает и поддакивает. Вы выходите с убеждением, что собеседник вас понимает, поддерживает и мысль оценил положительно. А потом - сюрприз! - он делает что-то прямо поперёк.

Где с этим можно столкнуться?

Наивный продакт менеджер рассказывает идею клиенту, а тот поддакивает. «Клиентам наша фича нравится!» делается вывод, а они не покупают потом.

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

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

Что можно сделать?

Самое простое упражнение на проверку понимания и взаимопонимания - это когда говорит второй собеседник.

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

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

У Sales есть в частности практика уточнять KPI покупателя в организации, чтобы понимать, что предлагаемое решение действительно выгодно для покупателя. Если нет выгоды, то нет и реального интереса. bizdev это почти как sales в этом смысле.

Вобщем, переспрашивайте.

Оказывается, существуют исследования о эффективности переработок, которые в разное время проводили такие титаны индустрии как Proctor&Gamble, Bureau of Labour Statistics of the U.S. Army Department o

Оказывается, существуют исследования о эффективности переработок, которые в разное время проводили такие титаны индустрии как Proctor&Gamble, Bureau of Labour Statistics of the U.S. Army Department of Labor, American Association of Cost Engineers, Construction Industry Institute, The National Electrical Contractors Association. Несмотря на всю заинтересованность в выжимке соков из трудящихся, исследования показали падение эффективности работы по мере превышения стандартной 40-часовой рабочей недели.
Хотя абсолютные показатели существенно отличаются между исследованиями, а в некоторых даже были примеры, когда удлиненная неделя не приводила к падению производительности, но в большинстве случаев видно, что уже даже 50 часовая неделя существенно снижает отдачу (92% и ниже). Наиболее интересны графики, построенные на основе данных Proctor&Gamble (на картинке), где оценивается не просто падение производительности, а комплексный вклад от <все потраченные часы> * <производительность> c поправкой на длящийся эффект (сколько недель уже продолжается overtime). Здесь мы видим, что уже на 6й неделе труда по 50 часов отдача от дополнительных часов полностью исчезает и дальше уже начинается сплошной вред (то есть дополнительный час не только не дает прибавки, но и наносит вред). Там, к сожалению, не рассмотрен вопрос восстановления до 100% эффективности после отмены сверхурочной работы. По моему личному опыту, 12 недель работы по 80 часов приводят к последующим 6 неделям эффективности чуть выше нуля. В смысле, что на почту человек отвечает и простые фиксы делать может.
По этой причине я не поощряю сверхурочную работу у нас.
https://revay.com/revayreports/en/vol20no3.php

На неделе громко прогремела новость про утечку исходников Аэрофлотовских сервисов по небрежности (просто доступ не закрыли) - https://habr.com/post/424625/

Это породило довольно много тредов со стебом всего, что можно - от Аэрофлота в частности, до докера и девопса вообще. Я тем временем поучаствовал в немного более полезном практическом треде, где народ каялся в собственных подобных косяках. Реальность такова, что сколько бы "матерые админы" не стебали "любителей докера", а уязвимости есть у всех, и даже у Cisco.

Компании делятся не на "с уязвимостями" и "без", а на тех, кто узнает про свои уязвимости вперед новостей и тех, кто после.

Есть практика, которая помогает быть первым - это наладить работу с внешними "белыми хакерами". Это могут быть как выделенные пен-тестеры, так и "bug bounty". Bug Bounty это когда вы готовы платить за сообщения о своих уязвимостях. Есть довольно много народу, кто этим промышляет.

Чтобы bug bounty заработал, надо
1) завести у себя людей, которые им будут заниматься
2) объявить если не условия (мы публично условия не объявляли), то хотя бы канал, куда можно с этим обращаться - например [email protected]
3) научиться пользоваться стандартной CVSS шкалой уязвимости и прикинуть сколько вы готовы платить за взломы разного уровня
4) научиться платить людям (для россиян с нашими бухгалтерскими заморочками это вообще настолько не тривиально - что по честному наверное даже невозможно)

Сейчас мы получаем несколько подобных репортов в неделю и потому не становимся героями новостей

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

Поговорить про уязвимости можно тут https://yangx.top/joinchat/B-bfYQrvBssyBCf4D2YjhQ

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

К примеру, в США банковские карты распространены давно, но бесконтактная оплата из-за этого распространена меньше, чем у нас - много старых терминалов, которые этого еще не умеют.

Или вот свежий пример, упорядоченный по убыванию прогрессивности и возрастанию времени игры одновременно:
- в Китае рынок мобильных платежей вырос в 15 раз за 2 года (!) и достиг 15 млрд долларов
- в России при этом население в основном пользуется переводами с карты на карту и терминалами оплаты (qiwi наше национаольное достояние)
- в Германии основной инструмент это банковские переводы (direct debit)
- а в США до сих пор в ходу бумажные чеки

Кто позже всех начал, тот дальше всех ушел.

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

Хотел бы поделиться одной довольно хорошо работающей у нас практикой.

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

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

Теперь польза:
1) участники выделяют и формулируют главное в услышанном. это очень важный этап в усвоении объемной информации, но мало кто достаточно дисциплинирован чтобы делать это самостоятельно
2) участники обсуждают свои оценки полезности доклада. это вскрывает разность взглядов, создает поле для дискуссии и расширения кругозора
3) не-участники видят какие доклады были наиболее полезны и чем, и могут выбрать какие доклады стоит посмотреть, как только появятся записи (а записи докладов выкладывать сейчас общепринято)
4) отдельное выделение "что хотелось бы применить" позволяет возвращаться к итогам конференции позже и оценивать, а не свалились ли мы в пассивное слушание, когда все всё понимают, но никто ничего не делает

поспорить за пользу/бесполезность конференций можно тут https://yangx.top/joinchat/B-bfYQrvBssyBCf4D2YjhQ

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

Такие интервью интересны возможностью как-то "сверить часы" с общим трендом. Из интересных мыслей:
1) поощряйте "соревнование" между продукт менеджером и дизайнером. каждый должен пытаться сделать лучше, бросая некоторый вызов второй стороне.

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

2) в дизайне нет места догмам. все правила работают в каких-то ситуацих, и вредны в каких-то других

Думаю, это не только в дизайне так.

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

У нас в ходу с легкой руки одного менеджера вопрос "Чтобы ЧТО?". Сам факт, что прозвучал такой вопрос, это сигнал проснуться и вернуться в реальность

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

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

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

Горский приводит примеры Амазона и Букинга, которые метрически заоптимизированы до упора, но выглядят ужасно. Но работают и генерируют гору денег. Но выглядят ужасно. Трудный выбор

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

https://www.youtube.com/watch?v=kZz8dJwmH48&index=4&list=WL&t=0s

И как обычно - если кто-то хочет высказаться за Горского, то в чатике https://yangx.top/joinchat/B-bfYQrvBssyBCf4D2YjhQ

Хорошая статья про разработку CLI интерфейсов.

UX в UI уделяется очень много внимания, но в силу специфики нашего продукта (техническая вещь для инженеров) в какой-то момент мы даже ставили лозунгом, что CLI (и API) также важен, как UI. Не могу похвастаться, что мы достигли небывалых высот, но мы стараемся.

https://medium.com/@jdxcode/12-factor-cli-apps-dd3c227a0e46

​​Закрытие Google+ иллюстрирует подход к решению ситуаций типа «нести тяжело, а бросить жалко».

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

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

В итоге пришли к соломонову решению под названием «план эвакуации при пожаре». Решили ничего не предотвращать, не улучшать и даже не чинить, а просто стричь купоны до часа Х. Пока не бомбанет. Как только бомбанет, должны были распечатать заготовленный «ПЛАН ЭВАКУАЦИИ». Где заранее расписано, что делать по шагам. Но восстановления в этих шагах нет, есть отправка пользователей в новую систему.

Планом, правда, в чистом виде воспользоваться не пришлось. Не бомбануло, но в итоге всё-таки приняли «политическое» решение о сворачивании сервиса.

Как обычно, по желании обсудить, действует чятик https://yangx.top/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) интересная работа

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

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