不是PRD一完成就万事大吉了，还是经常会出现需求想不全的情况。这个需求想不全有两重意思，第一个是只考虑到了需求的正常流程，忽略了需求的边界和异常部分。第二个是只考虑需求的当前版本，或者是当前设备的使用正常，却忽略了需求的上下文环境，比如说应用是跟以前的旧应用同时安装呢，还是在不同的设备上使用？
我们来看几种容易被忽略的边界：
第一张图中，这个创建下载任务的时候出现空间不足，这个就要事先提示用户，暂停任务的下载，保留已经下载的部分，让用户清理磁盘之后能够继续进行下载。下面的已完成的文件被移除之后就不再提供打开按钮，而是支持重新下载。
第二张图中，在没有读取到用户健身相关数据，或者是一个全新的用户没有数据的情况下，这些显示着用户的步数、健身时长的数据位置就要留有占位字符，避免有数据的时候，这些数据突然突兀的出现。
第三张图中，应用的UI上需要考虑不同的系统不同的语言环境。比如这个英文环境下显示是不是正常，超长的部分是不是要做截断的处理。
当然还有很多很多的边界场景。归纳下来通常需要考虑这么几个方面：
1、入口和流程
入口的就是启动应用或功能的入口，从桌面启动还是从通知栏启动？从你自身的应用上启动，还是被第三方应用拉起来？需要遍历所有可能的入口。
确定好入口之后就开始遍历入口执行的每一个流程。流程就是指按某个入口执行一系列步骤，实现某个功能的分解动作，包括成功的情况、各种失败的情况。失败的情里面况就包含了各种边界，比如你在描述一个购买失败的情况的时候，失败的边界可能就有余额不足，有可能是服务器下单失败，也有可能是程序本身就不允许重复购买。
2、场景与扩展
用户使用功能的场景，比如说你是横着拿手机呢，还是竖着拿手机？当你横着拿手机的时候是否需要支持横屏？如果你支持横屏的话，需要对字符串，或者是对功能模块进行哪些调整。还有一种情况，用户暂时退出的时候，是不是要持久化你当前的内容，等到用户回来的时候能够继续使用。
还有例子就是用户在电量不足的时候，这个功能能不能用？比如小米有一个应用，就是那个检查真机的应用，就是要求电量达到10%还是20%时候才能够使用。
用户的场景还有一个最重要的就是网络。它当前是wifi还是数据网络？如果是Wifi的话，是需要验证的wifi，还是不需要验证的wifi。通常在数据网络下进行一些消费行为的时候，都是需要给用户提示的，但是在用户提示同时，你需要暂停当前的流量消耗行为。
第二个就是扩展。扩展包括版本扩展，是否兼容新旧版本。比如我们最近就出现一个问题，最近在服务器端下线一个免费赠送用户流量的功能。但是我们就没有考虑到有些旧的版本仍然有获取赠送流量的入口。结果就导致N用户多来请求这个流量却失败情况，就是因为我们在下线的时候，需求没有考虑全面，没有顾及到之前的旧版本仍然存在这样的功能入口。
扩展还有一种就是功能的扩展。你当前要上线的这个版本，是不是要提前支持后续版本的功能？比如说你是否需要预留广告位？是不是要预留后续的字段等等。对于有风险或者需要随时下线的这些功能，是否都做了服务器端的云控？运营功能是否提供了服务器配置开关？运营的这些文案是不是需要在服务器端来控制。
3、设备平台
设备这个很清楚，就是不同的设备，比如PC，Pad，Android，苹果，盒子和路由，电视。不同的设备它的设计规范也不相同。另外还有就是同系列的手机和不同系列的手机它的规范也不尽相同。要支持多种设备就需要进行适配处理。平台呢，通常就是你是PC平台还是移动平台，是安卓系统还是ios系统，英文系统，还是是中文系统？要做到考虑全面的话，需要清楚各个功能大致的实现环节，了解每个平台的特性。比如安卓系统需要考虑物理键，比如你做网站的时候你要去申请域名，你做运营功能的时候需要给运营人员提供后台服务。PC上做一个应用图标，你要准备状态栏图标，桌面图标，加速启动栏的图标等等。还要理解客户端是做哪些功能的，服务端是做哪些功能的。
每次需求完成前检查一下上面描述的3个板块，是不是都考虑到了。
一回生二回熟
需求不是一次性就能考虑全面的，一回生二回熟，不用要求太苛刻。那种非常边缘或者是边界的一些功能，其实是可以暂时忽略的。比如我们在做迅雷移动版下载的时候，就考虑到手机上面用户的下载意识不是很强，下载文件也不是很大，所以我们就先忽略下载大于2G的文件这种边界情况。
本文根据迅雷高级产品经理孙遂意的《做产品经理这5年，我走过的那些坑》整理而成
