唐刘:关于产品质量的思考 - 我的基本认知

我在文章《TiDB in 2023 - 一次简单的回顾》中提到了一个我一直以来面临的问题:每次 TiDB 发布新版本后,我如何能够非常自信地告诉客户,这个版本的质量很好,大家可以放心使用呢?

坦白地说,这个问题并不容易回答。我计划通过一系列文章来分享我对产品质量的思考,这是其中的第一篇,主要讲讲我对质量的基本理解。

需要说明的是,这些都是我个人的理解,并不绝对正确。我会不断吸收和更新迭代自己对质量的认知。另外,我提到的产品主要是 TiDB 等基础架构软件产品,不一定适用于其他产品。

高质量的产品是用出来的

『高质量的产品是用出来的』,其实这句话还有后半句,完整来说就是『高质量的产品是用出来的,而不仅仅只是测出来的』。这是我近年来的一个深刻认识。一开始就提出这样的观点,可能会让人觉得我在为无法直接发布高质量产品找借口,甚至会让用户产生不必要的焦虑,觉得自己会被当成小白鼠来测试产品。

为什么我会有这样的认知,可以看下面这幅因果回路图:

关于因果回路图,我后面会写文章专门介绍,大家也可以先看看* Wiki - Causal loop diagram

以上是一个增强回路,我们从 Quality Product 这个点开始,整体的回路逻辑如下:

当我们有一个高质量的产品时,我们就会获得更多客户。具体的客户获取可以通过销售努力、客户自我推荐、品牌传播等方式,这里我们不做详细讨论。

当我们有更多的客户之后,产品就会面临更多的业务场景,承接更多的负载。

更多的业务场景、负载,更容易突破产品的边界能力,从而让我们发现更多的 Bug 和缺陷。

我们就会投入更多的努力去修复这些质量问题,从而提高产品质量。而产品质量的提高将进一步吸引更多客户。

我在上面的回路图中是从 “Quality Product” 这个点开始讨论,这也意味着我们需要有一个质量还不错的产品。如果我们的产品质量不行,由于这是一个增强回路,我们将会失去更多客户,同时也无法继续打磨产品

那么,如何发布一个质量还不错的产品呢?其中一个重要工作是测试,因此测试非常关键。但我们需要清醒地认识到,测试只是我们对客户业务系统的一种抽象,是我们自己对于我们自己产品系统能力的理解。而我们自己的认知是不可能覆盖到真实世界所有情况的,所以我们也需要在各种各样的现实场景中打磨我们的产品,让产品质量变得越来越好。

这里在回应一下上面『小白鼠』的观点,我认为,不仅 TiDB,市场上大多数软件产品都是如此。我们通常会先找一部分样板客户去打磨产品,打磨好之后才会推广到更多的客户。而更多客户的使用也将帮助我们发现更多问题,从而继续完善产品。这其实也符合前面的因果回路图。

更多的功能,更多的 bug

继续上面的因果回路,我们可以扩展另一个增强回路。当我们承接了客户更多的场景和负载之后,客户对我们提出了更多的要求,也就是会给我们提更多的功能需求。在这种情况下,我们就需要投入到新功能的开发当中。新功能做的越多,我们的产品在更多的维度上就更有竞争力,自然就会吸引更多的客户去使用。

这个外面的增强回路,看起来非常美好,不过这里有两个点需要特别注意:

新功能的开发,从最初的设计到最终发布,再到客户真正开始使用这些新功能,是需要很长时间的,这个时间通常以季度来计算。因此,产品竞争力的提升会存在一定的延迟。这也是我在新功能到产品竞争力之间加了一个延迟标记的原因。尽管在其他方面也存在延迟,但我在这里想要重点强调这一点。

更重要的是,研发的带宽是一个物理约束,公司不可能无限制的增加研发资源。当我们投入更多的研发带宽去研发新的功能时候,自然会挤占质量改进的带宽,所以无论是新的功能引入的 bug,还是累积的未修复的 bug,都会降低产品的质量。

注意:上面我在 Feature Development Efforts 到 Quality Improvement Efforts 之间,画了一条负反馈连接。虽然形成了一个调节回路,不过因为调节回路都需要收敛到一个目标,这个图其实画的并不完善,这里先就这样将就吧……*

这里就有我的第二个认知,『更多的功能,更多的 bug』。

这其实也是我的教训。在之前的 TiDB 版本里面,我们有时候太放飞自我,做了太多的功能,而功能越多的版本,质量在一开始就是不稳定,所以我们耗费了大量的精力去提升质量。注意,这里其实也有另一个平衡回路。当我们投入更多资源到质量改进时,自然也会影响新功能的开发。新功能减少会影响后续产品的竞争力。这也是为什么我们从 7.5 版本开始,在控制新功能数量的同时,努力寻找竞争力和质量之间的平衡点。

另外一个现实需要面对的,就是任何功能的开发,甚至包括 bug 修复,都会涉及到代码的调整。在一个极度复杂的产品里面,做任何的代码调整,都可能引入新的 bug。我相信研发都不愿意写有 bug 的代码,不过这个不会以研发的意志为转移。

当然我们可以通过非常多的手段来提升我们开发新功能的产品质量,或者修复 bug 的速度,这些我将在后面的文章中详细说明。我想强调的是,上述认知是我对现实的理解。只有接受了这一点,我们才能更好地做出取舍,更好地打造出有竞争力、高质量的产品。

小结

当我写下上面几点我的认知时,我感到非常吃惊。我承认,如果回到10年前,我绝对不会有这样的认知。当然,我也不指望我的认知是正确的,也可能不久之后,我的认知又会刷新。我也会在文章中做相关的更新。

写到这里,不由得让我想到一个语言的梗,据传来自 C++ 之父 Bjarne Stroustrup - 『世界上只有两种语言,一种饱受诟病,一种没有人用。』产品也是如此。一个好的产品必须要有大量的用户,用的多了,骂的自然也多了,当然最终的结果是越变越好,这可能就是产品成长的必然经历吧。

更新

一个很有意思的事情,在我当天 2024-02-24 发布这篇文章的时候,Hacker News 上也有一篇讨论软件质量的帖子上了首页, How to think about software quality (2022) | Hacker News,看来不只是我,大概率全球的开发者也在头疼这个问题吧。

另外也找到了一篇非常早的关于 MySQL 质量的帖子,里面的一些观点跟我不谋而合, https://www.percona.com/blog/7-reasons-mysql-quality-will-never-be-the-same/

3 个赞

赞!指导方针有了,有没有关于pingcap内部保证一个版本质量的具体手段相关的文章?

让我想起我刚毕业没转行前在车厂做质量管理,总结出好的质量是设计出来的。
后面工作也越发觉得如何平衡与中庸之道也是成事的重要一环。

文章提供了对软件产品质量和开发过程的深入思考,展示了对产品质量和功能开发之间复杂关系的理解。

有心了

文章够长,但,我看完了,收获颇丰

产品质量真的是伴随产品生命周期的一个话题。看完您的体会后, 我也有一些想法:产品文档的完善性有的时候也非常重要, 如果官方文档做到好, 就能做一个很好的推广。再辅助上相关的论坛等反馈渠道, 针对会然产品质量越来越好。 感觉tidb在这方面做的就不错。

收益颇多

学习了,受益良多。

拜读了。产品质量提升还有一条路径,就是从理论角度提出的创新,或以论文的形式发表,在实践中得到验证。数据库从网状到关系型到NoSQL到分布式等,凡五十多年的繁荣发展离不开理论的不断进步。理论的进步也是现实实际问题的倒逼,彼此相生相存,互为依存,不断螺旋式上升。

好的质量,肯定是设计出来的。
质量这个话题没有绝对的定义,但PDCA是循环的,不是某一次或某一功能,也不一定是整体。

学习了受益良多

学习了

:+1:

功能需求的增多,必然会引发更多的bug,质量保证是一个关键领域,我对TiDB的最深印象就是该数据库在质量这一块做得比较好。