需求评审图什么？

上周五第一次参加了公司的需求评审会，开了个寂寞，就很想写一篇文章吐槽一下，应该没有人有跟我一样的经历吧？

一、一次糟糕的需求评审

先来回忆一下上周五的这个需求评审会。

首先大家先在脑中构想一个原型，一个没有任何文字说明和标注的低保真原型。

然后产品同学打开了这个原型开始讲解:

“这是之前跟X总讨论的要做的一个XX功能，首先这里是一个配置页，用户可以在这里配置XX信息，然后…”

“这下面也是一个配置页，用来XXXX…，某个XXX产品也是这么做的，所以我们也XXXXX”

“这里有一个列表，用来展示XXXXXX…”

“这里也是一个配置，用户可以在这里配置XX信息，后面有三个规则，分别是XX1，XX2，XX3”

这个时候终于有人提出问题了：这三个规则是具体是什么意思？

“哦，第一个的意思是XXXXXXX，第二个是XXXXXX，第三个是XXXXXXX”

…

这次评审总共评了三个新需求和十来个优化需求，新需求的讲解过程就像上面那样，整个过程我都很懵。

优化需求呢，基本上就是读了一下标题，技术负责人评估了一下能不能做，能做，这个需求就算过了。

举个例子吧，有这么一个优化需求，是一个操作后的跳转页面，这个页面停留时间太短就自动跳转回上一页了，业务部门反馈希望优化一下。

这个优化需求的标题就是：XXX操作后跳转页面停留时间太短，优化一下。

开发觉得这个优化很简单，能做，就这个需求就这么过了。

我总算知道为什么TAPD上那么多一句话需求了，敢情他们之前都是这么评审需求的，我直接裂开来。

二、为什么要做需求评审？

1.需求评审的目的

我是一个测试，参加需求评审的目的对我来说，无非就俩。

• 让我知道这个需求是干什么的，为什么要做这个需求？(who,when,where,what,why）
• 研发，测试，产品，三方对需求的各功能模块有一个清晰的认识并能达成共识。

如果需求修改点太多，或者还有一些争议点没有确定，可能还要再组织一次需求评审，如果是敏捷开发走迭代的话，还需要评估这个需求完成测试需要的工时。

如果一场需求评审会下来，参会的人都不明白你这个需求到底是干什么的，只能说这会开了个寂寞。

说回上周五那场评审会，我是真没明白那个新需求是干嘛的，而且一直没有把会议文件发出来，全靠凭空记忆。

因为评审的时候产品同学总提到另一个产品，所以我大概知道这个新需求就是一个克隆需求，产品同学没讲明白，我只好自己去体验一下了，借着在第三方产品的实操+说明文档，我总算捋清了新需求到底在讲个什么玩意儿，就离谱。

2.需求的内容很重要

每个公司应该都有自己的需求规范吧，很显然，我现在这家公司暂时没有。

现在的需求都很随意。

有50%的一句话需求（线上用户反馈）。

有30%的需求是反馈的截图（运营那边的反馈）。

有10%的需求只有需求文档没有原型（可能有原型和UI，但是没整理在一起，只能找到需求文档）。

有10%的需求只有原型没有需求文档（就是我上周五开会那三个需求）。

公司也慢慢慢慢慢的在优化各种流程了，如果可以的话，我希望需求说明文档和原型不要再分开了QAQ。

需求的内容，我希望有：

• 需求背景，使用场景
• 需求依赖，影响范围
• 流程图（非必须）
• 原型图截图/UI（原型图最好有相应的标注）
• 功能说明
• 字段说明
• 特殊规则

数据从哪来，到哪去，有什么特殊规则最好都举例说明一下，既然在用TAPD，为什么不好好利用啊，暴风哭泣！

3.会前会后需要做什么

无论是会前还是会后，我都没有见过那场需求评审会的文档。

一般来说，开需求评审会之前，最好先把需求发出来让大家先看一下，给大家一些自主思考的时间，提前把自己的问题记录，在会议上好提出来。

如果不提前熟悉，很容易在评审的时候直接跟着产品的思路走。

有人可能会说，提前发了也不会有人看。

别人看不看是一回事，你发不发是另一回事，习惯是慢慢养成的。

评审会前提前发，评审会后及时更新，并同步三方，很重要。

后续有关这个功能的修改/联动都能根据这个需求文档有源可溯，也很重要。

没有参与这个需求的开发和测试，也能根据需求文档快速的熟悉这个功能模块，不是很棒棒吗？

没有确定的需求和有大改动的需求，再约一次好吗？

上周好像有一个技术实现困难，需要改流程的需求，还有一些不确定的优化需求，也没说什么时候再讨论，可能又是突然袭击吧，无奈摊手┑(￣Д ￣)┍。

三、图什么，也是在问我自己

前面说到我没弄明白新需求，去了第三方平台操作，就在这个操作的过程中，我有点怀疑自己了。

真的有必要弄清楚这个需求为什么要做吗？

这可能跟之前的工作习惯有直接的关系。

以前的工作模式是测试驱动开发，都说测试是半个产品，我经常在接到新需求的时候问很多问题。

这个需求是干什么的？为什么要做？没做这个需求之前用户是怎么解决这个问题的？用户真的需要这个功能吗？你们做过用户调研吗？

说好听一点就是拦截需求，保护我方开发同学，保证团队迭代节奏。

现在的工作模式这应该是产品需要去关心的问题了，而且既然都已经开三方评审会了，说明产品跟大BOSS已经敲定要做这个需求了，剩下的就是怎么做的问题了。

我好像应该把工作的重点放在测试这一块，可是测试就是基于需求来的啊！

目前我好像只能尽我最大的努力给他们提意见了。

四、心疼我方产品同学

其实说了这么多，我也不是想吐槽产品同学的不是，原罪还是公司流程不规范。

技术负责人老是说在优化流程了在优化流程了，来了十多天了也没开过什么讨论会。

产品同学的压力其实也很大，看得出来他应该是一个工作经验不多的产品，而且现在公司就他一个产品，需要做的事还是蛮多的，听说这个需求都还是他前一天晚上加班弄出来的，也很惨了。

之前出的一个需求也是反复还在修改，每天中午一起吃饭的时候都感觉他快自闭了。

公司已经在招另一个产品了，希望能有所改善吧。

五、最后

我只是一个有几年工作经验的菜鸡，而且也不是什么管理层，只是一个普通的测试，随缘吐槽一下，请不要骂我，我会玻璃心。

正是因为公司一些工作流程待优化，而且还有很大的成长空间，我才想留在公司尽我一份绵薄之力，工作很多年还只是一个普通的功能测试，只希望能和公司一起成长。

最后祝大家节日快乐~