189 8069 5689
【文章摘要】写PRD是一个技术活，也是一个细心活。PRD的主要阅览用户就是开发工程师，为了能够和开放人员进行高效的沟通，一份优秀的PRD文档应该满足的基本要求包括：完整、准确、清晰、简洁和稳定。其中”完整”便是指考虑周全没有遗漏。完整的功能描述和用例，不但可以方便开发工程师快速了解完整的功能需求，同时也为产品上线前的产品测试提供必要的参考。
最近Mr汤进er在学习PRD的写作。直接的感触就是：写PRD是一个技术活，也是一个细心活。PRD的主要阅览用户就是开发工程师，为了能够和开放人员进行高效的沟通，一份优秀的PRD文档应该满足的基本要求包括：完整、准确、清晰、简洁和稳定。其中”完整”便是指考虑周全没有遗漏。完整的功能描述和用例，不但可以方便开发工程师快速了解完整的功能需求，同时也为产品上线前的产品测试提供必要的参考。完整的产品功能描述主要包括两方面：功能点无遗漏和功能描述完整。
为了方便自己项目中进行相关功能点及其描述自查，Mr汤进er整理了一套针对应用开发的产品功能点及其描述自查清单。个人感觉，这个自查清单对于四类人群都是有帮助的：
1、产品经理：可以通过产品功能描述自查清单来系统的梳理产品功能点和描述，PRD可以帮助产品经理更加透彻和完整的梳理产品，同时，产品经理可以通过PRD和其他人员进行高效的沟通。
2、交互设计师：可以通过功能点及其描述自查来检查自己的交互稿是否遗漏特殊情况、异常情况、极限情况等等
3、开发工程师：可以通过功能点及其描述自查清单来检查自己的程序开发是否符合PRD中的相关要求。
4、测试工程师：可以将PRD中的功能描述和用例转化为测试用例的一部分，进行产品可用性测试。
二、原则在整理自查清单之前，我自己先梳理了几条自查原则或者叫做逻辑(建议在自查前先用Xmind等软件梳理下自查逻辑 )：
1、先总体，再细分：如果拿一棵大树举例，应该是按照树干→树枝→树叶的顺序去检查产品功能点，可以结合产品功能架构图来进行主要功能点的检查，在主要功能点完整的基础之上，再深入到主要功能点下的细节功能进行自查。
2、有顺序，依次检查：这个和撰写PRD中的功能点和描述是一致的，可以依据PRD功能描述撰写的标准综合运用以下顺序进行自查：
1)产品功能点需求：用户需求→后台需求(数据监控等)
2)功能在系统中的位置：前台界面→用户管理后台(个人中心)→官方管理后台;
3)业务流程：步骤1→步骤2→步骤3→步骤3.1→步骤3.2……
4)功能主次关系：主要功能(场景or流程)→次要功能(场景or流程);
5)功能点在页面布局中的位置：从上→下、从左→右;
6)按照软件状态：基本状态→特殊状态→异常状态;
3、随时关注，及时更新：很多遗漏的点不是自查一遍就可以检查出来的，说不定某个时间，就突然想起了某一个功能点的遗漏。同时PRD作为交流沟通的工具之一，需要跟进交流的结果，因此我们要随时关注，并做到及时更新。但别忘了PRD的稳定性哦，最好在正式交付其他人员时，完成功能点及其描述的梳理。
三、自查清单Mr汤进er自己先用Xmind绘制了一张清单导图，详细清单列表见下方
PRD中产品功能点及其描述自查清单，绘制@Mr汤进er
1 用户体验自查：
这部分主要注意自查功能框架、业务流程和用户界面布局(如菜单、对话框、窗口和其它可规控件)以及页面内容描述等等是否完整。
1.1 流程和页面布局
1.1.1 基本状态：
1)功能框架和流程的功能点是否完整?特别是注意流程中的主导航常驻or页面返回，是否是从哪来回哪去?不要出现一个页面点击某个BUTTON不知道去哪的问题!可以请交互设计师协同自查;
2)流程描述是否完整?这部分也可以请交互设计师协调完成，比如A→B页面跳转是否描述完整(包括交互触发方式：单击or长按or滑动;触发区域：整条Button or Button的某个区域;触发前中后状态：加载时间、动效、中间状态等等);再比如是否有不可点击的效果，如：你的按钮此时处于不可用状态，那么一定要灰掉，或者拿掉按钮，否则会给用户误导;
3)页面布局是否完整?比如页面标题栏、导航栏等否缺失?页面反馈(弹窗or加载状态进度提示等)是否缺失;
1.1.2 特殊和异常状态：
1)特殊流程是否缺失?比如登陆流程中是否缺失忘记登陆密码的流程;启动页和用户引导页等;
2)页面布局是否考虑横竖屏问题?
3)页面布局是否考虑不同屏幕尺寸自适应问题?
4)不同模式下页面情况说明：夜间模式?编辑模式?无图模式?等
1.2 内容自查
1.2.1 基本状态：
1)描述内容是静态or动态数据调用?如静态的标题title，动态的文本内容调用等;
2)内容描述是否完整?顶部标题、按钮里的文字等;文本是否错误等;
3)内容加载方式描述是否完整?本地缓存or刷新加载网络新内容等;
4)输入框内容描述是否完整?是否有初始内容?输入后是否有联系功能(比如搜索);
1.2.2 特殊和异常状态：
考虑等价、边界、负面、异常或非法等情况
1)数据内容为空如何处理?是否支持离线功能?是否有空数据界面设计，引导用户去执行操作;
2)内容长度是否有限制?比如内容展示是否限制字数，点击查看更多?昵称描述不得超出多少字?密码不得低于多少字符等等;
3)内容违禁如何处理?敏感词、违禁内容(如：涉及版权、专利、隐私等图片)等如何处理;
4)数据内容过期or删除or违禁后如何展示?比如某内容发布后因为违禁被编辑删除，那么用户再次点击后怎么展示等;
5)用户内容输入是否描述完整?比如输入框输入空格、特殊字符如何处理?用户输入是否保留历史记录?等等;
2 账号状态及用户权限自查
用户注册和账号管理功能都会涉及到用户不同登陆状态(登陆、非登陆、账号异常、账号被冻结等)和用户等级和权限(会员和非会员、付费和非付费用户等)，因此要说明清楚不同账号状态及用户权限下显示的内容和功能。
2.1.1 基本状态：
1)不同账号状态说明：登陆状态、非登陆状态不同情况是否说明完整?
2)不同用户等级和权限说明：不同等级用户有哪些权限?在页面展示上有什么不同?
3)不同账号状态切换时是否有特殊展示?
2.1.2 特殊和异常状态：
1)是否说明清楚一个账号多终端登陆问题?是否允许多终端登陆同一账号?一般根据MTOP的现有规则，一个帐户只允许登录一台机器。检查一个帐户登录多台手机时，原手机里的用户需要被踢出，是否给予用户友好提示?
2)是否考虑了多账号切换问题?是否保留历史账号?
3)是否支持第三方账号登陆?登陆后如何绑定自有账号?
3 硬件环境需求自查：
不同的终端水平涉及到包括硬件特性、网络状态等情况，需要在PRD中考虑清晰。
3.1 硬件特性需求说明
1)横竖屏是否需要锁屏?
2)不同分辨率是否要适配?如何适配?
3)是否调用手机物理按键?什么情况下调用?如何调用?
4)SD卡问题，文件导入本地时，没有SD卡、SD卡储存已满、储存位置等情况是否考虑并备注?
3.2 网络状态说明
1) 无网络时，显示什么内容?执行需要网络的操作，是否给予用户友好提示?
2) 在网络信号不好时，有无超时限制?是否说明了如何给予用户反馈?是否引导用户执行其他操作或退出?
3)缓存问题如何处理?什么情况下调用缓存?
3.3 服务器宕机或出现404、502等情况说明
后台服务牵涉到DNS、空间服务商的情况下会影响其稳定性，如：当出现域名解析故障时，你对后台API的请求很可能就会出现404错误，抛出异常。如何处理这些异常?
4 后台交互及管理需求自查
后台交互和管理需求涉及到消息推送、数据更新方式、软件权限和后台监管等方面的需求。
4.1 PUSH消息说明
是否说明必要的push消息业务规则?什么情况需要push消息?push什么内容等等
4.2 数据更新说明
1)需要说明哪些地方需要用户手动刷新?哪些地方需要自动刷新?哪些地方是手动+自动刷新?
2) 说明哪些地方从后台切换回前台时需要进行数据更新?
3) 需要说明哪些内容需要实时更新，哪些需要定时更新?
4) 说明数据展示部分的处理逻辑，是每次从服务端请求，还是有缓存到本地?
4.3 软件权限及安全性：
1)软件权限说明是否完整?什么功能，在什么情况下，需要调用什么样的权限?位置or通讯录or联网or照片等等
2)数据安全性说明是否完整?输人的密码将不以明文形式进行显示，备份应该加密, 恢复数据应考虑恢复过程的异常通讯中断等
3)交叉事件安全性说明是否完整?在运行其软件过程中, 如果有来电、SMS、EMS、MMS、蓝牙、红外等通讯或充电时, 是否能暂停程序，优先处理通信, 并在处理完毕后能正常恢复软件, 继续其原来的功能
4.4 后台数据监控及管理需求：
1)后台有哪些数据检测点?需要监控哪些数据?
2)后台有哪些功能点，为前端提供哪些数据内容?敏感词、违禁内容如何屏蔽?等等
3)如何进行内容推荐和排序等等
四、结语PRD写作是一个细心的活，确保内容描述的完整性，有利于产品经理自己梳理产品本身，同时也有利于团队合作与沟通。产品功能点及其描述自查是为了保证内容描述的完整性。当然Mr汤进er整理的这套自查清单肯定是不够完整的，也不是普适的。重要的是，大家需要有这样的意识、细心和一定的标准去做自查。虽然看似增加了工作量，但Mr汤进er认为，事实上这样会大大减少时间成本，特别是在大团队多人或异地协调工作的情况下。欢迎大家针对“PRD”与@Mr汤进er交流讨论(微信公共号：chuangshe_space，个人博客：www.tangjinweb.com,知乎or简书or微博：@Mr汤进er)，共同进步。
本文为原创，允许转载，但请注明作者信息和出处：
作者：Mr汤进er , 微信公共号“创设空间”：chuangshe_space