按照道理说，应该由相对专职的客户调研人员完成，输出是软件需求调研报告，或者更进一步---软件系统需求规约。。。

但是鉴于软件需求的不容易把握，团队成员沟通需求的成本很高，而且沟通质量堪忧，所以希望把小团队全部拉到现场，有需求调研员（项目经理兼任）灵活组织该过程，目标是让团队成员尽快介入需求过程，同时也可以提供不同的视图，减少沟通成本。。

但是这里有一个问题：开发人员的专长不在和人沟通上，可能会在客户中引起沟通障碍。。。

老板认为这个方法不行，仍然坚持由1~2人有经验的人完成需求调研工作，理由是没有必要和角色需要分工。

我很头疼，求治疗高招，谢了~

One Aim,One God,One Life. || 最爱:偶家阳阳 || 博客:愚人camer || MSN:camellxr@hotmail.com

在我的概念中，需求是一个持续的过程（所以需要需求管理），就是在需求获取过程中，不管你做到什么程度（当然要想尽办法获取真实的需求），客户的需求仍然是不稳定的“今天说的，明天就变了”的事情很容易发生，在需求得到认可后（客户签字），仍然有一种机制适应需求的变更（变更控制过程）。

在做调研之前一定要目标明确，一般在签订合同时会规定一个项目实现的范围（但是经常情况是边界不清晰，头疼！！），调研前必须要详细研究这个范围，提出一系列的问题清单，甚至要把沟通路径提前建立好。然后才面见客户/用户，这一点lshcom 讲的很明白。

另外，调研的技巧很重要，经常实现人员会诱导用户，就像病人看病，如果医生诱导病人，也许病人会疑惑的以为自己得了几种病，如何把握诱导的成分很重要。

对于我提出的问题，好多人都不认可我的提法，因为开发人员做业务调研不合理，不过换一个角度，在我们的过程成熟度不未到达cmm2的程度，在小团队中对开发员的依赖很大，一个懂业务的开发员和不懂业务的完成的功能差别很大。所以我提出尽早让开发员涉足业务需求，这里当然需要sa和业务专家主导，开发员仅仅参与（同时他们不同的眼光可以发现技术上的风险）。

One Aim,One God,One Life. || 最爱:偶家阳阳 || 博客:愚人camer || MSN:camellxr@hotmail.com