后台设计(二)：联运后台项目小结.pdfVIP

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