到了下周一，因为实施人员有别的项目要去支持，跟我约好了周三早上过去，所以我和产品经理先去了现场，参加周一下午的技术方案讨论会。
周一早上坐了最早一班车，和产品经理再赴客户现场。下午3点，行方组织了项目三个供应商一起，进行了正式的需求沟通以及架构讨论。会议过程中，先是明确了各方所负责的项目内容，我们一是提供语音的核心能力，开放SDK接口给APP集成商进行调用，并且配合联调，二是对转写效果进行优化，达到验收指标。这部分沟通的比较清楚了，接着讨论技术架构，有两个方案，可以将我们的SDK集成到app里，优点是转写速度快并减少带宽压力，缺点是会将APP大小增加20多兆。另一种方案是app调用行方的内部智能管理平台，再由平台来调用我们的SDK，这样的优点是便于统一管理，前后端通过中台实现解耦，但是对带宽要求高，影响访问速度。
经过沟通讨论，最终确定下来，按照第二套方案来执行，即使用中台调用的方案。会议还是挺高效的，有明确的结果输出，会后就可以各方开干了。因为我们的工作内容不涉及定制化开发，产品经理的任务也就结束了，于是第二天上午沟通几个技术问题之后，中午就让他回去了，准备在第三天上午实施过来之后，开始进行测试环境的部署。
周三上午，实施人员如期抵达现场，开始进行部署工作。小伙儿也确实挺给力，积极主动且认真负责，到下午三点左右，很快就把识别引擎跟合成引擎部署好了，然后开始安装管理平台。这时我计划返程的时间将近，于是跟客户方的项目经理反馈了一下进展情况，并且让实施人员留在现场，一是完成部署工作，二是配合集成商进行联调，把业务调用SDK给拉通。在行方的介绍下，我们跟集成商的项目经理进场了认识，并且互相加了微信，方便联调过程中的沟通。
临行前，我跟实施人员简单安排了一下，在现场配合好集成商，把流程拉通，保障我们的引擎运行正常，在联调过程中，遇到需要支持的地方，及时跟我说，我来协调研发和测试进行支持。说起来比较奇怪，按照正常的项目管理机制，实施直接找项目的研发或测试不就可以了？为什么还要通过我来协调呢？原因是我们现在的管理制度是弱矩阵，非常弱的矩阵，弱到项目经理是个光杆司令，单枪匹马往前冲，没有团队的概念，而是各方面资源要临时协调，来了任务了找这个帮忙一下，出了问题了找那个解决一下，包括实施的小伙子也是协调过来的，不然为啥他要周三才能到现场啊！可见管理制度的弊端带来了大量的沟通成本，严重影响了项目的执行效率。
交待完这些，我就踏上了回程的列车，下一步该考虑联调之后的效果优化了。
网友评论