在外工作（二）

在做的这个项目是为一个遗留系统提供Web Service，从技术上来说并不复杂。说起来就是接到请求，然后调用一下已有代码。

让这个项目有难度的是后面庞大的遗留系统。整个系统大概已经有十多年的历史了，已有codebase里面大量运用的JDBC可见一斑。真正要搞清楚如何把接收过来的请求对应到现有的代码上并不是那么容易的。虽然我们很快就把主体代码完成了，但随着项目的进展，对系统的不断发掘，一些遗漏的点就会不断显现出来。

客户有一个对系统比较了解的人和我们一起工作，但事实证明，他也不可能对每一个细节都了如指掌，更重要的是，他也有别的工作，不可能与我们时时刻刻在一起工作，这也在很大程度上增加了我们工作的难度。所以，我们更多的时候，要靠自己发掘问题，然后，和他确认我们的理解。他很忙，找到他人是件很困难的事情，与我们约时间，他很少有准时到的。原来，在忙碌的甲方问题上，国内国外都一样。

虽然我们是在用敏捷的方式进行开发，但是，客户并没有以敏捷的方式与我们衔接。比如，挂在Story Wall上的卡大多数都处于Ready for QA的状态。客户的QA从我刚刚到这边的时候就说要加入，两个星期过去了，QA的人除了standup和showcase之外，就只和我们真正坐在一起不到两个小时。每次我们的PM和客户提起这个问题，他们总会抛出各种各样的理由，证明问题不在他们身上。原来，在自保的问题上，国内国外都一样。

行将发布之际，我们解决了主要问题，要扫一些边角。于是，和我们的技术接口人进行讨论，他看到我们的开发速度比较快，于是，做出了一个有神来之笔的决定，让我们开发另外一个需求。是的，另外一个需求，不只是简单的修补。和客户讨论完，我们有些晕，怎么就又冒出个这么大的需求。于是，我们赶紧拉来了我们的PM和另外的同事一起讨论。冷静下来之后，我们明确了一个方向，要和这个接口人仔细讨论一下，不盲目承诺。事实证明，他也确实没有想明白，第二天，见到我们，还没有等我们把精心准备的问题抛给他，他自己就说，他和别人开会讨论了一下，这个需求确实不该放到我们这里来做。原来，在天马行空的问题上，国内国外都一样。

说来说去，这种企业级项目，人总是一个问题。