产品经理怎样写出高效文档
一、内容要有可读性
我们描述一个功能，或者产品需求的时，要考虑可读性强不强，描述的功能逻辑性是否清晰。可读性强能让你的读者花费的时间少、从最少的文字和图形里面，寻找到你的核心内容或者是功能，可读性不强，看半天都不知道你的核心。
很多朋友在写文档时，描述某个需求的时候东说一句，西凑一句，最后又加了一个参考某某产品，这就使得我们相关人员在阅读这个需求的时候显得颇为费劲。
二、如何才能避免写这种流水账文档呢？
那下面我将介绍高效文档的写作方法，内容如下：
1、将某个功能解释清楚后，在去解释另外的一个东西。
2、凡是遇到的细节部分一定不可马虎对待，不要抱着这个细节的忽略并不影响功能的正常使用的心态。
案例：拿我们设计一个电商网站的购物车功能来说，这个功能的主要实现的目的就是选择了批量的物品能够一次性付款，提高用户购买物品的效率，给用户一个更人性化的体验，但是最影响该功能使用的是添加了某个商品清空不了，只能通过结算才能清空，包括对已经购买的物品能否再次编辑修改属性。当然所有的购物车功能并不需要都做成这样，比如某电商网站百分之九十多以上的用户买了物品根本不会再清空，不会修改物品的属性，那么清空购物车中的某产品或者对产品属性进行修改，这就显得十分没必要。
总结：以上案例告诉我们，发现到某功能的细节问题的时候，一定要多去想，有哪几种情况会使用到该细节功能，分别是什么样的用户，会在什么样的场景下使用到，频次高不高，当然最理智的做法是能有可靠的数据为参考，以此做衡量。当然有的时候根本没有数据可参考，那就要在开发周期和开发难度是来做衡量，如果仅仅是几个小时就能搞定，那选择做，如果要两天以上的时间，可以考虑暂缓，等功能上线后看反馈程度来决定，我们还是要保持精益创业提出的最小可行性这一概念，尤其是在创业公司。
三、多张口，为的就是将事情做对：
接手了一个新项目，该项目的团队成员几乎工作资历浅薄，虽然至此，但是他们对该产品的理解远比你所深刻，这个时候作为年长的你更应该听取他们的见解，从产品的角度多做分析多做思考，我们最终为的还是要将事情做对。
作为老产品人的我们不应该趾高气昂，不应该有一群不懂产品的人凭什么对我指手画脚，你们行你们上啊的心态。
四、对照着模板，对你的产品做检查
1、不好的做法：很多人在准备写某某产品功能的需求的时候，就会迫不及待的上网找需求文档模板，但我认为这种方法不好，可能在你照着模板写的时候会打乱自己的思路，会受到模板当中一些思路的影响，最终很有可能会使产品目标偏离实际业务，所以拿着模板套，并不是一种很好的选择。
2、比较好的做法：我们应该按照自己的思路，先写一份1.0版本的需求文档出来，然后拿出模板，看看别人模板里面都写到了哪些内容，在我自己的需求文档里面哪几部分被我忽略了，或者根本没有想到，那这时候就应该将相应的内容都添加上去，模板对我们而言他无非就是一个检查器，检查疏漏的内容，对我们的需求文档进行1.1版本的一个优化。
总结：大家会感觉，我推荐的这种方法也是套模板的方法，但我是先根据自己的思路，设定的目标先出文档，然后再优化迭代。
我这样做就是担心大家，被一些模板里面的格式或者画的比较漂亮的流程图而给影响了思路，思路被分散了那最终产出的内容质量会高吗？
声明一下，这种套模版方法不是不好，每个人有每个人的方式习惯。
欢迎大家提出自己和意见和方法，谢谢大家支持
一、内容要有可读性
我们描述一个功能，或者产品需求的时，要考虑可读性强不强，描述的功能逻辑性是否清晰。可读性强能让你的读者花费的时间少、从最少的文字和图形里面，寻找到你的核心内容或者是功能，可读性不强，看半天都不知道你的核心。
很多朋友在写文档时，描述某个需求的时候东说一句，西凑一句，最后又加了一个参考某某产品，这就使得我们相关人员在阅读这个需求的时候显得颇为费劲。
二、如何才能避免写这种流水账文档呢？
那下面我将介绍高效文档的写作方法，内容如下：
1、将某个功能解释清楚后，在去解释另外的一个东西。
2、凡是遇到的细节部分一定不可马虎对待，不要抱着这个细节的忽略并不影响功能的正常使用的心态。
案例：拿我们设计一个电商网站的购物车功能来说，这个功能的主要实现的目的就是选择了批量的物品能够一次性付款，提高用户购买物品的效率，给用户一个更人性化的体验，但是最影响该功能使用的是添加了某个商品清空不了，只能通过结算才能清空，包括对已经购买的物品能否再次编辑修改属性。当然所有的购物车功能并不需要都做成这样，比如某电商网站百分之九十多以上的用户买了物品根本不会再清空，不会修改物品的属性，那么清空购物车中的某产品或者对产品属性进行修改，这就显得十分没必要。
总结：以上案例告诉我们，发现到某功能的细节问题的时候，一定要多去想，有哪几种情况会使用到该细节功能，分别是什么样的用户，会在什么样的场景下使用到，频次高不高，当然最理智的做法是能有可靠的数据为参考，以此做衡量。当然有的时候根本没有数据可参考，那就要在开发周期和开发难度是来做衡量，如果仅仅是几个小时就能搞定，那选择做，如果要两天以上的时间，可以考虑暂缓，等功能上线后看反馈程度来决定，我们还是要保持精益创业提出的最小可行性这一概念，尤其是在创业公司。
三、多张口，为的就是将事情做对：
接手了一个新项目，该项目的团队成员几乎工作资历浅薄，虽然至此，但是他们对该产品的理解远比你所深刻，这个时候作为年长的你更应该听取他们的见解，从产品的角度多做分析多做思考，我们最终为的还是要将事情做对。
作为老产品人的我们不应该趾高气昂，不应该有一群不懂产品的人凭什么对我指手画脚，你们行你们上啊的心态。
四、对照着模板，对你的产品做检查
1、不好的做法：很多人在准备写某某产品功能的需求的时候，就会迫不及待的上网找需求文档模板，但我认为这种方法不好，可能在你照着模板写的时候会打乱自己的思路，会受到模板当中一些思路的影响，最终很有可能会使产品目标偏离实际业务，所以拿着模板套，并不是一种很好的选择。
2、比较好的做法：我们应该按照自己的思路，先写一份1.0版本的需求文档出来，然后拿出模板，看看别人模板里面都写到了哪些内容，在我自己的需求文档里面哪几部分被我忽略了，或者根本没有想到，那这时候就应该将相应的内容都添加上去，模板对我们而言他无非就是一个检查器，检查疏漏的内容，对我们的需求文档进行1.1版本的一个优化。
总结：大家会感觉，我推荐的这种方法也是套模板的方法，但我是先根据自己的思路，设定的目标先出文档，然后再优化迭代。
我这样做就是担心大家，被一些模板里面的格式或者画的比较漂亮的流程图而给影响了思路，思路被分散了那最终产出的内容质量会高吗？
声明一下，这种套模版方法不是不好，每个人有每个人的方式习惯。
欢迎大家提出自己和意见和方法，谢谢大家支持
