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

一、統(tǒng)籌力-項目邊界管理

1.1 明確項目目標

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

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

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

1.2 明確交付邊界

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

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

梳理項目整體架構(gòu)，從基礎設施層、到網(wǎng)絡層、應用層、展現(xiàn)層來做界定交付邊界。

基礎設施層：

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

網(wǎng)絡傳輸層：

網(wǎng)絡環(huán)境如何，是專網(wǎng)建設還是在互聯(lián)網(wǎng)環(huán)境下建設？是否涉及跨網(wǎng)絡傳輸業(yè)務？如果需要跨網(wǎng)絡傳輸，那么是雙向傳輸還是單向傳輸？傳輸?shù)耐ǖ蕾Y源又由誰提供建設？

業(yè)務應用層：

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

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

展現(xiàn)層：

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

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

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

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

其中甲方干系人可根據(jù)不同職級、不同崗位類型和業(yè)務職責來做區(qū)分。

較典型的可以劃為三層：決策領導層，經(jīng)辦層，執(zhí)行層。

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

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

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

第三方干系人：

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

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

四、執(zhí)行力-項目進度管理

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

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

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

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

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

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

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

1）項目延期風險

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

2）需求變更風險

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

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

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

3）進度調(diào)整風險

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

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

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

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

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

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

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

七、總結(jié)

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

本文由 @慢吞吞 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Unsplash，基于CC0協(xié)議。