汽车行业DMS软件开发现状及交付流程总结

　　转眼跨入Web后端开发已经2年多了，也进入了一个新的行业汽车行业DMS软件开发，以前也听说过DMS、CRM软件但是一直没有开发过，这两年一直在给奇瑞做新版的基于微服务架构的经销商售后管理系统，可能很多人对汽车行业整个体系还不太清楚，简单理解分为两个大的部分：主机厂和经销商，奇瑞汽车（总部在安徽芜湖）作为主机厂，以及全国的600多家经销商，经销商又分一级经销商和二级经销商，我们平时接触最多的就是汽车4S店，作为汽车销售和服务的载体，这套售后服务系统就是管理全国这么多经销商日常业务的系统，包括汽车维修、售后索赔、备件销售......所有的业务都能够通过这一套系统进行管理，业务种类和内容非常多，公司已经和奇瑞合作了很多年了，第一套系统是基于微软Silverlight做的一套系统，随着微软停止对该技术的更新也寿终正寝了，之前的一套架构系统也用了很多年了，新的系统采用前后端分离的架构，前端框架基于React,后端基于Asp.Net Core技术的微服务架构，系统基于k8s技术部署在linux系统上，目前已经上线运行了很长的时间了，当然这中间也会碰到各种难题，但好在公司在全员的努力下系统运行良好，已经有400多家经销商在线上正式使用了，今天的这篇文章主要不是分析整个软件的技术架构而是就汽车DMS软件行业的生态及特点我们面临的挑战，以及整个公司作为乙方如何通过一套规范的流程来快速交付给客户软件产品，并保证软件质量的同时提升交付效率，这一套流程交付公司已经积累了近20年的经验

　　一 汽车行业DMS软件行业现状

       1.1 品牌众多，自成一体

　　现在都不太清楚奇瑞下面有多少个子品牌了，我们现在在做的就有：星途（Exeed）、奇瑞、奇瑞国际、凯翼......，每个子品牌及独立销售公司自成一体，业务上大体相同，但是完全是不同的销售体系、经销商体系所以完全都是独立的一套系统，每套系统业务上整体相似但是又有众多的不同，所以每个系统都是需要独立的业务团队和开发团队、运维团队去独立维护，而且业务众多，所以维护好每个子品牌本身就是一个巨大的挑战，一个奇瑞就有这么多的业务内容和品牌，国内汽车厂商众多，相信每一个厂商都有自己的独立的DMS软件系统，这个对于整个汽车厂商来说这套系统有多么重要了。

　　1.2 上下游对接公司多，外部接口多

　　汽车整个销售和售后服务涉及上下游产业众多，DMS软件最为最后的一个直接面对客户的系统，必须完整展示并且实现整个业务流程，其中任何一环出现问题最后都会导致系统上面业务处理的失败，最终影响日常的使用所以我们的系统是非常重要的，上下游对接公司多是因为奇瑞信息公司的软件供应商众多，物流公司、备件公司......这些我们需要去对接他们的系统获取最后的信息从而在DMS售后服务管理系统上面展示，另外我们的业务系统也需要将我们系统中的信息通过各种SOAP、REST API等接口供外部第三方来调用，这些对接过程中最大的成本就是跟不同厂商进行接口对接和调试工作，这个也是开发人员非常麻烦的一件事情，这个想必经历过的都会懂。

　　1.3 业务需求变更多

　　由于我们DMS软件系统是处理客户日常业务的，而实际的业务场景异常复杂，很多之前没有考虑到的场景可能会在使用中发现，然后去变更需求，另外很多和行业政策相关的业务流程也会随着行业政策的变更而发生变更，所以如何合理设计整个系统就考验着整个业务团队和整个开发团队，同时也需要非常重要的运维团队来保证这些后台数据处理和相关内容。

　　二 乙方公司交付流程总结

　　2.1 强大的业务团队

　　对于这样一个庞大的业务系统，准确理解客户需求并进行业务涉及是在是太关键了，由于我们是乙方公司物理距离上的间隔造成了沟通效率上面的降低，所以我们的业务团队也是非常辛苦的，经常需要常驻奇瑞公司，并且直接面对奇瑞的业务部门甚至经常需要到当地4S店去实地调研用户需求，在充分沟通之后开始业务涉及工作，我们的业务实际系统是在wiki中进行的，业务涉及团队除了日常需求调研，业务涉及还有后面的开发测试工作，因为很多的时候只有业务才能真正的发现系统中的漏洞，程序员在开发过程中只会发现一些技术上面的错误，有些业务方面的缺陷和漏洞只有他们才是最清楚的，另外业务团队还需要定期线上对新接入的经销商进行系统试运行的培训和指导工作。

　　2.2 持续迭代并保证高质量交付的开发团队

　　这点作为程序员的我最懂得其中的痛点，面对一个新的业务如何准确理解，理解了如何写好代码，保证性能，还有面对每个sprint迭代的交付压力，另外还要帮助业务团队一起来排查问题，以及一起排查生产环境上面的问题，这个过程中Sentry和Grafana就是发现错误和排查问题的利器，有了Sentry我们就能够通过邮件实时收到系统中存在的错误，通过Grafana我们就能够实时去看程序的监控日志，从而排查问题，另外我们日常的开发计划都是通过GitLab系统进行管理的，在这个系统中业务团队登记开发任务以及测试bug相关issue,团队leader进行任务的追踪和分配，这些都是需要进行有一个规范的开发流程的,好在我们有一个强大的团队大家可以在一起去沟通去交流发现问题，这其中面临技术难题或者交付时间上面的压力的时候也是非常令人焦虑的事情，还在我们现在都扛过来了......

　　2.3 认真负责的运维团队

　　代码中存在未测试出来的bug,已经发布到了生产环境造成了数据不准确怎么办，这些运维团队通过SQL处理数据库来得到正确的结果，所以他们也非常不容易需要非常有经验而且对业务十分理解，所以运维团队也是常驻现场的，很多时候还要帮助他们来导数据，以及一部分的测试工作，总之前面两个流程越精细，错误越少他们就越轻松否则前面的错误越多他们的工作量就会越大。

　　2.4 持续集成和软件发布部署

　　由于我们的软件是通过K8S部署到linux服务器上面的，这其中需要将每一个迭代部署到客户测试环境以及生产环境，如何面对线上环境的部署错误，无法访问以及CPU及内存使用过高等一系列问题都需要专门的人进行发布和部署，这些也是需要进行专业的团队进行维护的，当然这些程序员是不参与其中的，有专门的团队进行维护所以不需要参与，但是如果程序员能够学着歇一歇yaml部署文件，进行一些简单pod启动与维护，并掌握一些常见的docker的命令和使用还是非常重要的，这一点也希望在以后能够加强。

　　作为乙方公司我们必须无条件去满足客户的需求，整个软件项目的成败对于项目管理人员来说也是非常重大考验的，项目经理在现场每天面对甲方客户对项目进度和项目质量的要求以及软件需求边界的确认都是双方博弈的过程，哪些需求做，哪些需求不做，怎么保证软件的交付时间和人员成本方面更需要公司商务团队的不断周旋，整个项目最终能做成怎样的结果这其中每个团队都付出了巨大的努力,整个系统的成功交付使整个团队都付出了巨大的努力，上至管理层下到基层员工，只有大家目标一致认真做好日常工作中的点点滴滴才能够最终实现整个项目的最终成功。