2.3　软件实现侧该追求什么目标

现在我们开始分析软件实现侧要追求的目标。为什么要分析它呢？因为软件交付过程是软件实现侧的所有事情中的一部分。我们先把软件实现侧整体要追求的目标分析清楚，然后再看具体到软件交付过程，也就是本书主要研究的范围，要追求什么。

首先是软件实现侧要出活儿。也就是要有较高的产能，或者叫吞吐量（Throughput）。吞吐量是指系统在单位时间内处理请求的数量，在这里就是指软件实现侧在一定的时间内能够实现的软件需求的总量。比如有两个相互竞争的企业，它们在软件定义侧的能力是差不多的，但是在软件实现侧，其中一个企业一年能发布100个新特性，另一个企业一年只能发布20个新特性，那大概率后者会被淘汰掉。

把更高的产能作为追求的目标，这是“与生俱来”的。哪怕是当年流行的瀑布模式，同样也追求更高的产能。现在我们也同样要追求更高的产能。

那么，如今的软件开发跟当年的软件开发，在理念上有什么不一样的地方呢？从追求目标的角度来看，最明显的变化是，如今在追求更高产能的同时，越来越重视另外一个目标，那就是更快的响应速度。

前面我们分析时说，得小步快跑。靠定义侧定义小步，靠实现侧快跑。跑得快意味着，当定义侧把一个用户故事交给实现侧，说“拜托你赶快做出来”的时候，实现侧真的可以很快做出来，把它发布上线，使前置时间（Lead Time）很短。按照精益思想，追求快速响应、快速实现，可以称为聚焦价值流动效率。

为了更好地理解更高的产能和更快的响应速度这两个目标，我们做个类比，假如你是一个只做外卖生意的饭馆老板，那么你既要关注本饭馆的产能：一天能够炒出多少盘菜，因为这对应着饭馆的每日收入，也要关注本饭馆的响应速度，也就是从用户下单到菜打包好需要多久，因为这影响着食客的用户体验。假定本饭馆的“香菇油菜”这道菜很受欢迎，其中香菇都是干香菇泡发的，食客点了这道菜之后，后厨就去泡发香菇。那你一定会想办法改进这件事情，比如从用温水泡发改成用热水泡发，以求减少泡发时间，或者干脆把一定量的香菇提前泡发好。做这样的改进，大概对这道菜的产能提升帮助不大，因为产能的瓶颈是厨师每小时能炒出多少盘，而不应该是每小时能泡发出多少香菇。就算拿大澡盆每小时泡发出100盘，如果厨师只能炒出10盘，那还是只能卖10盘。但做这样的改进，会对这道菜的响应速度有明显的提升，比如从食客平均需要等待50分钟变成只需要等待25分钟就可以吃上了。

除了产能和响应速度，我们当然也得关注质量。这里所说的质量，是指用户能够感受到的软件服务质量，所以也包括稳定性、可靠性、安全性等。

注意，跟前面两项追求产能越高越好、响应速度越快越好不同，质量并不是要一味地追求越高越好。到底需要多高的质量，要看具体是什么业务场景。比如，对俄罗斯方块的质量要求肯定不如对无人驾驶汽车来得高。前者就是一个单机游戏，后者可是人命关天。甚至同一个系统内部的不同部分，对质量的要求也可能不同。

为什么质量不是越高越好呢？因为高质量是有代价的。质量越高，代价越大，代价包括产能变低、响应速度变慢、成本变高等。所以要看在特定的业务场景下，达到什么样的质量最“划得来”。所以说我们要追求的第3个目标是，适当的质量。

举个例子，谷歌的网站可靠性工程（SRE，Site Reliability Engineering）[2]追求的就是适当的质量。不同的服务有其不同的错误预算：如果每个季度服务的可靠性目标都是99.99%，那么错误预算就是0.01%。不用追求零事故运行，只要不超出错误预算就行了。在此基础上，应尽可能地加快功能上线速度。

质量不是非得越高越好，对应地，成本也不是非得越低越好。成本包括人力资源成本、硬件资源的投入、软件许可证的购买等。成本应当是一个适当的、可接受的值。成本不要离谱，比如为每一个开发人员都搭建一套其独占的由1000台服务器构成的测试环境来进行整个系统端到端的测试和调试，就离谱了。如果有改进方案，能在不影响产能、响应速度、质量的情况下，把某个方面的成本明显地降一降，那挺好。但是整个软件实现过程的改进重点通常不应该是降低成本——既然是从事生产活动，那么主要关注点应该是创造更多的价值，而不是省钱。

总结一下，软件实现侧要追求的目标通常是：

• 更高的产能。

• 更快的响应速度。

• 适当的质量。

• 合理的成本。

这正好对应“多、快、好、省”：

• 多——更高的产能。

• 快——更快的响应速度。

• 好——适当的质量。

• 省——合理的成本。

当然，你也可以把它对应到项目管理三角形：“多、快、省”对应三角形的范围、时间、成本这三条边，而“好”则对应三角形中间经常写着的“质量”两个字。

反正就这四个方面，你觉得怎么好记就怎么记。关键是要理解，更高的产能和更快的响应速度是我们要追求的核心目标，而质量要达到特定业务的要求，同时适当考虑成本。