前次简报中，售前部的冯雪武写了关于需求的理解，文章写得不错，把需求调研的方法论大致描述了一下，

我在这里写一下需求、沟通、设计和文档关系。

首先，不能把这4者割裂开来看，就像业务、管理其实是密不可分的一样，需求调研就是不断的沟通、确认、再沟通、再确认。而设计工作是基于需求调研的结果，文档则是设计和需求的结果和载体。

其次，很多开发人员、实施人员有个误区，以为需求调研完毕后，需求就不会动了，这时才可以进行开发工作，但很多情况并非是这么理想的，根据我的经验，需求的变动，存在于软件系统的整个生命周期，在任何时候，需求都有可能变动，我总结出下面的几条“定律”：

1、客户一定不是专家

开发人员的理想就是最好客户既是IT专家，又是业务专家，问题是这样的“极品”是非常罕见的，我这么多年经历这么多项目也只见过1，2个客户方面的主管是这样的专家，其实这1，2个所谓的专家也是相对而言的，人的精力有限，不可能是面面俱到，因此客户一定不是全才专家。

2、客户一定说不清楚需求

如果客户是IT部门主管，那么他们一定不懂业务，极端情况是连IT也不行，所以他们需求一定是所不清楚的；如果客户是业务部门主管，那么即使他们能说清楚业务，那也一定是基于本部门的

业务来说的，而且他们基本上不会懂IT，所以也很难跟开发人员沟通，因此也说不清楚；而如果客户是单位主管，那就更糟糕了，一般他们是业务懂一点皮毛，而IT似懂非懂或者一窍不通，这样的客户最难处理，如果完全不懂那也好处理，顶多是我们累一点，最怕就是懂一点，就会出很多无法预期的奇怪需求。根据我的经验，与IT部门主管沟通起来会非常顺畅，因为他们会很理解软件的局限性，所以一般不会提出过分的要求。



3、即使经过几次确认，但是需求还是会变

这时一个痛苦的经验，很多次，我曾经以为需求不会再变了，因此，我在设计的时候都没有考虑到可变性或者可扩展性，其实，通过血的教训，我总结出这条经验。因为，调研一定是不足的，我们不可能满足所有的需求，而这些没有被满足的需求就是一个隐患，说不清楚在什么时候就会被提起，引发这些需求的，可能是客户兴之所至，可能是下面操作人员的一个抱怨，可能是双方的妥协结果，因此在任何时候都要考虑到可能会有需求变动，即使软件已经开始试运行。

4、如果在我们与具体使用的部门发生争执时，客户一定是帮使用部门的

这时一个显而易见的定律，如果他帮我们，岂不是显得和我们有猫腻？而如果客户是IT部门主管时，这个问题更加严重，因为客户不懂业务，只要使用的部门一往业务上提，客户就会傻眼，想帮也帮不上。



基于上述的这3点“定律”，我们要掌握好几个原则：

1、我们不是客户的小工

这时最忌讳的，如果我们成了客户的小工，那么客户就可以满嘴跑火车，想提啥就提啥，而我们根本就没有拒绝的资本，可以参考镇海项目的教训，所以，我们开发人员首先就要树立一个原则：我们不是你的小工，客户提的需求，一定要经过正式的讨论、论证，并经过正式的流程确认才能成为我

们的工作，如果做不到这点，那一定是万劫不复。

2、客户嘴里的需求不一定是真正的需求

客户提出的需求，开发人员一定不能将其当作“圣旨”，我在第一点说的“正式的流程确认”就是让我们能讨论这些需求是否合理，是否不用修改就能实现？能否找到更加合理的做法？这些需求是否合理？代价是否过大？因此的变动是否有牵连？这等于是一个过滤网，把不合理的，代价大的，很难实现的都尽可能的剔出去。

3、需求是分级的，不是每个需求都一定要做的

需求通过了过滤网，那就一定要判断其优先度，这就要靠项目经理的功力了，如果能顺利的判断出客户的核心需求（项目价值）那就是事半功倍的效果，对于最优先级的需求，一定要尽早、尽可能好的实现，并不惜代价，确保其稳定性和表现度，客户如果认为其项目的核心价值实现了，那么项目

基本就可以及格了，其他的需求，可以以此为资本跟客户讨价还价的，如果太难实现的话，可以通过沟通慢慢磨，这在以后讲。

4、一定要掌握客户曾经对我们的承诺或者允许的可靠证据

这时一个重要的问题，任何我们与客户的沟通、确认、会议一定要留下被确认的记录，如果证据不能被证明，那就不是证据。简单的说，就是“空口无凭，落笔为证”。根据我的经验，有以下几种推荐的方法：

（1）、最好的沟通方法是MSN，即快捷，又留痕，我曾经不止一次的在MSN的沟通中得到有力的证据， 因此我们要不遗余力的培养与客户使用、依赖MSN的习惯。

（2）、其次是邮件，而且邮件也是正式确认流程中最主要的方式，所有的沟通最后都回落实为邮件，不过邮件的缺点是太慢。

（3）、会议，会议一定要做会议纪要，如果有条件还应立即得到与会者的签字确认。

（4）、电话，电话由于无法留痕，因此只能作为应急手段，电话中沟通的内容一定要落实为邮件。这是关键点。