導讀：由于G端項目的特性，產品經理不能不懂項目管理，項目經理也不能不懂業務和產品，所以做G端項目時，產品經理往往也兼任項目管理的職責。本文作者以一個服務公安行業的綜合性業務系統項目為例，梳理ToG項目產品經理所需要具備的項目管理五大力。

一、統籌力-項目邊界管理

1.1 明確項目目標

對一個有明確合同約束的實施項目來說，最重要的莫過于明確項目目標。我們在職場上所看重的“以結果為導向”的特質中，這個結果便是根據目標來定義的。

作為乙方，本項目最重要的目標即是如期、保質順利交付。

對于甲方來說，本項目最重要的目標莫過于順利驗收每一個功能模塊，并保證每個模塊能投入正常使用，提升本單位工作效率。

1.2 明確交付邊界

對于這類強甲方主導的項目，往往存在著高度定制化和需求漫延兩大特性。

因此，在項目進入入場實施階段后，第一時間要做的事就是熟讀合同和需求書，明確交付邊界。

梳理項目整體架構，從基礎設施層、到網絡層、應用層、展現層來做界定交付邊界。

基礎設施層：

包含數據采集設備的類型和來源，存儲資源、計算資源等基礎資源的來源類型，是甲方提供的資源還是合同范圍內的自采形式？是云資源還是實體資源？

網絡傳輸層：

網絡環境如何，是專網建設還是在互聯網環境下建設？是否涉及跨網絡傳輸業務？如果需要跨網絡傳輸，那么是雙向傳輸還是單向傳輸？傳輸的通道資源又由誰提供建設？

業務應用層：

將以上兩項基礎資源的問題解決后，即來到用戶能直觀感知到的業務應用層，在這一層，我們要明確的首先是本項目服務的用戶范圍，涉及到哪些業務部門？具備哪些業務模塊？每個功能模塊的數據來源如何？如果涉及到對接的第三方數據，則數據準備情況以及對接方式如何？

以上“人生五問”基本清晰后，便要開始進行針對性的細化需求調研和梳理，對每個業務模塊明確業務目標、用戶群體、業務邏輯，對于一個功能性模塊的交付目標，除了梳理前述三項以外，更重要的是做好用戶預期的管理。眾所周知，在科技發展的征途中，系統建設也進行著幾個里程碑式的迭代：信息化–數字化-智能化。當然，隨著數字化轉型的高歌猛進，當前的大多數系統正從信息化向數字化轉型。那么便要明確，當前業務模塊，更適用于信息化呢還是數字化呢？不論結果如何，在這一步，我們要做的是，和客戶統一認知，明確預期。并將預計交付的結果，述之紙上。

展現層：

接著我們來到了展現層。當業務模塊和客戶明確清楚后，隨即便需要根據使用場景來選擇展現介質。例如綜合指揮態勢監測模塊，使用場景是指揮中心對事件處置進行指揮調度，用戶為指揮中心的用戶及領導，需求是能對全局態勢一覽無遺，并快速調配所有人、物資源。那么展現形式介質是屏幕更大的大屏端。又如辦公室內處理業務的業務員角色，他們的需求更多是坐在電腦前處理一個個業務作業，完成流程節點，因此，大多業務模塊的主功能都在PC端完成。再如，公安中有許多外部巡邏執勤的民警，他們需要在外巡邏，無法長時間待在辦公室前，因此他們對系統的體驗介質，以移動端為主，例如巡邏簽到、信息上報、接收指令、提交申請。

梳理完成幾種典型的展現方式后，我們要做的是根據每個業務模塊的用戶類型和需求，來梳理需要用到的展現方式，并繪制出在不同展現介質中所要完成的主要動作，確保流程完整。

三、溝通力-識別項目外部干系人

G端項目的干系人種類往往有多種。根據所屬公司可分為公司內部干系人，及項目組成員，甲方干系人和第三方干系人。

其中甲方干系人可根據不同職級、不同崗位類型和業務職責來做區分。

較典型的可以劃為三層：決策領導層，經辦層，執行層。

決策領導層，往往是部門的一把手，最終決定是否要為這個項目買單的人。他們關注的更多是價值和效益，而不是具體的細節問題。因此在做功能方案設計的時候，往往會將大屏、各項數據統計結果的展示作為領導們關注的模塊。他們要的最終就是“好看”兩個字。當然，這里的“好看”不僅局限在UI設計的酷炫，更是項目效益的高價值感，例如業務模塊提升了業務部門響應處理的效率，項目產生了大量的社會效益為單位實際的政績添光增彩，這些都屬于“好看”。

經辦層，往往是甲方在本項目中實際上的“執行項目經理”，在項目實施過程中，我們接觸的最多的人。他們有的精通業務、有的熟知技術、有的善于管理關注結果。根據不同類型的經辦人，有不同的溝通方式和側重點。不論他們曾經經歷如何，在這個角色上，他們最關注的就必然是進度和交付質量。與經辦人溝通的過程中，核心是要達成一致目標，并形成定期匯報機制。

執行層，作為系統真正的使用人，他們可能來自各個不同的業務部門，帶著不同的業務需求。需求調研的主要對象就是這個群體，在功能上線之后，主要的使用培訓對象、使用反饋調研對象也是這群人。他們關注的是功能是否好用，是否會給他們造成額外負擔。

第三方干系人：

通常指和我們的項目有對接的第三方單位或公司，例如會有數據對接、業務流程交互關系。在這個場景中，我們需要對第三方干系人做好分類，典型的有兩類：

1. 甲方的兄弟單位，這類也屬于業務方，可能和我們的甲方有業務交互，需要我們梳理好業務邊界，明確交互流程。
2. 第三方服務企業，與我們同樣屬于“乙方公司”，他們通常是負責其他系統的開發工作，和我們的系統有系統層面的數據交互。我們需要做的是劃分技術邊界，明確對接的技術方式。

四、執行力-項目進度管理

當完成了項目需求邊界梳理后，意味著真正的項目實施交付環節啟動。G端項目通常都具有周期長、業務復雜的特性。為避免純瀑布式的開發流程導致的項目交付后和客戶預期風馬牛不相及的弊端，我們需要根據合同要求，確定階段性目標，鎖定關鍵節點，倒排工期。

例如項目內如果包含采購服務，則明確在什么時間節點需要采購什么設備或產品到位，并做好相關的驗收流程和材料。

對于系統開發的工作，需要根據前期調研的需求，找到關鍵部門的核心需求點，排出優先級，逐個攻破。當然，這一步切記要和甲方達成一致意見，并在實施過程中主動積極匯報進度及問題。

在做項目進度管理的時候，要提前對各個環節做好預估和溝通，保證盡量合理的分配和安排。避免前期設計的時間安排一個月，而留給開發的時間只剩3天。

五、判斷力-項目風險管理

作為項目經理，除了對項目進度的統籌把控以外，還有一個重要的職責便是風險識別和把控，這一項能力很大程度上決定了項目進展的順利與否。

一般G端項目在實施過程中，通常存在以下三類風險：

1）項目延期風險

項目經理在做進度排期的時候，通常會將設備采購、調研、設計、開發、測試各個環節工期拆解排期。其中有一個存在風險點的環節，就是設計環節。為了減少交付后返工的情況，面對強勢甲方我們通常會選擇將設計稿和甲方進行確認后再投入開發，這樣的方式相當于風險前移稀釋，將推翻返工的風險前置到設計環節，減少返工成本。但是也是一把雙刃劍，由于客戶構成的多層級特性，設計稿確認的決策鏈條過長，且經辦人往往需要和一把手再做確認，這個環節的耗時無法準確估計，所以在這一步，務必做好“三板斧”：前期調研充分，過程多次確認，后期積極跟進。

2）需求變更風險

在項目實施過程中，由于項目交付周期較長，甲方領導的想法也常常在變。因此需求變更的風險也高頻存在。

要提前識別和規避這類風險，做好的辦法就是多問多匯報多記錄。

1. 多問：在做需求調研和功能設計的時候，刨根追底探究出根本需求，做充分的需求分析。
2. 多匯報：在梳理和設計過程中，多向需求方匯報溝通，做好二次確認，保證自己對需求理解的正確性。
3. 多記錄：每一次的溝通和確認都做好書面記錄，形成會議紀要，最好和需求方做好簽字確認，減少甲方“貴人多忘事”的可能性。

3）進度調整風險

除了需求范圍和內容的變更，另一種很常見的是甲方對于原先排好的排期做的臨時性調整。這種情況多發生于以下三種場景：

1. 某些突發的大型事件，涉及到甲方的業務職責，需要作出及時響應，配合工作。例如疫情或突發惡性事件，這類事件的特性是無法預測且無法回避，只能積極響應及時應對。響應的核心重點在于“快”和“準”。在第一時間，和甲方相關人員或部門進行需求溝通，找到核心需求，以最小時間成本實現需求，后續再做調整完善。
2. 大型節假日活動，這類事件的特性是周期性的可以預期的，如果經驗足夠豐富、對甲方業務足夠了解，可以在活動到來之前，提前做好準備。甚至可以在做排期計劃的時候，就考慮在內，提前做好排期變更的風險規避。
3. 關鍵干系人的變更，這類情況發生的頻率較低，但是也很難預測。關鍵干系人的變更，主要體現在甲方單位一把手或是經辦人角色的人員變動。如上識別干系人一節中，我們介紹到不同類型的人員所關注的重點和管理理念不同，例如有的領導熱衷創新，喜歡求新求異，而有的領導一心求穩，只想先做好最核心的業務，不求有功，但求無過。這種情況下，往往合同最終的交付結果不會改變，但是交付過程中的核心打磨模塊和優先級會發生較大調整。

六、決策力-項目變更管理

作為乙方項目經理，我們還要明白的一條“潛規則”是，需求的變更和漫延幾乎在每個項目里面都是不可避免的，我們能做的有以下幾點：

了解需求變更的背景，是對已交付的功能不滿所以提出新的需求，還是因為業務或政策調整帶來的需求變更？

1. 如果是前者，則嚴格來說不算是需求漫延，而是對現有功能的調優?？赏ㄟ^培訓指導用戶正確用法，或者優化交互體驗的手段來提升用戶對功能的接受度。
2. 如果是后者，則需要從業務調整的核心點著手突破，是否只需要對原有功能模塊的局部流程做出調整，盡量避免大的開發變更，節約開發成本。當然，這種情況屬于需求變更，友情提醒各位項目經理，做好需求變更記錄，走變更流程哦。

純屬于在原有交付范圍外的新增需求，此時可以和甲方一起調研分析需求產生的背景和實現的目標，探討是否有延伸二期建設的可能性，做好新增需求記錄，將新增需求納入二期建設范圍中，先交付再收費。

七、總結

G端項目不同于常規的B端項目，除了需要標準化業務流的共性，還具備更高的定制化、更多層的領導架構、更敏感的受政策影響度。因此，在做G端項目的實施過程中，我們需要更多的懷著做服務的心態做項目，針對不同的客戶級別提供不同的服務體驗，同時為了保障公司成本和項目服務質量，我們一定要做好風險識別及把控這一步，才能夠更好地做好ToG項目交付。

本文由 @慢吞吞 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議。