第1个回答 2022-06-28
1. 功能结构图表达的是功能之间的从属关系；
2. 是产品功能模块及其逻辑结构的体现；
3. 功能结构图极少涉及具体的字段信息，只强调功能的逻辑关系。
1. 梳理页面和功能点的利器
2. 指引方案设计，避免边做边改
3. 分析产品的透视镜
4. 开发评估工作量的重要参考
1. 梳理业务流程
2. 拆解功能模块
3. 绘制成思维脑图
1. 为了清楚地描述一个对象，把信息按一定的逻辑，组合到一起，就构成了这个对象的信息结构图。
信息结构图是脱离于功能、页面、交互的，与页面和交互没有关联。同一个信息，不同功能的很多个页面、功能模块都可能需要用到。
如果产品经理能替开发多想一步，直接把功能包含的“对象”抽象出来，并完成信息字段的穷举，这对开发理解产品方案、设计数据表结构会是一个很重要的参考依据。
不是所有的信息字段都要绘制到信息结构图中。是否要被抽象为信息字段，取决于业务和功能是否需要它们，取决于它们对业务和功能的设计或未来的发展是否有价值。
功能结构图描述的是功能和功能之间的逻辑关系，而信息结构图描述的是对象本身。
在做产品方案时，建议先绘制功能结构图，再根据功能结构图绘制信息结构图。
建议包括：为什么做这个产品？产品目标是什么？本期目标是什么？关键干系人意见是什么？设计的时候是从什么角度考虑的?
2. 状态、事务定义约定
3. 整体方案功能架构图、流程图等
在具体功能设计之前，进行从宏观到微观的信息介绍。
●团队成员会存在理解偏差；
●惰性员工，可能故意理解错误，想着节省工作量的方向曲解；
●多团队协作，理解不一致，系统联调造成障碍；
●时间不够。项目进度永远都是在赶、赶、赶，，，，
●很多是重复工作，浪费时间，对技术团队可能也没有意义；
●细节可能覆盖到，但是也不可能100%覆盖。可能有细节未覆盖到或有优化空间；
●产品、技术工作边界不清。有些团队可能会要求一些技术方案层面的内容，也写到产品需求里面；
●团队是否熟练（包括UI、开发、测试）。团队成员技能越成熟，经验越丰富，可以写的“粗”一点；
●默契的可以写粗糙点。团队合作时间越长，越默契。可以写的“粗”一点；
●新功能写的详细点。新增功能，建议写的“细”一点；
●部门协作存在,,冲突、不和谐因素,,的，防止背锅，撕逼。建议细的“细”一点；
●团队间、不同公司间协作，大家工作习惯不一样，信息传递成本高，默契度低。建议写的“细”一点；
对一些复用概率高的规则、模块，进行模块库建设（或者叫规则）。
例如：手机号输入框校验规则、身份证号输入框校验规则、绑卡模块等。
进行尽量详细的设计，并全面记录。
但是要形成模块库（共同规则库）。
同一个功能或规则再次发生时，直接使用模块库中的内容。