編輯導(dǎo)讀：to G是從to B衍生出來的一種特殊劃分，面向的企業(yè)為政府或相關(guān)事業(yè)單位，主要是根據(jù)每年政府投入的財政預(yù)算，然后去做的一系列信息化項目。本文從作者自身工作出發(fā)，結(jié)合具體項目實踐中的所思所想，根據(jù)自己第一次所經(jīng)歷的to G項目，分享總結(jié)了自己的一些心得體會，供大家一起參考和學(xué)習(xí)。

本來想兩篇文章完結(jié)To G這個話題，但是在這半年多的工作中，卻發(fā)現(xiàn)這里面的水深實在不是兩篇文章可以說完的，那么就用三篇文章來說明To G這個大型話題吧。

在上一篇我們講到，To G項目有幾個特點：

• 用戶基數(shù)極大
• 用戶畫像不明確
• 準確率，支撐能力等務(wù)必100%
• 需求有著大量不確定性

這次我要再補充兩個特點

01 外部系統(tǒng)依賴性高

在這次合作的To G項目中，他們與很多其他的政務(wù)類，政府類系統(tǒng)都進行了業(yè)務(wù)上的連通，在一些主業(yè)務(wù)上甚至需要其他業(yè)務(wù)系統(tǒng)來進行信息完善和核對。

10月中就曾經(jīng)發(fā)生過這樣的一個事情：

由于對接的另一個系統(tǒng)出現(xiàn)問題，主業(yè)務(wù)上某個信息就無法進行校驗和填充，這直接導(dǎo)致了該業(yè)務(wù)無法正常運行。

由于對方系統(tǒng)無法在短時間內(nèi)完成修復(fù)，征得業(yè)務(wù)方的同意下，我們只能臨時修改業(yè)務(wù)流程，跳過這一步校驗，這樣的操作也導(dǎo)致了系統(tǒng)中這部分業(yè)務(wù)出現(xiàn)了兩天的臟數(shù)據(jù)……后續(xù)的數(shù)據(jù)清理工作也是一件十分繁瑣而復(fù)雜的事情。

也許你認為這只是政府部門之間的對接問題，不屬于我們的工作，這種想法是錯誤的。

不論是做To G還是To B/C這類的事情都有可能發(fā)生，如何在短時間內(nèi)拿出方案，將影響降到最低，是非?？简灝a(chǎn)品經(jīng)理的應(yīng)急能力的。

02 用戶體驗的對上與對下

我相信每個產(chǎn)品經(jīng)理都會說這樣的一個詞：用戶體驗。

在做To C項目時，他強調(diào)的是應(yīng)用場景下的流暢體驗，無論什么方法，讓用戶爽是目標。

在做To B項目時，用戶體驗指的是流程通暢，因為對于B端的使用用戶來講，保證流程便捷通暢，完成既定的業(yè)務(wù)是目標。

那么To G項目的用戶體驗是什么？

是用戶的流暢使用嗎？不完全是，他們會為了保證數(shù)據(jù)準確，從而多重校驗。

是流程的快速便捷嗎？不完全是，政府業(yè)務(wù)有著嚴格的業(yè)務(wù)流程標準，需要多個部門協(xié)作的流程一個也不能縮減，甚至有著嚴格的上下級層級流轉(zhuǎn)制度，不允許跨級。

那么他們的用戶體驗在哪里呢？有兩個方面：

對下：具體基層使用者

他們的體驗訴求在宏觀上與B端用戶相似，需要保證流程的通暢；

但同時對于一天8個小時都需要使用系統(tǒng)的他們來講，每個微觀功能點的使用體驗都需要像C端用戶體驗打磨那樣，保證他們使用起來順手流暢。

對上：領(lǐng)導(dǎo)層

對于To G項目來講，獲得領(lǐng)導(dǎo)考察的機會比起市場上的其他APP應(yīng)該都多，那么領(lǐng)導(dǎo)層在意的體驗是什么呢？

是反饋。誰的反饋？

1. 系統(tǒng)使用者，包括內(nèi)部業(yè)務(wù)操作人員以及C端用戶。
2. 數(shù)據(jù)反饋。

系統(tǒng)使用者的反饋不多說，這相當(dāng)于繞回了上面說的B/C端用戶體驗設(shè)計，而數(shù)據(jù)反饋是這些年隨著大數(shù)據(jù)概念的興起而衍生的一種關(guān)注。

之前說過用戶基數(shù)極大是To G項目的一大特點，如何將這個“大基數(shù)”運用得當(dāng)，是每個To G項目都在考慮的問題。

03 產(chǎn)品設(shè)計要點

接下來，我會對這半年中總結(jié)出來的一些產(chǎn)品設(shè)計想法歸納一下，將最重點的部分進行陳述。

1. 挖掘需求底層邏輯

這里指的底層邏輯并不是需求的深層次應(yīng)用場景，反而是最基礎(chǔ)的原始功能邏輯挖掘。

這次對接的To G系統(tǒng)由于更換過多個開發(fā)團隊，對接人也是一年一換，系統(tǒng)開發(fā)等相關(guān)文檔都處于零存儲。
常常在對接新需求時，業(yè)務(wù)方對于舊功能也是一問三不知。所有的功能流程，數(shù)據(jù)庫建表等邏輯幾乎都需要通過研發(fā)小哥哥對著代碼一字一句摳出來的，

最后，我們只能在每次對接到新需求后，將涉及到的舊功能重新梳理一次，相應(yīng)的接口，數(shù)據(jù)庫表格字段能找到的也都找出來。

研發(fā)小哥哥前兩天和我說了這么兩句話：

• 我第一次遇到開著數(shù)據(jù)庫表和我講需求的產(chǎn)品經(jīng)理！
• 你居然也會寫SQL，下一步來開發(fā)吧，功能接口你都熟了！

2. 提前規(guī)劃資源

這半年來對于做To G項目有一個感受是：每一臺服務(wù)器都帶著厚厚的工單條。

項目資源申請大到服務(wù)器，小到數(shù)據(jù)庫容量，每一次擴容都需要進行申請，時間長短不一，內(nèi)容復(fù)雜度參差不齊，如果遇到緊急事故加急工單也是漫長的催促流程。

所以在產(chǎn)品設(shè)計中必須有較全面的前瞻性，與研發(fā)同事確定好需要的資源，提前做好規(guī)劃。

3. 考慮最小并發(fā)值

由于To G項目的大用戶基數(shù)，在進行需求設(shè)計時，必須時刻謹記設(shè)計好每個功能的最小并發(fā)值，并讓研發(fā)和測試進行壓力測試，否則一旦上線后出現(xiàn)宕機，又臨時申請不到資源，那可就真的是麻煩大了。

04 總結(jié)

下一篇應(yīng)該會來講講如何與To G項目的業(yè)務(wù)方進行需求溝通，對于我這個之前做慣了B/C端產(chǎn)品的產(chǎn)品經(jīng)理來講，這半年的溝通能力可真的是突飛猛進……

互勉！

#相關(guān)閱讀#

初次接手To G項目，我真是太天真了（上）

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

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