文档的管理是为了使工作内容减少，降低沟通成本，所以无论好坏，能够达到目的的文档就是好文档，对于大公司而言可能文档顾忌的内容居多，小公司需要发挥其优势就是简洁、便于理解，甚至有时候文档不是必须的，只要能够更高效率的直接沟通，时刻跟进进度，产品制作出来自然就没有问题，但一般来说要么就是工程师不断找产品经理重复确认，导致效率下降。所以对于重要的细节逻辑最好用文档描述记录下来，给予工程师开发指导。
对于不同文档的格式每个公司、每个人使用的都不一样，也没有通版，我们只要满足以下几个条件即可：
1.逻辑清晰
自己一定要先理解你想说的，并且描述的明白，如果不明白就开会一起讨论并且对于达成一致性的内容要最后确认，对于一些不同的观点要讲清楚取舍的原则，围绕原则才能坚定内心的开发，减少沟通的几率。
（1）功能框架逻辑
功能日益复杂的情况下，就会用到框架，框架有利于产品思路的梳理，未来产品的规划引导，也就是缺什么补什么，对于研发来说结构可以让他们各自分工，把代码之间的耦合性降低，以便于后期开发。
拆分法
零散枚举→归类→补充
（2）业务流程逻辑
指的是功能使用流程步骤，一个是面向对象、一个是面向事件
1. 面向事件
指的是完成一件事情需要多次操作，所有的步骤流程。
2.面向对象
指的是对象的生命周期代表着一次完整的功能使用，对象带着数据，经过各种方法转化流程直至达到目标为止。
3.功能描述逻辑
功能描述最怕就是疏漏，有没有考虑到的情况，所以一定要有结构性的梳理，完整的枚举，枚举的越详细越好。
先横向枚举、再纵向深入。
1.完整性
不仅要考虑到正常情况的完整，还要考虑到特殊情况，避免程序上的bug和功能上的错误。
2.条件判断清晰
有明确的依据标准，什么情况下启用什么功能，进行哪一类判断，不然程序中的判断方法和代码就会混乱以至于出现bug。
3.含义明确
尽量避免名词缩写带来的解释混淆，使用新词时一定要备好案，通知好、沟通好。
4.叙述背景
和团队讲述功能设计的同事最好阐述你的思路，你的灵感来源，让他们更能理解你的想法，从而减少程序开发的误差。
2.没有疏漏
刚开始接受一个团队，对于每个人的工作方式都不了解，每个人的需求点不了解，导致疏漏总是会有，这时候我们要不断补充完善文档，将每个人的需求点都满足在内，创造出最适合自己团队的文档。
3.可读性强
把将会读这篇文档的人的知识范围了解清楚，比如设计师要的是rgb，你说的是颜色名词，这样他会很疑惑，但是对于其他人可能只需要知道或只懂颜色名词。尽量了解相关协调人员的工作流程，知道了他们工作流程中的需要、可能遇到的的问题，预先给予解决方案，这样才能让他们的工作更加顺畅。
