产品方案总结

最近在做项目文档方面的训练，业余时间在自己以前做的一个项目的基础上面整理了一个产品方案，现将其中得到的几点经验总结下：

1.从文档的组织结构方面，产品方案的逻辑按照包括：项目背景->需求分析->总体设计->产品功能->效益分析->开发进度的思路进行，这是参考售前工程师书籍上的摸板组织的文档结构，总体写起来对需求分析和语言表达这块还有很多提升的空间，主要表现在：

对业务现状和其中存在的用户痛点的提炼与分析还存在不足；

根据与用户的沟通和各个方面收集需求后，对场景的设计和总体需求的归类还需要提高；

文档的总体设计中需要对哪些方面需要设计还没有深入的认识，总体方案设计章节的编写薄弱；

产品功能与用户需求之间是否存在着对应的关系？如何将拆分出的用户需求组合转化为具体的产品功能；

总体来说可写的东西还是偏少，需要多多参考其他的文档和思考角度，丰富产品方案的内容；

2.上述是从产品的构思与项目本身来思考的，脱离开具体的项目，还有一些共性的文档编写方面的知识需要积累

word文档编辑知识：

文档多级标题列表的自动分层与自动编号；

分点陈述时的编号的自动添加；

visio绘图的知识：

多个控件叠加时的图层，如何设置各个控件所在的层；

如何自由添加文本框；

各种带箭头的线段的绘制；

3.在编写文档的过程中还有流程图和架构图等各种设计文档需要的专业图形的思路和特点：

流程图

绘制流程图，如果不能把整个系统的流程用一个流程图绘制出来，可以拆开成多个流程图来设计:

在一个系统中可能不止存在一个场景，一个系统可能是多个场景通过一定的关联组合起来，可以针对一个场景绘制一个流程图；

系统存在者一个主流程，但其中的某个流程比较复杂，在主流程图中如果画出来会导致主流程图过于冗长，可以在主流程图中进行简化，然后针对该子流程单独在绘制详细的详细流程图，这样就是一个主流程图和多个字流程图的架构’；

系统架构图

系统架构图，系统架构图与流程图不一样，流程图中主要是操作步骤，没有考虑系统的具体实现，强调了各个动作的先后顺序，主要是从需求分析转化而来，其中必须要有各个操作步骤和数据的流动方向，是从具体业务规则考虑；架构图则不同，架构图强调的不是各个操作的先后关系，其强调的是各个节点之间的交互关系，是主要是从系统实现的角度来考虑，其中必须要有节点和节点的相互关系，有点类似网络中的组网结构图，从技术实现手段考虑；