关于设计的可扩展性。

嘿嘿，但是这个客户肯给你好多钱……比其他肯承担责任的用户10倍的钱……

用户不肯签字，你是不是准备甩手不干呢？

不会。只要老板认可，我就继续做下去。但如果真是这种情况，老板也必须给我一个承诺，失败了不能找我的麻烦，不能找开发团队的麻烦，要清算责任就去清算marketing和sales，连客户的责权都分不清就敢签合同。

呵呵，这不就结了，实质是还得干下去。
当你来上个两三次这种过程以后，你就发现无论你怎么操作，最后结果都差不多，所以就很难再一遍遍的走这么复杂的流程了。

我现在的做法就是一纸风险列表给老板，一二三等风险一列，也不指望他能帮自己解决，然后自己管自己往下做，反正车到山前必有路……

不明白：
1.到底让开发人员做需求调查有什么弊端？
2.让一个懂技术的但又不做开发的人做需求调查很好吗？

我个人认为可以让开发人员做需求调查，在项目中增加一个对业务熟悉的人来指导。这样对以后的设计开发都比较有利。

呵呵，我觉得我前面已经把我认为的优劣都讲过了。
其实关键并不在于业务人员和开发人员的分离，而在于业务人员的能力是否足以担当起相应的职责，如果最后变成一个传声筒，那还不如没有。
但是如果业务人员能够担负起相应的职责，你就会发现很大的好处的。

另外，很多项目对业务需求的分析要求不是很高，客户就可以把自己的需求讲清楚了，而开发人员也承担了一部分业务分析的职责，这种情况下确实可以不把业务人员独立出来。

clamp，你带来的这个客户这么难缠，是真的碰上过吗？

到这份上，合作是谈不上了，就看项目终止谁的损失大，坚持到底，看谁先妥协，关键不能窝里反

恩，03年9月份接的项目，04年1月份系统建设完毕验收，2月份该部门正式成立，系统上线正式运行。撑了8个月后我们用一套新系统把它换下来了，原系统在运行过程中发布过五六个更新版本。

其实用户代表（一共三个）并不难缠，很好说话，也愿意提意见，但就是很难决断拍板，也不愿意签字，毕竟他们职位低，很多事情不是他们可以说了算的。

大家还是太理想化了．
我作为客户代表，远没有那么好伺候。而各个部门作为我的客户，对于需求的考虑并不仅仅是业务问题那么简单。
说白了，现在企业的单子，一般都是在了解大致的需求范围之后就签掉的，除非出现重大的变更，否则都不会再次坐下来讨论商务问题。但是，有一个很重要的问题就是温水煮青蛙，绝大部分项目都是这样煮残的.
还有一个关键，就是态度问题，项目组是来做项目的，还是做事情的。

如果项目涉及到的业务领域对项目组而言是陌生的，设计的可扩展性我的经验是不要过多考虑，项目后期变更频繁，跟系统设计的扩展性好坏没有太多关系，有这时间还是都和客户沟通，多和业务专家沟通。很多项目组因为没有专业的行业顾问，肯定是客户提什么项目组做什么，项目组还没有什么能力去考虑客户业务发展的方向、客户管理流程的变更之类的问题，技术的可扩展性是建立在业务的扩展规划上的。

企业管理应用项目的开发实施，对客户而言，业务专家和行业顾问的重要性远远高于技术人员，项目在实施阶段的变更主要是两种：
业务方面和使用方面，后者无非是添加几个查询条件、调整页面元素位置之类的，很容易也很繁琐，我的经验是没有什么好办法能解决，我们用界面原型给客户确认、培训不下5、6次，到用的 时候还是会一堆小的变更要求，没什么，改就是。
真正麻烦的是业务的变更，比如原来的模式是内网集中式的管理，为适应公司的管理变革，今年要将部门的管理工作全部下到全国各大区，这样就会有分级申报、审核、汇总、审核之类的处理，这些业务变更，如果对行业和业务领域有深入认识，会在项目初期就和客户的业务主管充分沟通，对其不合理的流程提出改进意见，否则，客户提出业务变更的时候，要么改，要么由商务人员来处理了。

呵呵，好象又有点跑题了。

还是单纯从技术角度来谈一下设计的可扩展性吧。
不是针对业务的变更，而是针对外部技术环境的变动。

举个例子，一个项目里面有一个导出word文件的功能，实践发现在不同的office版本下程序会有差异。

用户目前统一使用office97，用户声称他们每隔一段时间会由整个公司统一升级，但是下次升级的具体时间未定，升级到什么版本未定。
用户希望一旦升级以后该程序可以尽快的迁移过去，不影响他们正常的业务使用。用户愿意为今后的程序迁移付钱，但是对进度的要求非常严格（假设最多为一个月）

在这种情况下，在技术层面如何考虑扩展性?