创二

一、现状问题
缺少创二整体业务流程文档，对整体流程不清楚。详细设计的方案评审，方案合理性问题欠缺讨论
变更频繁、缺少维护，后续不利于定位问题
散落在各个项目和需求下，没有集中统一维护的地力
文档缺失。业务流程不清楚，导致自测比较困难
文档缺少迭代长期维护，缺少其他领域业务的分享

责任田不清晰
没有明确的职责分配，服务没有明确的第一责任人
服务代码存量不好安排治理，增量较难有人牵头保障
架构边界不清晰
trans、you-pin揉了很多功能
服务间循环调用
服务承载功能与职责定位不相符

项目难点:
1、产品是新人，PRD中场景考虑不全
2、兼容新老调度工作台，派单时增加开关是否判断调度状态，四种货源类型(代理、网点、平台、主站)，多种运力(派单自有运力，派单兼职运力，派单给众包运力，派单给众包服务商、派单给兼职服务商，一健帮找车、直接指派)的场景组合，是否需要判断调度状态业务逻辑是不同的，开发过程中需求变更未落地到文档
3、货主改单之后订单费用重新计算，可能会存在资损的风险
解决方案:
1、补位产品，需求评审及编写测试方案过程中补位产品列全了涉及的场景
2、拉通产品与开发对齐每一种场景，补充更新到测试方案中，并且在项目复盘中与产品研发对齐，需求变更同步测试，并且更新到PRD中
3、测试方案重点罗列出所有需要计算费用的场景(重点关注货源类型(代理、网点)、支付方式(到付、现付)下单人类型(零售商、代理商)装货时间(今日装、次日装)等场景不同场景的组合)，用例评审时着量check此模块用例
结果:
1、补充了一个涉及资损的重要场景，货主改单之后需要清空补贴金额，未清空的话会造成多发放补贴金额2、项目按期交付，无因为测试漏测导致的线上问题

项目难点:
1、创二冷运订单造数流程复杂繁琐，其他部门同学频繁找来协助造数
2、这个项目之前刚刚上了一个承运货源判断规则变更的项目，对与平台货源如何判断承运规则逻辑无法判断冷运是否能直接使用承运规则判断
解决方案:
1、协助其他部门同学构造创二冷运订单，并输出造数傻瓜式操作文档
2、协助产品梳理承运货源判断规则，并制定冷运订单特定的承运规则(承运成本价调整信息区别于平源)
结果:
1、帮助其他部门同学快速构造创二冷运订单，提高测试效率
2、保障项目按期交付，无线上问题

3.1 现状问题分析
现岗位工作中主要存在的问题和挑战
1、货源类型与业务类型逻辑比较复杂，四种货源类型(代理、网点、主站、平台)，两种业务模式(撮合、承运)，再加上是否开票，组不一样，很容易出现资损的风险
2、当前所在团队属于创新业务，倒排期的项目比较多，测试资源紧张，没有对应的基础建设，业务稳定性只能人为保障，业务测试回归成
3、人力紧张，当前没有区分业务域，没有测过的业务域，因为不了解对业务细节点，可能评估不到对应的场景，导致场景漏测
4、QA环境由各服务onwer 分别发布，发布效率低，QA环境基本在发布当天下午才可正常使用，导致QA环境只有半天时间做全流程回归个人思考和改进建议
1、搭建一个算价工具平台，这样就不用人肉回归了(或者也可以通过场景白动化的方式)
2、2-3的问题 就是基础建设包括业务总结、基线用例、白动化尽快建立起来(日前已经开始着手做了)
3、发布计划评审之后，QA环境由PM按照发布计划统一做lion配置、建立QA任务、建表、然后发布