产品经理整理 PRD 时，需要注意哪些点 本文作者将结合自身经验与你分享，在整理PRD时，产品经理需要注意的几方面。enjoy~ PRD，产品需求文档。世界上没有两片相同的树叶，也没有不做修改的需求文档，需求文 档不是在去修改的路上就是正在修改ing，开发看到我这言论估计会干死我，其实大家没 有必要总是想着一版搞定需求文档，那基本是不可能的，开发也会写出bug，测试也会遗 漏用例。 为什么产品的需求文档就不能有错误呢？ 之所以需求文档的修改会引起开发和测试的极大反感，主要是产品经理的需求文档处在一 个产品开发的源头，一开始源头就出现了问题，后面的流程能顺利实现目标吗？可想而知 源头出现了错误，会对后面加班工作的开发兄弟造成多大的打击。所以，作为产品经理的 我们必须尽可能地将PRD整理的详细易懂，不要遗漏，不要误解，不用意淫。 前段时间同样是在人人都是产品经理社区上看到一篇关于如何撰写PRD的文章，写的很好 但是个人觉得还不是很全面，以下PRD写作要点都是个人躺过的坑，被开发被测试屌过的 路，希望可以给大家一个参考，帮助大家更好的完成产品需求文档，不免有遗漏，大家可 以留言补充。 一、需求点的基本描述维度 角色 往往一个按钮一个界面，不同的角色所能进行的操作，所能看到的内容都不尽相同。 例如一个组团参加活动的需求，其中角色可分为队长、成员、非团队成员、组织者，队长 可以做什么？队长在界面上可以看到什么？成员又可以做什么？成员又可以看到什么…… 这些都需要界限清楚，这是一个需求点的“定位”，“定位”偏了，也许后面写了乌压压 的一片，到头来全白搭。 二、需求中常见但又容易遗漏、描述不全的 9大类型需求 点 1、退出机制 退出分为4类：退出登录、退至后台运行、杀死程序、关机；特别是数据型的产品，当发 生这 4类退出时分别对应的数据同步、数据中断都该如何进行，你可以简单处理一视同仁， 但是必须了解有这几类，不认测试问起就懵逼了。 2、显示机制 显示其实可以按照正常/异常来分类，也可以按照静态/动态来分类；我这里按照静态和动 态进行分类，一个界面或一个按钮的展示必须从两方面来描述，静态：展示形态、内容、 格式、数量等，动态：初始状态的展示、触发时的状态的展示、触发后的状态的展示、触 发成功/失败的展示等。 例如微信底部的四个按钮，分为两种静态显示：选中时填充色为绿色，未选中时无填充色； 但是介于选中和未被选中之间是什么颜色呢？这个可以定义为一个过程色，我们可以在微 信一级界面左右滑动页面观察底部按钮的变化，当即将被选中时，按钮是从轮廓慢慢变绿 并且绿色逐渐加深，然后是慢慢填充绿色；当即将被取消选中时，则按钮颜色变化正好相 反。 3、排序机制 凡是涉及到列表、记录的均需要考虑排序，不管是按照生成时间倒序还是正序，至少需要 确定一个顺序，而不是让开发进行到这个页面时再来问你，你这个时候其实就是失去了主 动权，因为是你的遗漏，另外在仓促之下做出的决定很容易导致体验不好或者其他考虑不 周的问题。 4、刷新机制 如果页面展示的内容是随着时间不断变化的，则必然要考虑到刷新，其中刷新就涉及到一 般的刷新前，刷新后，刷新中的展示了，也会有异常刷新失败的考虑，另外也需要考虑是 自动刷新还是手动刷新。 5、加载机制 其实加载机制和刷新机制经常在一块，有刷新一般会有加载。 6、缓存机制 有人觉得像这种偏点技术的需求应该由开发来决定，这里就不做争论了，但是作为一个产 品也必须了解，为什么要做缓存？做缓存会带来什么影响？做缓存大多时候是为了让用户 体验更流畅，不至于让用户长期停留在一处等待转菊花，如果缓存反而让系统频繁卡机， 这时就得重新考虑考虑了。 （右击在新标签页中打开，即可查看大图） 7、推送机制 目前推送越来越多，主要是想增加用户的