需求不评审，没有一个项目组跟进这个需求并为她的变更负责任，那么这个项目估计是永远作不完的。因为作出来的可能永远不是用户需要的。

同一楼上的：）

我只想明确的告诉你，对方跟本没有诚意与你合作。他们没有什么兴趣要你们的产品。
一个项目如果没有合同，是很难做的，除非是零售产品。公司的老板在没有与客户定下意向就开始开发，这本身就注定了这个项目的难度。
而如何开发，开发什么，你想怎样就怎样，没有约束的产品不是更容易开发么？难道你还得为整个项目负责？非得给有个框框，才能写代码呀？你可以自己给自己定义个框框呀，呵呵~~

应该有用户协议呀

请用户吃饭，尽量和用户处理好关系。人心都是肉长的，只要表示足够的诚意、足够的尊重，并且适时地吐吐苦水，相信用户在力所能及的范围内给予相应的协助的。

技术的问题，往往需要非技术的手段解决。呵呵

客户不一定是不想告诉你，有的时候，客户都无法准确描述自己的需求。
一种方法是你们能够提供很好的模板，引导客户把需求比较好地描述出来，另一种就是快速推出原型，让客户直接反馈。

我在这里想对测试的同行说一句：

我们的主要工作是测试；如何开拓市场，如何开发，以及如何与客户交流取得第一手需求资料，不是测试的主要工作。假如你能把这些都能处理好，你就不再是在做测试了，而是在做PM，在做Market!

我没能够在任何地方看到测试人员的工作内容还包括这么一部分，与客户交流并取得需求资料。测试人员要了解需求，但并不直接从客户处了解。

即使你了解了，你也不能决定开发人员如何开发，不能对这个项目负责。因为这个项目要由项目经理来负责，而如何开发则由具体的开发人员来决定。他们是真正要了解需求的人！作为测试人员首先要了解的是项目经理对客户需求的理解，以及开发人员对需求的理解，从而知道将要测试什么， 如何测试等等。

引用:

原帖由 Nio 于 2006-4-18 16:12 发表
我在这里想对测试的同行说一句：

我们的主要工作是测试；如何开拓市场，如何开发，以及如何与客户交流取得第一手需求资料，不是测试的主要工作。假如你能把这些都能处理好，你就不再是在做测试了，而是在做PM， ...

说的对。这些都不是我们测试人员的分内的事了。 让你的需求给用户确定签字，如果客户认为那边不合适，不跟你签字确认。那一定要他说出理由。这样不就有想要的需求了。如果他没有理由。那就签字同意吧。那就搞定了

项目经理的天职是什么？搞定客户阿！

呵呵，看了这个帖子很有感触，我即将去一个公司应该不会有这个问题了！
这个公司对测试要求高哦，测试是要面对客户的，直接面对哦：）
他们可能想做的是测试驱动开发：）希望真正做到做好：）期待中........

总结楼上的：

1、搞定客户
2、你需要一堆杯子，然后问客户，那一个是你想要的，然后签字确认，或者进行评审

1、从搂主的描述看，楼主的公司其实在这个行业应该还是有一定的积累的，但这种积累并未被整理，以致每一个项目都是一个教训，是一个客户需求不明确的教训，而不是一个总结后的经验；
2、我们应该理解客户的弱智和傲慢，但我们绝对不应该漠视这种默认与傲慢。既然客户不能提出明确的需求，那么我们就记录客户期望的目标，我们的领域专家可以根据以往的经验提出我们的解决方案，让客户做选择题；
3、拉客户下水，这一点很重要，要想尽一切办法拉客户下水。不一定是管理层，管理层没这么多精力。对方应该也有业务领域专家，一开始的kick-off就建立这种机制，识别这些相关领域专家的角色，以便必要时候能和他们一起做用户需求开发工作；
4、领导的意志：把成文的用户需求召开一个很正式的评审，邀请客户方有代表性的人物参加评审，是很关键的。关键是你如何打动客户，让客户参与到评审中来。不管是糖衣炮弹还是苦口婆心，只要是达到目的了，你就成功了

那就叫他做好了.

其实我觉得大多数时候,是客户不知道自己具体想要的是什么.

所以一定要有一个原型的东西给他去参考,让他找出他想要的是什么样子,
或是不想要的是哪些.

客户并不是专业人员，所以他们不会给你很详细的资料，我觉得这就要相关人员去引导客户。

在没法得到很好的沟通时，就去观察他所在的背景，世面上有的产品和应有的理解做个原型出来。
做第一次验收。

客户有需求对你们的要求肯定有考虑,主要还是在沟通上,如果你们都没把握好需求,那在研发上很容易出问题的,尤其是后期,客户很可能会修改需求而且是大量的修改,会造成彼此在金钱,时间上的大量损失

希望我们公司不要遇到，要不然。。。

其实这个话题严格意义上已经不属于需求管理的范畴了，而应该是项目管理范畴，项目经理也需要和客户套套关系的，管理之外的人情有时会反过来对管理产生很大的影响。人情关系的好与坏，反映到项目管理中可能是天和地。sdlkfj2

小弟我受益非浅啊，原来需求分析那么难搞定啊~但又条条道路同罗马啊~