紧赶慢赶，还是延期了半个月。一方面是客户方的整体进展有延期，另一方面是客户提供的语料不能适用。

在项目的整体进展上，做应用层开发的集成商，因为要对接我们和另外一家做底层能力的厂商，联调的时候经常发生问题，业务流程一直拉不通，不是流程节点有问题就是调用的时候出错，耽误了一些时间。在现场语料上，客户给了一批录音数据，但都是原来传统模式下人人对话的录音，对人机对话效果提升的帮助并不大，于是跟客户沟通，在系统上线后再收集现场的音频进行效果优化。因此希望系统能够尽快上线，真正用起来。

于是在上线之前，我跟客户沟通了解到，生产环境的服务器已经到位了，就和客户协商，提前安排技术支持人员来做部署，为上线做好准备。客户也非常同意，还专门协调了运维部门的同事来协助。但是到了现场发现情况不是想象的那样顺利。一是行方对生产环境的管控比测试环境严格得多，必须由行方运维部门的同事进行安装部署，不允许我们直接操作，只能做指导。二是指导还不能进机房，只能远程指导，也就是在机房外面指导机房里面的人来操作，尴尬症都要犯了。三是客户方项目经理对运维部门的协调力度有限，运维的同事说下午要开会，把门一关，走了～剩下我们的实施小伙子在现场干瞪眼，不知道该干啥，两天下来只完成了一个引擎的部署，急的马上跟我反馈情况。

我一听也觉得这样下去不行，虽说是提前部署，但也不能毫无效率，把人安排到现场只有一半的时间在干活，要知道协调实施到现场也非常不容易，还有好多项目在排队要人呢。再说了，按照这个效率，差旅费耗不起啊，项目成本肯定要超预算了。于是我跟行方项目经理电话沟通了现场的问题，对方也表示理解，但协调起来确实有难度，我隐隐感觉到了客户方部门墙的厚重，哎～

问题总是要想办法解决，我站在行方项目经理的角度，分析了当前项目的进展情况，还有我方产品部署的难度，并非像应用层系统那样部署相对简单，最好能我们操作，让行方来监督就可以了。对方其实也挺着急，说下周再沟通一下，想办法让我们进机房直接操作。于是我就先让实施人员回来了，跟行方项目经理沟通好，获取运维部门的配合之后再派人到现场继续做部署。

总算是不负有心人呐，三天后行方终于同意让我们来进行部署，他们的人员在旁监督和学习。于是我再次协调实施人员前往现场，顺利完成了部署，并且形成了实施操作手册给客户，也终于迎来了项目正式上线。

上线当天，我和技术支持的小伙子一同前往现场，同时跟家里的研发团队提前沟通好，做好后端技术支撑，虽然我们只是提供能力，而且能力层的技术已经是成熟的，但还是要防患于未然呐，项目经理的风险意识不能丢。下午2点到了现场，行方的项目经理正在为上线紧张忙碌着，于是简单的聊了几句，就继续忙活了。

我们因为前期已经部署好了，显得相对悠哉悠哉。到晚上8点，所有子系统和模块都已经陆续部署完成，开始最后的联调。我们的两个核心能力，一个在10点的时候顺利调通，另一个在11点的时候遇到问题了，联调虽然成功，但是文字转换成音频后系统不出声！于是紧急跟实施小伙子讨论了一下，应该是发音人那里出了问题，立刻到服务器上进行排查，发现授权更新上去之后，服务启动异常。我们紧急在群里也跟家里待命的研发做了沟通，花了半个小时左右的时间，确定问题可能是授权文件缺少现场的音库导致的。但是眼看着快12点了，这大半夜的上哪里去找合适音库的授权文件呢？

就在这时，实施小伙伴说，他有一个包含全音库的授权文件，但是测试授权，只能用3个月。于是我当机立断，就用这个测试授权来上线，回去之后马上找生产部门解决正式授权的音库问题。我紧急与行方项目经理进行了沟通，把情况进行了反馈，并承诺一个月之内完成正式授权的更新。行方项目经理也同意了我的方案，于是就用测试授权进行了更新，经过短暂调试，终于顺利调通，正常发音了！

现场的沟通、问题的协调、风险的管控，都源于对项目能够顺利上线的考量，因为要保障上线，所以在现场遇到配合度低的时候，要积极跟客户沟通，要紧急召集干系人协商，要提前做好风险防范措施。当然对产品的了解也非常重要，能够帮助自己避免踩坑，这在我另一个项目里面体现的淋漓尽致。

上线成功后，就要对效果进行运营优化了。然而世事难料，一是客户方并未组织试运行也未进行公网发布，导致没有现场语料可供优化。二是公司内部进行组织架构调整，项目要更换项目经理，做了一半的的项目要进行交接了。