項目需求

出自 MBA智库百科(https://wiki.mbalib.com/)

項目需求（Project Needs/Project Demand）

　　企業要明確的需求不可單一理解為明確我要管理什麼，而是我對要管理的目標怎樣實現。整個過程強調的是管理的目標和管理的方法之間的關係，只有立足在這個關係的基礎上，才可以保證做到真正明確需求。

　　當企業有信息化方面的項目規劃時，企業經常會得到來自很多方面的意見，以指導企業在選型的初期應該怎樣做。其中，肯定會有共同的一條，那就是“明確需求”。由此可見，明確自己的需求在信息化選型的初期階段是多麼重要。

　　但是，所謂的“明確需求”到底是要明確什麼呢？是明確管理的目標，還是管理的方法？這卻是企業很難把握的。另外，需求是怎樣產生的？或者說需求應該怎樣產生，才可以保證最後產生的需求是既完整又合理的？這同樣也是很多企業都很難做得好的一件事。

　　一般來講，在最初的需求調研階段，這部分工作大都是由公司的管理部門或從事分析工作的人員來完成，而調研人員考慮問題的出發點往往只是讓企業的管理水平有一個飛躍，但是卻容易忽略企業的現狀，或未能完整深刻地對企業的實際潛在性需求進行調研，這導致在實際應用階段之時，很多部門覺得不太適用，甚至導致各個部門怨聲載道，於是不得不宣告失敗或推倒重來。所以處在這個階段的企業，需要有一種科學的方法來指導自己確定真實準確的需求。

　　首先，企業要明白一點，現在所需要瞭解的不單單是企業目前的需求，而是要制定出企業長期發展的階段性戰略目標，並以此為依據，來制定各個階段的需求和發展計劃。特別是對於處在快速成長髮展期的企業而言，企業會在較短的時間內經歷多個成長的階段，在不同的階段會派生許多不同的管理需求。只有企業明白了自己需要管理什麼，才可能制定對應的管理方法。這樣的戰略目標的確定是分階段的,企業只有根據自己企業的特點或者行業的特點制定出階段目標，才能夠明確自己每個階段的管理需求。

　　同時，無論是製造業還是流通行業，都強調物流和資金流這兩個閉環。那麼，這兩個閉環中的每個環節都存在管理上的需求。在對這些環節進行定義時，不單單是要定義管理的各個環節的管理目標，更重要的是要定義各個環節之間的關係。企業只有按照這樣的方法制定階段性的發展目標，才可以完整地對各個環節進行管理方法的定義。

　　其次，當企業已經制定了企業各發展階段的戰略性目標之後，根據各階段的目標進行管理的規劃就比較簡單了，因為企業已經明白了自己需要管理什麼，剩下的只需要探討管理的方法就可以了。按照既定的戰略性目標制定每個環節的管理方法的時候，一定要本著立足本部門的需求，放眼整個公司的管理目標的原則來制定管理方法，只有這樣才能保證本階段的管理方法的科學性以及合理性。

　　最後，在對各個環節的管理方法進行定義的時候，不但要考慮管理的目標通過管理方法的實現，而且要註意前後兩種管理方法的差異。只有註意了兩種管理的方法的差異，才可能保證兩種管理方法的平穩過渡。

　　同時，公司的管理部門或從事分析工作的人員在做各個部門的需求調研的時候，也要在立足企業的管理目標的前提下，充分瞭解各個環節實際的管理需求。瞭解他們日常工作實現了哪些目標，對於整個公司的管理目標，他們還缺少哪些，需要補充的是哪些。只有這樣才能避免調研開始的時候“沒得說”，到了應用的階段卻“說不完”的情況發生。

　　所以，在項目初期的選型階段，企業要明確的需求不可單一理解為明確我要管理什麼，而是我對要管理的目標怎樣實現。整個過程強調的是管理的目標和管理的方法之間的關係，只有立足在這個關係的基礎上，才可以保證做到真正明確需求。

　　大部分 IT 項目缺乏支持文檔，縱然擁有商業案例（ Business Case ）或其他相關文檔，也不能很明確地把項目所需的工作涵蓋起來，只能建立項目的周邊，對項目的實際工作量缺乏描述，這很容易導致項目過程中所產生的變動。

　　為解決這個和問題，國際上已於上世紀 80 年代末期開始採用“工作陳述”（ Statements of Work 或簡稱 SOW ）來固定範圍，同時放棄範圍定義（ Scope Definition ）的應用。因為 IT 項目有別於其他基建項目的地方在於基建項目有其他附屬文檔來支持範圍定義，比如在基建項目的項目範圍中，一般都有諸如項目的有關設計圖則、用料標準等等明文規定，讓範圍能夠非常明確地涵蓋基本的工作需求。而 IT 項目的項目範圍中往往沒有這樣的定義。

　　以商業效益來確認功能需求，再利用功能需求來建立項目範圍。而在範圍確認後，我們緊跟著必需建立詳細的工作需求和項目計劃，否則項目的工作便像橄欖球內的充氣量一般，可以按照客戶的要求隨意變動。

　　工作需求和項目計劃基本上是利用工作架構分解法（ Work Breakdown Structure ）建立。明確的工作陳述（ SOW ）讓渠道商或服務商瞭解本身的服務承諾，有效地建立項目的成本，降低項目過程中所產生的變動。這些工作陳述應該在銷售過程中建立，成為服務合約的內容一部分。萬一合約中只有項目範圍定義，那麼交付小組必須在交付初期建立有關的項目工作陳述，避免交付期間所產生的爭議。

　　IT 業內人士多未能把握WBS的實際應用技巧。而有如工作量估算，錯誤的工作細節將對項目計劃不利。

　　每一個項目都有不同的交付物，而每一件交付物需要經過不同的里程碑才能夠產生，同時每一個裡程碑也需要經過不同的階段才能夠達到里程的目標。每一個階段需要經過不同的步驟去完成，而每一個步驟需要進行不同的工作。

　　每一個步驟需要完成一系列工作才能進行第二步驟，直至同一階段的步驟完成才開始第二階段，而直至全部階段完成後才能到達一個裡程碑。有些里程碑內的工作可以同期進行，但有些里程碑內的工作得等另一個裡程碑完成後才能夠開始。到最終完成全部的里程碑內的工作後才能夠交付項目中的某一件交付物。

　　利用 WBS 技巧來建立交付組合架構，為每一件交付物建立本身的工作需求，可以讓我們很明確地說明每一件交付物所包含的工作。這個交付組合架構更可以讓我們在同一時間為項目建立有關的工作計劃。

　　項目開發的目標對軟體用戶來說，目標是：項目及時開發完成，達到管理要求，併成功應用於企業管理，為企業創造效益。方案的用途可以讓用戶在沒有使用最終軟體的情況下，對未來軟體的使用方法和計算原理有足夠的認識方案可以正確指導軟體開發商進行正確的開發方案可以幫助軟體測試工作正常進行方案可以指導用戶去使用未來的軟體方案可以作為雙方認可的項目驗收標準。