本文档只讨论一件事情，如何才能写好PRD文档
PRD文档是产品每天工作中必须撰写的文档，能够写出好文档成为一个PM的基本技能要求。然而，写好PRD并不容易。
不但很多刚入门的产品经理很难写出专业且质量高的PRD，如果你让从业多年的资深产品经理亲手撰写，也难免会出现小到功能疏漏定义不全，大到逻辑与已有功能相矛盾的情况。
你是否遇到过以下情况？
状况1: 同一功能经过多次迭代，现状如何只能查代码，为什么这样设计没人说得清只能推翻重新思考
王同学是从业多年经验丰富的产品经理，接受某条产品线后，某次迭代需求需要调整一个相关的老的功能模块。然而这个模块的具体逻辑没有人说的清楚，使用关键词查找历史文档找到10多篇，信息支离破碎，无从整理。好不容易让研发大大耗费2-3天查代码把逻辑搞清楚了，却不知道当时为什么这么设计，产品设计陷入僵局。前任产品也很委屈，我写的很清楚呀，只是你找不到。文档当时总监也Review了，没毛病。
原因分析：历史文档版本管理混乱，查找麻烦。
解决方案：产品经理需要按照功能模块来持续修改文档。至于多文档中同一个功能模块更新繁琐，维护成本增高的问题。
你是否遇到过以下情况？
状况2：产品经理写的PRD总是漏掉细节
总监和团队Leader一遍遍指出遗漏点，但好像这些点永远也改不完。最终研发做出来一堆问题，回顾甩锅大会上，产品只能认栽，承诺下次写的更细致一些。但是，当事产品经理也很委屈，我就差亲手写代码了，到底还要怎么详细呢？
原因分析：缺乏系统的撰写框架，琐碎的点过多，复杂的系统设计中难免漏掉重要细节。
解决方案：每次撰写一个组件、一个页面、一个功能，都需要定义好框架和结构。下次再引用的时候就可以站在巨人的肩膀上，有效提醒撰写者避免遗漏。框架如何构建？
你是否遇到过以下情况？
状况3：同组内同样的功能大家反复思考，反复造轮子。
明明是同一个产品，各个功能模块内部各自为政，差异越来越大。当事产品表示，别人做了什么，怎么设计的，我哪知道，总不能天天把所有人写的PRD都读一遍吧。
原因分析：相似的功能没有抽象出来，也就更不用说能否检索的问题了。
解决方案：做过的组件要抽象出来单独放在一个组件库，整个团队都可以共享这个库中的资源。当然，如果有一天产品经理离职了，这些资产被抽象出来，理应可以被其他产品继续复用。
你是否遇到过以下情况？
状况4：原来投影技巧也需要培训，很多产品真的控制不好文档和原型的互动
产品经理召集了一大票研发、测试同学坐在会议室里面讲解需求（评审），但一会儿看文档，一会儿看原型，原型窗口大小又很难控制，没几分钟就把研发测试都将晕了。文档的逻辑和原型对应不上，原型比例一会儿太大，一会儿太小，大量时间被浪费。
原因分析：原型中的各个部分应该与PRD中的对应描述相对应，预设好对应关系，会上才能从容自如。
解决方案：焦点移动到文档的指定的位置后，原型部分会按照预设自动调整位置和缩放。
