新媒易动态
NEWS CENTER
NEWS CENTER
2020-05-12
有人用word写长篇大论，结果开发根本不看，还要问你每个页面怎么跳转。
有人用sketch，不配合专属插件的话，很容易画成没有结构性的页面流程图。而且是否具备普适性，取决于周围与你配合的人。
工具本身没有问题，有问题一定是工具人的问题。
为了让你的PRD的用户使用效果更好，汲取意见是很重要的。有的时候不要埋怨开发为什么不认真看，去问问他们喜欢看什么样的，适当调整达成统一。
Tower、禅道、tapd等团队协同工具，会导致一部分人习惯把产品的结构通过协同工具中的单个需求建立父子关系连接，在每个子需求中上传需求图片+文字描述。
这种方式更适合优化已有功能，功能可以在小范围内实现闭环，但是容易使人忽略细节的调整对全局的影响。
产品经理应该把控Axure源文件的颗粒度，哪些版本/模块在一个源文件里更新，从哪个版本/模块新建文档维护；文档或文件夹之间尽量去重、解耦。在原有文件上新增或调整的部分，更显眼的做出标注，让人可以一眼看出变动的部分。
在Axure里搭建当前版本/模块最完整的产品结构，并且及时更新。要明确一个认知，协同工具是给UI、开发、测试、运营看的，目的是让他们看起来方便，可以针对单个需求设置执行人员、排期、添加bug记录等，核心价值是项目管理。
而不是为了产品经理维护需求文档方便，所以在需求的撰写和管理时，不要依赖协同工具。在追溯需求问题的时候，要能做到在Axure文件里便能找到记录，而不是去翻协同工具里的需求记录。
用两个类比帮助你更好理解我要表达的观点：
在项目流程中撰写PRD，和在产品设计中设计首页、在工作经历中梳理简历的感觉类似。它们都不是独立存在的，都与之前的各个环节有着千丝万缕的联系。
诚然后者需要技巧，但是如果不是建立在前者价值的基础上，将言之无物无的放矢。所以梳理PRD怎么写，无法脱离于项目流程单独思考，需要带入流程。
再来看这张图：
项目的流程大同小异，在做好需求评审前的各个环节之后，你自然会积累从抽象逐渐到具体的一系列文档内容。此时将它们进行整理，做汇总提炼，补充颗粒度更细的内容即可。
一顺百顺一损俱损。从项目的维度拆解PRD的组成后，可以发现，前面的每一个环节做的越完善，在撰写PRD的时候越能降本增效。
在撰写PRD出现问题时，也可以追本溯源根据内容部分找到对应的环节，定位问题从而找到解决方案。
所以PRD到底怎么写，如果你把问题定位在“怎么写PRD”这个颗粒度，你能找到的大部分内容大致是一下3种：
多看第三种，更有可能通过结论找到思考路径。
但是这些都是被动的做法，你只能去碰，找到能给你启发适合你应用的内容的概率。
主动的做法是，拆解→定位→聚焦
为了实操性，我不会放一个看起来高大上的需求文档模板，面面俱到，导致参照的时候要素过多无法聚焦。
以下的内容可能存在争议，重点是你要独立思考，想想什么样的才是最适合你的。
我写这些的适用场景不是你兴致勃勃的想要学习提升，而是：
如果把它当成职场向内容看，可能违和感会小一些。
产品规划和PRD的撰写，都要知道哪些部分承载核心价值，不要妄图通过堆积功能/内容来增加满足用户的可能性。
（1）必备内容
这里的必备内容已经是降低过要求的，是real必备，有了这些内容才能起码确保你思考的足够完善，表达的足够清晰。
a. 业务流程
通过流程图展示，泳道图也是流程图的一种，更加强调分工，比普通流程图多了一个划分维度。根据描述角度的侧重，这个维度可以是角色（患者/医生）or终端（用户端/医生端/管理后台）or场景（就诊前/就诊中/就诊后）。
业务流程至少要说明的内容：
b. 角色说明
角色名称、角色定义、角色权限（数据权限、操作权限）。
如果产品的业务属性没有那么强，角色比较单一，至少要说明游客和注册用户的权限区分。
在相关功能设计时，注意区分不同权限的对应状态样式，无权限的分支流程。
简单权限划分：
复杂权限划分：
如果功能权限颗粒度过细，比如常见的后台产品，在角色说明表格之外要做更多补充。
此类场景下权限管理有必要做为一个功能模块来规划，划分好功能权限，预设角色（用户分组），明确角色定义，配置好角色对应的权限模板。
c. 功能流程
功能流程表达的是，业务流程中的内容，是如何通过人机交互实现的。
根据具体功能划分适合的颗粒度，标准是解耦、形成闭环。
如果分支流程比较复杂，可以在对应位置标注，再把闭环的分支流程作为一个单独的功能流程图展示。如：注册/登录流程，可以根据独立闭环的子功能划分为：登录、注册、找回密码等，通过三个流程图展示。
注意不要把产品结构和功能流程混在一起。一个功能流程中只完成一个任务，有两种结果：成功or失败。
常用的元素只有四种：
d. 原型+功能详述
一份交互自查表，搞定一切，整体＆流程：
内容＆状态＆显示：
反馈＆通知：
文本＆控件：
常见类型：
绘制原型＆添加注释的过程，是想好再动手；越简单的逻辑或越快速的思考可以使想和做的节点趋于一致，甚至手跟不上脑子。抽丝剥茧厘清逻辑条理清晰的记录下来，是很有快感的事情。
交互自查表里的内容相对全面，根据你的使用习惯和不同控件的侧重点来进行思考和注释。比如列表，重点注释列表的（筛选）初始状态，排序规则，列表项组成及数据来源。
如果数据来源有需要用户自定义编辑的部分，则要权衡编辑的规则（如极限值）和列表中的展示规则（如极限值）。比如表单，重点是区分初始、浏览、编辑等状态；编辑状态下的引导、校验、提醒，中途退出的数据是否缓存。
要考虑数据流转对其他流程的影响，业务思维影响产品设计，产品设计影响交互规则。如个人资料提交之后不涉及其他业务流程，则提交后立即生效，并且可以反复修改。如认证资料提交后需要专门人员进行审核，审核结果的不同导致后续流程不同。则提交后不会立即生效（这时需要提供更多的进度提醒让用户安心），可根据业务特性和审核人力成本来权衡修改限制。
这是一个先乘后除、先加后减的过程。写得够多以后，你自然会找到一个自己更舒服而且团队更接受的方式。
至于你要用标注点、要连线、还是建立表格来写这些东西，不重要；重要的是统一、清晰。
（2）常见内容
常见内容是意思的在PRD里展示出这部分，会使PRD更加完善。如果没有这些内容，也不会直接影响到项目进展；但是不代表产品经理可以不思考不输出这些内容。
这些内容就算在PRD里没有展示，也要确保已经思考清楚并且在其他地方有所记录。
a. 需求分析：需求背景＆需求价值
在PRD之外，可以通过需求模板、需求池等方式记录。
PRD的用户是UI、开发、测试、运营等团队成员，有的人对产品有自己的思考乐于讨论，想要在执行之外获得成就感；有的人不想参与讨论，只想直接知道结论，知道需要执行什么内容。根据你的用户特点，来决定这部分内容沟通的深度。
需求评审时绝大部分时候要说，但是并不绝对。如果有人想知道，一定要解释清楚。
避免信息差，划分客观事实和基于对客观事实的调研观察得出的主观结论。
双方的沟通要在信息同步的前提上，不要在评审人员提出质疑的时候才抛出一个他不知道的客观信息来反驳。表达的越全面越能帮助评审人员发现问题引起讨论，降低评审人员的思考门槛，进行引导。无论需求大小，就算只是调整一个简单交互，表单里加一个字段，都有与之对应的需求背景＆需求分析。
如果被质疑的时候，你只能说出“老板要这么做”的话，说明你在需求调研和需求分析阶段偷了懒，没有负起责任，这也容易因为对需求理解不到位造成返工。做功能只是手段、不是目的。
想想销售对你说“客户就要这样的”时候你心里的万马奔腾，不要只做一个传话的人，不要变成自己讨厌的人。
b. 版本记录和修订日志