是先做需求分析还是先签合同呢？

[kueixing]

我有一个问题觉得很矛盾，需求过程分四个阶段：可行性分析、需求导出、需求描述和需求验证，但我觉得从需求导出开始就已经很深入，做得很细，而且需要花很多时间的了，这样应该是在签订开发合同后才做的工作。但如果先签订开发合同，而你对需求都不了解，无法以需求文档作为合同附件，无法确定收费，那么你又怎么签订合同呢？这样不是很矛盾吗？

[mis98ZB]

在拿到订单之前，客户怎么会把细节部分公布出来呢？
所以都是有个大概的概念就开始竞标，拿到订单之后还要重新分析。

特别是有些性能或者技术上的要求，虽然是细节，但是代价很大。
这时候就要跟客户协商，追加预算什么的。

[kueixing]

本想结帐了的，但看有这么多人发言，我想再留多两天，大家踊跃点讨论一下拉，看有没有好点的方法啊

[DT1156]

先做需求分析，还是先签订合同？
这的确是个很矛盾的东西。用户的需求往往涉及用户的具体的业务流程，客户是否愿意让你了解这些业务流程？客户是否能够提供充裕的时间来配合你进行需求调研？需求分析详细到什么程度？你又是否能够冒多大的风险投入巨大的人力物力？
较为合理的办法，还是应该引入信息工程承的咨询或者监理服务，这种服务可以是分阶段的，比如开始的项目可行性论证到项目招投标结束阶段，这种服务的费用相对要低廉一些，客户应该能够接受。这样就解决了客户对信息系统不熟悉所导致项目的盲目性。一个合格的咨询公司或者监理公司虽然不具备工程项目实施的操作能力，但是也能够以比较专业的角度来审视问题。在完成项目论证以后，帮助客户选择合格的系统开发商。
当然，我指的咨询（建立公司）是合格的，不会和开发商合伙糊弄客户。

[kueixing]

大家说的都是一般的情况，都是客户本身先有做系统的意识或需求，然后出标书让各个公司竞投。开发公司拿出设计方案竞争。
但我现在碰到另一种情况，那就是客户本身一开始并没有对企业进行信息化的意识或需求，但看过我们为其策划的方案后（就是告诉他们应该并且如何进行信息化，会有什么好处），对此很有感兴趣并表示要做，那么此时客户的所有需求都是我们提出来的，客户自己真实的需求还是隐含的，未被我们引导出来。我觉得这种情况如果我们不先进行详细的需求分析，充分将客户的需求引导出来，风险会更大的。
对于这种情况大家有什么好的建议呢？

[kueixing]

顶上去

[BirdGu]

决定这个问题的，往往不是技术因素，而是市场因素和客户关系因素。
上面有几位提到了在合同里如何如何规定，但合同条款是一回事，实际执行就是另一回事了。还是中国那句老话：“店大欺客，客大欺店”。甲方、乙方的关系并不会因为法律规定了它们是平等的，它们就平等了。

[熊猫哥]

to DT1156()
你说的那种情况属于方案推荐，前提当然是你提出完整的方案甚至是产品后由用户决定选择什么样的东西。正常情况提出方案的公司要对某个行业有深入的了解，并且要远远超过现有的一般从业人员。

拿原始工业来说就是定做与选购的区别。

[hewei2003]

如果你的竞争对手很多，那得先签合同，否则得先做一下需求再说

[supper22]

这是个经验问题，刚开始不交点“学费”怎么成大事呢？

[samuelpan]

我们公司的需求分析是拿来招标的，然后确定软件开发商。

我们认为,一般软件开发商不大可能是某个应用领域的需求分析专家。

[zhouguoyao]

up

[clamp_chen]

这确实是一个很麻烦的问题，尤其是在客户和开发商相互之间的信任度不高的情况下。

从软件开发商的角度，我把它归结为这样几个问题：
1、如何在未签定详细合同的情况下花费尽量少的前期投入更准确的了解用户需求？
2、如何在合同签定的不够细致的情况下在项目实施的过程中控制需求变更？

一般来说，前期调研应该可以把大方向和范围谈妥，然后签定合同，但是很多细节
不会涉及到。一方面受限于开发商本身的认识，更关键的则是缺乏客户本身的强力
配合。

但是在定了大方向之后，如何控制细节变更，仍然是一件非常头疼的事情。
这需要项目实施人员对于用户的任何一个变更要求都要有非常敏锐的认识，并且能够
理解到它是否超出了目前项目的范围，或者是否会引起新的变动。
在很多情况下，客户会提出一个接一个的“小”功能，但就是这些小功能可能会把进
度拖延几倍！！！

[sxzz]

业务--用户需求--解决方案--合同--需求分析--系统分析与设计--实施
我觉得这样的划分可以比较准确的明确责任或分工，用户--第三方咨询--开发商，可以在不同阶段参与项目，作为开发商，从哪个阶段入手应视具体情况而定，风险总是难免的，关键是你有一套风险控制机制，同时有一套赚钱的商业策划机制（如先免费后收服务费等）。如果这两方面你都没有解决，冒险是肯定的。

[rolandash]

我的看法是，这个问题很难有一致的回答，需要根据不同的情况来做不同的处理。

对于一些风险性比较大的项目，比如某种新产品的研发，试图只在简单的需求调查后就确定合同金额实在是太冒险了。所以对于这种项目，一般还是分阶段地实施，每个阶段单独签署合同比较好。

对于一些比较简单和成熟的应用项目，工作量基本上可以根据以往的经验估算出来，相差不会太大。所以不必做仔细的需求分析而签合同是可行的。

当然还有很多皆与两者之间的情况。这些项目的操作就需要依赖双方操作人员的具体经验和信心了。当然，在不确定的情况下，分阶段实施会是一个比较保险的做法，但对于招标的一方可能负担会大些。

[turnmissile]

看来看去，还是不明白，通常一个工程应该是在什么定下具体收费的？
1。简单的需求调查之后，签订合同，确定项目费用。
2。简单的需求调查，签订合同，确定大概费用，再进行需求分析，和客户协商,根据情况调整费用并确定。

到底应该是怎样的流程呢？

[lovezpl]

先签合同

[linnet2000]

1、先做可行性分析，从经济，技术等方面进行初步的，总体的分析，这里主要做的是业务的需求，可行的话签合同。
2、详细的需求分析，这个阶段就要确定需求的定义，范围等用户需求，功能需求方面的工作了。

[freedom2001]

其实主要是看是什么样的公司了，很多正规一点的大公司一般都是先做需求后签合同，如果先签了合同再去做需求，那你的费用很可能严重超支，甚至赔本。而很多的中小型公司则会先签合同后做需求，因为他们的能力有限，所以所做的是一些中小型项目，对他们来说可以比较好的控制成本和需求。楼主的问题不能单纯放在软件工程或工程实施的面上来讨论，一定要切合实际。对于有经验的系统分析人员，他们在拿到需求后会在短期内对需求做出一个大体的估计，这也就方便了后面的决策，是该先做需求还是先签合同

[go_my_sky]

要看对方公司规模、项目规模而定。
没有一定的模式。

[a00]

其实也很简单，对己方来说最关键就是能够获得最高的利润和最低的风险，包括眼前的和长远的；对对方就是实现最大的客户满意度和质量。拿这个尺一量，呵呵，就知道该怎么办了。