东东推荐：上次后台设计第一篇文章阅读量非常高，证明关于后台设计的文章比较稀缺。干货继续来，这是作者的关于后台设计的第二篇文章，各位看官请笑纳。

两个月下来，第一期的联运后台项目也接近了尾声。趁着这段验收的时间，温故而知新，重新出发，看看之前处理不当埋下的坑，以防再次踩坑。

（1）序列图，主要是关注系统角色之前的交互，关注业务流的整体，可以让其他人员快速的获知整体工作流，同时也可以为后台的角色权限做参考

（2）序列图由于没有涉及到细化的分支流程，这样在前期讨论可以让人们更加关注在主流程本身，而不会陷入在一个异常分支流程中不可自拔，其次返工也是够快（原谅我是个懒癌，哈哈）

（3）但是，在产出序列图的时候，更好是对分支流程有所考虑后再进行产出，这样在后面进行流程图的产出时，也可以避免考虑不足导致的流程变更

2、流程图

（1）流程图，对比序列图，更加关注的是后台本身的细分流程，因为流程图的产出往往是针对开发阶段，需要对不同的状态、不同异常情况进行说明

（2）在进行流程图的产出时，可以先将部分通用流程统一成一个页面，然后设定标注规范来处理，其次，将不同业务模块的流程放在不同的页面去描述，如果业务模块间会有交互流程，可以放在通用流程中去描述（业务流程图的产出是一门学问，可以从软件设计类的书籍中去了解，最近我也在翻阅类似的书籍~~）

让团队理解业务

后台类产品，往往都是业务驱动类的产品。这样会导致团队对于需求的理解上存在一定的难度，在立项会议上，如果没有将产品的业务流很好的传递下去，最终的产品也许无法很好的满足业务需求。

小结：要解决这个问题，往往是需要产品负责人和项目经理（有些团队，产品经理也是项目经理）付出一些努力的：

1、立项：立项会议上，先说清楚业务流是怎样，与团队在业务方面得到一定的统一，然后再通过业务流进行细分，把需求进行代入其中，而不是将立项会议草草带过

2、产品与开发过需求前，先把业务说清楚，再说需求，再讲解详细功能点

3、进度会议：在进度会议上，产品要对当前的Demo进行核对，保证方向的正确性，而不只是对当前的进度进行阐述

需求实现程度的把控

需求与实现，理想状态就是需求文档的像素级实现。但实际上呢？往往都是需要产品和开发不断的思维碰撞、文档不断的修改，产品出来往往与原需求是有一定差距的。这个对于后台产品来说，更加如此，这个就需要在验收时去把控好需求实现的程度。

对于这个问题，如果从最根源的出发，就是与开发过完需求后，尽快的从开发口出得到反馈。不对，很多人可能会觉得这扯远了。但是，这其实才是保证需求实现的最好方法，就是在一开始就与开发在需求实现上达到一致，这样开发在设计数据库时，将能够把你需要的字段都设计好，防止提测版本与需求差距较大的情况。

对着文档操作一遍

后台产品往往都是在Web端去实现的，相对于APP端产品能够放在手机上去进行实际操作来说，是很抽象的一种存在。之前在产出文档后，往往是根据产品结构图对于不同功能点的逻辑进行梳理，觉得没有问题就收工了。后来发现，这样的做法还是不够的，这样的处理方式往往只是解决了产品的实用性功能。

较好的做法，就是产出文档后，对着文档的不同功能点，在脑海中模拟操作一遍，看看这样的逻辑会对其他功能点产生什么联系，这样的逻辑处理对于用户来说真的够用了吗？反复的思考后，觉得没有问题，这样产出的文档会更好。

本文作者：@Yoic；来源：简书