如果产品文档没把产品业务说清楚会有什么影响？
常见的：产品不符合业务（实际使用场景），验收不通过，需要加班修改，调整。产品经理被骂。
严重的：甲方爸爸受不了了，换供应商，如果乙方坚持，可能打官司。比骂更严重。
可见一份把产品业务说清楚的产品文档非常重要
怎样的产品文档是说清楚了业务的？
1.是产品交互画得很清楚的吗？
产品交互设计划得很清楚，可以快速开发，程序交互上少改动，但产品交互设计划得很清楚，不足以说清楚业务，会只见树木不见森林，而且日常项目进度都不宽裕，没有很多时间画详细的交互设计图，尤其是需求不确定的业务，一边做一遍探索的，熬夜画了一宿的交互设计，第二天客户可能会推翻。
2.没有产品交互设计，只有需求文档，大篇文字描述的？
此类也不行，中国文字博大精深，人的想象丰富多彩，盲人摸象。产出的产品与业务偏差风险很大。
从以下几方面入手，清楚说明业务不难！
1.先见森林
即先画业务流程图，业务流程图也先从粗到细，从主流程到子流程
2.再见树木
业务流程画好后，先与甲方确认，确认了基调，即有了森林，有了蓝图，就把蓝图里的每一个节点摸清楚，即见树木。清楚每个节点的功能、页面、页面里的字段、按钮。
3.再摸森林里的小路
不是交互，页面间的跳转不是难事，点击“编辑”按钮，进入编辑页面，这是常识。
数据流向，这个列表的数据是从哪里流入的。对于开发工程师来说，这是很关键的，工程师要知道去读哪些数据来展现。
一般说清楚 列表 数据流入就够了，因为列表通常是一个功能节点的入口。
数据权限，不同的角色，有不同的数据权限，业务员进入只能看到自己的，主管进入能看到更大范围的数据。
审批流程（如果有），涉及流程状态与角色的对应关系
下图供参考
4.与客户一起探索森林
即业务结合客户实际使用场景，进行拟人化场景模拟。
场景一：公司线下参保
2019年4月10日xxxx公司参保办理员xxx到职工服务中心，在现场电脑上填写了参保保单。如下图
在电脑上导入公司参保的员工清单。核对保单上信息与参保员工人数等信息，确认一致后打印保单和参保人员清单。清单如下图。
场景二：特病理赔领导审批
xxx同时符合A特病与B特病的理赔。提交A理赔资料，领导审批。提交B理赔资料，领导审批。
此时客户说：不，将A与B合并，领导审批一次，怎么可以让领导审批多次呢？（这就是客户实际使用场景，好产品需要考虑）
总结
一份关注以下点的产品文档，可以讲业务说清楚，并符合开发与测试工程师所需，又让客户满意。
1.业务流程图
2.页面字段，按钮，搜索条件、按钮权限、编辑权限
3.数据范围、流转、权限、审批、状态等
4.结合了客户实际使用场景