对PRD的一些思考与理解
PRD是什么
PRD，也就是产品需求文档 ，是用于在项目开发过程中，由产品撰写，开发阅读，辅助项目高效开发完成的书面交流工具。
PRD没有固定的撰写形式，但是作用却非常大，大概体现在几个方面
1.梳理思路，从文档的撰写过程中，能够全面地对功能/产品进行思考
2.结合产品原型，梳理产品细节，避免遗漏一些细微却又比较重要的点
3.清晰易读的文档，可以很大程度上降低与开发的交流成本，有条理的文档，有时候其实就是开发自己敲代码的过程
4.功能的记录，无论是不论多久都能根据文档清晰回忆起规则，还是方便工作的交接，PRD的存在都是必不可少的
PRD很重要吗
在我看来，PRD仅仅是开发的辅助工具（游戏另说），一个功能能否保证顺利无误按照产品的想法开发完成，最核心的两个条件，第一个是产品自身对功能的思考，是否全面，细节是否到位，有没有对功能仔细进行过评估，有没有想过更好的方案等等，这些条件会决定在开发过程中是否存在改需求或者返工的情况；第二个是与开发之间的交流，功能成型后，能否带着开发与美术完整的过一遍需求，让所有参与开发的人充分理解功能点，只有充分理解并认同，才能减少返工的可能，这时候就十分考验自己对功能的理解是否深刻，如果不深刻，在交流过程中可能自己就会发现很多问题。 当产品自己想清楚了，也交流到位了，这时候才需要PRD
PRD应该写什么
每次写PRD就会想起带我入门的领导，给我讲文档结构，给我讲为什么要这么写，给我讲文字的表达怎么更合理，给我讲怎么在文档中梳理自己的思路，受益匪浅。
现在我写文档，会结合以前学习到的和实际工作中的情况来写，基本包括这些
1.设计目的，写清楚这个功能主要是用来做什么的，比如我要写一份会员的文档，我会把我做会员的目的是什么写在第一项，不仅有助于自己的思路，也有助于别人阅读时，更快理解你的目的
2.文档的关键点，比如会员的文档，我需要在最开始就写清楚：服务内容、定价策略、已购买状态、使用反馈、提醒内容等，写清楚了这些内容，也就梳理了清楚了自己的思路
3.具体的规则，包括每项功能具体的逻辑，主要是后端逻辑
4.特殊界面的跳转规则，之前做游戏策划，写文档很不注重这一点，所以经常会出现一些沟通上的失误。APP有时候后端逻辑并没有多复杂，更多的反而是界面之间的跳转，主要的跳转展示还是要做在原型图里，但是有一些很重要的前端逻辑还是要很清晰地记录在文档中，比如打开APP默认页展示哪一页这些内容，不通过文档记录的话，还是很难避免不出现沟通失误
怎么提高PRD的使用效率
1.保证所有规则的完善
2.保证有改动时，能够及时更新文档，并且对开发人员通知到位
3.闲暇时多返回来看文档，我记性非常不好，所以工作过程中很需要对文档进行回顾以保证能熟记每个规则（目前做的不够）
4.使用更高效的写作软件，之前用的excel，很方便，就像一张无限大的纸，做APP后依然使用excel，发现并不利于阅读，并且非游戏行业的开发可能对excel类型的文档并不习惯，所有最近开始使用markdown软件来撰写，结合git，更新更加方便，开发阅读也不需要再反复下载文档，可以达到“在线看”的效果
犯过的错
在做产品后，在撰写文档方面犯过很多错，很多错误直接导致了文档写到一半发现写不下去，或者经常跟开发理解出现误差，也经常出现缺少东西，需要开发来进行提醒的地方，比如
1.没有思考清楚功能，所以没有思考清楚产品逻辑与关键点
2.文档不注重更新，当两个月后返回来看文档的时候，发现文档与线上功能有出入，此时很难再回想起来具体什么才是正确的规则
3.撰写文档时分心，分心最大的坏处就是遗漏，一分心就会想不起来某些比较重要的细节
4.缺少文档，有些小的功能点，不足以形成一份完整文档的，没有形成一个零散需求合集的文档，
5.文档出现错别字，出现错别字经常会导致阅读体验变差，甚至会出现功能跟自己想的不一样的情况
6.不喜欢回头看自己的文档，这种情况一般是自己写的文档是在太垃圾了，再垃圾也要对自己的文档进行多次反复查看与修改
总而言之文档是一个产品的基本功，承载了产品对所设计功能的完整思考，而且是整个项目开发的书面规则依据，是项目中走在最前面也最不可缺少的东西。提升文档能力，也是在提升产品能力
