【架构优化过程思考】质量高于效率

研发质量和研发效率都是研发过程中，追求的目标，高质高效的产出最终决定了研发产出的有效性。也是持续的，对当下，对长期影响最小的交付方式。

但当质量和效率只能二选一时，是优先选择效率，还是说选择质量？这个问题貌似不应该存在，效率高事做的再快，质量不好也不上了线；质量高无bug，事干不完同样也上不了线。

为啥我还在这碎碎念，质量高于效率呢，这个得从影响面来看。当一位研发人员，负责的一件事，质量不好，影响的是他负责的这个模块相关的业务中的相关人员及用户；如果这位研发人员做的基础架构模块的研发，那质量不好，影响的就是基础架构所支持的业务中的相关人员及用户；

研发人员在研发的过程，是个人的资源在投入，因为是唯一路径，研发人员提前的交付，对于提效的影响是重大的。但是当研发人员提测之后，质量保障的工作就是由测试人员+研发人员一同保障了，没有质量问题大家都好，有了质量问量，就在重复测试和改bug的过程。一些严重的质量问题甚至需要更高阶的工程师或管理人员参与一同处理。最终的提前交付收益，也被后期的人员投入而抵消了。

质量出现了问题，不止是当期版本这一个层面可以解决的，因为质量问题的修复，对于线上的用户，对于协同修复这个bug的相关人员，以及修复过程花费的时间，看是对于当前的版本实现了交付，实际上因为质量问题，在消耗之后版本的时间。当期质量不好，修复质量问题同样也需要时间，问题就在这，不可能忽略不管，最终还得需要投入人力资源来修改，当期的研发已完成了，实际上人力还在占用。

如果项目是一个长期的，多版本交付的功能，当期的质量问题产生的资源消耗，需要之后的几期的时间才可以抹平。对于研发人员来讲工作从有计划的进行功能的研发及迭代，变成了被动的修复bug，如果研发工程师还有并行的需求需要研发，那就会存在，并行研发的情况，一面改bug，一面新功能的迭代。最可怕的是，过程中产生的一些bug，长期把研发人员深深的困住了，解一个来一个，质量问题趋势得到不控制，对于质量问题的处理趋于疲惫，麻木，深度思考不足，恶性循环就产生了。这也是研发过程中最不愿看到的一种糟糕的状态。

所以，在功能研发面前，理想的状态是高质和高效的完成需求的交付；退而求其次的是高质量的，略低效率的完成需求的交付；最不愿看到的是高效率，低质量的完成需求的交付，这样长期来看是不符合预期的。

补充一下，这里说的质量问题，不止是bug，也包含一些不达标的指标，需求的目标，团队的目标等。这类问题，需要提前的规避，从技术方案，到评审，再到排期，完成的不是终级目标，完成了，具备上线的条打，可交付给用户使用，才算是当次的完成，毕竟研发的工作不是一次交付就结束了，只要产品在，团队在，功能的上线只是刚开始。