唉！專案又延期了，例會上老闆恨恨的批評了整個專案組，投入了那麼多，生產出在**？查原因，發現是由於專案的需求不斷變更導致，這恐怕是很多老鳥和小鳥都經歷過的事。
這裡就談談專案延期的乙個重要因素：需求問題
客戶提出的需求
專案組客戶期望的結果
是否滿意
需求a系統a
系統a是
需求a系統b
系統a否
需求a系統a
系統b否
客戶為何提不了真正的需求？
1、業務部門：業務人員基本是站在自身的角度看問題，從自身負責的業務出發，沒有從本部門或更高層次來分析問題，導致需求的著眼點比較低。在此基礎上形成的最終需求也就是把各部門的需求進行彙總，簡單處理罷了。而且，業務部門對技術知識的匱乏，也導致其提出需求時是沒有考慮技術上方面的。
2、技術人員：客戶方面的技術人員由於業務知識有限，無法挖掘更深層次的需求，只能是基於已有需求，或者輕度發掘部分需求，無法從根本上解決需求的問題。
按照以上提出的需求，可想而知，專案的結局如何。也有部分專案，在需求分析階段，生成了完整的需求規格說明書，並且使用者簽字畫押，最終的結果是如果不能真正解決客戶業務的問題，即使系統投產了，也必將引來使用者的各種抱怨，勢必對公司形象、後續專案產生各種不利影響。
我們在整天抱怨需求不斷變化的同時，能否換個角度來看待需求的變化，假設需求就是變化的，事實情況也是如此。從公司及業務自身的發展來看，公司是不斷發展的，而業務也是不斷發展的，為了滿足公司經營需要及業務發展需要，需求本身就是應該是不斷變化和發展的。
那麼，真正的需求在**？
從公司運營角度看，為什麼要做系統？其目的都是滿足公司運營的需要，只有站在公司運營的高度來審視需求，才能真正幫助需求發起人，形成完整的客戶需求。這就需要我們：
1、真正掌握做該系統的目的
2、程式設計師要深入了解業務，多溝通，最好有領域專家協助，從上而下梳理業務需求，糾正不合理的需求，挖掘潛在的需求
3、以技術的手段來解決需求變更的問題，做到以不變應萬變，從而在最大程度上減少需求變更帶來程式的變化。這方面對程式設計師、專案設計者的要求比較高。
需求變化不可怕、需求變更也不可怕，可怕的是我們不知道變化及變更的本質，而是停留在表象；可怕的是我們不知道去擁抱這種變化，而是一味的排斥；可怕的是我們不知道用自己的長項（技術手段）最大化的去解決這種變化，而是把自己的弱項（業務）暴露在客戶面前。
走出軟體作坊的秘密
走出軟體作坊 已經一周歲了。在這一年裡得到了許多朋友的鍾愛，也收到了許多朋友的來信。仁者見仁智者見智。有人從書中看到了心態和堅持，有人看到了樸實的創新 原來創新就是這樣，不要整天大戰略大構思大藍海 有人看到了術，有人看到了方 每個人都或多或少能收穫到一些東西，這已經達到了這本書想要傳達的目標了。於是...
五步走 軟體需求的管理過程
摘要 角色 職責描述 市場人員 負責discover階段所有工作，並幫助開發專案經理在define階段初期很快地了解業務和客戶 開發專案經理 協調discover階段的所有活動 負責完成需求文件 維護scope matrix。行業專家 提供行業諮詢 高層團隊 指導discover和define階段的...
客戶需求的挖掘
客戶需求的挖掘 下午，乙個客戶要求先幫他們做個資料錄入頁面。在紙上寫了幾個字段。寫完後，我開始引導客戶，了解具體需求。我 你這個錄入完後，所得到的資料，需要拿來做什麼。客戶 需要對合同資料進行錄入。我 誰進行錄入，錄入的是什麼資料？客戶 業務員進行錄入，錄入的是商家的資料。客戶描述了好一陣，拿出一本...