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

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

1.1 明確項目目標

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

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

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

1.2 明確交付邊界

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

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

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

基礎(chǔ)設(shè)施層：

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

網(wǎng)絡(luò)傳輸層：

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

業(yè)務(wù)應(yīng)用層：

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

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

展現(xiàn)層：

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

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

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

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

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

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

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

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

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

第三方干系人：

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

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

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

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

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

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

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

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

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

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

1）項目延期風險

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

2）需求變更風險

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

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

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

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

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

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

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

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

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

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

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

七、總結(jié)

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

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

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