如何在需求评审时提BUG

软件质量管理是一个永恒的主题。在敏捷开发和迭代开发并存的产品开发中，软件发布前的每一个阶段（需求、设计、开发、测试、上线）都可能引入BUG，并且传递到下一个阶段。软件测试阶段解决BUG的成本是设计阶段的60倍，而在上线后再解决BUG，这一数字会攀升为417倍。那么，如何在需求初期就发现BUG呢？

提起软件开发，那必须要提及的就是软件质量管理。质量管理不仅是在测试阶段，而是贯穿整个软件的生命周期。我们都知道越早发现bug，解决bug的成本就越低。

一个中型项目各阶段解决bug成本可参考下图：

因此，我们如果能在需求评审时就发现bug，那对于质量的把控是大有裨益，同时也会减少大量项目成本。

首先，我们需要明确一点，需求评审不仅仅是owner的事，跟研发、QA也是息息相关。我们在日常的工作中，可能都会遇到过这样一种情况：需求评审不提疑问，事后又说需求不完善，那这是产品的责任还是技术的责任？

“某些情况下，设计师的最大问题是一直在和产品纠结一个设计解决方案，而不是需求本身。”

作为技术人员，这句话我们同样可以用来借鉴。说这个问题，只是提醒我们，我们在关注技术解决方案的同时，不能忽视了需求本身。

如果需求本身就自带bug，那么这个bug一定会传递到下一阶段。

产品作为需求最终负责人，对负责模块的风险需尽早充分暴露，需求评审就是一个很好的时机。那么作为技术人员，如何在需求评审时就发挥作用，给需求提bug呢，我们可以从以下几个方面入手。

需求文档应该包含些啥

我们做了这么多项目，看了这么多需求文档，那么对于需求文档本身是否合格，我们也应该做到心里有数。

对于一份需求文档，包含的内容很多，对于技术人员来说，我们需要关注以下几点：

在检验完需求文档是否合格后，我们就可以从以下几个方面切入提bug了。

需求合理性

产品人员提了一个需求，在你看来这个需求无论是页面展现还是功能逻辑都不合理，上线一定会被用户吐槽。我们会怎么做呢？

实际工作当中，完全不合理的需求是比较少见的，但我们仍然可以从这点来出发进行思考，评审的需求为什么是合理/不合理的。

【举个例子】：xx浏览器某个版本曾提出一个需求，当用户的系统内存占用比较高的时候，浏览器会自动进行内存清理并告知用户。

这个需求有个很大的问题就是会频繁弹泡打扰用户。参照此前就曾出现过类似的“问题”：xx浏览器有个假死检测功能，当页面假死的时候浏览器会自动弹泡提示，避免用户在页面停留等待时间过长。但实际结果是用户根本不买账，反而认为xx浏览器相比其他浏览器容易假死。当我们遇到这种情况时，就应该摆事实讲道理。

【举个例子】：对于外卖产品，有时候等外卖太久，用户很无聊，很焦虑，那么在用户等待的时间里，我们是不是可以做个小游戏让用户来打发时间。

乍一看这个需求是在帮用户解决问题，实则经不起推敲：用户为什么会选择玩我们的游戏、我们的小游戏如何和大游戏厂商竞争，如果要投入大量资源让游戏变的好玩，但我们的主业是外卖。因此这个需求的合理性就值得商榷。

面对这样的需求，当然要在评审时就提出bug。

需求完整性

当某个需求不完整时，对于技术人员来说工作量是减少了，但是后期产品上线可能会带来更多的麻烦。因此在需求评审时，我们要关注需求是否是完整的。

【举个例子】：

对于抽奖活动大家都不陌生，用户中奖后我们送实物奖品给用户，当我们考虑了奖品的发货、收货流程后，我们还需要再考虑奖品的售后流程。奖品支持售后，那需要增加售后流程；不支持售后，那需要做好页面说明以及客服应对用户咨询售后的准备等等。

除此之外，一些比较小的点、甚至常见的点我们可能容易疏忽。

【举个例子】：

1、对于常见列表数据展示，在展示数据时我们需要关注数据是否需要排序，同时需要关注当没有数据时页面如何展示

2、对于一些提交表单页面，那么每个输入框是必填、非必填也是必须要考虑的

3、对于各种商品售卖，需要关注库存为0的表现

4、对于一些活动页面，登录用户和未登录用户都需要考虑

5、对于系统改版或拓展新功能，新老数据兼容也是要提前考虑的

异常项

对于产品来说，总会有异常场景出现，因此这部分内容在需求评审时也需要考虑进去。

【举个例子】：如果手机未联网，或者网络不通畅导致的加载失败 ，就该提示“加载失败，稍后再试”。

默认项

当用户进入某些有选项的页面，那么我们就需要考虑是否设置默认项

【举个例子】：进入商品页面，是否需要默认选中商品sku属性

排除项

对于一些操作，我们需要确认哪些触发事件不被允许

【举个例子】：我们通常说点击按钮打开新页面，指的是「单击事件」。但是有时候代码不做排除的话，就会将双击事件当做两次单击事件进行执行。

我们可能遇到这样的场景：点击某个按钮两次，会跳转两次页面。此时，用户难免会对产品产生抱怨：不专业。

用户体验

用户体验是个比较大的议题，重要性也比较高，但同时也是容易被遗忘的。那么在需求评审时，就要开始关注用户体验。

【举个例子】：

1、删除功能太常见了，但是有没有每次都关注删除时有二次确认弹窗

2、现在几乎每个商家都会用优惠券作为营销手段之一，那么在订单结算时，是否默认为用户选择了优惠力度最大的优惠券呢

3、我们每天都要用搜索功能，高频搜索为用户保留搜索记录也是非常需要的

4、风格统一也是对用户友好的体现，比如商品价格保留2位小数，那么从商品列表开始一直到订单页面均需保持一致

此外还有一些非功能性需求我们也要关注，这些也是产品的一部分。

产品性能

产品性能是老生常谈的话题了，需求评审时必须要确认好产品需要达到什么样的性能。多见于秒杀、大促等一些营销活动。

安全性

安全性问题也需要在需求评审时提出来，等项目后期再考虑安全性又是需要投入额外的资源。例如对于一些福利、优惠活动，需要确认是否有刷单风险。

可靠性

可靠性问题容易被大家忽略，但是这也是产品潜在风险点之一。前期没有关注可靠性问题，后期再弥补成本是巨大的。

例如需要接入第三方服务的某些场景，当后期才发现第三方服务不可靠时，尤其是已经签了合同的，此时已经有点骑虎难下的味道了。

拓展性

如果在需求评审时就能提出拓展性的问题，那么对于后续技术方案设计是大有好处的。

很常见的场景：系统是一次性的还是可以复用的。

如果不关注拓展性的问题，可能会面对这样的问题：产品告诉你，这个功能复用上次做的系统就好了，技术此时可能要抓瞎了，因为上次的系统就是按一次性使用来做的。

通过以上10项组合拳评审完需求，你应该是全场最靓的仔了。

我们可以看看做好需求评审的收益：

减少带入研发阶段bug的数量---->减少开发工作量---->减少QA工作量---->项目周期得到保障。

当然面对不同的需求，除了上述的一些方法之外可能还需要其他的手段。总之，如果能在需求评审时就有意识的给需求提bug，对于提高产品的质量、需求的质量、降低项目的成本是非常有利的。

本文来自公众号：网易杭研项目管理，作者：蔡鹏丞 

授权发布于管理圈。