在日本写代码的日子(二十五)

通过1个多小时的梳理,我大致定位了问题所在:

  1. 现场的工程师基本上是我以前组里资历比较浅的。对NFLC SDK自身的认识不够,不能一针见血地指出问题所在,导致客户怀疑我们的专业能力,这是客观基本问题;
  2. 现场的PGM在汇报问题的时候,没有明显区分客观事实、推理、提案这三个部分,导致客户在不信任的情况下,很容易抓住把柄,进行反攻,将所有问题推卸到我们这边;
  3. 上面这些问题在过去的几个月当中反反复复,导致了双方的决裂;

针对这些问题,我制定了解决方案:

  1. 将问题的真正所在,以及问题产生的机理告诉组里的工程师,并让他们修改代码进行实际的验证,将验证结果做成报告;
  2. 由我暂时接管现场的项目管理工作,让可怜的PGM回酒店好好洗个澡,刮个胡子理个发,然后美美睡上一觉;
  3. 将汇报内容按照客观事实、逻辑推理(问题原因的推测)、修正方法的提案这三个模块进行重新组织;
  4. 与客户沟通的时候做到对于客观事实双方必须一致确认,对于逻辑推理双方进行逻辑上的互攻、对于解决方案提供多种方案供用户选择

凌晨3点钟,对方的部长带着几名资深工程师下来了。课长首先向他们介绍了我,说我是DLNA方面最好的专家,并且在skapa实验室作为主要技术人员与日本的各大电器制造商成功完成了对接,目的是让对方认识到我们很重视这个项目,也为我添加谈判的砝码。

接下来我首先代表公司对项目的进展情况表示由衷的道歉,同时指出当前的首要任务应该是尽快解决问题,而要解决问题必须保持高效正向的沟通,对话的决裂会使得项目停滞不前。

然后,我按照前面的叙述框架,将目前所有没有解决的问题一个一个梳理了一遍。每讲完一个客观事实(对问题的定义),我都会询问客户是否承认这个客观事实,描述是否完整。这样做的好处是避免由于对问题的不同定义而引起的分歧,而且其实也是将问题的范围锁定住,避免客户那里因为测试不充分在后面不断地扩大问题的定义。

在客户的部长表示对问题的客观事实认同之后,我具体阐述我们对问题发生机理的逻辑分析。这个时候需要注意的是,因为客户并不保有和我们一样的底层知识,所以仅仅用我们具体实现的现状去说服客户是不可取的。因为这里有个信息不平等的问题。

所以,在说明的时候不仅要说明我们目前是怎么做的,而且要说明为什么这么做,是否有其他的替代办法,各有什么利弊。要做到客观通俗,逻辑清晰。

最后,我提出问题的解决方案。这里常见的问题是,往往双方都会倾向于选择不需要自己动手的方案,也就是将工作量推给对方。但是由于双方在合同关系上存在着委托关系,所以被委托方往往会被欺负。这在工程师这个层级可能是无解的,所以就要充分给站在更高角度,对项目全体负责的人讲明白,哪种方案是对项目整体最好最自然的。这样就可以得到对方管理职的帮助,对方的工程师也就难以将工作完全推过来了。

这个会议一直开到天明,对方的部长终于理解了当前问题的全貌,也意识到很多问题是需要双方共同解决的。会议之后双方工程师立马开始了解决方案的执行,而我被对方的部长叫到了3楼,与他们的技术负责人再次开会,将所有open的问题都过了一遍。

临近中午,我才终于有时间回到酒店,但是酒店已经帮我调换了房间,我的总统套房就这么样没有了。

为了帮助现场年轻的工程师解决问题,我继续在神户呆了一个月左右。但是因为我手上还有自己的项目,所以我没等项目完全结束就回东京了。走之前客户请我们吃了神户牛肉,非常美味。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

This site uses Akismet to reduce spam. Learn how your comment data is processed.