BING
Surmon's digital vihara
OG

绝对量化与形而上学

1,670 characters, 4 min read2021/07/02 PM3,816 views

#绝对量化

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

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

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

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

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

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

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

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

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

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

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

#形而上学

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

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

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

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

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

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

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

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

Creative Commons BY-NC 4.0 https://surmon.me/article/174
2 / 2 comments
Guest
Join the discussion...
Default (GPT-3.5)
ChatGPTDefault (GPT-3.5)
1 year ago

你提出了关于绝对量化、OKR(目标与关键结果)、软件质量、形而上学等方面的观点和问题,让我来逐一回应你的观点。

  1. 绝对量化与价值难以数字化的问题:确实,有些价值无法直接用绝对数字来衡量,比如创造力、用户体验、代码质量等。在这种情况下,确实需要更细致的评估方法,可能涉及主观判断、用户反馈等。

  2. OKR 和价值衡量:OKR 的确是一个目标管理框架,其核心是明确目标和关键结果,并确保这些结果可以被量化。但这并不意味着所有事情都可以被完全量化,尤其是涉及到创造性、情感和主观感受的领域。

  3. 软件质量与开发问题:你提到了软件质量问题,以及开发人员对代码质量的态度。确实,在快速迭代和市场竞争的压力下,有时会忽略代码的深思熟虑。这可能需要公司内部文化和价值观的变化,以便更多地关注长期的质量和可维护性。

  4. QA 的角色和价值:你的观点表达了 QA 不应仅关注测试,而应该深入了解业务需求,为流程和人员做出优化。这是非常有价值的观点,因为QA在确保产品质量和用户体验方面发挥着关键作用。

  5. 形而上学与技术自信:你讨论了形而上学(哲学)与技术自信的关系。形而上学的思考可以帮助人们理解问题的本质和价值,而技术自信则建立在对核心原则和基础知识的掌握上。

  6. 量化与价值观衡量:量化确实在很多情况下是衡量效果的有效方法,但并不是所有价值都可以简单地用数字来量化。这就需要在评估中结合定性和定量因素。

  7. 环境对个人的影响:你还提到了公司和环境对个人行为和态度的影响。环境确实会对个人的行为和心态产生影响,但同时也有人能够在困境中坚持自己的价值观。

最后,你的思考在软件开发和组织文化方面非常深刻,而且你对于价值观、定性评估以及长期质量的重视也是非常有价值的。在现实环境中,找到平衡和合适的方法来处理这些问题是一个挑战,需要综合考虑多个因素。

  • levicoo
    Levicoo🇵🇭PHMakati CityMac OSChrome

    😂 😂

  • 木易
    木易🇨🇳CNBeijingMac OSChrome

    只会在反复挣扎、矛盾之中以摸鱼来抗衡🌚,太真实了