0
0
0
0
专栏/.../

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

 TiDB社区小助手  发表于  2024-03-05

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

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

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

高质量的产品是用出来的

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

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

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

1

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

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

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

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

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

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

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

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

更多的功能,更多的 bug

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

no-alt

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

no-alt

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

 更重要的是,研发的带宽是一个物理约束,公司不可能无限制的增加研发资源。当我们投入更多的研发带宽去研发新的功能时候,自然会挤占质量改进的带宽,所以无论是新的功能引入的 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,看来不只是我,大概率全球的开发者也在头疼这个问题吧。

no-alt

 另外也找到了一篇非常早的关于 MySQL 质量的帖子,里面的一些观点跟我不谋而合, 7 Reasons why MySQL Quality will never be the same

0
0
0
0

声明:本文转载于 https://mp.weixin.qq.com/s/zEY6I3E9-cDhlHWTFTc7Dw

评论
暂无评论