起點課堂會員權(quán)益
職業(yè)體系課特權(quán)
線下行業(yè)大會特權(quán)
個人IP打造特權(quán)
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業(yè)技能直播
會員專屬社群
榮耀標識初次接手To G項目，我真是太天真了（中）
編輯導讀：to G是從to B衍生出來的一種特殊劃分，面向的企業(yè)為政府或相關(guān)事業(yè)單位，主要是根據(jù)每年政府投入的財政預算，然后去做的一系列信息化項目。本文從作者自身工作出發(fā)，結(jié)合具體項目實踐中的所思所想，根據(jù)自己第一次所經(jīng)歷的to G項目，分享總結(jié)了自己的一些心得體會，供大家一起參考和學習。
本來想兩篇文章完結(jié)To G這個話題，但是在這半年多的工作中，卻發(fā)現(xiàn)這里面的水深實在不是兩篇文章可以說完的，那么就用三篇文章來說明To G這個大型話題吧。
在上一篇我們講到，To G項目有幾個特點：
- 用戶基數(shù)極大
- 用戶畫像不明確
- 準確率，支撐能力等務必100%
- 需求有著大量不確定性
這次我要再補充兩個特點
01 外部系統(tǒng)依賴性高
在這次合作的To G項目中，他們與很多其他的政務類，政府類系統(tǒng)都進行了業(yè)務上的連通，在一些主業(yè)務上甚至需要其他業(yè)務系統(tǒng)來進行信息完善和核對。
10月中就曾經(jīng)發(fā)生過這樣的一個事情：
由于對接的另一個系統(tǒng)出現(xiàn)問題，主業(yè)務上某個信息就無法進行校驗和填充，這直接導致了該業(yè)務無法正常運行。
由于對方系統(tǒng)無法在短時間內(nèi)完成修復，征得業(yè)務方的同意下，我們只能臨時修改業(yè)務流程，跳過這一步校驗，這樣的操作也導致了系統(tǒng)中這部分業(yè)務出現(xiàn)了兩天的臟數(shù)據(jù)……后續(xù)的數(shù)據(jù)清理工作也是一件十分繁瑣而復雜的事情。
也許你認為這只是政府部門之間的對接問題，不屬于我們的工作，這種想法是錯誤的。
不論是做To G還是To B/C這類的事情都有可能發(fā)生，如何在短時間內(nèi)拿出方案，將影響降到最低，是非常考驗產(chǎn)品經(jīng)理的應急能力的。
02 用戶體驗的對上與對下
我相信每個產(chǎn)品經(jīng)理都會說這樣的一個詞：用戶體驗。
在做To C項目時，他強調(diào)的是應用場景下的流暢體驗，無論什么方法，讓用戶爽是目標。
在做To B項目時，用戶體驗指的是流程通暢，因為對于B端的使用用戶來講，保證流程便捷通暢，完成既定的業(yè)務是目標。
那么To G項目的用戶體驗是什么？
是用戶的流暢使用嗎？不完全是，他們會為了保證數(shù)據(jù)準確，從而多重校驗。
是流程的快速便捷嗎？不完全是，政府業(yè)務有著嚴格的業(yè)務流程標準，需要多個部門協(xié)作的流程一個也不能縮減，甚至有著嚴格的上下級層級流轉(zhuǎn)制度，不允許跨級。
那么他們的用戶體驗在哪里呢？有兩個方面：
對下：具體基層使用者
他們的體驗訴求在宏觀上與B端用戶相似，需要保證流程的通暢；
但同時對于一天8個小時都需要使用系統(tǒng)的他們來講，每個微觀功能點的使用體驗都需要像C端用戶體驗打磨那樣，保證他們使用起來順手流暢。
對上：領導層
對于To G項目來講，獲得領導考察的機會比起市場上的其他APP應該都多，那么領導層在意的體驗是什么呢？
是反饋。誰的反饋？
- 系統(tǒng)使用者，包括內(nèi)部業(yè)務操作人員以及C端用戶。
- 數(shù)據(jù)反饋。
系統(tǒng)使用者的反饋不多說，這相當于繞回了上面說的B/C端用戶體驗設計，而數(shù)據(jù)反饋是這些年隨著大數(shù)據(jù)概念的興起而衍生的一種關(guān)注。
之前說過用戶基數(shù)極大是To G項目的一大特點，如何將這個“大基數(shù)”運用得當，是每個To G項目都在考慮的問題。
03 產(chǎn)品設計要點
接下來，我會對這半年中總結(jié)出來的一些產(chǎn)品設計想法歸納一下，將最重點的部分進行陳述。
1. 挖掘需求底層邏輯
這里指的底層邏輯并不是需求的深層次應用場景，反而是最基礎的原始功能邏輯挖掘。
這次對接的To G系統(tǒng)由于更換過多個開發(fā)團隊，對接人也是一年一換，系統(tǒng)開發(fā)等相關(guān)文檔都處于零存儲。
常常在對接新需求時，業(yè)務方對于舊功能也是一問三不知。所有的功能流程，數(shù)據(jù)庫建表等邏輯幾乎都需要通過研發(fā)小哥哥對著代碼一字一句摳出來的，
最后，我們只能在每次對接到新需求后，將涉及到的舊功能重新梳理一次，相應的接口，數(shù)據(jù)庫表格字段能找到的也都找出來。
研發(fā)小哥哥前兩天和我說了這么兩句話：
- 我第一次遇到開著數(shù)據(jù)庫表和我講需求的產(chǎn)品經(jīng)理！
- 你居然也會寫SQL，下一步來開發(fā)吧，功能接口你都熟了！
2. 提前規(guī)劃資源
這半年來對于做To G項目有一個感受是：每一臺服務器都帶著厚厚的工單條。
項目資源申請大到服務器，小到數(shù)據(jù)庫容量，每一次擴容都需要進行申請，時間長短不一，內(nèi)容復雜度參差不齊，如果遇到緊急事故加急工單也是漫長的催促流程。
所以在產(chǎn)品設計中必須有較全面的前瞻性，與研發(fā)同事確定好需要的資源，提前做好規(guī)劃。
3. 考慮最小并發(fā)值
由于To G項目的大用戶基數(shù)，在進行需求設計時，必須時刻謹記設計好每個功能的最小并發(fā)值，并讓研發(fā)和測試進行壓力測試，否則一旦上線后出現(xiàn)宕機，又臨時申請不到資源，那可就真的是麻煩大了。
04 總結(jié)
下一篇應該會來講講如何與To G項目的業(yè)務方進行需求溝通，對于我這個之前做慣了B/C端產(chǎn)品的產(chǎn)品經(jīng)理來講，這半年的溝通能力可真的是突飛猛進……
互勉！
#相關(guān)閱讀#
本文由 @DHAllison 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。
題圖來自 Unsplash，基于CC0協(xié)議
描述的都是很實際的問題，很有同感！
感謝分享，大佬 能加個v嘛？向您請教請教