項目管理：如何把握不存在的需求
發布時間：2010-01-14 共1頁
任何從事IT行業的人員都清楚，軟件開發項目失敗的其中一個主要原因是項目在啟動的時候功能需求模糊，導致開發過程的不斷修改，讓項目不斷延誤，功能不斷擴張，資源越來越吃緊，最終影響交付的質量和客戶的滿意度。
作為一個軟件工程的專業人員，如何能夠從客戶所提供的模糊需求建立一個明確的范圍，然后從這個范圍中建立整個系統的功能需求，讓我們可以控制軟件開發的過程，減少項目的范圍變動，降低開發過程中的修改需求，讓我們能夠按預算、按工期，提交符合質量要求的交付物，達到客戶的預期目標，我們便需要理解問題的根源，打破過去的工作習慣，尋找一套可行的方法。
在項目管理知識體系(PMBOK)中我們學習范圍變動管理，而不是需求變動管理，范圍變動才是需求變動的主要原因。其實在這里PMBOK做了一個假設，就是有了明確的范圍便可以建立明確的功能需求，如果能夠控制范圍，便能夠控制功能需求。
功能需求變動是導致軟件工程在開發過程中進行修改的主要原因，那是說我們在軟件工程項目啟動的時候沒有把握好項目的范圍，才會發生我們面對的問題。所以，我們首先需要理解范圍與功能需求的關系，什么是范圍?什么原因導致需求模糊?能夠明確理解兩者的異同，才能夠找出解決的方法，建立明確的項目范圍，轉換成功能需求。讓我們能夠從模糊的需求轉變成為明確的需求。
建立明確的項目范圍代替不明確的范圍，才能夠減少開發過程中的修改。本人最近一直從過去30多年的科技項目開發和管理經驗中，結合近年回國后對國內IT企業運營模式的理解，我國技術人員的工作習慣，客戶的思維、心態和期盼，總結出一套建立明確項目范圍的方法，特在此與讀者分享，共同改善我國軟件企業的困境。
70年代的項目范圍與需求
項目范圍與項目需求是兩個完全不同的概念，但兩者卻不能單獨處理。讓我們回到上世紀70年代的時候，國外企業正進行自動化的過程。項目基本上是把人工作業流程轉變成計算機程序。那時候并沒有項目范圍這個名稱，我們用Terms of Reference (ToR)來界定項目的邊界，采用文字描述的方法說明這個項目要做什么。例如，要為希賽公司建立一個庫存管理系統，這個項目的ToR會說明貨品從進入倉庫開始，到貨品因應生產或銷售申領要求離開倉庫為止，其中包括貨品存入量的統計，存放位置記錄，總庫存量統計、申領數目、檢貨、提取貨品、準備出倉，最后更新貨品存量統計等工作過程。這個項目的Term of Reference只說明這個項目的范圍，包括一些需要執行的工作和記錄等。
作為一個軟件工程的專業人員，如何能夠從客戶所提供的模糊需求建立一個明確的范圍，然后從這個范圍中建立整個系統的功能需求，讓我們可以控制軟件開發的過程，減少項目的范圍變動，降低開發過程中的修改需求，讓我們能夠按預算、按工期，提交符合質量要求的交付物，達到客戶的預期目標，我們便需要理解問題的根源，打破過去的工作習慣，尋找一套可行的方法。
在項目管理知識體系(PMBOK)中我們學習范圍變動管理，而不是需求變動管理，范圍變動才是需求變動的主要原因。其實在這里PMBOK做了一個假設，就是有了明確的范圍便可以建立明確的功能需求，如果能夠控制范圍，便能夠控制功能需求。
功能需求變動是導致軟件工程在開發過程中進行修改的主要原因，那是說我們在軟件工程項目啟動的時候沒有把握好項目的范圍，才會發生我們面對的問題。所以，我們首先需要理解范圍與功能需求的關系，什么是范圍?什么原因導致需求模糊?能夠明確理解兩者的異同，才能夠找出解決的方法，建立明確的項目范圍，轉換成功能需求。讓我們能夠從模糊的需求轉變成為明確的需求。
建立明確的項目范圍代替不明確的范圍，才能夠減少開發過程中的修改。本人最近一直從過去30多年的科技項目開發和管理經驗中，結合近年回國后對國內IT企業運營模式的理解，我國技術人員的工作習慣，客戶的思維、心態和期盼，總結出一套建立明確項目范圍的方法，特在此與讀者分享，共同改善我國軟件企業的困境。
70年代的項目范圍與需求
項目范圍與項目需求是兩個完全不同的概念，但兩者卻不能單獨處理。讓我們回到上世紀70年代的時候，國外企業正進行自動化的過程。項目基本上是把人工作業流程轉變成計算機程序。那時候并沒有項目范圍這個名稱，我們用Terms of Reference (ToR)來界定項目的邊界，采用文字描述的方法說明這個項目要做什么。例如，要為希賽公司建立一個庫存管理系統，這個項目的ToR會說明貨品從進入倉庫開始，到貨品因應生產或銷售申領要求離開倉庫為止，其中包括貨品存入量的統計，存放位置記錄，總庫存量統計、申領數目、檢貨、提取貨品、準備出倉，最后更新貨品存量統計等工作過程。這個項目的Term of Reference只說明這個項目的范圍，包括一些需要執行的工作和記錄等。
