通过1个多小时的梳理，我大致定位了问题所在：
- 现场的工程师基本上是我以前组里资历比较浅的。对NFLC SDK自身的认识不够，不能一针见血地指出问题所在，导致客户怀疑我们的专业能力，这是客观基本问题；
- 现场的PGM在汇报问题的时候，没有明显区分客观事实、推理、提案这三个部分，导致客户在不信任的情况下，很容易抓住把柄，进行反攻，将所有问题推卸到我们这边；
- 上面这些问题在过去的几个月当中反反复复，导致了双方的决裂；
针对这些问题，我制定了解决方案：
- 将问题的真正所在，以及问题产生的机理告诉组里的工程师，并让他们修改代码进行实际的验证，将验证结果做成报告；
- 由我暂时接管现场的项目管理工作，让可怜的PGM回酒店好好洗个澡，刮个胡子理个发，然后美美睡上一觉；
- 将汇报内容按照客观事实、逻辑推理（问题原因的推测）、修正方法的提案这三个模块进行重新组织；
- 与客户沟通的时候做到对于客观事实双方必须一致确认，对于逻辑推理双方进行逻辑上的互攻、对于解决方案提供多种方案供用户选择
凌晨3点钟，对方的部长带着几名资深工程师下来了。课长首先向他们介绍了我，说我是DLNA方面最好的专家，并且在skapa实验室作为主要技术人员与日本的各大电器制造商成功完成了对接，目的是让对方认识到我们很重视这个项目，也为我添加谈判的砝码。
接下来我首先代表公司对项目的进展情况表示由衷的道歉，同时指出当前的首要任务应该是尽快解决问题，而要解决问题必须保持高效正向的沟通，对话的决裂会使得项目停滞不前。
然后，我按照前面的叙述框架，将目前所有没有解决的问题一个一个梳理了一遍。每讲完一个客观事实（对问题的定义），我都会询问客户是否承认这个客观事实，描述是否完整。这样做的好处是避免由于对问题的不同定义而引起的分歧，而且其实也是将问题的范围锁定住，避免客户那里因为测试不充分在后面不断地扩大问题的定义。
在客户的部长表示对问题的客观事实认同之后，我具体阐述我们对问题发生机理的逻辑分析。这个时候需要注意的是，因为客户并不保有和我们一样的底层知识，所以仅仅用我们具体实现的现状去说服客户是不可取的。因为这里有个信息不平等的问题。
所以，在说明的时候不仅要说明我们目前是怎么做的，而且要说明为什么这么做，是否有其他的替代办法，各有什么利弊。要做到客观通俗，逻辑清晰。
最后，我提出问题的解决方案。这里常见的问题是，往往双方都会倾向于选择不需要自己动手的方案，也就是将工作量推给对方。但是由于双方在合同关系上存在着委托关系，所以被委托方往往会被欺负。这在工程师这个层级可能是无解的，所以就要充分给站在更高角度，对项目全体负责的人讲明白，哪种方案是对项目整体最好最自然的。这样就可以得到对方管理职的帮助，对方的工程师也就难以将工作完全推过来了。
这个会议一直开到天明，对方的部长终于理解了当前问题的全貌，也意识到很多问题是需要双方共同解决的。会议之后双方工程师立马开始了解决方案的执行，而我被对方的部长叫到了3楼，与他们的技术负责人再次开会，将所有open的问题都过了一遍。
临近中午，我才终于有时间回到酒店，但是酒店已经帮我调换了房间，我的总统套房就这么样没有了。
为了帮助现场年轻的工程师解决问题，我继续在神户呆了一个月左右。但是因为我手上还有自己的项目，所以我没等项目完全结束就回东京了。走之前客户请我们吃了神户牛肉，非常美味。
文礼简阔 