那怎样的文档才是好的产品文档呢

看来的一篇文章，挺有意思的,来源于哪,忘记了

那怎样的文档才是好的产品文档呢？

其实，产品文档的作用就是为了高效地传递产品经理对产品功能的描述。

只要是能够顺畅推动项目前进，在产品开发和测试过程中能够大幅度减少工程师和产品经理反复沟通的文档，就是优秀的产品文档。

基于上述标准，好的产品文档应该具备以下的几个特质：

1. 产品逻辑要清晰且流畅

如果产品的大逻辑有硬伤，是没有办法进行研发的。另外，写文档要秉承先整体后局部的原则，先要从全局去定义整体的产品逻辑，再去逐步分解细节，这样研发人员才可以顺畅的开展研发工作。

2. 避免产品功能的疏漏

一个产品功能牵连的信息和逻辑越多，就越会产生考虑不周全的情况，研发人员在写代码的过程中就容易产生问题。所以在描述产品功能时，要考虑到所有的情况，比如会不会对其他模块产生影响？异常流程的描述，边界情况等。

3. 文档的可读性要强

能用图描述的一定不要用文字，多用流程图、用例图、时序图等去描述你的产品。在涉及到很细节的交互时，最好将相关功能做出高保真原型图供研发人员参考。这些图能比文字更好地传达设计思想。

2. 为什么开发说这个功能实现不了？

对于这个问题，大多数没有技术背景的产品经理都会遇到，我们的疑问是开发真的实现不了，还是不想做呢？

我的几个开发好友，坦诚的跟我说过确实存在技术忽悠PM的事情存在，有时真的是任务太重了，或是产品经理的脑洞太大了，不得已而为之。

人人都是产品经理平台中梁锋的文章已经给出很好的答案——《研发说方案无法实现，产品经理怎么办？》 梁锋将方案无法实现归纳为四种情况：

1. 确实无法实现
2. 不知道可以实现
3. 不知道是否可以实现
4. 可以实现但是就是说不能实现

2.1 确实无法实现

产品经理需要自己想想做这个功能的目的是什么，是否可以通过其他方案来实现，条条大路通罗马。

区别于开发的技术思维，产品经理一定要具有业务思维，不要技术说不能实现或是时间来不及的时候，就无可奈何、束手无策了。

举个真实的例子：在开发多项目并存，资源紧张的情况下，关于点滴日报系统新增下载团队周报功能，开发评估需要两周，并且两周后才可以开工，意思是用户一个月之后才能使用该功能，短期内确实无法完成该任务的开发。

产品经理不能开发一说没办法了，就认为没办法，不能让用户等着呀，产品经理需要另想办法，让用户可以提前使用该功能。

开发只是从技术的角度给PM建议，PM还需要有业务思维，急用户之所急，痛用户之所痛。

我们当时的解决方案是，可以每周五从SQL中导出团队周报发给用户（Manager权限用户），直至这个功能开发好。这样用户的需求就可以提前满足了。

2.2&2.3 不知道可以实现、不知道是否可以实现

这是因为开发人员的水平问题，PM可以咨询技术专家，调研行业和竞品解决方案.

2.4 可以实现但是就是说不能实现

PM可以将这个功能的意义讲给开发听，获得开发的认同感和参与感；亦或是开发任务太重了？

如果真的拿不准开发到底能不能实现，架构好友支了一招：

当开发说功能不能实现时，产品经理可以这样说：我上家公司做过这个功能，要不我帮你问问他们是怎实现的？

当然，产品经理如果能问出开发说需求不能实现背后的原因，双方好好沟通，一起想办法解决问题是更好的解决方案。

另外，产品经理平时需要多多学习技术知识，才能和开发无障碍的沟通