我家的一次制度设计尝试

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

如何监督减肥

事情的起因是朱苹果要减肥,立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产生的流失,等到他走了以后才产生越来越严重的后果。但这时候人已经走了、级别已经升了、奖金也发了。

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

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

2021/22雪季小结

周一从Whistler回来,这个雪季就算差不多了。之前我已经有三年多没怎么滑雪了。2018年3月回国工作后,平时在杭州,就去了一次Whistler、一次新西兰和一次奥地利St Anton。朱苹果还带着娃去过一次北大壶和一次日本,我工作太忙都没去。

去年搬回西雅图了,可能是对前几年的报复性反弹,这个雪季滑的比较多。一个雪季加起来滑了二十几次,应该是有史以来最多的。虽然说起来从2010/11雪季开始滑雪,到现在也好多年了,但之前都滑的不多:生一个娃耽搁两三年,再生一个娃再耽搁两三年。今年是平生第一次买season pass,由此可见。Season pass的确很方便,尤其是今年滑雪的人好像特别多,到后来要买票都买不到了。

夜场

今年滑的这二十几次里,有至少一半是夜场。Snoqualmie这点很值得点赞,夜场开放的天数很多,开放区域足够大,而且开到晚上10点。我家基本上就是平时工作日等哥哥和妹妹放学回家,五点多钟我们出门去雪场,路上在I-90的exit 15或者exit 31买个Burger King当晚饭。从家里到雪场很快,只要40分钟。每次去一般可以滑两三个小时,回到家九点多,也不耽搁睡觉和第二天上学。

夜场的好处,总结下来就是一句话:人少。基本上每次都可以把车停在最近的位置,下了车就可以直接上缆车的那样的近。不用扛着板走好远好远的路,实在是轻松了很多。人少,缆车也都不排队。夜场每次滑两三个小时也够了。像我家妹妹今年刚开始滑雪,滑一天她也滑不动,两三个小时差不多了。

夜场的缺憾就是有些道不开。在Snoqualmie,Alpental 上边 的Chair 2是不开夜场的,Summit East也是不开夜场的。所以今年就完全没去过Alpental,和哥哥一起滑一下 Upper International 的愿望就只能等明年了。不过Snoqualmie开夜场的区域也足够多了:Silver Fir的蓝道和黑道、Central Express的蓝道、还有Triple 60和Parachute。明年打算还是继续这样,以平时工作日去滑夜场为主。

收获

今年最大的收获是学会了snowboard。

很多年前我曾经尝试过一次,那时我们家哥哥还很小。那是我们第一次去Whistler,我在Blackcomb下面的魔毯区域自己练snowboard,练了一个多小时,摔到感觉屁股已经裂开,遂放弃。自那以后就心里留下了阴影,我一直觉得我这辈子都不会再尝试snowboard了。好好滑好ski就好了,滑好ski了也就哪里都能去了,不要再折腾自己去学snowboard了。

今年哥哥先开始学snowboard。他大概是ski这几年滑下来感觉不太有挑战了,想尝试一些新东西。那天是12月31日,他又跟我说想学snowboard。我看他是认真的,就直接冲到店里给他买了全套的板、binding和鞋。回来还被朱苹果说了,说Facebook marketplace上买个二手的就好了,不要每次都买新的出手那么大。不过哥哥还算争气,后来滑的挺好的。

哥哥中间也放弃过。之前有一次在Silver Fir Express,从Outback下来,滑了两趟他放弃了,说要回车上换ski。那天我带他去换了,因为我很能理解那种摔到信心全无的感觉。不过哥哥过几天又继续练了,就觉得Outback没啥难的了。今年哥哥把单板学会了,我和朱苹果看着挺高兴的,平时都羡慕别家娃是自推娃,现在我家的娃终于也有一些东西会自己推自己了。

哥哥开始学snowboard了就鼓动我也学。我因为多年前的心理阴影,一直不太想学,还跟他扯了很多bulls**t的逻辑。后来被哥哥说了太多次了,心一横就豁出去了。俗话说:要鸡娃,先鸡自己。感谢鹿叔叔和鹿阿姨借给我的板和鞋子。第一次去,滑了两趟魔毯,就跟着哥哥去了绿道。第二次是夜场,我自己去练了一个晚上绿道,感谢喝水哥从缆车上帮我拍的video。第三次,在绿道热了下身,就去了Pacific Crest,号称是条蓝道,但我们都觉得Snoqualmie的道有点水,Pacific Crest如果放在Whistler估计会标成绿道的。

我觉得我学的还挺快的。我认为这就像游泳:会自由泳的人学蛙泳,或者会蛙泳的人学自由泳,是要比第一次学游泳的人要学的快的。Snowboard和ski也是一样的道理。今年我半路出家学的snowboard,很多时候要带妹妹滑也没法练,到雪季结束的时候也能turn下不太难的蓝道了。鹿叔叔和鹿阿姨一直是滑snowboard的,他们今年开始学ski,也学的很快。

能把学snowboard给坚持下来了,要给我自己点赞。后来我遇到各种事情就都拿这个来lecture哥哥:你看,你爸四十三岁了,还不怕摔,把snowboard给学会了。

这个雪季的收获挺多的。除了我和哥哥都学会了snowboard,其他还有:

  • 朱苹果膝盖手术成功。本来十月份动手术的时候担心今年雪季要报销了。后来恢复的挺好,滑的也越滑越好了。
  • 我们家妹妹学会ski了。今年从魔毯pizza开始滑,后来顺利的下了Snoqualmie的 Hogwild。这次去Whistler她下了Dave Murray和Raven。暂时不打算带她去更难的道(比如 Whistler Bowl)。来日方长,现在先把动作练练好。
  • 我学会了ski的倒滑和switch(即360度转圈)。带妹妹滑雪一开始都在绿道和简单的蓝道上,闲的没事我就跟在边上自己练倒滑、练转圈。

教训

那天我能从Golden Nuggets上面滑snowboard滑下来了,我知道我已经不会再像上次那样放弃了,于是就买了块自己的snowboard。

其实学snowboard的一个动机就是可以买新的板 :) 。可以花很多时间研究板,研究各种牌子,看各种视频。后来看上的是Jones的Mountain Twin。那时候雪季已经过半了,整个西雅图地区已经没有这块板了。二月中旬 mid winter break的时候去Whistler,在一家店里看到有,而且还有10%打折,就毫不犹豫的买下来了。

Binding我买了Union最便宜的那款。结果前几天搭扣掉下来了,因为一颗螺丝松掉了。我看了看,那个螺丝的确是很简陋,连垫圈都没有,那三震两震肯定松掉啊。我想明年是不是要去换个好点的binding,至少不能在山上给我掉链子吧。这个事情又一次印证了“buy cheap, buy twice”的道理。

今年雪季的另一个教训就是考 ski instructor 失败了。去了才发现自己准备的太不充分了。别人都是上过不止一次 clinic 的,还有人是已经当过实习教员了。就我,啥都不知道,啥都没针对性的练过。考试失败的原因一个是技术不过关,比如转的时候内板有提起来的动作。如果去上过 clinic 可能就能纠正了。另一个原因是理论知识掌握的不够,比如,考官问step turn有啥用,我就懵了。

视频器材

今年拍了很多滑雪的视频。一个是为了多记录记录。现在回过去看,哥哥那些年滑雪的视频太少了,想拼凑一个他的学习历程都不太容易拼凑出来。拍视频另一个就是为了给自己看。有反馈才有改进,没有教练指导、没有高手指点,就要拍了视频自己回家琢磨。我还想过要不要买套Carv来帮助自己改进,但一直没下手。明年可以去搞一套。

今年为了拍视频,先后入了三套设备:

  • GoPro 10和Falcon的稳定器
  • DJI OM5稳定器(配iPhone手机)
  • Insta360 ONE X2加自拍杆

后来用的最多的是Insta360。全景拍摄实在太方便了,可以无脑跟拍,只要拿在手里跟着滑就可以了,不用操心震动,不用操心要对准被拍对象。后期可以重新选角度、重新构图,非常方便。唯一的不足就是分辨率不够,5.7K的视频重新构图以后导出就只有1080P了。

GoPro也不错。配上Falcon的稳定器,体积够小。GoPro本身有自动水平功能,很好的满足了我对水平的执着。GoPro 10能拍4K 120P的,视频画质实在比Insta360好了很多。就是GoPro+稳定器的组合对拍摄者的要求有一丢丢高,要一直把GoPro对准被拍者,还要注意俯仰角度。我是先入的GoPro,但哥哥拒绝拿GoPro帮我拍,他嫌重。所以我才又入了Insta360。现在他很愿意拿着Insta360跟着滑。但GoPro我打算还是留着,以后去rafting、潜水啥的都可以用。

DJI OM5不work。一开始买DJI OM5的原因是看中了它的自动跟踪功能(active track),这样就不需要像GoPro那样需要拍摄者注意对准被拍摄对象。但用DJI OM5拍了以后发现一个很蛋疼的问题:OM5的stablization和iPhone本身的光学防抖(optical image stabilization)功能冲突了,导致的结果是拍出来的视频jitter的很厉害(jitter这个词不知道中文怎么翻),素材基本没法用。网上查了查,大家都遇到了这个问题,而且貌似无解:iPhone的光学防抖功能没法关掉。有一个帖子建议用 iPhone的 0.5x超广角镜头,说超广角镜头是没有光学防抖功能的。我试了试,一样还是有很严重的jitter。自那以后这只DJI OM5就躺在抽屉里了。改天去二手卖了它。

滑雪的意义

今年二月份去Whistler的时候和哥哥一起去滑了 Whistler Bowl。这是我们第一次滑Whistler Bowl。早在回国之前就想去了,但每次要么是山顶缆车因为风大关了,要么就是哥哥觉得有点犯怵怂了。于是就一直处于一个心心念的念想状态。二月份的那次去滑了,下第一个turn前做了一下心理建设,但开始下了也就蹭蹭蹭的下来了。滑过了,一直没迈过去的那个坎儿迈过去了,心里也就放下了。

这次在Whistler滑的时候路过了很多以前做过心理建设的地方,回忆起最初几年来Whistler的情景。那时候即便是Blackcomb那条easiest way down的盘山绿道都把我们滑得累趴。后来滑Cruiser等蓝道,每滑一个坡就觉得腿酸,要休息一下。当时看到身边有些厉害的人直接风驰电掣般从上面下来,扬起一阵雪,绝尘而去,那时候就想,我以后能有这样的水平就好了。现在我们自己也是这么滑的了。

滑雪就是这样一种不断的自我实现。曾经需要心理建设的坡,现在已经马不停蹄的直接下去了。曾经自己羡慕的高手的样子,现在自己也是那个样子了。但又有新的坡需要心理建设,又有滑的更好的人的样子成为自己的目标。有时候会有plateau,觉得进步很慢,但继续滑,总会变得比原来的自己更好。

虽然有时候也会有些气馁,觉得自己也许永远也无法达到小红书上那些视频里的水准。这时候就再想想自己滑雪的初心,提醒自己不要因为走得太远而忘记为什么出发。

当初之所以开始滑雪,就是觉得如果不会滑雪,冬天有很多很赞的地方没法去enjoy。当初之所以想要滑得更好,就是觉得如果水平高了就可以去山上人更少雪更好的地方,就不用和很多新手挤在一起排好长好长的队坐缆车了,就可以更轻松的背着更重的摄影器材滑,就能拍出更好看的照片了。

现在滑雪,也是给以后留点事情做做。Whistler有好多白头发白胡子的滑雪教练。以前还在杂志上看到东部有个九十几岁的ski patrol。现在练滑雪,以后说不定也可以像他们那样。有事情做,还有那么漂亮的风景,还挺好的。

明年

小二的计划是滑遍所有开过冬奥会的雪场。我没有什么太具体的计划,就是有一些想去滑一滑的雪场:

  • 去Cypress滑个夜场,从雪道上看温哥华的夜景。“Breath-taking”这个词已经被用烂了。我觉得那个景是真正配得上“breath-taking”这个词的。Cypress就在北温,也是每次去Whistler的必经之路。照理说这个愿望要实现并不难,但就是阴差阳错每次都没实现。希望明年可以去一次,有Snoqualmie的season pass可以免费在Cypress滑三天。
  • Big Sky也是可以用Snoqualmie的season pass免费滑三天的。去年开车去黄石的时候路过过Big Sky,就在从Bozeman到黄石的路上。去Big Sky滑雪的话也可以顺便去一下黄石,拍拍冬天黄石的景色,拍拍雪地里的野牛。雪地里的野牛和大眼睛的女孩是常见的国家地理型糖水片。
  • 美西北有几个不错的雪场还没去过:Mountain Bachelor,Mountain Baker 和 Mountain Hood。
  • 犹他州和科罗拉多州那些雪场都没去过,像Vail、Breckenridge等。我对大的雪场有偏爱。Whistler就很大,道巨长。每次滑完Whistler回来再去Snoqualmie就觉得道怎么那么短,下了缆车才转几个turn就到底了的感觉。犹他和科罗拉多那几个雪场好像也很大,想去滑一下。我就喜欢那种山顶有饭店、半山腰也有饭店的雪场。
  • 三山谷是欧洲我最想去的雪场。大,非常大,非常非常大。那里有高大上的高高雪维尔。去三山谷的话还可以顺便去一下Chamonix。

  • 采尔马特好像也不错。尤其是上次看到小红书上有人发了个视频,在采尔马特一路从瑞士滑到意大利。种草了。
  • 日本。虽然那边的雪场好像都不大,但总也是去要见识一下二世谷的粉雪的。还有藏王的树冰。

这个list估计可以干上好多年了。

有时候计划外的也有惊喜。2017年圣诞节期间去的西班牙,中间有一站在Granada,发现边上的Sierra Nevada 雪场挺近的,就临时起意去了一天。到现在哥哥还一直记得Sierra Nevada。那天在Whistler的7th Heaven上面他就说这里到tree line上面就光秃秃的一大片,很像Sierra Nevada。

每个家庭都有一些shared memory。我们家的很多shared memory都是和滑雪有关的。

那天在Sierra Nevada顶上的风好大好大的,几乎吹的人都在坡上停住不会往下滑了。后来每次在雪场山上遇到刮大风,他都会跟我说“比起那次在Sierra Nevada,还是那次的风大”。

//the end

中国社会的功效主义倾向

曾经有人问我,中美两国有什么文化差异。我的回答是:中国社会有强烈的功效主义(utilitarianism)。不仅仅是当代。中国社会的功效主义倾向,古已有之。古人说,“书中自有颜如玉,书中自有黄金屋,书中车马多簇簇”。这话很清楚了:为什么要读书?因为读了书就有美女、有钱、有香车宝马。

古人还说,笑贫不笑娼。这是一种典型的功效主义:the end justifies the mean。“结果即正义”在当代的著名例子就是“不管是黑猫还是白猫,抓到耗子就是好猫”。辩证法说,事物有两面。这句话,在当时那个时代环境下,当然是对的、是非常有意义的。不过,不幸的是,这句话以及这句话后来带来的效果,虽然帮助中国社会摆脱了贫困,却进一步加强了中国社会的功效主义倾向。

中国社会的功效主义的另一个典型体现是拜佛。中国人到庙里拜菩萨,很多都带着目的:求子、求功名、求姻缘。有一说一,中国的文化里也有一些不那么功效主义的东西的。比如,有时候我们会说“但行善事,莫问前程”,会说“善有善报、恶有恶报”,也会说“桃李不言,下自成蹊”。但总的来说,中国社会是明显的倾向于功效主义的。

功效主义在公司环境里的体现就是“为过程鼓掌,为结果买单”。“结果导向”(result oriented)本身是天经地义的,因为公司是生意。拿人钱财,替人消灾。你不能拿了工资忙忙碌碌的就是不出活。但是,把“结果导向”叠加到一个本身就已经有强烈的功效主义的环境里,导致的结果就是更加为达目的不择手段。结果大于过程,只要老板给下来的目标达成了,具体执行有些瑕疵是可以接受的。

功效主义可能导致“the tyranny of the majority”。因为人数多寡是功效的直接体现。在“电车困境”里,功效主义的选择是牺牲一个人来拯救一车人,因为让更多的人活下来是功效更高的。

拆迁中的冲突,根源之一也是功效主义。拆迁的道义基础是为了多数人的福祉牺牲少数人。拆迁会迫使一小部分人离开从小长大、居住了几十年的街区,但这些牺牲是“值得”的,因为拆迁是为了城市改造,改造城市是为了让”更多人“有更好的生活。你一个人赖着不肯搬,你为了你一个人的利益(“一己私利”),阻碍了“大家”获得更好的生活,所以你不搬也得搬,你不搬就强制你搬。

《奇葩说》有一期的题目是“救画还是救猫”。李诞讲的最后那段话,值得品味:

很多有知识的人,他们知识多了之后,就觉得天将降大任于斯人也。他也不苦其心志,也不劳其筋骨,他就天天想着怎么牺牲别人。他每天都在想我怎么牺牲这个去救那个,怎么牺牲小的去救大的,怎么牺牲近的去救远的。历史已经告诉我们了,维系这个世界靠的是我这样自私的人,我们这样自私的活着,但我们不伤害别人,这个世界才能运转。而正是那些为了所谓宏伟事业,为了一些远大目标去不计后果牺牲别人,牺牲别的小猫的人,频频地让这个世界陷入大火。

川普的税表,谷爱凌的国籍

几天前,北京冬奥会的记者会上,有记者问谷爱凌:”Are you still a US citizen?” 谷爱凌讲了一大段话,没有回答这个问题。该记者又追问了一遍,谷爱凌的回答是:”I am just as American as I am Chinese. I am an American when I am in the US and I am Chinese when I am in China.”

我很诧异,几天过去了,没看到什么文章在批她的这个回答。这个回答怎么听怎么让人觉着有一股浓浓的味道,精明、算计和投机的味道。这个回答,照理早就该在互联网上被批的体无完肤了。

“你是美国公民吗”这个问题的性质和“你更喜欢爸爸还是更喜欢妈妈”或者“你是北京人还是上海人”的性质是不一样的。我可以说我又是北京人又是上海人,我在北京的时候就是北京人,我在上海的时候就是上海人。怎么说都行。“你是男人还是女人”也可以各种回答,可以说我又是男人又是女人,我和男人在一起的时候是女人,我和女人在一起的时候是男人。你还可以说我既不是男人又不是女人。

“你是美国公民吗”这个问题,有且只有一个答案。穷举所有逻辑上的可能性,事实必定是以下四种之一:

  1. 我现在是中国公民,不是美国公民
  2. 我现在是美国公民,不是中国公民
  3. 我现在既是美国公民,也是中国公民
  4. 我现在既不是美国公民,也不是中国公民

既然有且只有一个答案,既然这是一个简单清楚的事实,那为什么不直接回答呢?

我不想猜测她为什么要讲这些外交辞令而不是直接阐述事实。我愿意相信谷爱凌在记者会上没有正面回答这个问题是因为这个问题一句话两句话说不清楚。如果的确如此,那就出一份详细一点的声明,讲清楚。

如果有人觉得她没有正面回答这个问题是因为有什么见不得人的秘密,这种观点我是反对的。当年川普选总统,很多人要他公开税表,因为过去几十年里已经形成了一个不成文的惯例,总统候选人都会公开自己的税表。川普拒绝提供税表,很多人就质疑:what are you hiding?

我认为这个质疑是不成立的。

我们经常在美国电影电视里看到 “take the fifth”,意思就是被告行使美国宪法第五修正案赋予自己的权利,人不可被迫自证其罪。我以前也很疑惑,当一个被告说 “take the fifth”,难道不就说明觉得自己是有罪的吗?因为,如果相信自己是清白的,那就不怕自证其罪咯。但后来我渐渐明白了,一定要纠正自己的直觉,不可以觉得 “take the fifth” 就相当于是 have something to hide。

同样的道理,拒绝提供税表和拒绝回答“你是美国公民吗”也不可以被解读为 they have something to hide。

一个烹饪说明的重构

昨天烧晚饭的时候,我注意到包装盒上的烹饪说明里有个很有意思的事情:三种烹饪方法的第一步是一模一样的,都是 “If frozen, defrost in refrigerator overnight”:

同样的内容重复了三遍,这在不少程序员的眼里是很糟糕的写法。遇到这种重复的内容,而且已经满足了Rule of Three,他们一定会要把它提取出来,放到一个公共的地方。如果让他们来重构这个烹饪说明,他们会增加一个公共的 “准备工作” 模块,把 “If frozen, defrost in refrigerator overnight” 这句话放到 “准备工作” 里:

他们这么做的理由是:

  1. 这个烹饪说明显得更简洁了
  2. 这个烹饪说明更容易维护,下次如果要修改 “If frozen, defrost in refrigerator overnight”这句话,比如把它改成 “If frozen, defrost in refrigerator for 12 hours or more”,就只需要修改1个地方,而不是3个地方。

在程序员的世界里,当一个人提出不要 copy/paste 代码时,几乎是不会遇到什么反对的。但是,减少重复的代码并不是一条“第一性原理”,它并不是不言而喻、不证自明的。减少重复的代码只是一种手段,它的目的是减少问题、减少工作量。如果在多个地方重复同一段代码反而可以减少问题、减少短期和长期的工作量,那就应该让它去重复,不要去抽取出来。

重复有重复的好处。我在蚂蚁的时候,经常给周围的人转发一篇题为《Write code that is easy to delete》的文章。这篇文章有一个核心观点:增加重复可以减少依赖。减少依赖可以降低风险和减少工作量。如果我的代码在另外N个地方被引用了,下次我修改我的代码的时候就不得不加倍小心、三思而行,生怕我的改动导致别人的代码无法正常工作。

对于重复,我的观点是:如果有两个地方有同一段逻辑,或者同一段文本,我们不应该简单粗暴的直接挥舞 Don’t Repeat Yourself 的大棒。我们要问清楚:这几个地方是否必须要保持一致的?如果要,那么怎么确保它们是一致的?如果不一致了会有什么后果?我是不主张在团队里大张旗鼓的提倡 “以代码复用为荣,以copy/paste为耻“的。

“惠普之道”和Monorepo

如今听说过“惠普之道”的人,估计都是至少四十岁以上的了。我刚毕业那几年,大家都在说“惠普之道”。《惠普之道》是一本九十年代的书,英文书名叫”The HP Way“(我估计 “Aliway” 也是从 “The HP Way” 来的)。那时候惠普在大家眼里是一个成功的公司,Carly Fiorina是那时候最火的CEO,江湖地位堪比今天的Elon Musk。

二十年过去了,现在很少听到有人讲“惠普之道”了,我甚至怀疑如今刚毕业的大学生可能连惠普这个公司都没听到过。现在大家都在学谷歌,因为谷歌是一家成功的公司。其实,谷歌成功已经有很多年了,只不过出圈需要一个过程。以前谷歌还只在圈内红火的时候,大家已经在学了,大家都在说 20% time 怎么怎么好,怎么怎么培育创新。

这两年好像不太听到有人讲 20% time 了,这几年大家都在学谷歌的 OKR。满眼都是各种文章阐述 OKR 的精髓是什么、OKR 和 KPI 的本质差别是什么、为什么 OKR 比 KPI 好。甚至连有些政府部门都在搞 OKR。虽然有很多人 clarify 说我们搞 OKR 并不是跟风、并不是因为谷歌搞了 OKR 所以我们也要搞,但夜深人静的时候扪心自问,如果谷歌没有那么成功,OKR 还会有那么多人学吗。

这样的例子还有很多。二三十年前,通用电气如日中天的时候,大家都学通用电气的末位淘汰,感觉末位淘汰是保持大公司企业活力的关键。后来通用电气走下坡路了,大家就开始反思,反思末位淘汰是不是导致微软的企业文化问题的原因,一家接着一家的公司都把末位淘汰和 curve 给取消掉了。

谷歌之后最红的科技公司是 Facebook。Facebook 声名鹊起的那段时间,大家都学 Facebook 搞 Hackathon ,但这两年大家讲 Hackathon 渐渐讲的少了。真正被 Facebook 带红的是 Monorepo(大库)。或者说,Monorepo 是被谷歌和脸书两家一起带红的:谷歌和脸书都是用大库的,那肯定不是巧合吧,而且谷歌和脸书的研发效能的口碑都是顶流的,让人不得不相信大库一定在里面起到了很大的作用。

大库其实也有大库的痛苦。上周我做了一个 diff,把六十几个 Dockerfile 里面 pip install 的 “-vv” 参数给去掉了(that’s a story for another day)。这个 diff 到现在还在等 code review,因为这个 diff 动了十几个微服务的 Dockerfile,要那十几个团队的人都 code review 通过了才能 land。除非我一个个 team 一遍遍的催,否则估计这个 diff 永远没法合并了。

大家都说大库的好处是做这种大面积 horizontal 的改动比较容易。我看也不见得有多容易。看样子,到头来我可能还是会把这个大 diff 拆成十几个小 diff,每个微服务一个 diff,单独做 code review。但这样搞一堆小 diff,那和每个微服务单独一个 repo 有啥差别呢。

员工满意度调查

早上填了一个公司内部的 developer productivity 满意度调查。这种调查在我以前公司也经常搞,我相信其他公司也有。今天这个调查我基本上每一项填的都是 Very Satisfied 或者 Satisfied。其实现在每天都能遇到各种问题,各种不完善的地方。但我也没觉得不满意,因为这样那样的问题、这样那样的不完善的地方都很正常,在中美两国的各个大厂小厂都普遍存在。就算是几家整体上做的很好的公司,到具体的团队也一样有很多问题。有问题就一点点搞呗。

满意度、幸福感,很大程度上是基于期望的。我上周四买了两顶帽子一件衣服,这周一收到邮件,说我的 order 已经 shipped 了。看了看 UPS tracking,要这周五(明天)deliver。这水平比淘宝差到不知道哪里去了。不过我也没有觉得啥不满意,因为期望低呗,我反正也不急着用。而且我知道美国这些网站的尿性,所以买东西都是 plan ahead 的。

如果有个满意度调查,问我对美国 online shopping 的 shipping speed 满意不满意,我大概也还是会填 satisfied。所以满意不满意和真的做的好不好之间没有太直接的联系。满意不满意和被调查的这个人有没有见过世面也没关系。过去几年我是已经习惯了淘宝和京东的速度的。京东上买个洗衣机都能隔天就送到,美国你买个洗衣机试试看。

“研发满意度调查” 或者 “研发幸福感调查” 的结果,看看就好。如果今年的结果比去年的满意度高、幸福感高,也别太当回事儿。这个结果可以拿去给不称职的 CTO 看,可以拿去给做业务出身的总裁们看。真的拿着各个团队的 “研发满意度” 做横向排名的,非蠢即坏。其实很多老板们心里也明白这个道理,很多时候大家都只是看破不说破罢了。

满意度高不代表 developer productivity 做的好。做的好的团队和公司,满意度和 “研发幸福感” 调查的结果完全有可能比做的不好的还差。全球 happiest countries 榜上名列前矛的很多国家同时也在 depression rate 榜上名列前矛。还有个说法说不丹是世界上 happiest country,但不丹人民的生活水平可比不了那些发达国家。所以“研发幸福感”这东西,还有那些员工满意度调查,只能 take with a grain of salt。

以前在微软的时候,每年都有一个员工满意度调查,叫做 MS Poll。那里面有一部分问题是关于你对你的直属老板的满意度。之前阿里巴巴没有这个,我就跟我们的大G和BP建议说要搞一个,所以后来阿里巴巴就搞了(这个因果关系就类似于公鸡打鸣了所以太阳就出来了),叫做 “管理者快照“。这东西挺好的,让大家对自己老板的不满有地方可以输出,这个分数也让各级老板有所忌惮。

以前在微软的时候,各级主管对这个满意度调查还是满上心的。分数如果很难看,日子多少会有点儿不那么好过。每年有这个分数在,我们做主管的一年到头都要很小心,团队要好生伺候着,就怕到时候分数不好看。临近年度调查的时候还要多搞一些聚餐,拉拢拉拢感情,各种暗示。但有时候,辛辛苦苦一整年,调查前一个月来了个紧急项目加班很多,一年的努力就白费了。

怎么让 MS Poll 分数高一点,这事情困扰了我很多年。直到有一次,我当时的老板给我说了他的一个秘诀。每次临近调查的时候,他都会找他的手下做 1:1,聊的时候就会把 MS Poll 里面的那几个问题先问一遍。人嘛,当面都是不太好意思说太难听的,所以 1:1 的时候被问到了都会说”还不错“、”挺好的“。神奇的地方在于:等到过几天填正式的调查表的时候,你选择的答案会不由自主的向在 1:1 时候自己嘴巴里说过的话靠拢,会更偏向于选择”满意“、”比较满意“。

我当时听他讲完后的感觉就是:哇塞,还能有这样的骚操作啊。YYDS!

Fish and Shark

I have been through the “Fish vs Shark” dilemma a number of times before. It was like:

The team has a product/tool/service/system called “Fish”. Fish works, but has shown a lot of signs of aging. And the team/company/business/people have almost outgrown the Fish. So the team started to build the Shark.

Building Shark and helping users to migrate to Shark takes time, and takes resources from that team who owns Fish and Shark.

The team now struggles: Fish is getting worse, and the users are increasingly unhappy with Fish. Plus, knowing Shark is coming, themselves and the users are more hesitant to invest in Fish. That only makes things deteriorate even faster in Fish. Meanwhile, Shark isn’t there yet.

The dilemma is: how much time should the team spend on Fish? Double down on Shark? It’s risky. If Shark delays for some reason (including those out of the team’s control), they are dead in the water: Fish is so broken, while Shark isn’t there yet.

Should the team carve out some time to keep Fish floating? In both Chinese and English there is the phrase “a bird in the hand is worth two in the bush”. That will keep business going and buy some time for Shark, but that will probably delay Shark.

That’s really a hard decision to make. We surely can look at the data: How close is Shark? How much effort does it take to keep Fish float?

But how “floating” is enough “floating”? How long can users bear with “just floating”? How much confidence you have to get Shark ready on time? At the end of the day, it might still rely on some judgement and gut-feeling.

给老板点赞

有一次在我们项目的Slack频道里,在一件大家争议很大的事情上,我发现我的思路和我老板的思路出奇的一致。我当时犹豫了一下,要不要在我老板的那句话下面加个点赞。我犹豫下来的决定是:我没有点赞。

以前有一次,我是老板。也是一件大家意见很不一致的事情。那次,我下面有几个人就公开站我,结果他们被其他人炮轰,说他们是拍老板马屁。我也连带的被喷了,说我就是古代的昏君,让自己 surrounded by 佞臣。所以我后来明白了,为什么老板都很少发表自己的观点。

拍老板马屁,在以前古代,叫佞臣。古代的官儿们很喜欢给其他官儿扣一顶“佞臣”的帽子。大家的风气是觉得跟皇帝对着干是刚直不阿,支持皇帝的想法是拍马屁、是佞臣。我觉得皇帝心里也很苦闷啊。大家都怕被扣佞臣的帽子,搞得懂自己、支持自己的想法的官儿都不敢说话,皇帝多孤独啊。下次遇到有大臣站自己,皇帝还要担心他们会不会被扣上佞臣的帽子。

大家这么防着佞臣,是要防止有人就是通过拍老板马屁来捞好处,要防止皇帝被马屁精包围了,这样皇帝就不能兼听了,皇帝就不能看到自己的不足。这不是最近大家都在批某大,说许某印就是被马屁精包围了。 

At the risk of being overly confident,我觉得我是能分辨清楚我手下谁是 yes-sayer、谁是真正的思路一致的人的。子曰,君子不以言举人。主要就是看行动,看他们做的事情。不过也有很多人会就盯着老板关心的事情做。这样的风气要是不刹住,就没人do the right things和那些看不见的脏活了。而且,从逻辑上来说,可能虽然我觉得我能分辨马屁精,但我实际上还是会被骗。就好像觉得自己不会被金融诈骗的人,还是会被金融诈骗。

但反过来想想,有时候,让自己的手下觉得自己很容易骗,其实不是件坏事。哈哈。

归因难,难于上青天

2021年诺贝尔经济学奖的获奖理由是“因为他们对因果关系分析的方法论贡献”。很多人觉得这个奖给的很水。我觉得一点都不水。因为归因太难了。

那几年,多少次半夜醒来(figuratively speaking),脑子里挥之不去的就是那些问题:你怎么证明这个结果是你做的这些事情的结果?你怎么证明你不做这个事情就没有这个结果了?今天有这个结果,原因很多,你做的这个事情在里面贡献了多少?你怎么量化你做的这个事情的效果?

代码覆盖率从80%提升到90%,效果是什么?节省了多少研发时间?人均每天代码行数因此提升了多少?提升了多少研发幸福感?迭代交付周期因此缩短了多少?需求吞吐量因此提升了多少?对业务增长的贡献是多少?千行代码缺陷率因此下降了多少?降低了多少个P1P2故障?服务可用率提升了多少?资损故障因此下降了多少?

CI通过率从90%提升到99%,效果是什么?节省了多少研发时间?人均每天代码行数因此提升了多少?提升了多少研发幸福感?迭代交付周期因此缩短了多少?需求吞吐量因此提升了多少?对业务增长的贡献是多少?千行代码缺陷率因此下降了多少?降低了多少个P1P2故障?服务可用率提升了多少?资损故障因此下降了多少?

主干开发,效果是什么?节省了多少研发时间?人均每天代码行数因此提升了多少?提升了多少研发幸福感?迭代交付周期因此缩短了多少?需求吞吐量因此提升了多少?对业务增长的贡献是多少?

做code review,效果是什么?对业务增长的贡献是多少?千行代码缺陷率因此下降了多少?降低了多少个P1P2故障?服务可用率提升了多少?资损故障因此下降了多少?

今年故障下降了70%,和你做的这些事情有多少关系?你怎么证明?为什么不是因为我们的工程师能力提升了?为什么不是因为我们做了很多架构治理?为什么不是因为今年立项抓得严了?为什么不是因为公司今年更加重视了?为什么不是因为今年比去年少了很多大型重构?

我们做事情都是要讲投入产出比的。你说的这些事情,都是对的。但是要看投入产出比,我们没有无限的资源。你没办法量化度量你这些事情的效果,你怎么衡量这些事情的投入产出比?

你证明不了你做的事情和结果的关系,那凭什么给你好的绩效?你做的事情和结果的关系,是你自己要证明的。你证明不了,那怪不了别人。你证明不了,就算拿到结果了,也是碰运气的,不是可以复制的结果。

所以我觉得2021年诺贝尔经济学奖一点都不水。每一个被“你怎么证明这个结果是因为你做的这个事情”这类问题反复折磨过的人都知道,归因非常难,非常难,非常难。

直道超车

最近几天都在修case。其实不是我的case。都是其他那些team的。自己不看,总是怪infrastructure。那只好我自己来了。

好像中国和美国的程序员都是类似的:自己的用例失败了,总是不会先从自己身上找原因,总是先blame infrastructure。总是要别人一而再再而三的把铁一样的证据放在他们面前了,他们才会承认是自己的用例有问题。

承认了自己用例有问题还要继续找借口:哎呀,你们这个工具不好用啊,排查起来很辛苦;哎呀,你们这个工具不好用呀,我要单独跑一下用例很辛苦;哎呀,你们这个工具不好用呀,能不能把失败的用例给自动重跑一下呀;哎呀,你们这个工具不好用呀,能不能智能一点,做一下智能分类、智能诊断。就是不肯乖乖的把自己的case修修好。

要不说姜还是老的辣。今天修的这个case,那几个兄弟之前都挣扎过了,都挣扎不出。我从中午开始看的,看啊看,看啊看,都是从来没看过的代码。看到晚上,被我灵光一现看出来毛病了:有个地方把now()转成“US_EASTERN”时区的时间。当时就觉得这个地方很fishy。

Fishy 在字典里的意思是 arousing feelings of doubt or suspicion,翻成中文就是:这里看着很可疑,这个地方感觉怪怪的,这里感觉不太对劲。

这不有个故事吗。说有台机器坏了,谁都搞不定。最后请了个老师傅来。老师傅看了看,把一个螺丝拧紧了,机器就好了。老师傅收了1000块钱,人家嫌贵。老师傅说,拧一个螺丝只要10块,但剩下990块是知道拧哪个螺丝。

老程序员就是值这个钱。改一行代码看上去很简单,只值10块钱。但能看出来要改哪一行代码,就凭这个,老程序员的工资就比新兵蛋子高。

写这个“US_EASTERN”的估计也是一个新手,没吃过timezone的苦头的,顺手就写了。他这一顺手,后面好几个人好几天时间就没有了。要是再到线上出问题,或者等到屎山已经很高了再搞技改,那就是动辄几百人日的代价了。

“US_EASTERN”的问题就是:每天有一个小时的时间,当“US_EASTERN”还是10月19日的时候,真正的纽约当地时间已经是10月20日了。就差这一天。每天这一个小时里面这个case必败。大家之前看不出一个头绪,看不出什么pattern,原因之一也是之前败的并不频繁。这是不是从另一个侧面也说明,我司在西海岸的同学们到晚上九点提代码的人就不多了。

这两天还修了一个很有趣的case。有个case,偶尔会败。这个case其实没干啥,就是在本地的DynamoDB里面插好多条假user,然后再读出来,看看对不对。但有时候在PutItem的时候会报错,报“Cannot do operations on a non-existent table”。好几个人看了,看不明白,没头绪。

那天我看了一会儿,也没看出来为啥。但我就看到一个地方很fishy:这个用例,用一个for循环插数据,for循环循环了1000次。我看到那里的时候就眉头一皱:有必要吗?

我就去问这个用例的原作者。还好这个用例还算新,八月底加的,作者还在。作者说,其实1000就是随便放的一个数字,到底是 100还是1000,对这个用例来说并没所谓。我说,那要不我帮你改成100吧。因为这个case时间太长了,现在要跑八九秒钟。我改成100,估计不到1秒就跑完了。他说可。

于是我就路见不平的改了。把循环1000次改成了100次。然后我发现,改完以后,这个用例不flaky了,“Cannot do operations on a non-existent table”彻底消失了。敢情这背后的原因就是循环太多了哇,把本地DynamoDB给压坏了。

那个作者还算心思缜密,还问我,这是不是意味着在线上也会有性能问题。我说,也许吧。也许只是本地DynamoDB比较搓,云上的可能就没这个问题了。你要是实在不放心,去云上直接测一测。总之,就别在CI里面跑压测了。

用例不稳定,基本上每个公司都有这个问题。很多人都想走捷径,老是把“弯道超车”挂在嘴上,想搞个什么大招可以一下搞定,或者想另辟蹊径,绕开这个问题,或者搞个自动重跑什么的先对付着。其实,用例不稳定的问题,只有一条路:好好写代码。不稳定的用例好好分析,好好修,修了就修修好,不要东加一个sleep西加一个retry的糊弄过去。

这就和减肥是一样道理。不想改变不健康的饮食习惯,但还想减肥,那是不可能的。局部减脂,不存在的。代餐,都是智商税。减肥的办法,就是做正确但艰难的事。

美国互联网黑话

昨天写了一篇design spec,关于code ownership的。文档上来就引用米尔顿·弗里德曼的话,在design spec里可以算是逼格非常高的了。

文档是从上周就开始写的,昨天写完的。写了足足有18页。我也很惊讶,居然写了那么多。本来以为四五页就差不多了。Code ownership这个事情说起来其实很简单,一句话就能讲清楚:加一个OWNERS文件。

咋就把一句话变成了18页了呢?这不是要”starting from first principles”嘛。国内互联网也有类似的说法,叫做“你的底层逻辑是什么”。这两年阿里被黑的厉害,其中就包括阿里的人用的那些互联网黑话,像什么“抓手“、”赋能“、”闭环“,还有“底层逻辑”也是。

其实黑话这个事情,东西方都一样。美国也有互联网黑话。比如,刚工作那几年,有一个词我每次听到都想吐:synergy。美国的黑话也在不断进化,这两年synergy听到的少了,有些新的黑话涌现出来,比如我回国前还很少听到有人讲first principles,这次回来后好像用的人多起来了。

因为要“starting from first principles”,所以把一句话就能讲完的事情写了18页。有段时间没写那么长的文档了。上一次是写了一份九十几页ppt的新财年规划。那也是被杠精逼的。不管你怎么写,他们总是能给你挑出点毛病来。

我谈目标,他说你这个没有落地过程。我谈要做什么,他说你没有推导过程。我谈why,他说你能不能告诉我们要做什么。我谈远大的目标,他说你太理想化。我谈具体目标,他说你留白不够。我谈重点, 他说你不全面。我谈全面了,他说你要抓重点,就讲top 3。我谈原则,他说你不要一刀切。我谈原理,他说你不要老是讲概念。我谈抓手,他说你这些是单点,没有体系化。我谈体系,他说你不要讲大道理。我谈最佳实践,他说那套东西在这里未必适用。

没办法,为了堵住杠精的嘴,只能都写上,于是就变成九十几页ppt了。可谁能想到,我把所有东西都谈了,他说你怎么ppt那么多页。