职场内卷与挑战

写在前面

职场是个理性大于感性的场所,很多企业鼓励大家相互挑战,背后的理由也很简单,只有相互挑战,才能相互学习,相互促进,从而优化决策质量,提高执行效率。

比如,某个部门领导提出一项动议,其他部门的人,会从各自的维度,提出一些相反的意见或案例,这样的结果,要么发现这个动议的重大漏洞,进而否决这个动议,要么持续完善这个动议。最终的结果,都是优化了决策质量。

但,挑战要基于团队完全的相互信任,如果信任基础不够牢固,挑战则不但无法达到预期效果,甚至会变成一种职场的内卷。

一个案例

最近亲身经历了一个典型的案例。一个产品临近发布,产品的测试以及 BUG 修复,也在锣密鼓地持续进行。研发部门的一个同事,在一个群发的测试报告的邮件里(抄送了一大堆人),全部回复了一封邮件,大意是:测试部门在这个版本提了一个几乎存在了 1 年之久的 BUG,而且还把这个 BUG 的严重级别定义为 HIGH (发布前必须解决)。此外,还补了一刀:最近有很多 MEDIUM (发布前,要尽量解决,如果不解决,需要和测试以及产品经理逐个沟通) 级别的 BUG 也是这种情况,都是新发现的,这样会给软件的发布带来额外的风险。

一石激起千层浪。

这个项目的测试负责人,在很短的时间内,全部回复了一封邮件,大意是:这个 BUG 虽然存在了很久,但它依然是比较严重的,而且之前测试发现过一个类似的 BUG,那个 BUG 解决了,这个 BUG 还存在,研发也需要反思为什么两个相同的问题,一个修复,另外一个还可以存在一年之久。

当天晚上,测试部门的负责人,也回复了一个邮件,不过处理方式明显高明很多。首先,缩小了邮件收件人,把研发部门那个首先发起这封邮件的人排队在外,只发给研发部门的几个经理以及这个项目的测试负责人。其次,邮件重点强调信任和共同目标的重要性。再次,也对事件进行了定性,把研发部门这位同事,定义为使用“甩锅”的方式解决问题,是不好的团队协作思想。最后,提出了一个解决这种问题的方案,即研发需要快速响应,快速解决,同时用沟通和协作的方式解决问题。

个人感受

作为这个事件的旁观者,也作为利益相干人,一个直接的感受是:试图通过责备对方解决问题,不但不能解决问题,而且会深深地伤害信任,进而让问题变得更复杂,甚至造成职场内卷。

联系到家庭生活,很多时候,我们也总是通过责备对方,来期望对方改进某个缺点。往往这也是行不通的,且会深深地伤害彼此之间的信任。

从历史上看,那些让王朝走向衰弱的统治者们,也是不停地伤害“政权”,他们以为“政权”是打不死的猴子,不管如何伤害它,它总会保护自己,也会给自己提供不尽的权力和荣华富贵。赵高在后期,甚至认为,作为政权的最高统治者的赢胡亥,也是可有可无的。

事件的背后

回到事件的始作俑者,他发出这封邮件想表达什么意思呢?想解决什么问题呢?

他大概想表达的意思是,测试部门不给力,等到产品要发布了才测出这么多新问题,这样研发根本没有足够的时间解决这些问题。他希望测试部门能在项目初期多测试出一些问题,而不是在后期,产品快发布了,测试出这么多新问题。

但一个真实的状态是,测试部门在产品临近发布的时候,压力也很大,生怕有什么疏漏,从而导致产品在市场上引起质量问题。所以,他们往往在项目后期,会加大测试力度。

从这个角度来看,这个问题无解。因为研发在项目的后期,也是提心吊胆,生怕测出一个重大的问题,不容易解决,从而造成项目延误。所以,他们在临近发布,看到新的严重问题,可能第一感受就是:不会吧,早干嘛去了,这个问题现在才发现?

坦白讲,这个时候,能做的,只能是快速响应,快速迭代,用沟通和协作的方式解决问题。比如,研发的同事,可以先判断,如果这个问题容易修复,就抓紧修复,不多说一句话。如果发现这个问题非常不容易修复,但这个问题其实并没有想像的那么严重,则可以私下找测试的同事沟通,是不是可以把这个问题降级。比如,这个问题都存在了 1 年之久了,也没有人反馈。其次,这个问题用户遇到的概率很小,即使遇到了,造成的后果也并不严重。再次,这个问题修复起来确实工作量比较大。通过协商解决问题。

职场内卷

有人可能会提出一个建议,比如根据 “BUG 早期发现率” 这个指标来衡量测试部门的工作绩效。比如,一个产品,要测 10 个版本,则到第 8 个版本,要发现系统 95% 以上的 BUG。

看起来这样的指标确实能反映出一部分问题。但测试部门的人,可能会提出另外一个指标:研发部门发布的每个版本,也需要有 “BUG 修复率” 这个指标,如每次发布新版本,必须解决 80% 以上的问题。否则会影响测试部门的 “BUG 早期发现率” 这个指标。

上述要求看起来,也合情合理。毕竟,如果你不能测量它,你就不能管理它。

最终,研发和测试,都要求双方都把细节做得更好,都要求对方 “在细节上雕花”。

就像一个段子所说的,本来公司要求大家写周报,后来发现不能达到预期的管理效果,就要求大家写日报,发现还是不能达到预期的管理效果,就要求大家写“小时报”,最后大家都在写小时报,不需要干活了。

这就是典型的内卷。

换个考虑问题的角度

上述指标,看起来没有问题,但实际上并无用处。理由如下:

目前测试部门做的是黑盒测试,理论上是无法穷尽的。即,理论上,BUG 的数量可以是无穷大。这种情况下,到底 “BUG 早期发现率” 是 80% 是合理的,还是 90% 是合理的,可能根本就没有办法有个统一的标准。因为这个和系统的复杂性,产品的形态有密切的关系,还有测试的强度,测试的时间长度有关系。我们经常开玩笑,只要给够时间,BUG 数量总是会不断上升的。

即使定义出了 “BUG 早期发现率” 这个指标的标准,当测试部门的人在项目后期,发现这个指标出问题时,他们除了加派人手之外,没有任何可以改进这个指标的有效动作。加派人手虽然可以尽快地发现更多的 BUG,但其副作用,是进一步让这个指标更糟糕。

因为,“BUG 早期发现率” 是个事后指标,即只有项目全部测试完成,发布出去之后,才能统计出来。在项目执行的过程中,比如到了第 8 个版本,这个时候根本就不知道这个指标到底是不是达标,到了第 9 个版本,发现不达标,这个时候测试部就会投入更多资源,加大测试力度,这个时候,会让这个指标更糟糕。

所以,有时候,对数据控可能是个坏消息:有些数据,并不是表面上看上去的那么有用。

换个角度,这个问题更好的解决方案,是测试部门直雇佣白盒测试工程师,和研发工程师一起进行“结对”编程,即由白盒测试工程师给研发工程师编写测试例,进行白盒测试。一来,白盒测试理论上是可以穷尽的,因为可以统计测试代码的覆盖率。二来,可以倒逼研发工程师写出更高质量的代码,设计出更优美的接口。

再换个角度,项目的资源预期,时间周期预期,是否合理。如果在这些更高层面上就出现了问题,那么在执行层面,不管如何进行 “细节上雕花”,最终都无法解决问题。

再上升一个维度,公司的研发和测试体系是否有问题?所谓的敏捷是不是真的敏捷?是不是真的能做到持续迭代,持续集成?业界标准做法是什么?当然,到了这个维度,即使发现问题,也很难快速改进。

再上升一个维度,可能你发现了公司的研发体系有问题,是不是就要无条件地照搬业务的标准做法?单元测试,集成测试,系统测试,持续迭代,持续集成,敏捷开发,能引进的全部引进。如果真这样做,你可能会发现更大的问题:你理想中的公司的研发体系,一个同等规模的产品,有 20 个在维护,而你现在的公司,只有 1 个人在维护。请问如何引进?这就不得不提一个更残酷的现实:公司的研发体系,很可能是由这个公司所在行业的利润规模决定的。

上升了这么多维度,感觉还是没有看到解决问题的策略。这就是研发,特别是软件研发的困境。这也是为什么软件工程中有“人月神话”这种陷阱。毕竟,要管理它,必须要量化它。但软件研发,一半技术,一半艺术,并不能完全量化。

解决之道

那什么是解决之道呢?

答案是:人。

要回到人本身。尽最大的努力,找到那种一流的人才。这种人,他的工作效率可能是普通工程师的 10 倍,甚至 100 倍。而且,这种人,无法容忍和普通的工程师一起共事,他一定还会找一流的人才。这种人,管理起来又特别轻松,成本特别低,基本不需要管理,只需要对目标达成共识即可。

相反,如果你找了个二流的人到团队里,这个人就会找个三流的人进来。久而久之,你发现团队这里有问题,那里也有问题,然后你就会开始制定一堆的规则,什么 “BUG 早期发现率”,“每千行代码 BUG 数”,“每个版本 BUG 解决率” 之类的。然后为了这些指标,你会发现,大家的工作重心变了,所有人都围绕着这些 KPI 在工作,而把产品本身不知道丢哪个角落里了。然后,你不得不开始搞企业文化建设,倡议大家回到产品本身,倡议大家以客户优先。然后你就会发现,你的管理成本上涨了 N 倍。人力资源更加紧张了,需要招更多的人进来,也招了更多的管理人员进来,然后管理成本进一步上升。

(完)


Post by Joey Huang under essay on 2021-12-05(Sunday) 23:20. Tags: 职场,


Powered by Pelican and Zurb Foundation. Theme by Kenton Hamaluik.