问题：
我们公司有不少的软件项目，但是如何避免现场开发这个问题上没有很好的处理办法，尽管大家都知道现场开发弊端多多。
请教各位是否有什么好的办法？
papachong：在XP极限编程之中，现场开发是一件不错的事情，当然需要客户沟通比较好，另外，适合小团队2-10人的开发。
zhjohny：行业软件，因为版本的控制和人力资源合理使用的问题，应该最大限度的避免现场开发。但是如何避免呢？
Jennie：这要看你具体的客户要求了
我通常用的方法是，告诉客户：
我们的开发需要XXXX开发环境，你们能有吗？
我们遇到技术问题会组织公司的技术委员会讨论，在现场是做不到的
我们相对封闭的测试环境，各种测试装备和用例你们这里有吗？
……
列出一大堆客户不能满足，但影响开发的条件，让客户自己抉择吧
如果客户过于执着，也就不好办了
这个方法在开发的阶段80％左右比较好用，如果到了上线阶段，这一切都没有用了
zhjohny：Jennie说的如果相客户解释是非常正确的。
现场开发主要是两个因素导致的，有客户的原因，也有自己的原因。
我想知道的是，大家有没有什么好的管理办法，解决因为自身原因导致的现场开发，主要问题仅仅处在项目管理上面吗？
白菜：避免现场开发，那么对需求调研准确性的要求会很高，而且用户需求的变化不能及时跟进也是个问题。
zhjohny：是否可以概括成两方面的问题：
1、客户方的问题：
客户总觉得开发人员不在场，对项目的成功信心不足。
2、软件开发商的问题：
bluestone：客户的需求永远是变的，永远是该不完的，所以现场开发是个错误。我们的项目6月份现场开发，计划7月结束，现在还在进行开发阶段，大部分的功能都已经与需求的不一样了
zhjohny：如果我们能够不现场开发也让客户时刻感到我们在他们的身边（比如定期的周报，完备的计划，计划一步步执行，并按时给用户提交里程碑或是阶段文档），那么客户也不会很强烈的要求现场开发；如果我们的项目管理水平和软件开发水平能够高一些，我们就不会不能按计划完成高质量的软件，也就不需要把源码带到现场了。
我正在做一个项目，快上线了，是这么操作的。客户基本满意，我们也没有现场开发。
focuser：现场开发是软件开发的原始做法：）
现场开发主要原因是:
不熟悉要开发的软件项目的业务，拿不到明确需求。一般都是公司新开辟领域的项目。只好到客户那渐进明晰需求，同时进行定制开发。
办法：
一般来说客户不关心你是现场开发还是在公司开发。说服客户不在现场开发容易，加强系统分析人员对客户需求的调研力度，做熟悉的行业是解决避免现场开发的一个办法。我们公司现在就很少接不熟悉行业的定单。
zxk91：我们公司项目大都拿个版本，一个项目组到客户现场客户化，集成测试，上线。
我也是认为
“（比如定期的周报，完备的计划，计划一步步执行，并按时给用户提交里程碑或是阶段文档）”
我们公司这种项目管理还处在比较原始阶段。如果项目管理做的好，是项目可视化，确实有利管理和规范
bjyr：感觉上，比较好的生意是，谈单字的时候，除了要谈公司的行业解决方案对客户很适合，也要谈必须做不少二次开发，以便突出成本，防止客户过分压价。
在实施过程中，尽量减少二次开发，即使开发也尽量不要去客户公司进行。
camer：xp方法强调现场客户，其实也可以理解为现场开发，如果有良好的组织，现场开发不是什么不好的，不过xp一般的做法是把客户请到公司来，配合开发团队，因为在客户的环境中，毕竟还没有公司的开发环境提供的支持好。。
lookmezh：如果找到客户代表人,即利益相关人,就可以由他现场指导.不过,一般客户仅对功能表示一些需求.而开发过程还是由RD自己完成比较好.毕竟客户过多参与,会产生无穷的需求.
另来,一定要知道,哪些客户才有产品决定权,哪些客户有支付权.
yxqselect：我觉得是否现场开发不是项目成败的关键，关键整个项目组的综合是否胜任本项目！只要能获得需求，开发场地根据项目成本来定，如果客户能提供优厚的现场开发条件，也可以到现场解决。
wuzh：客户的需求设计和信息化设计应该同步进行；概要设计必须在现场进行沟通和交流。
需要成熟的客户、畅通的沟通、合理的软件开发模式
mkopen：软件尽量做的灵活，争取在现场配置软件，而不是开发软件。这是软件成功的关键
zhjohny：同意楼上的观点。对于成熟的行业，可以尽量组件化；不太熟悉的行业，设计模式的思想很重要。
henny：根据我们的国情，现场开发，项目成功率比较高
可以让用户（项目干系人）参与到项目中来，能得到他们的认同和支持...
camer：现场开发比较常见哦，不过现场开发不容易控制节奏，也缺乏变更判断的严肃性，毕竟内部的研发环境要有利于开发得多。。。我还是本能的想回避现场开发发生率 ：）
谈一下自己的看法：现场开发有它自己的不可替代的一面，尤其在一些特殊的企业（譬如说这个行业在国内很少,不居可比性），大家对它的
业务都不是很熟；或者公司以前在这行业涉及经验很少。如果前期的业务调研、需求分析做的细的话可以在公司开发，但实际情况往往是这个
前期的需求一般都不可能做得很细，而且非常切合用户的需求：在开始阶段客户往往也不能够描述一个自己想要的东西,此时一定要和客户确认
好本次要完成版本的业务范围,给各个业务需求做优先级,确定哪些方面是客户最关心的.现在稍微大一些公司都有自己的信息中心,如果你想从他
们那得到真正的需求，呵呵那你可就惨了：P，我有教训在里面，他们对实际业务其实也不是很清楚，而其在企业中有没有实权，不能要求实际用
户按他们指定的流程完成业务，所以一定要和实际用户会谈（一定要）。在做详细设计时有一个简单但很有用的办法以验证当前的设计没有偏离
客户的期望：做界面原型图，附在系统详细设计说明书内，和用户讨论业务流程和各个流程中的界面。这样做的好处是可以给用户对系统的一个
直观的认识（虽然现在系统还不存在），帮助客户发现系统中的问题，而且这样做的一个好处是可以个客户一个先入为主的感觉，将客户的需求
限制在一定的范围内，不会在提一些乱七八糟的要求。可以将项目的开发计划发给客户，定期向客户汇报一下进度，如有可用的版本（哪怕
只有一些简单的功能）可以发给客户试用。在开发的过程中如果发现有什么重大的问题（譬如说以前设计的业务流程有不可操作性或者
有什么异常发生会导致系统不能够正常执行，对异常和例外怎么做特殊处理）一定要和客户沟通，做一个圆满的预防或补救或限制。无论你做得
再详细细心，到现场仍然会有这样那样的事情发生，记住一句话：客户的需求永远都在变，需求无止境。所以在项目的后期对客户提出的种种要求
要尽量避免修改（除非不修改这个需求导致整个业务无法进行下去），这是就要看项目经理的水平了：怎么说服客户或者能提供变通的方法（呵呵
你也可以告诉客户这个功能无法实现，要等microsoft的下一代操作系统发布以后才能给他们升级）。不过在现场不做修改是不可能的，在开发过程
应该注意下面一些问题：版本控制、源码管理备份。还要注意团队的士气，如果碰上特别刁钻的客户，无止境的修改很快就会把大家的热情折磨的
无影无踪，项目经理有责任想办法激励大家的斗志.碰上刁钻的客户可要做好两手准备，软硬兼施，必要时可以向他们大吐苦水，博得同情啊:)
