产品经理文档的PRD
1.帮助团队归档产品信息。
在产品实现过程中，有很多逻辑和算法需求，没有文档记录，容易在团队变动和转移时造成很大的风险。通过产品需求文档记录产品的各种需求和实现方法，可以有效降低团队的风险，提高交接效率。
2.提高内部信息沟通的效率。
需求虽然可以口述，但不代表所有员工都能一下子记住，遇到不清楚的开发、设计或测试，可以直接查文档。结构清晰、表达清晰的文档仍然具有不可替代的作用。
3.产品工作是有据可查的。
当各方对需求的理解不同，或者推迟产品工作时，通过产品需求文档可以有效地找到问题的根源。
R&D人员:由于R&D人员本身专注于功能的实现和表现，其表现相对与运营、时长、设计等其他岗位无关。，而且他们从产品经理那里更了解产品。
设计师:设计师本身更注重产品的表达和原型，所以对PRD的需求相对较弱。
还有老板，项目经理，运营，市场，客户，财务...
所以，PRD文档，根据阅读对象，可以用最直白的文字，把产品描述清楚。
文本模式:Word。对于时间充足或者岗位责任制明确、文档要求规范的团队，建议选择Word来写文档。
原型图模式:Axure。对于追求时间效率和灵活性的团队，建议选择Axure来写文档，原型配产品描述。只用一个文件，不用切换，方便快捷。
无论哪种方式，都差不多，本质上不影响PRD文件的使用效果。
1.修订记录:版本号、修订日期、修订章节、修订内容、修订人等。
版本号描述，以1.25为例:
版本号(1 .25):重大调整升级，一般是产品结构和功能预定。
颠覆数(1。2 5):局部功能在原有基础上进行了升级或调整。
修订号(1.2 5):局部小范围优化和Bug修复一般都是不动功能的东西。
版本号的命名规则:
归零原则:前面的数加一位，后面的数全部归零。
修订记录的作用:
修改前后比较
有利于珠三角的维护和管理
记录修订人和修订日期。
方便查询，只需查看修改的部分，就能快速找到修改的地方。
2.术语:对一些产品中难以理解、容易混淆或缩写的词语进行统一列表，有助于阅读。
全局描述包括:权限描述、授权描述、异常情况、键盘描述等。
权限描述:划分角色权限，比如登录和注销状态下可以访问的功能权限。
授权描述:手机号码授权、地理位置授权、相册授权等。
异常情况:加载失败、网络异常等。
键盘说明:数字键盘，字母键盘。
......
1.产品结构:包括产品功能结构图和信息结构图。
2.业务流程图:产品经理设计的用户行为，通过用户行为连接信息结构和产品结构，可以更好的理解。
3.功能列表:该列表包括功能模块、功能点和功能描述。
4.功能细节:原型设计、功能描述和用例。
功能细节可以按照功能逻辑或者产品结构的顺序来表达，看个人习惯和团队需求。
用例:用例图和用例描述。用例图描述了系统外部参与者与系统之间的关系，是由参与者和用例组成的示意图。
注意:
在写之前，要保证思路到位，产品结构本身短期内不会有大的变化。这样，即使交付后，需要调整或优化的地方，也不会出现重新配置的情况。
文件用词一致，同一件事的表述要一致，避免混用。
非功能需求是对产品非功能需求的描述，包括性能需求、技术组件需求、安全需求、可用性需求、质量需求等。
性能要求:系统满足多用户同时工作的需求，保证5000人同时在线，1000人并发。
技术组件要求:数据存储和计算使用环大数据平台等。
安全需求:对于外部网络环境，需要保证数据网络架构中的数据传输安全，并具有良好的跨平台部署能力。
可用性要求:系统支持IE11和向后兼容，支持Chrome等主流浏览器。
质量规格......
以上文档结构只是PRD的基础结构，并没有成为可以应用的固定的东西。文章只是一种分享思路的方式，要根据你所在公司和团队的习惯，以及目标的达成情况进行调整。不要生搬硬套。
阅读原文
对产品经理感兴趣的朋友可以转战《行业与市场分析》，期待共同交流。