麦子学院 2017-03-12 23:19
撰写PRD的7大注意事项
回复:0 查看:2276
突发事件
昨天编辑了一篇纯逻辑修改的文档，交付开发后，开发方向偏离，后台大量订单数据出错出错。
我立马叫停开发人员，交流之后，发现开发人员错误理解了PRD
文档。开发人员在阅读文档的时候直接看掉了两个字。
后来我自己回去阅读的时候也看错了，说明我文档是不易读。所以一方面叫开发人员停下来修复数据出错的地方，一方面重新整理文档。
下面我就介绍一下我在梳理文档过程中发现的几个坑。
第一坑——名词交流混乱
这是昨天文档中最大的问题，因为后台是管理订单的，所以会有大量的时间结点，但是目前只有两个时间结点有自己的专属名字。其他的时间结点的叫法都是今天一个样，明天一个样。
所以我在写文档的时候就按照自己的叫发来写文档，其中就有一系列相似名称的时间结点叫做“
服务时间
”
、
“
次服务时间
”
、
“
官方服务时间
”
，技术同学在开发的时候，直接把
“
官方服务时间
”
的
“
官方
”
二字看掉了。
看错后就直接对“
服务时间
”
的先关内容进行大刀阔斧的修改，所以就导致后台订单数据错乱。于是乎经过交流，终于重新定名
“
服务时间
”
、
“
订单时间
”
、
“
官方时间
”
。
关键词命名的注意点：
1.
整个团队要将关键词进行统一，最好创建规范性名词解释列表；
2.
关键词命名时，同一个模块、流程中的词语里边相同字的使用不要超过
50%
；
3.
还有产品设计各个环节中，关键词的一致性，也是需要注意的。
第二坑——专业名称重复出现
昨天在写文档的时候，为了使每一个名词都能精确的定位到每个点上，所以每一个名词都使用专业名称来表示，全篇PRD
专业名称横飞。由于昨天写的文档是属于纯逻辑性的文档，所以大量在专业名称充斥的情况下，整篇文章的可读性极差。
专业名称使用注意：
1.
同一句话中，能使用代词来代指句子中的专业名称的时候，尽量使用代词表示，因为代词更口语化，也更容易让人理解。
2.
如果使用代词会让整句话产生歧义，那就一定不要使用代词；
3.
使用代词可以增加可读性，使用专业名称可以增加准确性，所以只有在恰到好处的地方进行敲到好处的表达，才能把文档的易读性和准确性最大化。
第三坑——行文逻辑不清晰
在写开发文档的时候，凭着直觉来写文档，在写之前并没有梳理清楚其中的逻辑，以至于最后写出来地文档逻辑混乱，各个板块互相穿插。
在撰写文档前，首先自己要清楚整个功能的流程，这个肯定是毋庸置疑的。但是，我们在写文档的时候，可能就没有这么在意行文的逻辑，全凭自觉来撰写。
所以在写文档的时候，不仅仅需要理清整个产品、功能的逻辑，还需要为整篇文章的结构和行为逻辑进行提前的思考，不然产出的文档可读性也很差。
第四坑——详细得臃肿
在写PRD
时，为了想一次性把问题说清楚，让程序员能一次性把文档理解透。所以会把一个问题解释得很详细，从而使得文档变得很臃肿。
这不是认真，这其实是一种懒惰，因为想用文档砸给程序员，让他们自己去理解产品，不想和程序员进行过多的交流和文档解释。
其实在实际工作中，我发现有就算你写得再详细，如果不进行口头介绍，程序员想把如此臃肿的文档理解清楚也非常不容易。所以，如果能用流程图来表述，就不需要长篇累述；如果能先进行产品大致的介绍，让大家先理解整个思路，就不需要文字上过于累赘的表述。
产品文档应该做到
“考虑全面，逻辑清晰，语言精练”
第五坑——文档排版不易读
原来才开始写文档的时候，完全不知道什么排版，在无数次打磨自己的格式后，开始对排版有了一点自己的理解。
如果说排版有什么技巧，我想可能是这几个：
1.
以功能划分大板块，
大板块标题醒目
。
2.
把大板块简单拆分，并用
小标题区分
。
3.
用点号罗列观点
，不要写成一大段。
对于文档排版，统一文字格式后，做好以上几点就能确保文档基本整洁和可读性。但是排版是个长期打磨和锻炼的事情，必须要经常锻炼，才能有一套自己的合理的排版风格。
第六坑——重点内容不突出
重点加得非常随意，就会造成两个结果，重点不突出和重点不够重点。
所以，文档中应该标记重点，但也要注意：
1.
重点最好为重要的动词、转折词、新名词和关键逻辑判定词等。
2.
重点内容不在于多，更在于精，满篇重点则是没有重点。
第七坑——不用程序员喜欢的形式写文档
最后，特别重要的一点，也是不可不说的一点，那就是使用程序员容易理解的、喜欢的方式来写文档。
1.
程序员更喜欢看到能用公式来展现各个数据或者信息之间的关系；
2.
了解程序员编程的时候常用的逻辑，多以这种逻辑术语来写文档，这样程序员就更能理解；
3.
多用分句，别用连句，一个分句表达一个意思就可以了。
4.
能用配流程图的，千万别只写文字。
来源：人人都是产品经理