关于设计的可扩展性。

假如在开发的过程当中，我问了一下“代客户”关于需求的一些问题。他一时也不太清楚，那他只好打电话给“真客户”了。那边一时也说不清楚，那看来我今天是没事情做了。等他问完了需求回来，说了一大堆给我听。完了我要问的东西他没问。

ft，你不能假设业务需求人员水平很差，然后再说“代客户”不好。
如果你们公司没有更好的业务需求人员的话，我建议让你去当，但是必须放弃技术决策的权力。

嘿嘿，开个玩笑。

呵呵，让他再去问吧。

如果不行，要亲自把问题交流清楚的。

客户也有无法确定，需要请教更加了解需求的人。

那就是南海问题，搁置再议

千万不要做自己认为"应该是如何如何"的系统，那样的代价太昂贵。

我对xp的一个理解是它相对传统开发方法而言把很多责任移到了别的什么地方去了。
比如现场客户，就要求这个现场客户能够拍板定怎么做，并且能够和你沟通，让你获得你要的东西。

哎哎，扯开说一下
假如合同已经签了，但是用户方用这套系统的部门还没有成立，这个部门的职责还在讨论之中，派过来的人有想法但是互相矛盾又没人敢拿主意担责任，领导能拍板但是又很忙老见不到，而且也不太会坐下来谈细节的功能。

咋办？

但我们也不能总是假设需求人员的水平很高。我是想说开发人和真客户中间隔了一个需求人员，使得开发人员不能真正面对客户的需求。让开发人员直接去做需求调查不是很好吗？会有什么问题吗？难道就因为xp中要求开发人员只作技术决策吗？

等死吧。热脸贴上冷屁股，注定是个失败的项目。

咋办？ 这是中国特色的东西自然要用具有中国特色的办法解决了。

  1、送礼
  2、公司领导和对方领导直接峰会确定步骤
  3、实在不行，就忙其他项目先，不过保留一些你们确实要求对方解答需求的证据，只是对方没有回复。万一闹疆了，还有个道理可说。

  一般情况下，不会为难你们的，多玩玩CS也无大碍。

  除非，你有能力在没有客户需求下作系统啊。

  当然，对于负责任的群体来说，以上都是扯淡

作为xp的定制，我想也只能让开发人员做需求调查了，但这么做的后果undefined。需要修正其他的实践了，可能能和xp刮上边的就只剩集成测试和结对编程了。
再一个方法可能就是用通讯手段弥补一下无法面对面交流，怎么着沟通非常重要。

呵呵，还好，这个项目搞定了。