3. 項目工作梳理

3. 項目工作梳理

來自專欄 如何做好甲方項目經理

在確定項目「完成」的定義後，項目工作便有了明確的建設目標，相關的建設工作也都是為了實現這一目標而開展的。對於甲方項目經理來說，在具體項目建設工作開始之前，其需要基於自身的工作經驗和建設要求，來對完成該項目所需的各項工作進行深入、全面的梳理。只有對項目建設的整體流程和相關的各項工作做到心中有數、胸有成竹，其在對項目進行管理的時候，才能做到有條不紊、有的放矢。

為了便於對項目建設工作進行管理，筆者按照自身的工作經驗，將項目建設分為了3個階段：項目籌劃期、項目建設期和項目運維期，每個階段按照自身的建設要求，都會包含有一系列相關的項目建設工作。其中，項目籌劃期主要指項目從規劃、立項、採購到乙方廠商入場的這一階段；項目建設期主要指乙方廠商入場後，開始項目的具體建設至項目上線為止；項目運維期主要指項目正式運行直至項目終結這一階段。

3.1. 項目籌劃期

在項目籌劃期，項目由一個初始的概念或是想法逐漸轉化成為一個具體的、可實施、可落地的軟體建設項目。在這個階段，項目建設工作主要由甲方機構自行完成，其工作目標分為以下兩個方面：一是在機構內部，完成項目立項工作；二是通過相關的採用形式，引入負責項目建設的乙方機構。為了實現上述目標，這個階段的建設工作主要有以下幾種：

1. 編製業務需求

業務需求編製工作指在對相關業務進行深入的分析和梳理後，將抽象的業務轉換為具體的功能要求並落實到紙面上，從而形成需求文檔的過程。其內容主要包括業務背景、業務主體、業務流程、業務場景、業務功能需求和非功能性需求。其中非功能性需求主要包含安全、性能、擴展性、持續運行時間、無差錯率、易用性、美觀等多個方面的需求。它是整個項目建設工作的實現標準和參考依據。

對於甲方機構來說，業務需求編製工作通常由負責該業務的部門承擔，有時也會由技術部門等其他部門代為編寫。但無論哪個部門承擔業務需求的編製工作，甲方項目經理都應該積極的參加到編製過程中去，有利於其充分理解需求提出的業務背景和初衷，使其可以更加深入的理解業務需求、了解需求人員的想法。只有在這種情況下，甲方項目經理才能真正的了解到業務部門需要建設什麼樣的系統、實現什麼樣的功能，才能夠將業務要求準確的傳遞給乙方建設廠商，並確保其產品可以滿足業務需求。

2. 制定實現方案

項目實現方案的編製工作通常由甲方項目經理來負責，其在對業務需求充分理解的基礎上，結合項目「完成」的定義，並依據自身的工作經驗，對該項目的建設思路和實現路徑進行梳理，主要包含以下內容：業務功能規劃、核心技術要求、建設實施路徑、投入資源梳理、存在風險及應對措施等。

對於甲方項目經理來說，其編製該方案的目標主要有以下幾點：一是從不同的角度，向機構管理人員及項目團隊成員，介紹項目軟體的建設規劃和實現思路，使其對項目建設工作有所了解，便於甲方項目經理後續工作的開展；二是通過可落地的實現方案，為相關領導樹立項目可完成的信心；三是針對負責項目具體建設工作的乙方團隊，通過該方案來對其項目建設工作進行約束，可以有效的避免乙方廠商由於業務方面的欠缺而導致產品無法滿足業務需求的風險。

3. 估算項目預算

項目預算的估算工作，主要指在項目建設工作正式開始前，通過相應的估算方法對項目建設所需的各項費用進行估算的過程。該工作通常由甲方項目經理負責，基於其對項目需求的理解，依據自身的工作經驗或是參照同類型的項目，從而估算出該項目的規模，並最終得出相應的預算。

通常情況下，我們會使用代碼量來描述一個軟體規模的大小，而且其與項目規模成正比關係，即代碼量越大對應的項目規模也越大，反之則越小。但我們應該看到，在項目建設工作中還存在很多無法用代碼量來估算的工作，如設計、測試、部署和文檔等，這就使得僅通過代碼量是無法準確、全面的對項目規模做出估算的。因此，在實際工作中，我們一般會採用標準工作量來對規模進行估算，標準工作量越大則項目規模越大。其中標準工作量，不同於傳統意義上的工作量，其通常會以某一工作量明確的功能為基準功能，相關功能在評估時通過與其進行對比、分析的方式來得出相應的工作量。這樣做的好處有以下幾點：一是所有工作量的評估都是基於同樣的標準，可以有效的減少人為因素對項目規模評估工作的影響；二是對於採用相同評估標準的已完成項目，可以通過分析其最終費用與最終標準工作量的關係，來獲得每個標準工作量所對應的費用，有助於提升預算評估的準確性；三是採用相同評估標準的已完成項目，可以為新項目的投入資源預估工作提供有效的參考；最後可以作為不同乙方團隊能力的評判標準，完成相同標準工作量的工作，投入資源少、花費時間短的團隊能力更強。

按照筆者的工作經驗，在對軟體項目規模對應的標準工作量進行估算時，為了降低估算的複雜度、提升其準確度，我們可以按照分析、設計、開發、測試、部署等不同軟體建設階段來對所有功能模塊的工作量進行估算，參照指定的評估標準，依據本階段工作內容、成果物和功能模塊的複雜度來確定其具體的工作量。其中對於部署這樣無法區分功能的工作，可以採用整體估算的方式。在進行評估時，甲方項目經理不能僅僅針對已有的功能，還需要依據已有的需求、並結合其工作經驗，為可能存在的變更預留出恰當的空間。最後將各部分的估算值累加起來後，就得到了該項的標準工作量。如下表3.1，單位為人月：

表 3.1

在明確項目規模後，扣除掉其中甲方機構需要付出的工作量，即可依據每個標準工作量所對應的費用或甲方項目經理的工作經驗，得到項目對應的預算。

4. 制定項目計劃

項目計劃制定工作通常由甲方項目經理負責完成，其依據項目的「完成」定義中對時間的要求，結合自身的工作經驗，按照時間順序對所有項目建設相關的工作進行排列和規劃。主要包含以下內容：什麼階段做什麼事、需要什麼人參與、產出什麼成果物、需要多少時間、每個裡程碑大概的完成時間等等。其目的在於，通過項目計劃一方面可以確保項目組成員了解項目建設的整個流程，清晰其需要承擔的工作職責和工作要求，有利於甲方項目經理管理、協調工作的開展；另一方面通過對計劃的梳理工作，甲方項目經理可以及時發現項目建設中可能存在的不足與風險。

依據筆者的個人經驗，在編製項目計劃時，一般採用由粗到細、由近及遠的方式。具體流程如下：首先將項目建設工作中的里程碑按時間順序列示出來，如需求分析、產品設計、代碼開發、功能測試、上線部署等，並標明每個裡程碑的關鍵產出物；其次確定里程碑之間的依賴關係，再依據項目「完成」對時間的要求，確定每個裡程碑的開始和完成時間；最後在里程碑下補充具體的項目工作及產出物、依賴關係和時間安排。

對於甲方項目經理來說，其需要依據項目建設過程中的具體情況，來相應的對項目計劃做出調整，並通過各種項目管理手段來確保項目建設工作能夠按照計劃正常進行。

5. 項目立項

對於大多數甲方機構來說，由於自身的規章制度和內控、審計等方面的要求，軟體項目只有在通過相關的立項評審流程後，項目工作才可以算作是正式的開始。對於待立項的項目，甲方機構通常會舉行由高層領導主持、各相關方共同參與的項目立項評審會。會上，評審人員依據甲方項目經理提交的立項材料，對項目建設的必要性、可行性以及預算的合理性進行審議，如均無異議，則項目正式立項。

在項目立項評審會之前，甲方項目經理需要依託項目前期的工作成果，如實現方案、項目規模、項目預算和項目計劃等，整理出該項目的立項建議書，主要包含以下幾個方面：一是分析業務需求，判別其與已有業務系統的關係，以此來確定項目是新建項目還是延續性項目；二是從市場狀況、同類型產品比較、盈利分析、技術可行性等方面來確定項目建設的必要性和可行性；三是指定項目組成員，及其對應的工作職責；四是彙報項目建設的工作計劃和實施方案；最後彙報項目的預算情況，並簡要彙報預算的計算方式。

對於項目立項材料，為了確保其可行性和完備性，還可以邀請外部專家進行評審，從第三方的角度，本著客觀、公正的態度，對項目建設方案的可行性和預算的合理性，提出各自的意見和建議。同時，專家的意見可以作為立項評審會決策的參考依據。

6. 項目採購

對於大多數甲方項目來說，項目採購工作主要指通過相應的採購方式來引入項目建設相關的各類廠商，主要有項目諮詢機構、軟體開發廠商和測試廠商等。其中項目諮詢機構主要提供業務規劃、軟體架構等方面的服務，負責為甲方機構引入先進的業務理念和成熟的建設經驗；測試廠商是在質量要求較高的情況下，引入的開發廠商以外的專門測試機構；軟體開發廠商負責建設滿足業務需求的軟體系統。

在採購過程中，常見的採購形式主要有招標採購和非招標採購兩種，其中招標採購又可以分為公開招標和邀請招標；非招標採購主要有競爭性談判、詢價和單一來源採購。其中，公開招標，指通過招標機構在法定的媒介發布招標公告來邀請所有滿足條件的機構參加相關項目的投標；邀請招標，指通過招標機構以投標邀請書的方式直接邀請特定的機構參加相關項目的投標；競爭性談判，直接邀請3家及以

上的機構就項目開展談判和報價，以確定符合條件的機構；詢價，通過向市場機構詢問價格的方式，來選擇價格適合的機構；單一來源採購，指定某機構作為唯一的供應商。不同的採購形式各有特點，適用於不同的情況。從公開招標、邀請招標、競爭性談判、詢價到單一來源採購，採購的公開性逐漸降低，但是流程也越來越簡單、費用也隨之減少。

甲方項目經理應在公司相關制度的指導下，綜合考慮項目的各種情況，如是否新建項目、預算、採購費用、項目時間等，確定適合的項目採購形式並形成相應的說明性文檔。最後，將該項目的採購請示文檔提交專門的採購管理部門，來決定是否採用該採購形式。

確定採購形式後，即可開始相應的項目採購流程。如果採用招標採購，首先甲方項目經理需要編製項目招標文件，然後由專門的招標中介機構負責標書發送、組織開標、評分、結果公示等後續工作。最後，選擇評分高的機構作為中標機構；如果採用競爭性談判，可以由甲方項目經理或是其他中介機構邀請3家及以上的機構，就項目進行談判，最後依據談判結果和報價選擇中標機構；詢價則要求甲方項目組至少2人，通過電話、郵件等方式對市場上的相關機構就價格、售後等方面進行溝通，形成詢價列表，通過比較、分析確定最後的建設機構；單一來源採購直接指定廠商即可。

最後，甲方項目經理將採購結果以書面的形式彙報項目管理組和採購會，得到確認後即完成採購流程。

3.2. 項目建設期

在項目建設期，項目建設工作進入到了具體的開發、實施階段，所有的項目工作都是為了確保項目軟體能夠按要求、按計劃的完成。該階段的項目工作主要由乙方廠商負責，甲方項目經理在這個階段的工作主要是協助、管理乙方廠商，同時對乙方廠商的相關成果物進行評審，以確保其工作能夠滿足相應的建設要求、項目工作能夠順利開展。在這個階段所涉及到的工作主要有：

1. 編製需求規格說明書

需求規格說明書是乙方廠商在對項目的業務需求進行學習、分析後，依據實現方案的功能規劃和實現要求，編製的軟體功能描述文檔，通過文字、圖表等方法將軟體功能全方位的落實到紙面上。其主要包括以下內容：用戶分類及特徵、許可權劃分、功能模塊框架、介面要求、功能詳細信息和對非功能需求的實現方案。其中，功能詳細信息包括功能說明、功能流程、演算法描述、使用角色、涉及欄位、校驗規則、狀態變化、彈出信息、異常處理等等。

需求規格說明書是開發人員設計工作和開發工作的基礎，是相關測試人員在編製測試案例的參考依據，也是甲方人員了解乙方廠商軟體建設思路的有效途徑。為確保乙方對業務需求理解的準確性和完整性，同時其規劃功能可以滿足業務需求，甲方項目經理需組織業務部門等相關部門，通過評審會的形式對需求規格說明書進行評審、確認。通過評審的需求規格說明書，將作為甲乙雙方共同認可的項目建設基礎文檔，不可隨意變更。

這裡需要注意的是，本書中對需求規格說明書的要求，是在國家標準文檔《計算機軟體需求規格說明規範》的基礎上，結合筆者的工作經驗而整理出來的，可能無法適應所有的甲方項目。因此，讀者可以依據自身項目的要求，來制定相應的需求規格說明書要求。

2. 確定技術方案

技術方案是由乙方廠商編製的技術層面的軟體實現方案，和甲方項目經理編寫的功能層面的實現方案不同，它聚焦於軟體建設所涉及的各種技術，以及如何通過這些技術手段來實現軟體相應的功能。其內容主要包括：軟體架構、硬體架構、開發語言、開發框架、資料庫和運行環境等信息。同時，還需要在方案中明示技術選型的依據、涉及第三方軟體是否開源、是否有額外的採購費用等內容。

技術方案是乙方廠商能否確保項目落地的重要憑證，因此甲方項目經理需要依據自身的工作經驗，來對其可行性和合理性進行仔細的評審、全面的分析，必要的情況下可以邀請外部專家協助完成評審工作。

3. 軟體設計文檔

軟體設計工作主要由乙方廠商承擔，是其在對業務需求深入了解的情況下，依據甲方對項目的建設要求，從技術實現的角度對項目軟體的功能模塊、調用關係、數據結構、資料庫、關聯介面和界面等內容的實現方式進行設計、規劃的過程，最終將這些內容落實到紙面上就形成了相應的設計文檔。同需求規格說明書相比，其功能模塊不僅有業務層面的模塊，還包含了技術、數據層面的底層模塊。同時相關功能模塊均按照高內聚、低耦合等設計模式，重新進行了規劃和梳理，使得其更易於實現。軟體設計文檔從不同的方面來對最終的軟體產品進行了全面、詳細的描述，項目組成員通過它可以提前對項目軟體有一個初步的了解。為了確保項目軟體能夠滿足項目建設的相關要求，降低軟體功能不滿足業務需求所帶來的風險，甲方項目經理需要在設計工作完成後，組織業務、技術和外部專家等相關人員，來對其進行相應的評審工作。

通常情況下，軟體設計工作分為概要設計和詳細設計兩種。其中，概要設計主要是對軟體的整體結構做出規劃，如模塊結構、模塊關係、數據結構等，其產出物主要是軟體架構圖和數據關係圖；詳細設計則是在概要設計的基礎上，對各功能模塊對應的功能說明、功能流程、演算法描述、數據欄位、資料庫表結構、校驗規則、狀態變化和異常處理等內容進行具體的描述。對於詳細設計的產出物來說，既可以是包含所有內容的詳細設計文檔，也可以是按照不同設計對象來分類的設計文檔，如軟體結構設計文檔、界面設計文檔、資料庫設計文檔等。讀者可以依據自身項目具體的建設情況和項目管理需求，來要求乙方廠商出具相應的設計文檔。

4. 制定開發計劃

開發計劃的制定工作主要由乙方廠商負責，其依據甲方機構對項目建設時間的要求，結合自身的建設方案，按照時間的先後順序來對軟體開發過程中涉及到的各項工作進行排列和規劃，其內容主要有開始時間、完成時間、前序工作、責任人、產出物等。通過該計劃，乙方團隊的相關成員都可以清晰的明確自己的工作職責和工作目標。

對於甲方項目經理來說，圍繞著開發計劃其需要完成以下兩項工作：一是為了確保開發計劃可以滿足項目整體計劃的要求，其應依據自身的工作經驗來對開發計划進行相應的評審工作；二是依據開發計劃來對項目建設進度進行管理。其可以依據項目工作進度與對應計劃的關係，來判別項目建設的進度情況，主要有正常、提前和延期。然後根據具體的進度情況，來開展對應的項目管理工作，以確保項目建設進度始終處於可控的範圍內。

對於乙方廠商來說，開發計劃不是一成不變的，其應依據軟體開發過程中的具體情況，及時的對開發計划進行調整。但需要注意的是，調整後的開發計劃，只有在獲得甲方項目經理的認可後，才可以在團隊內正式推行。

5. 軟體開發

軟體開發工作由乙方廠商負責完成，是項目建設工作最重要的組成部分，其需要通過代碼開發、單元測試等開發建設工作，按照開發計劃的整體安排，來將業務需求轉化為可執行、可操作的軟體系統。

對於甲方項目經理來說，通常不會直接參与到軟體的開發過程中去，但其會通過相應的項目管理手段來確保開發工作能夠按計劃正常進行，主要包含以下幾方面的內容：一是創造不受外部影響的開發工作環境。其通過取消非必要彙報、提供獨立工作場所等手段，來避免開發工作受到過多的外部影響，以確保乙方廠商能夠專註於軟體開發工作；二是開發進度管理。通過日報、晨會等形式及時掌握軟體開發的進度，發現其中可能的進度風險並予以處置；三是軟體質量管理。通過代碼評審、功能測試等手段，對軟體產品的質量進行管理；最後是軟體需求管理。為了避免軟體需求變更對開發工作的影響，其應依據需求提出方的意見，結合項目建設的具體情況和自身的工作經驗，來對需求變更進行管理。

6. 軟體測試

軟體測試工作是保障軟體質量的主要手段，其目的是確保軟體產品可以滿足業務需求、達到業務使用的要求。為此，項目建設相關的各參與方，如乙方技術人員、乙方測試人員、測試機構測試人員、甲方項目組成員、甲方業務人員等，都需要依據其自身的要求來對軟體展開相應的測試工作，主要有單元測試、冒煙測試、功能測試、聯調測試、性能測試、安全測試、文檔測試、市場試用等。但需要注意的是，這些不同類型的測試工作對應著項目不同的建設階段，相互之間存在有一定的關聯關係，這就要求甲方項目經理在制定項目工作計劃時，要充分的考慮到這些情況，確保相應的測試工作可以有序、順利的開展。

對於絕大多數軟體來說，軟體測試相關的工作通常都會佔據整個項目建設工作的1/3到1/2，在保證軟體質量的前提下，測試工作能否按計劃如期的完成會對項目建設工作的整體進度產生極大的影響。因此對於甲方項目經理來說，為了確保項目測試工作能夠按計劃開展，其需要完成以下兩個方面的工作：一方面是提升測試工作的效率。即通過測試案例評審、自動化測試等手段，來提升測試工作的效率；另一方面要及時的發現影響測試工作進度的風險，並進行相應的處置。其中，常見的風險因素有代碼質量不過關、需求理解錯誤、連帶問題過多、需求變更時點太晚等。

7. 產品上線

產品上線工作通常由乙方廠商和甲方項目經理共同承擔，其標誌著項目軟體的開發建設工作基本告一段落，軟體產品在功能、性能等方面均已達成了預定的建設標準。在完成上線工作後，軟體產品即具備了向市場提供業務服務的能力。

為了確保產品上線工作能夠有序、順利的推進，乙方廠商需要制定出相應的上線方案，包括上線的工作計劃、軟硬體的部署方案、應用軟體的類型和版本、軟體配置參數以及原始數據初始化等方面的內容。同時，在方案中還需要對上線過程中可能出現的風險提前做出預案，防止上線工作因不可控的風險而失敗。如果涉及到多個相關的軟體同時上線，其還需要依據軟體的關聯關係來約定所有軟體的上線順序。

對於甲方項目經理來說，在上線工作中，其一方面需要對乙方廠商的上線方案的可行性和合理性進行評審；另一方面則需要協調相應的部門為上線工作做好準備，如業務制度、人員培訓、硬體設備等。

3.3. 項目運維期

在項目運維期，軟體已正式推向了市場，該階段的各項工作主要是為了保障軟體能夠穩定的運行、確保業務能夠正常的開展。通常情況下，項目的運維工作會由專門的運維人員負責，其可能來自於甲方的相關部門，也可能來自於相應的乙方廠商或運維廠商。對於甲方項目經理來說，其在這個階段的工作主要有兩點：一是將項目相關的資料、文檔交付給具體的運維人員，確保項目相關信息能夠最大化的交接給運維人員；二是協助運維人員解決運維過程中存在的問題。

1. 項目工作交接

項目進入運維期後，項目工作由建設團隊轉移給運維團隊，工作的目標也由確保軟體產品能夠按要求、按計劃的完成轉變為確保軟體平穩運行、業務正常開展。為了使項目運維工作能夠順利開展、保證其工作的質量，運維團隊必須對運維產品有深入的、全面的了解。這就要求在進行工作交接時，甲方項目經理應將建設過程中涉及到的所有與軟體產品相關的信息，如業務需求、設計方案、功能架構、測試案例、產品代碼和軟硬體部署圖等，通過相應的方式移交給運維團隊。

對於甲方項目經理來說，其交接工作主要有以下幾點：一是梳理項目建設中與軟體相關的各類文檔，形成相應的項目文檔集；二是邀請項目建設過程中不同角色的人員，從不同角度來為運維人員講解系統建設背景、業務要求和軟體實現方案等建設信息；三是對運維人員進行相應的考核，確保工作交接的質量。在完成交接工作後，甲方項目經理的工作職責基本完成。

2. 日常運維

日常運維工作主要由項目運維人員負責，其目標是在整個項目運維期內，通過相應的運維工作來維持軟體運行的穩定、確保業務能夠順利開展。其涉及到的工作主要有以下幾個方面：一是產品軟體日常檢測。即對軟體產品的運行情況進行檢測，以及時發現運行過程中存在的問題並予以解決；二是軟體產品升級部署。在對軟體功能進行升級或完善後，完成相應的部署、發布工作；三是運行環境監控。對軟體相關的軟硬體環境進行監控，以及時發現並解決影響環境穩定運行的各類問題；四是運行環境管理。定期對運行環境的參數、運行文件和運行數據等內容進行梳理，並按照相應的運行要求進行調整或備份；五是運行環境升級。依據業務開展需要、修補系統漏洞等方面的原因，通過軟體升級、硬體更換等方式對軟硬體環境進行相應的升級。

3. 使用支持

對於軟體的用戶來說，其在軟體使用過程中可能存在一些使用上的疑問，如找不到功能、業務無法實現等。對於這些使用問題，其一方面可以通過軟體的操作手冊，來了解相應功能的操作方式；另一方面則需要通過電話、QQ、微信或郵件等方式來聯繫甲方機構指定的支持人員，由其來解決相應的問題。依據筆者的工作經驗，大多數情況下，用戶使用方面的問題是通過系統支持人員來解決的。

因此，對於使用支持人員來說，其工作應包含以下內容：一是解答用戶在使用方面的疑問；二是通過對用戶所提出的問題進行整理，來完善軟體的Q/A文檔或操作手冊；三是在同用戶的溝通過程中，了解其對軟體的建議和要求，為後續的軟體優化、升級需求編製工作提供依據。

推薦閱讀：