什么时候该减少软件质量投入?

什么时候该减少软件质量投入?

不需要高质量

虽然有点危言耸听,但其实大部分产品并不需要很高的质量,只需要够用的质量。而不同产品“够用的”标准是不同的,这取决于软件的质量需求。

软件的质量需求是软件需求的一部分,根据《系统与软件质量模型 GB/T 25000.10》,软件产品质量需求的完整描述,包括内部质量的评估准则、外部质量的评估准则、使用质量的评估准则,以满足开发者、维护者、需求方以及最终用户的需要。

软件的质量需求

软件的质量需求

简单来说就是软件的质量是否满足评价者的评价标准。

为了弄清软件的质量需求,我们需要找到以下问题的答案:

  • 谁来评价质量(质量干系人)
  • 从哪些方面评价(评价维度)
  • 评价的标准是什么(评价方法或指标)
  • 都有哪些因素会影响评价的结果(影响因素)

我们在分析投资策略或效果之前,就需要澄清质量需求,找到对于当前上下文的“标准答案”。只有清晰知道这些信息,我们在投入时才能更有针对性,管理者也能从“盲目而又苦口婆心的追加投入,但效果未知”,转变为 “高效响应干系人的需求”,获得令管理者和研发团队都满意的效果。

假如在真实情况下,我们分析出干系人的预期并不高,可以对相关干系人进行一定的沟通引导。因为预期不高的原因可能有两种,一是本身要求确实不高,二是干系人可能尚未清晰认知质量,因此无法给出准确的质量需求。对于第一种情况,要求确实不高,那么团队就可以减少盲目地投入,去把精力花在最有价值的事情上。针对第二种情况,赋能的绝佳机会就在眼前,趁机对齐理解和需求尤为重要。

团队状态不佳

也有一些情况是这样,由于要求较高,团队追加了相关的投入,如补充大量测试、统计测试覆盖率、评估测试有效性等实践,但获得效果往往不好。一个可能的原因是,团队的状态限制了产出的质量。

比如新组建的团队正在磨合期,不确定因素较多,团队没法以一个相对稳定的节奏开展研发活动;比如团队面临大量新人涌入或关键角色的变更;再比如团队管理者对投资回报过于乐观,或者团队不同角色间存在冲突对立……类似这样的情况,此时最大的瓶颈在团队,不调整团队状态是很难获得高质量的,此刻并非追加投入的最佳时机。进一步讲,质量不好恰恰是团队健康度低的直接展现,此时盲目改进是治标不治本,应先解决团队状态的问题,再谈改进。

团队状态不佳是一个管理问题,但可能归根结底是个意识形态的问题。对于想改善的团队,不妨进行团队状态检查(Team Healthy Check),帮助团队评估和整体改进。具体细节不在本文讨论范围内,比较重要的可能是回答以下问题:

  • 最近一段时间,我们做得好的是什么?(强化优秀实践)
  • 我们如何改进工作方式?(需要深入探讨)
  • 我们接下来一段时间的改进重点是什么?(如三个月)

改善团队状态的过程,很有可能已经在改善质量了,过程质量一定能获得提升。广义来讲,团队状态肯定会影响质量。当我们在考虑质量投入时,需要想清楚投资哪些方面,是不是投在了关键点上,并根据具体情况进行一定的适配。

质量已经足够好

再有一种场景,就是我们已经做得足够好,软件质量好体验佳,团队运转顺畅无摩擦,肉眼可见的需求也不会有太大变化,或者有变化我们也能迅速响应。假设我们处于这种状态,而投入又在可接受范围内,此时应维持平衡,可以不追加或试探性减少相关的投入了。

相信绝大多数团队都不会处于理想状态,往往任务艰巨、资源紧张、时间紧迫才是常态。处在困境中的质量从业者,需要深入思考投资的时机和重点。

永远存在改进空间?

基于以上讨论,我们可以看到不需要追加投入的情况。而就目前观察来看,大部分团队基本会处于这种状态:干系人的预期较高,因此需要提供高质量的软件;团队状态并不理想,能达成动态的平衡就算接近理想了;同时,我们做得并不够好,但一直走在持续改进的路上。由此可见,大部分团队都存在改进的空间,需要增加相关的投资。

针对大多数需要改进的情况,很重要的一点在于需要明确质量需求,只有知道干系人要什么,才能知道我们该给什么。明确改进目标,以免仅追求了形式上的投入,而忘记为什么要投入。

明确需求和目标后,还需要思考有限的资源投在哪些重点上才能最大化收益。在整个改进过程中,还需要时常管理预期,必要时对团队纠偏,促使质量保持在稳定或小幅度波动式上升的状态。

源自公众号  圆小豆的美梦工场



留言