惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

S
Schneier on Security
有赞技术团队
有赞技术团队
T
The Blog of Author Tim Ferriss
F
Fortinet All Blogs
D
DataBreaches.Net
F
Full Disclosure
腾讯CDC
博客园 - 【当耐特】
MyScale Blog
MyScale Blog
Stack Overflow Blog
Stack Overflow Blog
小众软件
小众软件
Hugging Face - Blog
Hugging Face - Blog
Last Week in AI
Last Week in AI
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
爱范儿
爱范儿
The GitHub Blog
The GitHub Blog
Engineering at Meta
Engineering at Meta
大猫的无限游戏
大猫的无限游戏
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
S
SegmentFault 最新的问题
The Register - Security
The Register - Security
WordPress大学
WordPress大学
博客园 - 聂微东
雷峰网
雷峰网
J
Java Code Geeks
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
P
Privacy International News Feed
酷 壳 – CoolShell
酷 壳 – CoolShell
A
Arctic Wolf
Scott Helme
Scott Helme
C
Cyber Attacks, Cyber Crime and Cyber Security
T
Tor Project blog
博客园 - 三生石上(FineUI控件)
Know Your Adversary
Know Your Adversary
AWS News Blog
AWS News Blog
G
Google Developers Blog
www.infosecurity-magazine.com
www.infosecurity-magazine.com
C
CERT Recently Published Vulnerability Notes
O
OpenAI News
Project Zero
Project Zero
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
Application and Cybersecurity Blog
Application and Cybersecurity Blog
云风的 BLOG
云风的 BLOG
N
News and Events Feed by Topic
MongoDB | Blog
MongoDB | Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Microsoft Security Blog
Microsoft Security Blog
Cisco Talos Blog
Cisco Talos Blog
P
Palo Alto Networks Blog
Schneier on Security
Schneier on Security

Comments for zhengziying.com

从个人主页到微博 六问 Monitoring and QA are the Same Thing? (Part 3) 听说阿里内网不删帖 听说阿里内网不删帖 谁推翻了“罗伊诉韦德案” 听说阿里内网不删帖 我在交大 BBS 删帖的日子 美国不是一个法治国家 我家的一次制度设计尝试 Monitoring and QA are the Same Thing? (Part 3) 六问
我家的一次制度设计尝试
2022-04-27 · via Comments for zhengziying.com

最近发生了一些令人气愤的事情,大家都说问题的根源在于制度设计的不合理。改革开放的总设计师邓小平曾经说过,“制度好可以使坏人无法任意横行,制度不好可以使好人无法充分做好事,甚至会走向反面”。但是,制度设计是很难的。我们家最近就有一个例子。

如何监督减肥

事情的起因是朱苹果要减肥,立flag说每天晚上六点以后不吃东西,并且邀请哥哥和妹妹监督。于是我们就开始讨论如何监督,如何设计奖惩制度。我提议说,每次妈妈违反规定、六点以后吃东西了,就奖励哥哥和妹妹各打一盘游戏。哥哥和妹妹都赞成这个提议,朱苹果也觉得OK。但后来我们觉得这个制度有问题:会不会哥哥和妹妹为了能打游戏,反而引诱妈妈违反规定呢?

要不我们就反过来,改成“如果妈妈不违反规定,就奖励哥哥和妹妹各打一盘游戏”。这样哥哥和妹妹就会努力的阻止妈妈违反规定了。但转念又一想:减肥、六点以后不吃东西,是妈妈的努力,凭什么哥哥和妹妹就可以平白无故的得到奖励呢?我们还讨论了几个版本,包括如何把爸爸加进来作为一个制衡的角色、不是按单次而是以每星期为周期进行奖励,等等。但每个版本都有一些问题,都不太好。最后的结果是:没有监督、没有奖惩制度,还是靠朱苹果的自觉。

制度不好会走向反面

在上面这个例子里,我们对第一个提议的担心是有道理的:的确有可能出现哥哥和妹妹为了能打游戏,反而引诱或者放任妈妈违反规定。历史上曾经发生过这样的事情,比如1902年法国殖民政府在越南搞的灭鼠运动。每消灭一只老鼠,只要上交一条老鼠尾巴作为证明,就能获得政府奖励。结果出现了专门养殖老鼠的养殖厂,专门用来割老鼠尾巴。类似的例子还有英国殖民政府在印度搞的消灭眼镜蛇运动。

维基百科上的“perverse incentive”条目还列举了另外二十几个这样的例子,都是奖惩制度没设计好,导致了反面结果。

成功案例

奖惩制度设计在公司环境里的一个成功例子是阿里B2B的提成制度。常见的销售奖励制度是当月的提成比例取决于当月的销售额,销售额越高,提成比例越高。阿里B2B的奖励制度是:销售员当月的业绩决定其下个月的提成。我第一次看到这个制度的时候觉得惊为天人,此后每次细品仍然回味无穷。

制度设计在社会层面的一个成功例子是美国的宪法。我以前觉得美国宪法的产生是碰运气的,就好像很多人来猜N个股票的涨跌,其中总有几个“股神”是能猜对所有股票的涨跌的。类似的,很多国家尝试各种可能性,总有一两个国家撞大运撞上了一个能work的可能性。

我是后来看了 Miracle at Philadelphia 和 The Federalist Papers 这两本书改变了认知。Miracle at Philadelphia 在讲费城会议之前先介绍了一些历史背景。美国的宪法是迭代出来的。Articles of Confederation是第一版,不到十年就出了各种问题,所以到了1787年,先贤们觉得有必要迭代一下。那次迭代的产物就是今天的美国宪法。 

The Federalist Papers 更是一本神书,它的中文名字是《联邦党人文集》。如果我要去坐三个月的游轮,只能带一本书,我会带它。看过《联邦党人文集》以后就明白了,美国宪法能存活那么久,成为当今世界上第二最古老的宪法(仅次于圣马力诺),不是偶然的。从《联邦党人文集》可以看出,这些Founding Fathers对从伯里克利时代开始的两千多年的成功和失败的经验有很渊博的知识,对各种政治制度和人性有很深的洞察。他们制定美国宪法,不是拍脑袋的。

说到神书,《纳粹德国的腐败和反腐》也是一本神书。这本书的中文版是译林出版社在2015年出版的。神就神在这本书的中文版居然还在卖。

这本书的核心思想可以概括为一句话:因为纳粹德国的官员是自上而下任命的,所以各级官员只对上负责,所以腐败是必然的、反腐是没用的。

我觉得这个道理放到公司环境也同样适用。公司里的各种问题,比如“KPI导向”、各种短视行为、部门间壁垒、如何避免“创新者的窘境”、等等,究其根源,也是因为公司里的各级职务都是自上而下任命的(而不是投票或者自下而上推举的)。虽然一些“360环评”、”peer feedback” 等做法可以在某种程度上缓解一下,但无法改变问题的根本。

简单之美

据说阿里B2B的“当月的业绩决定下个月的提成”奖励制度是李琪设计的。卫哲曾经在接受采访的时候说,“如果你问我李琪对阿里巴巴整个销售体系最大的贡献,就是一些简单易行的制度”。

简单的制度往往比复杂的制度更容易执行、更少负作用、更long lasting。对于当前制度中的问题,常见的做法是打补丁,遇到一个问题打一个补丁,增加一些条件、覆盖更多的corner case。但常常是越打补丁漏洞越多。比如在我们家的例子里,把爸爸加进来作为一个制衡的角色、不是按单次而是以每星期为周期进行奖励,这些都是在打补丁。但效果都不好,补丁都不完美,而且补丁本身又会引起新的问题,又需要打更多的补丁。

我们写程序、设计软件架构,其实也有类似的情况。所以,我是非常信奉“optimize for simplicity”的。在公司里,我不喜欢在各种流程里搞很多“细则”、把制度搞得很复杂。做事情还是要凭良心做,就好像在我们家的例子,我们最终没有搞任何监督奖惩制度,还是靠朱苹果的自觉。

“I know it when I see it”

我不喜欢别人问我各种“细则”的问题。

比如以前我们有个规定,要求每个发布都是可回滚的。我觉得“可回滚”这三个字就足够了。但就是有人要问,到底什么算可回滚?是一定要有回滚脚本的才算可回滚,还是有一个文档写了回滚步骤的也算?如果要求必须能”一键回滚“才可以算可回滚,那么什么是“一键”?按两下按钮算不算一键?打三个命令算不算“一键”?另外,对回滚时长有要求吗?我这个系统可以回滚的,只不过回滚比较复杂,每次回滚都需要三四十分钟,这算不算“可回滚”?

对于这些对回滚的细则问题,我心里其实一概不想回答。说到底,这些细则是定义不完的。与其不断的细化规则,还不如就搞简单一点。具体到每一个case,到底是违反了还是没有违反,其实大家的认知不会差太远。我说,下次出了故障,是不是“可回滚”没做到,I know it when I see it。

“I know it when I see it” 这句话是一位美国最高法院大法官Potter Stewart说的。1964年,在审理一桩关于言论自由和色情电影的案件时候,他说了这么一段话:

I shall not today attempt further to define the kinds of material I understand to be embraced within that shorthand description [“hard-core pornography”], and perhaps I could never succeed in intelligibly doing so. But I know it when I see it, and the motion picture involved in this case is not that.

这些对细则的问题背后的根源还是奖惩制度设计。因为我们的奖惩制度对于违反“可回滚”要求导致的故障是严惩的,绩效会被打最低一档,会被取消当年晋升提名资格。但对于符合安全生产运维要求但由于其他原因导致的故障,比如设计和需求没有沟通清楚、写代码的人就是写出bug来了而且测试用例也漏掉了、或者测试用例没有自动化,这样的故障是不会那么严惩的。

于是,大家最关心的不是不要出故障,而是不要因为违反运维流程要求而出故障。

另一方面,从管理者角度说,管理者要抵抗住自己内心的本能,也要抵抗住来自他人的压力,避免试图通过细化规则来解决理解和执行中的偏差。有几次我拒绝细化规则,我只提供一些具体案例,别人再问我就说“I know it when I see it”,这时就有人给我扣帽子,说我不是“法治”,是“人治”。这样的帽子,我每次都是拿下来扔地上的。

越往上,管理者越要避免细化规则。这倒不是因为要给自己留下诠释空间。说一些正确的废话、空洞无物的口号,是可以给领导留下将来解释的空间,正过来反过来都可以解释,这的确是一种“术”。但主要还是因为大脑离四肢的距离远了。我们常常拿蒋介石来当反面典型,他动不动直接指挥师长怎么打仗,效果肯定是不好的。我是非常推崇“去中心化”(decentralized)的决策和执行的,因为大脑离四肢末端太远了,一方面对四肢末端的情况感知不够敏感不够细,一方面从四肢末端到大脑的反馈弧太长,做出决策后对效果的观察太滞后。

诺贝尔经济学奖

公司环境下的奖惩制度设计,我觉得最难的就是如何回溯。

很多人都经历过类似的例子:有个人,到了一个团队,短期内拿到了很好的结果,但是这个过程中,要么是欠了很多债,要么是把团队burn out了。但这个人拿到结果、拿到奖金和晋升以后就move on了,要么去了其他部门,要么去了其他公司。欠的这些债、团队因为burn-out产生的流失,等到他走了以后才产生越来越严重的后果。但这时候人已经走了、级别已经升了、奖金也发了。

级别、奖金、股票,给出去了就都很难收回来。在蚂蚁的时候,我曾经听到过有讨论说级别要可升可降。不知道后来讨论的怎么样了,有没有真的这么做。反正降级的事情是非常少的,我工作二十年了,见过的降级加起来一只手就能数的过来。至于奖金和股票,连那些搞出全球经济危机的华尔街高管的薪水和奖金都拿不回来,更别说是大部分普通的公司人了。而且对大部分公司人来说,用短期行为换来自己的加薪、奖金和股票,这样做的经济收益远远大于通过自己的贡献把公司搞好、把公司股价搞上去的收益。

我希望将来有一天,会有人是因为对奖惩制度的回溯能力的研究和贡献而获得了诺贝尔经济学奖。