第七章——文档管理。
一直以来都不是特别清楚产品经理的具体定义，如果从Product Manager直接翻译过来，那除了“产品经理”之外，还可以理解成产品管理者，这也就意味着产品经理最本质的工作应该是产品管理。其它方面的工作——比如需求管理、项目管理等——都是由产品管理所衍生出来的。
产品经理要不要懂技术？
这其实是一个老生常谈的问题了，有个公众号叫“给产品经理讲技术”，连续一年，更新了好几百篇技术文章，知乎上关于这个问题也是讨论得热火朝天 [产品经理需要懂技术吗？懂到什么程度？ - 互联网 - 知乎](https://www.zhihu.com/question/19554113) 。但不管再怎么争论，产品经理肯定是要会懂技术的，问题在于要懂到哪个程度。
好的文档到底是什么样的？
一个很简单的检验方法：能够减少甚至免除在开发过程中技术人员跟产品经理沟通的文档就是好的文档。
从这个原则出发，好的文档应该要满足以下几个条件：
1. 没有逻辑硬伤——不会出现文档前后逻辑不一或逻辑不通。
2. 没有疏漏——要定义清楚细节。
3. 逻辑清晰——尽量在文档里配合开发人员从全局出发定义清楚问题。
4. 可读性强——尽可能更加友好地把事情说清楚，不要让开发人员找你反复确认。
产品经理不仅仅是要理解用户的需求，还要配合好开发人员理解他们的需求。需要输出给他们有效、友好的具体功能描述。
输入是不断跟用户产生互动，输出就是不断跟开发人员产生互动。
文档逻辑
主要分为3块：功能框架逻辑、业务流程逻辑以及功能描述逻辑。
功能框架逻辑
一个比较简单的梳理功能框架逻辑的方法是拆分组合。
拆分：把产品的功能（或预期有的功能）枚举出来，组成相对独立的模块
组合：把罗列出来的产品功能组合成相对独立的模块
这个方法还可以用在对其它产品的分析上面，比如可以用这个方法分析一下得到。
业务流程逻辑
业务流程的梳理，可以从两个维度进行：面向事件以及面向对象。
面向事件指的是要整理出一个有可能出现多步操作的事情，整理出健全的流程，逻辑清楚且不存在疏漏。
面向对象指的是对象的生命周期代表着一次完整的功能使用。（例：一个订单的生命周期）
功能描述逻辑
在描述功能时要注意以下几点：
1. 完整：尽量枚举所有的情况，并且分情况详述功能内容。
2. 考虑所有影响点：对任何认为细小的改动都有可能牵扯到其它地方，所以必须特别注意。
3. 条件判断清晰：在什么情况下会触发什么样的功能（if…else、while、switch）
4. 含义明确
5. 叙述背景
6. 功能所要达到的目的
总结
文档的完整性和逻辑性是在写作文档的时候必须要重点关注的。
