#绝对量化

OKR 要求产出可以被绝对数字化，但很多真正有价值的事物根本无法数字化。

就像你可以定个目标说你要把新书卖出去多少本，但你无法定个目标让这本书的内容的构思和表达提升多大一个级别，让读者的颅内高潮多延续了多久，让读者把你那字字珠玑的段落在心里刻得有多深。

如果你认为销量是质量的投票，那么销量就应该交给市场，这样的销量才反应了它的价值。 而不是限定了公司内部只能用 XXX，然后你这个 XXX 每次在自己的汇报文档上打上 “服务了多少个项目” “使用人数增长了多少”...

我看到公司想要提升软件质量的时候，真正实施的人们其实找不到入口点，大家慌慌张张想要去做点不一样的、出彩的、能拿绩效的、别人没做过的，但唯独没人去做也同时不被允许去做一些真正改变软件质量的，决定着业务发展基因的东西。

同时我看到的是大家的代码都写的很烂，没有艺术性，没有深入的构思，没有反复斟酌的设计，没有花过时间的痕迹。当我指出问题时，大部分人表示认同，但同时大部分人也都给出了：这个项目赶得急、改起来很麻烦、就那样吧、能用就行、项目迭代快不适合... 等等理由。

我觉得更失望了，仿佛是，我们都看到了一坨垃圾，我说这真的很垃圾并给你解释了原因，你也说是，然后你说 “我就是那样的垃圾”，行吧，我还能做点什么。

我看到 QA 也是一样，在想着怎么 “做点以前没做过的，哪怕性价比不高”，但没有放太多精力去关注 “如何让 QA 实施人员能够系统彻底地了解业务需求” 这件事，也许真正能改变质量的就是这一点呢？QA 也可以是产品经理，QA 不应该在要实施的时候才去跑来问我这个功能是什么意思，甚至得出错误的测试结论。 对 QA 来说，更重要的是流程的改进、人员的优化，不是吗？难道是多写几个不符合实际的 E2E 脚本？

自诩现代化的公司，不是喜欢绝对量化吗？仿佛数字可以体现、解决一切问题。

那就把 QA 的用户：开发者对他们的业务服务体验量化一下。

把一个软件项目的代码的用户：下一任维护者对上一份维护着留下的代码质量和感受量化一下； 量化出是骂它是一坨狗屎想马上跑路还是仿佛看到了一份代码教科书奉为经典。

把那些钦定的内部的工具包库量化一些，量化一下他们的用户多少是不情愿边骂边用的，量化一下大家用起来的时候内心是离职的冲动多，还是终生卖命的冲动多；顺便可以量化一下这样的东西输出到外部有多少开发者会为你点 Star。

#形而上学

技术自信建立在很强的自我认同之中，自我认同一定是以事无巨细的形而上学作为根基。 有的人讨厌这样的东西，觉得这些没用，但同时人们想要的 Geek 又基于这种对一切极致的探究。

对形而上学来说，“形” 就是本质，就是正义本身。我们追求一切 “当下最正确的行为和当下最正确的事”，这其实也就是那位酒后程序员酒后写的第二段：

技术栈不重要。技术领域有大约 10-20 条核心原则，重要的是这些原则，技术栈只是落实它们的方法。你如果不熟悉某个技术栈，不需要过度担心。

就像是人们更关心权力的产生和权力本身，而不是关心靠出卖权力获得的利益。

所以，同样的道理，如果你接受不了我们花半天时间去论证 interface 前面要不要加 I，你也很难有机会写出多么严谨和精致的艺术品代码。

相应的，你也没有能力察觉一个系统已有的设计缺陷，并且会用自己勤奋的双手让他更烂一点，加速崩坏，除了那些混日子和没有技术追求的人，不会再有优秀的开发者与你共建。

你看那各个地方政府都在为了自己的 GDP 崇拜拉东拉西拉房价，他量化你的感受了吗？量化你的幸福程度了吗？他们不需要，“你是否幸福” 不由你自己的感受决定，由 “量化后的人均 GDP” 决定。

我不知道这种问题是不是不可克服的，但在这种环境下，我无法成为那个 “做漂亮事情” 的人，我只会在反复挣扎、矛盾之中以摸鱼来抗衡。