9. 項目建設前準備

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

9.1. 需求理解情況管理

我們知道，對於乙方廠商來說，其在項目建設過程中涉及到的絕大部分工作，無論是需求分析、產品設計等設計工作，還是功能開發、軟體測試等實施工作，都是基於業務需求而開展的，其完成情況通常取決於在項目開始階段，相關人員對業務需求的理解程度。

為確保項目建設工作能夠滿足相應的業務需求，甲方項目經理有必要對乙方項目團隊成員的業務需求理解情況進行管理，目的是確保每個成員對需求的理解是準確的、一致的。一般情況下，甲方項目經理可以通過一「正」一「反」兩個方面，來對乙方成員的需求理解情況進行管理：

1. 業務需求講解

通過業務需求講解工作，可以有效的幫助乙方項目團隊成員對業務需求理解、掌握的更加透徹、準確和全面。通常情況下，甲方項目經理會在乙方項目團隊入場後，協調相關的業務人員或親自來為項目團隊成員講解業務的需求，同時介紹項目的實現要求和建設目標。

甲方項目經理在首次講解業務需求時，其內容通常以業務的整體情況和主要流程為主，目的是為了確保乙方成員能夠對業務有一個整體的、全面的了解，從而為其開展業務需求分析等項目工作提供有力的支持和幫助。

同時，隨著項目建設工作的開展，甲方項目經理還可以依據乙方團隊的建設情況和工作需要，來有針對性的來對業務需求的全部或某一部分進行講解，可以是講解業務的主流程，也可以是講解具體某一功能的業務細節。

2. 業務需求反講

甲方項目經理可以通過業務需求反講的方式來了解乙方項目團隊成員對業務需求的理解程度。在反講時，由乙方項目團隊成員來為甲方項目經理和業務人員講解業務需求中的各項內容，如業務流程、業務功能等，並回答與業務需求相關的各類問題。

對於甲方項目經理來說，為了確保項目建設質量，只有通過業務需求反講的乙方成員，才可以參與到項目建設中去。而對於未通過業務需求反講的乙方成員，應要求其暫緩參與項目建設工作直至其通過需求反講。

9.2. 確定開發模式

乙方項目團隊在進行項目開發工作時，一般會採用其慣用的開發模式，在個別情況下也會根據項目的要求而採用其它的開發模式。在項目建設中，常見的開發模式主要有：瀑布開發模式、迭代開發模式、快速原型開發模式、增量開發模式、敏捷開發模式以及螺旋開發模式等。不同的開發模式有其各有的特點，不能簡單的比較誰好誰壞，只能說在不同的開發場景中誰更適合。在本書中，筆者不對這些模式進行詳細的介紹，有興趣的讀者可以自行查閱相應的文檔。

對於乙方項目團隊應採用何種開發模式，甲方項目經理應在乙方團隊慣用的開發模式基礎上，結合項目的實際情況，依據自己對項目的進度管理、需求管理和風險管理等多個方面的需要，同乙方項目團隊負責人來共同確定。大多數情況下，項目開發過程中不會單純的採用某種特定的開發模式，而是會根據項目需求將幾種開發模式進行組合或是對乙方項目團隊慣用的開發模式進行改造，使之滿足項目建設需求和管理需要。如採用瀑布開發模式時可以引入敏捷開發的站立會議，並利用快速原型開發模式來快速的確定需求。

對於甲方項目經理來說，明確了項目將採用的開發模式，相當於確定了乙方項目團隊在項目開發工作中的基本操作規範。其在進行項目管理時，需要結合項目開發模式的規範來制定相應的項目管理制度：一方面要可以對項目進行有效的管理；另一方面則不能對項目開發工作產生較大的影響。如在瀑布模式下需求分析評審可以一次性完成，而在迭代模式下需求分析評審就需要分為多次。

9.3. 需求分析成果物及評審

需求分析是乙方項目團隊在對業務需求進行分析、學習，並同甲方相關人員就業務功能細節進行深入的溝通後，將相關信息歸納、整理為軟體功能描述文檔的過程。需求分析工作的產出物主要是需求規格說明書，內容主要有：用戶分類及特徵、許可權劃分、功能模塊框架、介面要求、功能詳細信息和對非功能需求的實現方案。其中，功能詳細信息包括功能說明、功能流程、演算法描述、使用角色、涉及欄位、校驗規則、狀態變化、彈出信息、異常處理等等。

我們知道，需求規格說明書是開發人員設計工作和開發工作的基礎，是相關測試人員在編製測試案例的參考依據，也是甲方人員了解乙方廠商軟體建設思路的有效途徑。為確保乙方對業務需求理解的準確性和完整性，同時其規劃功能可以滿足業務需求，甲方項目經理需組織業務部門等相關部門，來對需求規格說明書進行評審。如有必要，還可以邀請外部專家參與到評審工作中來。

評審工作主要是通過評審會議的形式來開展的，首先乙方相關人員將需求分析的工作情況向與會人員進行彙報，主要有：分析背景、分析方法、分析過程中發現的問題、分析結論等；然後將需求規格說明書向與會人員進行充分的講解，並解答與會人員對其中存在的疑問。

對於需求規格說明書在評審過程中發現的問題，甲方項目經理需敦促乙方項目團隊儘快提出可行的改進方案，並在獲得各方認可後完成相關文檔的修改。同時協調相關人員，對改動後的需求規格說明書再次進行評審，如改動範圍較小，在同評審人員溝通後，可以通過郵件的形式進行函審。

9.4. 技術方案及評審

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

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

技術方案的評審工作一般是通過評審會的形式來開展的，參會人員主要有甲方項目經理、技術部門人員、乙方團隊成員等。會上，由乙方項目團隊成員向參會人員介紹項目的技術方案，主要有方案制定思路、技術選型分析、軟硬體架構解析、中遠期規劃等方面的內容，同時其還需要解答參會人員所存在的各種疑問。通常情況下，技術方案一旦確定後，如非必要的情況，都不得再進行更改。

9.5. 產品設計成果物及評審

產品設計是乙方項目團隊在對業務需求深入了解的情況下，依據甲方對項目的建設要求，從技術實現的角度對項目軟體的功能模塊、調用關係、數據結構、資料庫、關聯介面和界面等內容的實現方式進行設計、規劃的過程。通常情況下，產品設計工作分為概要設計和詳細設計兩種。其中，概要設計主要是對軟體的整體結構做出規劃，如模塊結構、模塊關係、數據結構等，其產出物主要是軟體架構圖和數據關係圖；詳細設計則是在概要設計的基礎上，對各功能模塊對應的功能說明、功能流程、演算法描述、數據欄位、資料庫表結構、校驗規則、狀態變化和異常處理等內容進行具體的描述。對於詳細設計的產出物來說，既可以是包含所有內容的詳細設計文檔，也可以是按照不同設計對象來分類的設計文檔，如軟體結構設計文檔、界面設計文檔、資料庫設計文檔等。

為了確保項目軟體能夠滿足項目建設的相關要求，降低軟體功能不滿足業務需求所帶來的風險，甲方項目經理需要在乙方團隊的設計工作完成後，組織業務、技術和外部專家等相關人員，來對其進行相應的評審工作。其中，需要注意的是，來自不同部門的甲方人員因其專業背景的局限和崗位職責的不同，在對產品設計進行評審時，往往只會關注到與其相關的部分，如業務人員主要關注於界面設計圖片或是可交互的DEMO，技術人員則更多的關注於資料庫設計、程序設計等專業性較強的內容。因此，為了保證評審工作的質量和效率，甲方項目經理在對產品設計的成果物進行評審時，應針對不同的設計對象來組織相關人員進行專項評審，如原型界面評審、資料庫評審等。

產品設計成果物的評審工作主要通過評審會的形式來開展，乙方項目團隊的相關人員首先向參會人員介紹產品的設計思路和設計依據，然後通過產品設計文檔來詳細的介紹相應的設計成果，並解答與會人員存在的疑問。對於評審人員提出的改進意見，甲方項目經理應在同各方溝通後，督促乙方項目團隊及時的對產品設計進行相應的修改。

需要注意的是，通過評審的產品設計並不是一成不變的，在項目建設過程中，它會隨著工作的需要而隨時進行調整。而且每次調整後，都需要將設計文檔提交給相應的人員進行評審、確認。

9.6. 項目開發計劃及評審

項目開發計劃是乙方項目團隊在甲方項目經理制定的項目整體計劃的基礎上，對項目建設過程中涉及到的各項工作進行分析、梳理後，對這些工作的時間、資源和人員做出的具體規劃和安排。其內容主要有：建設階段、工作明細項、開始時間、結束時間和具體的責任人。其中建設階段為項目建設中的幾個主要階段：需求和設計階段、開發階段、測試階段和上線階段；工作明細項為項目建設工作中的具體工作事項，要求可以對應到具體的項目成員身上，如無法對應，則需要將工作進一步拆分直至滿足要求。示例見下表9.1。

表 9.1

為了確保乙方廠商提交的項目開發計劃的合理性和可行性，甲方項目經理應依據自身的工作經驗、結合項目的具體要求從以下幾個方面來對其進行評審：一是列示的工作項是否包含項目建設涉及到的所有工作；二是項目建設工作的時間安排是否合理；三是工作安排是否考慮相互之間的依賴關係，優先安排被依賴工作；四是項目成員是否存在同時參與多項工作的情況；五是工作項的責任人要明確，不應有模糊不清的情況；最後是項目開發計劃的時間安排是否符合項目整體計劃的要求。其在通過評審後，甲方項目經理應通過會議、郵件等形式將發計劃傳達給乙方項目團隊中的每一位相關成員，確保其了解各自需承擔的工作。

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