盘点PRD中易遗漏的三类非正面需求

PRD除了描述产品的正面需求，即要什么之外，还要描述产品的非正面需求，即我不要什么，或预防什么。

笔者将非正面需求归为三类：排除项、异常项、默认项。

一、需求的排除项

在PMBOX中，项目排除项是项目范围说明书中的一部分。同样，需求排除项， 也是需求范围说明的一部分。

交代需求排除项，不仅要告诉开发人员，哪些是不需要的功能、哪些不是目标场景或目标用户，而且要交代哪些触发操作不被允许。

1. 哪些是不需要的功能

比如，GIF图是很常见的图片形式，但是「微信」规定，发布的图片不支持GIF格式。

又比如，更换游戏用户头像是个很常见的功能，但是「王者荣耀」就不支持（直接）更换头像。

这些是产品克制的体现、边缘性需求，或者说是功能边界，当然也可以简单归属为产品的个性化玩法。

作为产品经理，一方面需要基于产品定位，主动设置这样的功能空缺，好像书法“飞白”，让产品更加立体和独特；

另一方面，某些时候受限于资源（比如开发人员不足），只能实现部分优先级高的需求，这时候也要被动地划分出阶段性的需求边界，待日后做增量迭代。

不管上述那种动机导致的“非需求”，产品经理都要明确地将这些不需要的功能点，作为需求的一部分呈现在PRD中，以便团队步调一致，避免思维定势导致实现错误。

2. 哪些触发事件不被允许

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

于是出现双击之后打开两次页面。那么用户在新页面操作完，返回的时候就需要返回两次。如下图演示了双击「搜索」和双击作者「头像」时分别按两次单机处理的画面。

当然这与开发的细致程度和经验也有关系。但作为产品经理，可以事先跟团队约定：

PRD中不提双击的，则一律将该控件的双击事件都定义为无效。只在需要双击的时候才定义双击事件。比如抖音，双击视频画面则为点赞，单击则切换【播放/暂停】。3. 哪些不是目标场景或目标用户

比如业务规定，主播在直播间获得打赏的虚拟物品，可以对应领取指定的实物商品。那么假设，某主播积攒了上百个同一虚拟礼物，并且要同时全部领取。

但是实物库存不够，主播以“平台不守信用”为理由投诉平台，该怎么办？

办法很多。要么就规定每次只能领取n个（n在试运营阶段确定）；要么发现库存不足的时候，提前发出延迟供应的免责声明；要么就通过客服下线解决（比如兑换同价值商品或现金）。

总之，在这件事上，不把这种场景作为产品设计的考虑对象。即不为其开发对应的产品功能，也不考虑其他办法解决该问题带来的不良的用户体验。

因为根据边际效益，或者说产品定位来说，这种场景下的这号人就是排除项。既不是我们鼓励的现象，也不是能为产品带来价值收益的场景，同时花费精力只能让产品失去重心。

产品经理在对待类似这种情况时，要判断出这是不是我们的目标用户和场景。如果不是，需在方案评审时或者在需求背景描述时候加以解释，并果断转换解决方案。

二、需求的异常项

异常，主要包括目标App本身的异常、手机系统环境引发目标App的异常，和周边平行应用引发目标App的异常。

1. App本身设计的异常

举个例子，电梯中打开App，到达初始页面【首页】，界面显示在加载。我们知道，这是网速问题。

这时候点击【我的】菜单，想看草稿箱。但是发现无法打开【我的】。退出重启，依然如此。

【我的】是本地文件，不依赖网速，却为啥也打不开呢？

其实是因为代码这样定义的：打开App，要做一次初始页面的加载，没加载好，就不会允许其他操作。

这就导致了无需加载的【我的】页面，虽然不依赖网速，但是因为依赖网速的【首页】没完加载，所以“殃及池鱼”，【我的】也打不开了。

因此，作为产品经理，对于这种初次加载App的规制，就要做一个最长加载时间的设置。比如，若2s仍旧加载不出来，则切换到无网情况下的机制展示（无网络情况下可以查看页面）。

2. 外部环境导致的异常

以系统的定位功能为例，正常情况下，若定位系统开启，那么打开App，定位功能就会为App提供当前位置，并展示在页面。

但是若手机定位不开启，那么APP的位置就无法获取。

这时候就需要产品经理考虑，在这种手机GPS异常（系统设置带来的异常）情况下，位置显示什么？比如是显示空、还是图标。

同样，如果手机未联网，或者网络不通畅导致的加载失败 ，就该提示“加载失败，稍后再试”。

如果App检测到断网了，或者网速不好，就该更准确地提示“网络不佳”。

3. 平行应用影响导致的App异常

比如，当手机开启蓝牙，并且被另一个手机连上的时候，就会在手机顶部展示一行状态：1个连接。

这时候实际手机界面被这一行挤压了。

遇到全屏播放的界面，就会出现下图这样：顶部Tab页签下移，视频画面不居中，底部菜单下移。

App是否有考虑过这种情况下的界面兼容呢？如果没考虑，那么就会出现这一合理场景下的异常bug。

又比如，一个语音聊天应用，当按住home键切出去的时候、来电话的时候、当用户执行其他应用的时候等，该怎么规定呢？

作为产品经理，抛砖引玉一个方案例子：

a.【语音聊天】时 home键切出来，不影响聊的功能。

b.【语音聊天】时 不管是否切出去，若来电话（电话未挂断的情况下） 则双方屏蔽语音，但不挂断。同时给对方toast提示：对方忙碌，马上就好！

c.语音聊天时 切出去，看视频、听歌曲、打开其他应用（如微信）进行视频等，都不影响语音聊天。（是否影响到效果，玩家自行处理）。

三、默认值设置1. 默认头像

这就像是统一制服一样，不能因为这个孩子没准备衣服你就让他裸着出场。所以要确定一个这样的图。

这个头像可以是灰色底图，比如花椒的就是。也可以定制带产品元素的，比如映客的。

2. 默认昵称

好处就是万一用户懒得写，也不至于空荡荡的。

产品经理设计一个昵称库，随机给用户分配昵称，有时候还有意想不到的惊喜感。

个性签名也是同样的道理。

3. 默认提示

在无数据的页面，比如【好友列表】，如果不告诉用户这里确实没数据的话，用户可能会怀疑是不是App故障导致的呢。

所以产品经理一般都会给予一个默认的全局通用的提示，比如“暂时无数据哦”。

4. 默认封面

比如相册， 在网速不好的时候，加载不出来，那么怎么办呢？黑洞洞的不好看，所以也需要产品经理确认一个默认的封面或者数据背景图。

这样大家一看就明白了，哦，是没加载出来啊。

5. 其他默认项

默认项总体上就是通用规范范畴的。远不止列举的这几项。产品经理应事先就做全局设计，确保默认项一致、通用，且不遗漏。

总结

一个产品可以拆解梳理出一份PRD；但是反过来，提供这份PRD给开发，却往往不能逆向地输出同一个产品（假设UI一样）。

这就是bug的诞生，和测试的必要性。

因此在确认PRD的时候，就像素描，不仅要高光区，还需要阴影区。

产品经理在说完正向的要什么之后，还要说清楚不要什么、异常情况下怎么办，以及默认怎么办。只有将细节说完备，才有可能让需求完整落地。