两个月下来，第一期的联运后台项目也接近了尾声。趁着这段验收的时间，温故而知新，重新出发，看看之前处理不当埋下的坑，以防再次踩坑。
术语表
这个名词也许对于大多数的产品经理来说，是很少接触的一个名词。在接触后台产品之前，一直做的是工具类的应用，架构不算复杂，而且模块划分清晰，开发、设计、运营日常都会使用，对其中的一些产品术语会有所了解，因此，在日常的沟通上没有专门的术语表（or项目词典），都不会有太大问题。
但是，这次的后台项目，一是联运后台是业务导向的产品，除了产品，其他人其实对于联运后台的相关词汇及业务了解不多，二是联运后台，往往是多个后台同时进行开发，涉及的人员跨团队、跨部门。由于以上两个原因，在项目一开始的时候，没有及时的产出术语表，出现了 开发阅读文档时对需求产生错误的认知、测试在进行测试用例的撰写时产生了对业务的疑惑等问题，无形中增加了沟通成本。
小结：从上述可得，术语表其实不仅仅是提供团队沟通效率的工具，在针对业务类型的产品，术语表还可以充当业务说明的角色。因为术语表中往往会涉猎到业务上的专业名词，在这种时候，可以将相关的业务进行说明，降低沟通成本，将业务需求更好的传递下去。
业务流程图的细化
从之前的小结中，我也提到了业务流程图是作为工作流设计的基础。经过这次项目后，发现业务流程图其实还可以细分为 序列图、流程图：
1、序列图
（1）序列图，主要是关注系统角色之前的交互，关注业务流的整体，可以让其他人员快速的获知整体工作流，同时也可以为后台的角色权限做参考
（2）序列图由于没有涉及到细化的分支流程，这样在前期讨论可以让人们更加关注在主流程本身，而不会陷入在一个异常分支流程中不可自拔，其次返工也是够快（原谅我是个懒癌，哈哈）
（3）但是，在产出序列图的时候，更好是对分支流程有所考虑后再进行产出，这样在后面进行流程图的产出时，也可以避免考虑不足导致的流程变更
2、流程图
（1）流程图，对比序列图，更加关注的是后台本身的细分流程，因为流程图的产出往往是针对开发阶段，需要对不同的状态、不同异常情况进行说明
（2）在进行流程图的产出时，可以先将部分通用流程统一成一个页面，然后设定标注规范来处理，其次，将不同业务模块的流程放在不同的页面去描述，如果业务模块间会有交互流程，可以放在通用流程中去描述（业务流程图的产出是一门学问，可以从软件设计类的书籍中去了解，最近我也在翻阅类似的书籍~~）
让团队理解业务
后台类产品，往往都是业务驱动类的产品。这样会导致团队对于需求的理解上存在一定的难度，在立项会议上，如果没有将产品的业务流很好的传递下去，最终的产品也许无法很好的满足业务需求。
小结：要解决这个问题，往往是需要产品负责人和项目经理（有些团队，产品经理也是项目经理）付出一些努力的：
1、立项：立项会议上，先说清楚业务流是怎样，与团队在业务方面得到一定的统一，然后再通过业务流进行细分，把需求进行代入其中，而不是将立项会议草草带过
2、产品与开发过需求前，先把业务说清楚，再说需求，再讲解详细功能点
3、进度会议：在进度会议上，产品要对当前的Demo进行核对，保证方向的正确性，而不只是对当前的进度进行阐述
需求实现程度的把控
需求与实现，理想状态就是需求文档的像素级实现。但实际上呢？往往都是需要产品和开发不断的思维碰撞、文档不断的修改，产品出来往往与原需求是有一定差距的。这个对于后台产品来说，更加如此，这个就需要在验收时去把控好需求实现的程度。
对于这个问题，如果从最根源的出发，就是与开发过完需求后，尽快的从开发口出得到反馈。不对，很多人可能会觉得这扯远了。但是，这其实才是保证需求实现的最好方法，就是在一开始就与开发在需求实现上达到一致，这样开发在设计数据库时，将能够把你需要的字段都设计好，防止提测版本与需求差距较大的情况。
对着文档操作一遍
后台产品往往都是在Web端去实现的，相对于APP端产品能够放在手机上去进行实际操作来说，是很抽象的一种存在。之前在产出文档后，往往是根据产品结构图对于不同功能点的逻辑进行梳理，觉得没有问题就收工了。后来发现，这样的做法还是不够的，这样的处理方式往往只是解决了产品的实用性功能。
较好的做法，就是产出文档后，对着文档的不同功能点，在脑海中模拟操作一遍，看看这样的逻辑会对其他功能点产生什么联系，这样的逻辑处理对于用户来说真的够用了吗？反复的思考后，觉得没有问题，这样产出的文档会更好。
