项目又延期了，老板恨恨的批评了整个项目组，投入了那么多，产出在哪里？查原因，发现是由于项目的需求不断变更导致，这恐怕是很多项目经理、程序员都经历过的事。
　　我这里谈谈项目延期的一个重要因素：需求问题

　　这张图大家再熟悉不过了，我再炒一下冷饭，列一下主要可能的情况：

　　客户为何提不了真正的需求？
　　1、业务部门：业务人员基本是站在自身的角度看问题，从自身负责的业务出发，没有从本部门或更高层次来分析问题，导致需求的着眼点比较低。在此基础上形成的终需求也是把各部门的需求进行汇总，简单处理罢了。而且，业务部门对技术知识的匮乏，也导致其提出需求时是没有考虑技术上方面的。
　　2、技术人员：客户方面的技术人员由于业务知识有限，无法挖掘更深层次的需求，只能是基于已有需求，或者轻度发掘部分需求，无法从根本上解决需求的问题。
　　按照以上提出的需求，可想而知，项目的结局如何。也有部分项目，在需求分析阶段，生成了完整的需求规格说明书，并且用户签字画押，终的结果是如果不能真正解决客户业务的问题，即使系统投产了，也必将引来用户的各种抱怨，势必对公司形象、后续项目产生各种不利影响。
　　我们在整天抱怨需求不断变化的同时，能否换个角度来看待需求的变化，假设需求是变化的，事实情况也是如此。从企业及业务自身的发展来看，企业是不断发展的，而业务也是不断发展的，为了满足企业经营需要及业务发展需要，需求本身是应该是不断变化和发展的。
　　那么，真正的需求在哪里？
　　从企业运营角度看，为什么要做系统？其目的都是满足企业运营的需要，只有站在企业运营的高度来审视需求，才能真正帮助需求发起人，形成完整的需求。这需要我们：
　　1、真正掌握做该系统的目的
　　2、程序员要深入了解业务，多沟通，好有领域专家协助，从上而下梳理业务需求，纠正不合理的需求，挖掘潜在的需求
　　3、以技术的手段来解决需求变更的问题，做到以不变应万变，从而在大程度上减少需求变更带来程序的变化。这方面对程序员、项目设计者的要求比较高。
　　需求变化不可怕、需求变更也不可怕，可怕的是我们不知道变化及变更的本质，而是停留在表象；可怕的是我们不知道去拥抱这种变化，而是一味的排斥；可怕的是我们不知道用自己的长项（技术手段）大化的去解决这种变化，而是把自己的弱项（业务）暴露在客户面前。