做成功的專案經理人)

做成功的專案經理人

 

資訊系統的開發過程是十分複雜和多變的。因為市場、使用者、開發人員、開發技術等等所有的東西都不一樣，所以就算開發同樣的資訊系統，兩個項目都不可能一模一樣的進展和完成。資訊系統開發的複雜性來自軟體本身的複雜性和人的腦力創造性勞動；並且資訊系統的開發牽扯到如此多的不同性質的工作和如此多的不同的模型（過程模型、用例模型、資料庫模型、順序圖、類圖、商業模型等等）。

這篇文章通過系統開中需要注意的核心問題，或者說是在系統開發過程中需要關心的重點工作，以說明資訊系統開發的靈魂或者內在。掌握了一個事物的本質或者內在的東西，就可以主動地創新我們做事情的方法或者手段。如果我們總在被動或者混亂中，那是因為我們沒有掌握這些要旨，而被事物外在的形式所迷惑。
1、商業目標

資訊系統開發的核心問題就要從資訊系統的結果進行入手。開發一個資訊系統的目的是實現一個組織或者團體的商業目標（或者其它目的，這裡只關心商業目的）。所以一個資訊系統開發成功的標誌是給受益人或團體帶來預期的商業收益。

所以，在專案計劃過程中，項目確立之初，需要明確地調查和定義出即將開發的資訊系統的商業目標。在這個目標中必須依次說明：

² 受益人或者團體是誰。

² 他或者他們就這一問題的當前商業模式或者工作方式、經營狀況、等等。這個問題就是系統開發背景或者使用者在這一領域的現狀。我們的使用者是為了改善現狀才會開發資訊系統，這一點要切記。

² 最終要達到的商業目標是什麼。要改變現狀，使用者期望達到什麼樣的商業目標？例如，通過新的資訊系統，增加互連網銷售業務、預期在2年內收回開發成本，3年內收益增加多少；估算資訊系統開發的代價、年收益率、增長率等等。為了估算預期的商業收益，此時可能用到預期的商業收益表，並且為了實現這些收益條目，將要估計待開發的資訊系統的能力，形成一個系統能力表（這就是最原始的系統功能表）。

² 如何達到商業目的。一個資訊系統的成功，重點不是技術，而是商業模式。所以要描述這個問題，就必須採用兩個方案：一個是商業計劃、一個是技術放案。這兩個方案的編製分別需要不同領域的人員。商業計劃需要由商業知識人員或者專家來編寫，而技術方案則需要技術經理或者總監來編製。編製這兩個計劃的人就是分別在研究兩個方面的可行性問題，以保證新的資訊系統確實是成功的系統。所以分別需要市場調研、預測；技術調研和公關研究等工作，最終的研究結果是從兩個方面如何達到商業目標。這個時候，系統大概的主要功能需要在技術放案裡面被確定，以便研究可行性。其中商業計劃是核心，技術放案是手段。

2、資源問題

商業目標的問題研究清楚以後，商業目標已經明確、並且可行性已經從理論上得到保證，就需要研究項目需要的資源問題，也就是資源可行性問題。如果資源得不到保證，那麼項目註定不會成功。依次需要解決的資源如下：

² 硬體和軟體資源。包括項目的管理、開發、機構支撐和維護過程的所有資源。例如開發用電腦、伺服器、所有的工具軟體等資源；軟體安裝部署需要的電腦或者伺服器、軟體環境等資源。應該估計大概需要多少這類資源（明細表）、並說明資源如何得到。

² 人力資源。包括項目開發過程需要的人員和系統維護過程需要的技術服務人員。需要估算和籌劃一個人員明細表，包括職位、技能、職責等；並且說明人員來源，有些可以從一個組織內部直接調用，而有些需要通過人力資源部門招聘。

² 資金。也就是項目的投資。項目所需資金需要根據多種情況進行估算，包括購買軟硬體資源的費用、人員工資、項目開展過程的所有開支等。最終需要說明資源來源、如何到位等問題。需要弄清楚的一點是，一個資訊系統的支援階段的費用往往是各種費用裡面最多的。例如，系統安裝、人員培訓、系統維護、系統運轉等幾個費用，其中後兩個會在整個系統支援階段一直發生。所以，在資金預算中必須把這一點考慮在內，在成本/收益估算分析報告中也是一樣。

3、其它可行性問題

這些可行性來源於投資商或者終端使用者的其它方面。例如企業文化、組織圖等等。需要研究新的資訊系統在特定的使用者群體內會不會被接受、會不會被大力支援。一個資訊系統成功的第一要素是產生了預期的商業收益，實現了預期的商業目標。一個做的再好的系統，如果因為某些原因得不到使用，那它也是失敗的。

4、初步的系統開發進度表

到這一步，就需要制定出初步的系統開發進度表。這個時候專案管理人員不可能有詳細的WBS功能分解資料，所以這個進度表一般是對系統開發生命週期中的主要活動的進度進行的一個定義。這個進度表是對系統開發的一種約束和檢驗，沒有進度表項目永遠做不完。按照既定的成本預算，在預期的期限內完成工作才能叫項目。

此時因為資源問題已經有了結果資料，所以就可以根據系統能力表進行工作量的估算，對項目的主要活動分配人員，進行一個進度安排。

5、定義產品

到現在，上述問題解決以後，項目得以啟動。當然，啟動項目有一個方法或方式，但這些不是核心問題，這裡主要闡述核心問題。

項目啟動，資訊系統的分析和開發階段開始了（以前處於計劃階段，現在計劃已經被批准執行了）。這個時候就需要明確地定義正在開發的資訊系統 ---- 定義產品。定義產品的依據是要達到的商業目標，在商務分析及計劃書中如果有一個系統能力估計表，這個就是最初的依據。我們的產品大體上就需要提供這樣的能力。但這個遠遠不夠，最終開發結束，進入測試和交付，就需要按照產品定義來檢驗最終的產品是否合格。這個階段就是需求資訊收集和分析階段。最核心的要點有：

² 系統能力表。系統為了實現商業目標必備的能力。

² 系統詳細功能表。通過需求調研和分析，初步的WBS功能分解等手段從原始的系統能力表產生詳細功能表。每個功能在調研期間必須說明使用者在當前是如何完成這些商業或者生產活動的，新的資訊系統又是打算如何定義這些活動的完成過程的。所以，商務程序、資料流等東西都在需求調研期間進行研究。

² 確定系統正常啟動並執行條件。也就是運行環境定義。必須明確定義系統正產運轉需要具備的所有條件。例如啟動並執行電腦硬體要求、網路要求、作業系統要求、需要的支撐組件和應用程式、資料庫類型等等。這些是產品檢驗階段進行測試的依據，如果一個系統能夠運行在多種環境，那麼測試階段，系統要逐個地在這些環境裡被測試。這個環境和舊的系統和技術選型等因素直接相關。

6、進一步的系統開發進度表

根據詳細的功能列表，進行初步的WBS工作分解，通過估算各個子功能的工作量大小和複雜性，就可以制定進一步的系統開發進度表。這項工作是對項目可行性的不斷檢驗和對項目進展的不斷校正，很重要。

7、設計系統

產品定義明確以後，就開始設計這樣一個被定義好的東西。就像汽車被定義好以後，具體要設計出來，以便投入生產。只要能夠符合要求，設計成寶馬、勞斯萊斯或者平治都無所謂。投資決定設計方案，因為不同的方案實現的代價不一樣。其實投資是首先決定了產品的定義，然後才決定產品設計的。投資少，那麼只能定義成一個具有奧托那樣功能的車，並且設計和生產出來；投資多就可以定義更多、更好的特性，成為寶馬或者平治了。

² 設計使用者介面。一個資訊系統最終要和使用者互動，資訊系統提供給使用者的介面有哪些？必須詳細的進行定義，這是對最終產品是否合格的最直觀的定義文檔。介面布局圖案，介面元素定義，介面功能說明，介面流轉關係等等都要詳細定義。

² 設計系統外部行為（或者系統介面）。一個資訊系統的很多功能是使用者在介面上無法看到的，但是使用者可以認識到或者感受到這些功能的存在。例如，一個網路許可證控制應用系統，需要程式開發伺服器方和客戶方的高層通訊協定。伺服器最初維持20個許可證，每登入一個用戶端就分發掉一個，最多登入20個用戶端；等等。這些不可見的和多軟體內部需要處理的問題，就是外部行為。因為，這些行為一般是資訊系統模組之間，或者新系統和舊系統之間的互動產生的，所以也可以說是系統介面。

² 設計應用程式結構。也就是根據需求中的功能表、使用者介面和系統介面等資訊，設計整個資訊系統的網路整合體繫結構和軟體體繫結構。首先要確定新系統如何和其它系統整合，所以網路整合體繫結構首先要被確定。

² 設計資料庫、資料結構。現在可以根據系統的外部表格現和行為以及其它需求分析結構設計資料了。這些資料包括資料庫和應用程式使用的其它資料結構。例如根據使用者介面、系統介面、其它需求資料，分析和抽象其中的資訊，設計資料庫和資料結構。

² 設計系統的模組。從系統功能表、使用者介面、系統介面（介面）、應用程式體繫結構、資料庫和資料結構等資訊，需要設計系統最終的所有主要模組（沒有必要太細密的劃分，否則設計成本將大大上升）。這個時候一般就會用到WBS分解方法，把系統的功能分解為許多小的模組，以便能夠團隊分工協作。對於非常大的系統，可以初步的進行模組劃分，然後把這些模組分配給不同的部門，進行再次的劃分和設計。

8、詳細的項目進度表

在模組的劃分完成以後就應該制定一個詳細的項目進度表，把模組承包到戶。因為模組的很多細節性的設計工作還要交給具體開發人員完成（小規模的團隊定義好模組功能和介面以後，就可以把所有的其它設計工作都交給開發人員，這樣可以降低設計成本）。

模組劃分和定義完畢，設計之前就制定詳細的項目進度表。

9、實現系統

至此，系統內部的組件 --- 模組被定義和設計出來了。現在要投產。

具體實施系統的時候又有這個實施過程域的許多活動和規範、模型等（這是域內的細節問題）。

10、測試系統（品質保證）

系統在實施的過程，要對組件的品質進行檢驗。這就是白盒測試和黑箱測試。需要測試系統的每個模組，保證它是達標的。具體的測試方法和詳細程度是這個活動的細節問題。

系統實現完畢，就需要把各個組件組裝起來，對整個資訊系統進行整合測試。這個時候是檢驗系統是否符合產品的定義。這是整合測試。具體的測試方法屬於細節問題。

系統整合測試必須以產品定義為依據，要達到品質要求（能力、效率、穩定性、各種環境等等）。而組件測試必須以模組的定義為依據。

11、安裝部署和支援過程

系統最後進入安裝部署和支援過程。這個階段及其重要，一個資訊系統能夠被順利應用，就需要好好研究和策劃這個過程。並且這個過程也是花費最多的地方。具體的方法也是細節問題。
 

結束語：文中很多沒有提及或者被稱為細節問題的，就是一個專案管理者不必要過分考慮或者不必要去考慮的問題。項目的很多細節問題並不是小問題，它們都需要工作人員有特定的知識，所以專案管理者需要把這些具有專長的人員安排到合適的位置。

一個專案經理成功的條件是：一是他掌握了一個項目包括的關鍵工作或任務；第二是他擁有這些不同的任務各自需要的相關專業人員。