Начальник-самодур эффективнее, чем менеджер, практикующий KPI

1. Закон Гудхарта: «Когда метрика превращается в цель, она перестает быть хорошей метрикой». Люди начинают оптимизироваться конкретно под эту метрику, пренебрегая другими, не менее полезными, делами.

2. Поставим менеджерам по продажам KPI по количеству сделок — они перестанут дожимать сложных клиентов с потенциально большими объемами. Поставим KPI по объему продаж — они начнут гонятся за сомнительными толстыми журавлями в небесах, игнорируя мелких синиц, готовых свалиться им в руки. Поставим руководителю компании KPI по прибыли — он перестанет вкладывать деньги в рост, а бизнес через некоторое загнется на фоне ускоряющихся конкурентов. Поставим цель по росту выручки – никогда отлупа на карман не получим.

3. Парадоксальное наблюдение. Какая самая эффективная метрика? Это метрика, не имеющая объективной связи с показателями бизнеса.

4. Пример? Пожалуйста. Есть такое понятие — «эффективный рынок». Он основан, в том числе, на бирже как инструменте регулирования рынка. Что является главным биржевым показателем? Стоимость акций. Насколько объективна связь стоимость акций к показателям бизнеса? Объективная связь отсутствует. Вчера WeWork был любимцем рынка, а на следующее утро — с теми же самыми показателями, заметьте — уже изгой, которого надо срочно спасать. Один стартап оценивается в десять годовых выручек, а другой — с теми же показателями по выручке и убыткам — в одну прибыль. Почему? Инвесторы одного надеются на быстрый рост, а другого — нет. А на чем основаны надежды или их отсутствие? На чисто субъективных мнениях.

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

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

#kpi
очень долго и часто спорил с коллегами-менеджерами на тему, почему не работает "kpi на разработку", а оказывается это Закон Гудхарта

Локализация приложений: как мы подружили перевод и разработку
https://habr.com/ru/company/badoo/blog/485138/

Кстати, котаны, у Defront-то днюха!
Если кто не в курсе, то это мегакрутой канал про фронтенд с кратким изложением свежих пейперов + авторским мнением по сабжу. Так что, вперед подписываться!

Ровно год назад появился Defront. Канал начался с простой идеи — начать читать минимум одну статью каждый день и делать небольшой tldr, чтобы в будущем быстро находить нужные статьи. Но несколько недель спустя стало понятно, что канал несёт пользу не только мне, но и сотням разработчиков, а сейчас уже почти трём тысячам.

Хочу поблагодарить за помощь в развитии канала:
Сергея Рубанова (@juliarderity — очень крутой канал про web-стандарты и новинки web'а от участника TC39)
Олега Ковалёва (@oleg_log — самый лучший канал про бэкенд и go)

И, конечно, передаю привет всем дружественным каналам и сообществам (если кого-то забыл, пишите в лс):
@we_use_js @cyberhermitage
@sysadmin_tools @overtimehate
@odinraznepitonist @ithueti
@UkropsDigest @evodevclub
@lord_alfred @ch_11
@schopenhauer_was_right
@testerinlife @ufostation
@javascript_ru @css_ru
@forwebdev @winterview

Спасибо всем за помощь и поддержку! Следующий год будет ещё лучше.

P.S. Если считаете нужным, можете сделать подарок каналу и рассказать про Defront своим друзьям, коллегам и подписчикам.

https://twitter.com/myshov/status/1222444224571899905

#k8s
Во-первых, котаны и котанессы, в блоге Фланта очередное пополнение: обзор Calico. Обзор годный, рекомендую. В начале достаточно годное введение в CNI и плагины, потом сабж с ссылками
Во-вторых, из обзора узнал, что оказывается в Azure AKS можно(теперь) CNI плагины приделывать!

#postgres #db
Оказывается в вики постгреса собраны не только лучшие практики, но и антипатерны. А вот тут сделали тулзу для проверки вашей базенки на предмет этих косяков

Тут такое дело: оказывается у grep'а в этом году юбилей! Старичку аж 45 стукнуло! И вот интересные размышления о том как делать софт, который сможет оставаться юзабельным и через 50 лет

Впихивание и вынимание

Есть два способа управлять временем команды — через впихивание и через вынимание.

Самый распространённый способ в наших широтах — первый: просто берём все дела, которые нужно сделать, и впихиваем в людей, которые могли бы их сделать. Если плохо впихивается — трамбуем: главное получить обещание, а человек потом сам что-нибудь придумает.

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

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

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

#db
Интересный подкаст про CDC и Debesium в частности

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

#sre
Открыл для себя https://www.learningfromincidents.io/ Это каталог материалов и бест-практисов по работе с инцидентами. Очень много крутых материалов и будет еще больше(судя по coming soon-разделам)

Тут вот интересное мнение по поводу Alpine: https://pythonspeed.com/articles/alpine-docker-python/ говорят, что для питона его не надо использовать, т.к. образы получаются больше и дольше собираются.
Не буду это комментировать, но мы всегда юзаем alpine, т.к. альтернатив особо и не видим

#gc #dotnet #go #java
Котики, с работой в последнее время завал, так что не особо получается отыскивать ништяки, но обещаю исправиться. А пока вот вам 3 нетленки про работу GC: раз, два, три.
З.Ы. в первой автор почему-то сильно бомбит от Go, но если блейм пролистать, то статья очень крутая

https://habr.com/ru/post/487058/
#hadoop #zookeper

Видосы с ZooKeeper митапа в фейсбуке. Много про тюнинг, конфигурацию и рецепты из разных крупных компаний(Facebook, Twitter, Cloudera и т.д.)

#patterns
Наткнулся тут на очень интересную мысль о том, что вместо валидаторов надо писать парсеры.
Т.е
void ValidateJson(string s) throws BadJsonError //🤮

User ParseUserFromJson(string s) throws BadJsonError //👌

Причина в том, что при парсинге система типов окажет вам неоценимую помощь, а так же, такой подход сохранит вас от антипаттерна Shotgun parsing.
За подробностями велкам в статью(осторожно, примеры на Хаскеле, но подход актуален и для систем с более слабой системой типов)

#algorithm #scala
Узнал про интересный алгоритм под названием Happy eyeballs.
Представьте, что DNS вернул вам на резолв-запрос ответ состоящий из N IP-адресов, при этом некоторые из них могут быть нерабочими, а некоторые очень долго отвечать. Наша задача, с одной стороны, найти рабочий узел с приемлемым временем отклика, а с другой, не рассылать кучу запросов по всем возможным узлам(ибо дорого).
Что интересно, реализация этого алгоритма является своего рода лакмусовой бумажкой для concurrency фреймворков, и по ссылке можно найти реализацию на scala ZIO и нескольких питонячьих фреймворках. Надеюсь челендж продолжится и можно будет увидеть реализации, например, на гошных горутинах

чет я прям очень ору https://youtu.be/9wvEwPLcLcA

Обнаружил, что мой доклад «Программирование на уровне типов на TypeScript: выжимаем из компилятора все соки» с эпамовского ITSubbotnik еще в начале декабря выложили на YouTube. Если вдруг кто-то хотел послушать, но не получилось быть на митапе вживую, то теперь есть возможность наверстать упущенное 🙂
Ну и напомню, что слайды и примеры доступны в репозитории на Гитхабе: https://github.com/YBogomolov/talk-typelevel-ts