不需要高质量
虽然有点危言耸听，但其实大部分产品并不需要很高的质量，只需要够用的质量。而不同产品“够用的”标准是不同的，这取决于软件的质量需求。
软件的质量需求是软件需求的一部分，根据《系统与软件质量模型 GB/T 25000.10》（阅读原文中的文字链接可下载这个标准），软件产品质量需求的完整描述，包括内部质量的评估准则、外部质量的评估准则、使用质量的评估准则，以满足开发者、维护者、需求方以及最终用户的需要。
简单来说就是软件的质量是否满足评价者的评价标准。
为了弄清软件的质量需求，我们需要找到以下问题的答案：
- 谁来评价质量（质量干系人）
- 从哪些方面评价（评价维度）
- 评价的标准是什么（评价方法或指标）
- 都有哪些因素会影响评价的结果（影响因素）
我们在分析投资策略或效果之前，就需要澄清质量需求，找到对于当前上下文的“标准答案”。只有清晰知道这些信息，我们在投入时才能更有针对性，管理者也能从“盲目而又苦口婆心的追加投入，但效果未知”，转变为 “高效响应干系人的需求”，获得令管理者和研发团队都满意的效果。
假如在真实情况下，我们分析出干系人的预期并不高，可以对相关干系人进行一定的沟通引导。因为预期不高的原因可能有两种，一是本身要求确实不高，二是干系人可能尚未清晰认知质量，因此无法给出准确的质量需求。对于第一种情况，要求确实不高，那么团队就可以减少盲目地投入，去把精力花在最有价值的事情上。针对第二种情况，赋能的绝佳机会就在眼前，趁机对齐理解和需求尤为重要。
团队状态不佳
也有一些情况是这样，由于要求较高，团队追加了相关的投入，如补充大量测试、统计测试覆盖率、评估测试有效性等实践，但获得效果往往不好。一个可能的原因是，团队的状态限制了产出的质量。
比如新组建的团队正在磨合期，不确定因素较多，团队没法以一个相对稳定的节奏开展研发活动；比如团队面临大量新人涌入或关键角色的变更；再比如团队管理者对投资回报过于乐观，或者团队不同角色间存在冲突对立……类似这样的情况，此时最大的瓶颈在团队，不调整团队状态是很难获得高质量的，此刻并非追加投入的最佳时机。进一步讲，质量不好恰恰是团队健康度低的直接展现，此时盲目改进是治标不治本，应先解决团队状态的问题，再谈改进。
团队状态不佳是一个管理问题，但可能归根结底是个意识形态的问题。对于想改善的团队，不妨进行团队状态检查（Team Healthy Check），帮助团队评估和整体改进。具体细节不在本文讨论范围内，比较重要的可能是回答以下问题：
- 最近一段时间，我们做得好的是什么?（强化优秀实践）
- 我们如何改进工作方式?（需要深入探讨）
- 我们接下来一段时间的改进重点是什么?（如三个月）
改善团队状态的过程，很有可能已经在改善质量了，过程质量一定能获得提升。广义来讲，团队状态肯定会影响质量。当我们在考虑质量投入时，需要想清楚投资哪些方面，是不是投在了关键点上，并根据具体情况进行一定的适配。
质量已经足够好
再有一种场景，就是我们已经做得足够好，软件质量好体验佳，团队运转顺畅无摩擦，肉眼可见的需求也不会有太大变化，或者有变化我们也能迅速响应。假设我们处于这种状态，而投入又在可接受范围内，此时应维持平衡，可以不追加或试探性减少相关的投入了。
相信绝大多数团队都不会处于理想状态，往往任务艰巨、资源紧张、时间紧迫才是常态。处在困境中的质量从业者，需要深入思考投资的时机和重点。
永远存在改进空间？
基于以上讨论，我们可以看到不需要追加投入的情况。而就目前观察来看，大部分团队基本会处于这种状态：干系人的预期较高，因此需要提供高质量的软件；团队状态并不理想，能达成动态的平衡就算接近理想了；同时，我们做得并不够好，但一直走在持续改进的路上。由此可见，大部分团队都存在改进的空间，需要增加相关的投资。
针对大多数需要改进的情况，很重要的一点在于需要明确质量需求，只有知道干系人要什么，才能知道我们该给什么。明确改进目标，以免仅追求了形式上的投入，而忘记为什么要投入。
明确需求和目标后，还需要思考有限的资源投在哪些重点上才能最大化收益。在整个改进过程中，还需要时常管理预期，必要时对团队纠偏，促使质量保持在稳定或小幅度波动式上升的状态。
