項目又延期了，老板恨恨的批評了整個項目組，投入了那么多，產出在哪里？查原因，發現是由于項目的需求不斷變更導致，這恐怕是很多項目經理、程序員都經歷過的事。

　　我這里就談談項目延期的一個重要因素：需求問題

　　這張圖大家再熟悉不過了，我再炒一下冷飯，列一下主要可能的情況：

　　客戶為何提不了真正的需求？

　　1、業務部門：業務人員基本是站在自身的角度看問題，從自身負責的業務出發，沒有從本部門或更高層次來分析問題，導致需求的著眼點比較低。在此基礎上形成的最終需求也就是把各部門的需求進行匯總，簡單處理罷了。而且，業務部門對技術知識的匱乏，也導致其提出需求時是沒有考慮技術上方面的。

　　2、技術人員：客戶方面的技術人員由于業務知識有限，無法挖掘更深層次的需求，只能是基于已有需求，或者輕度發掘部分需求，無法從根本上解決需求的問題。

　　按照以上提出的需求，可想而知，項目的結局如何。也有部分項目，在需求分析階段，生成了完整的需求規格說明書，并且用戶簽字畫押，最終的結果是如果不能真正解決客戶業務的問題，即使系統投產了，也必將引來用戶的各種抱怨，勢必對公司形象、后續項目產生各種不利影響。

　　我們在整天抱怨需求不斷變化的同時，能否換個角度來看待需求的變化，假設需求就是變化的，事實情況也是如此。從企業及業務自身的發展來看，企業是不斷發展的，而業務也是不斷發展的，為了滿足企業經營需要及業務發展需要，需求本身就是應該是不斷變化和發展的。

　　那么，真正的需求在哪里？

　　從企業運營角度看，為什么要做系統？其目的都是滿足企業運營的需要，只有站在企業運營的高度來審視需求，才能真正幫助需求發起人，形成完整的需求。這就需要我們：

　　1、真正掌握做該系統的目的

　　2、程序員要深入了解業務，多溝通，最好有領域專家協助，從上而下梳理業務需求，糾正不合理的需求，挖掘潛在的需求

　　3、以技術的手段來解決需求變更的問題，做到以不變應萬變，從而在最大程度上減少需求變更帶來程序的變化。這方面對程序員、項目設計者的要求比較高。

　　需求變化不可怕、需求變更也不可怕，可怕的是我們不知道變化及變更的本質，而是停留在表象；可怕的是我們不知道去擁抱這種變化，而是一味的排斥；可怕的是我們不知道用自己的長項（技術手段）最大化的去解決這種變化，而是把自己的弱項（業務）暴露在客戶面前。