法则4：不要“二手需求”

　　曾经有一个某政府部门的项目，系统是各业务部门使用的，但需求只能从信息科那里获取。信息科的人自认为很牛，对项目组说：“需求向我们要可以了！”而这个项目上线后，具体使用系统的部门是不买帐，后这个系统由信息科验收了。

　　信息科提供的是“二手需求”，向客户调研需求时，一定要避免“二手需求”！

　　上述案例你可能会觉得有点好笑，其实“二手需求”在项目组内也经常会发生。

　　某测试人员问为什么要做这个功能？开发说：这个你不用管，你这样这样测可以了……

　　某实施人员觉得某功能看上去不太符合逻辑，提出疑问。开发说了一大通实施人员听不懂的技术用语，然后实施人员只能憋着不说话了。

　　项目组的测试人员、实施人员应该接触第一手的需求，好能直接面对客户，而不是通过开发人员转述需求。

　　法则5：成为业务专家

　　你可能遇到过这样的情况，客户经常抱怨软件不好用，然后我们问：如何不好用？客户好容易说出了一些要求，我们按照这些要求修改了系统，但客户总是不满意，总是说不好用。诸如此类，不断重复。

　　客户说啥，我们做啥，是比较落后的一种层次。我们应该处在客户的利益，提出超出客户想法的解决方案。要打造有竞争力的产品或项目，成为业务专家是必须的，不能偷这个懒，不要仅停留在需求调研这样的层次，而是要引领需求，给客户带来更先进的知识和管理办法。

　　法则6：需求是“设计”出来的

　　手机订餐系统的故事我经常拿出来举例子，大意是：

　　某公司有一个订餐系统，但高层要求在这个基础上做一个手机订餐系统，让外出工作或请假的同事可以方便定午餐。手机订餐项目组花了九牛二虎之力，终于弄出这个系统，但问题多多。高层领导很不高兴：这点小事都折腾这么久！后来有人说：外出工作或请假的同事，打电话回公司，让前台帮忙订餐不可以了？

　　“解决不方便订餐的问题”是需要，而“手机订餐系统”只是可以满足该需要的某种解决方案，我们完全可以通过其他更加简单的方法来满足需要。我个人观点：除了需要是来自客户的想法外，系统要具体做什么功能之类的需求，不是通过问客户问出来的，而是我们根据客户的需要，理解了客户的业务流程后，并根据限制条件，设计出来的！当然客户提出来的想法，会给我们带来很多启发，但我们不应该仅停留在需求调研的层次，而是提供一个高性价比的需求解决方案。

　　法则7：七分需求分析，三分需求管理

　　遇到客户变来变去的情况，我们可能第一反应是：有没有搞错！当初应该让他签字！好是录音！

　　如果我们连客户的需要都搞不清楚，去抱怨客户需求变来变去，那我们的水平未免有点低了。其实真正很难缠的客户、不讲道理的客户很少的，只是我们水平未够，不能理解或找出客户真正想要什么，才让我们误以为客户变来变去。

　　需求工作可能有很多问题，应该以做好需求分析工作为主，而需求管理为辅，两者比例大概是七三开。需求分析工作做好了，需求的问题可以减少很多，而且客户也会非常认可你的专业水平，这样后续的工作比较容易处理了。

　　当然也可能会遇到很难缠又不能绕过的客户，遇到这样的情况，建议你看看“挨踢项目管理求生法则-战略篇”，如果从战略上判断该项目有很大问题，那么好不要做这个项目，如果不幸要负责这样的项目，那么记住其中一个法则“输少当赢”。