項目又延期了，老闆恨恨的批評了整個項目組，投入了那麼多，産出在哪裡？查原因，發現是由于項目的需求不斷變更導緻，這恐怕是很多項目經理、程式員都經曆過的事。
我這裡就談談項目延期的一個重要因素：需求問題
這張圖大家再熟悉不過了，我再炒一下冷飯，列一下主要可能的情況：
客戶為何提不了真正的需求？
1、業務部門：業務人員基本是站在自身的角度看問題，從自身負責的業務出發，沒有從本部門或更高層次來分析問題，導緻需求的着眼點比較低。在此基礎上形成的最終需求也就是把各部門的需求進行彙總，簡單處理罷了。而且，業務部門對技術知識的匮乏，也導緻其提出需求時是沒有考慮技術上方面的。
2、技術人員：客戶方面的技術人員由于業務知識有限，無法挖掘更深層次的需求，隻能是基于已有需求，或者輕度發掘部分需求，無法從根本上解決需求的問題。
按照以上提出的需求，可想而知，項目的結局如何。也有部分項目，在需求分析階段，生成了完整的需求規格說明書，并且使用者簽字畫押，最終的結果是如果不能真正解決客戶業務的問題，即使系統投産了，也必将引來使用者的各種抱怨，勢必對公司形象、後續項目産生各種不利影響。
我們在整天抱怨需求不斷變化的同時，能否換個角度來看待需求的變化，假設需求就是變化的，事實情況也是如此。從企業及業務自身的發展來看，企業是不斷發展的，而業務也是不斷發展的，為了滿足企業經營需要及業務發展需要，需求本身就是應該是不斷變化和發展的。
那麼，真正的需求在哪裡？
從企業營運角度看，為什麼要做系統？其目的都是滿足企業營運的需要，隻有站在企業營運的高度來審視需求，才能真正幫助需求發起人，形成完整的需求。這就需要我們：
1、真正掌握做該系統的目的
2、程式員要深入了解業務，多溝通，最好有領域專家協助，從上而下梳理業務需求，糾正不合理的需求，挖掘潛在的需求
3、以技術的手段來解決需求變更的問題，做到以不變應萬變，進而在最大程度上減少需求變更帶來程式的變化。這方面對程式員、項目設計者的要求比較高。
需求變化不可怕、需求變更也不可怕，可怕的是我們不知道變化及變更的本質，而是停留在表象；可怕的是我們不知道去擁抱這種變化，而是一味的排斥；可怕的是我們不知道用自己的長項（技術手段）最大化的去解決這種變化，而是把自己的弱項（業務）暴露在客戶面前。
最新内容請見作者的github頁：http://qaseven.github.io/