G端產(chǎn)品的工作流程和B端、C端還是有一定得差異。比如正文作者分享的這種零散性需求，其流程和方法，都與大家認知的有很多不同。

在G端項目中，根據(jù)項目需求的大小、復雜度和涉及對象的不同，往往可以大致劃分為幾種不同的類型。

新項目：需重新搭建并規(guī)劃產(chǎn)品

如政府部門的全新電子政務系統(tǒng)、大型企業(yè)的ERP（企業(yè)資源計劃）系統(tǒng)建設等。這類項目通常是從零開始，需要進行全面的市場調(diào)研、需求分析、產(chǎn)品規(guī)劃、系統(tǒng)設計、開發(fā)實施及后期運維等全鏈條工作，并伴隨著長期的戰(zhàn)略規(guī)劃，其中的技術選型、架構設計、未來擴展性等都需要考慮長遠。在系統(tǒng)的搭建上，可能需要跨部門、跨團隊甚至跨公司的緊密合作，包括項目管理、產(chǎn)品設計、開發(fā)、測試、運維等多個環(huán)節(jié)。

針對政策的新模塊需求或零散性需求，涉及不同公司負責的不同模塊

如稅務系統(tǒng)的年度更新、社保政策的調(diào)整導致的相關系統(tǒng)模塊升級等。這類需求往往由政策變化或新政策出臺引起，需要快速響應并調(diào)整現(xiàn)有系統(tǒng)，需求可能以模塊化的形式出現(xiàn)，每個模塊可能由不同的公司或團隊負責，需要高效的接口對接和協(xié)同工作，且系統(tǒng)需要具備一定的靈活性，以便快速適應政策變化帶來的需求調(diào)整。

針對后臺或前端的零散需求或自用需求，只涉及自己公司的開發(fā)內(nèi)容

如公司內(nèi)部OA（辦公自動化）系統(tǒng)的功能優(yōu)化改進等。這類需求通常來源于公司內(nèi)部用戶或特定業(yè)務部門的直接需求，不涉及外部合作。往往要求快速響應和迭代，以滿足業(yè)務發(fā)展的需要?？赡芨⒅靥嵘到y(tǒng)性能、優(yōu)化用戶界面使用效果等。

本文主要介紹第2種，針對新需求涉及到不同公司負責不同模塊，其中第3種需求其實也包含在第2種需求中，屬于最為簡單的一類，此處我將會后續(xù)主要的流程及能力做個羅列，并且后續(xù)內(nèi)容將圍繞展開：

1. 需求了解
2. 需求前期邊界溝通
3. 了解接口文檔
4. 業(yè)務流程串聯(lián)及原型輸出

一、需求了解

通常，G端項目產(chǎn)品的模塊新需求會有2種形式文件下達。

1. 政策文件及上級負責人（或者業(yè)主）的主需求信息
2. 具體的功能文檔

但無論是哪種需求，本質(zhì)都要求產(chǎn)品經(jīng)理擁有快速高效理解文檔的能力，此處針對不同的文檔需求進一步講述理解思路。

對于政策文件

• 宏觀把握，明確背景：仔細閱讀政策文件，理解政策出臺的背景、目的和預期效果。這有助于把握整個項目的宏觀方向，確保產(chǎn)品設計符合國家或地方的政策導向。
• 提煉關鍵信息：從政策文件中提煉出與本次產(chǎn)品模塊更新直接相關的關鍵信息，如需要解決的問題、期望達到的目標、優(yōu)先級等。這些信息將是后續(xù)需求分析和產(chǎn)品設計的核心依據(jù)。
• 溝通確認：與上級負責人或業(yè)主進行深入溝通，確保對政策文件的理解準確無誤，并進一步明確他們的具體需求和期望。通過面對面的交流，可以捕捉到文字之外的意圖和關注點。
• 需求分解與細化：將提煉出的關鍵信息進一步分解為具體的需求點，并考慮如何在產(chǎn)品中實現(xiàn)這些需求。這包括功能設計、界面布局、交互流程等多個方面。

特別要注意的點，閱讀這件事也是需要一定積累的，想要快速讀懂提煉有效信息，不要忘記日常的積累，也能夠幫助快速理解自己所在的行業(yè)。

具體的功能文檔

如果是明確的文檔內(nèi)容要求，幾乎所有的功能需求，文檔都有記錄。所做重點就是全面閱讀，理解框架，對關鍵的功能點、約束條件、技術要求等進行重點標注，同時梳理功能之間的邏輯關系。需要注意嘗試從用戶的角度出發(fā)，模擬使用場景，思考這些功能如何滿足用戶的需求和期望，并且從自己的角度出發(fā)，考慮是否有缺失情況，若有的話，可以及時和對方溝通或者做好內(nèi)部反饋。

在理解功能需求的基礎上，評估實現(xiàn)這些功能所需的技術難度和資源投入。同時，規(guī)劃出合理的實現(xiàn)路徑和時間表。

二、需求前期溝通邊界

文檔需求內(nèi)容理解后，整理該需求所涉及的功能清單，為防止不同團隊/企業(yè)之間的任務責任不清晰，事先進行需求溝通邊界確認非常重要。

功能清單整理及內(nèi)部梳理

在文檔需求內(nèi)容理解透徹后，產(chǎn)品經(jīng)理整理出一份詳盡的功能清單，清單包含所有需求點，以及每個需求點對應的功能描述、預期效果、優(yōu)先級等信息。針對此清單組織內(nèi)部會議（包括項目經(jīng)理或熟悉技術的同事），對功能清單進行逐一討論。重點分析每個功能的實現(xiàn)難度、技術可行性、資源需求等要點。同時，識別出哪些功能是其他公司負責的內(nèi)容，哪些是需要自行開發(fā)的。

多方協(xié)作與邊界確認

內(nèi)部梳理完成后，產(chǎn)品經(jīng)理應準備一份詳細的溝通材料，包括功能清單、責任劃分初步建議、可能的合作方式等。同時，邀請G端技術負責人共同參與其他公司技術人員的會議，再次確定彼此直接負責的事情，并處理會議過程中的疑議，對于難以達成一致的問題，可以記錄下來，會后進一步研究和討論，直至找到滿意的解決方案。

為了確保合作過程中各方都能遵守既定的責任劃分，明確記錄各方負責的功能模塊、時間節(jié)點、質(zhì)量標準等關鍵信息，以便在后續(xù)工作中作為參考和依據(jù)。

在需求溝通前期多公司合作的項目中，確定不同公司負責的內(nèi)容事項，此過程非常重要，整體溝通范圍可由大到小直至實現(xiàn)，防止邊界不清晰，導致后期實現(xiàn)效果有出入，彼此之間扯皮的情況發(fā)生。

三、了解接口文檔

如醫(yī)保系統(tǒng)中，公共服務部分與省份后臺經(jīng)辦系統(tǒng)可能是不同公司承辦的，每個公司可能只是負責某一個模塊的設計。在彼此邊界溝通清楚后，可能負責其他模塊的對方公司會開始設計自己的接口文檔，而我們所對接的模塊又需要對方進行對齊，以免自己設計的原型最終實現(xiàn)上對方接口不支持，這樣會導致后續(xù)反復修改的問題。

正因此就要求產(chǎn)品經(jīng)理擁有閱讀接口文檔的能力，能夠在已有的框架里，針對接口文檔中的出參入?yún)⑻釤挸鲎约耗塬@取的字段，進行串聯(lián)業(yè)務流程和用戶體驗。

在接口文檔查看之前，產(chǎn)品需要在前面的需求背景下，在不考慮接口文檔文檔的情況下進行設計字段排布構思，想好自己需要哪些字段進行展示，并通過對比接口文檔的字段，取出需要展示接口字段。梳理設計思考，是因為有時候接口文檔不一定符合我們的的設計需求，這時候可以提出質(zhì)疑，要求對方補充。同樣的，自己設計的時候，很有可能對這個業(yè)務其實理解不足夠，這時候，接口可以用來查缺補漏。并針對已經(jīng)梳理好的最終字段，串聯(lián)流程后，產(chǎn)出原型。

對于接口的查看方式，可以關注以下幾點：

1. 關注必填字段及出入?yún)?/li>
2. 一般InDto為入?yún)ⅲň唧w可以詢問開發(fā)，不同的開發(fā)或許有不同的命名方式），可以用來設計篩選，因此在原型設計的時候，要對比下自己設計的原型篩選字段接口是否能支持
3. 一般PutDto為出參（具體可以詢問開發(fā)，不同的開發(fā)或許有不同的命名方式），可以用來設計頁面展示字段，比如查詢之后，出現(xiàn)哪些字段。

此處對于接口查看方式的描述較為簡單，但是個人感覺基本簡單的字段查看是足夠的，如果想要深入了解，建議閱讀一些更為專業(yè)的文檔進行知識補充。

四、業(yè)務流程串聯(lián)及原型輸出

本質(zhì)上，業(yè)務流程串聯(lián)流能力，更多的是指對業(yè)務的理解能力，對需求中的業(yè)務理解透徹之后，就能把所需的頁面字段之類的進行串聯(lián)，將通過接口文檔和需求文檔得出的字段頁面進行梳理，每個頁面能能串起來，實現(xiàn)業(yè)務上的邏輯完整性。

在進行流程串聯(lián)后，將所有的流程和字段進行梳理并繪制原型，原型繪制完成后，先行檢查每個邏輯完整性，是否實現(xiàn)閉環(huán)，后續(xù)原型經(jīng)由業(yè)主確認無誤后，進行內(nèi)部評審，此處業(yè)主的確認很重要，得到業(yè)主的認可，意味項目不會偏離主要需求，同時后續(xù)若有相關需要調(diào)整的內(nèi)容，需要其他公司配合，也能從中得到周轉協(xié)調(diào)。業(yè)主確認后，進行內(nèi)部評審，評審完成后，算是進入排期開發(fā)階段。

總結

原型輸出評審后，還會有開發(fā)跟進，也許跟進過程中會面臨不同的需求調(diào)整，需要及時的做好版本記錄并及時更新原型，G端項目制的產(chǎn)品，如果只做項目的話，很多公司可能會開發(fā)直接繞過，直接自己修改字段，做好原型記錄，做好驗收，做到細節(jié)心中有，可以提升自己的產(chǎn)品專業(yè)度，遇到不懂的別人也會第一時間詢問自己，不容易被當背景板，但是具體的產(chǎn)品定位和自己想做的產(chǎn)品目標，也是每個項目制產(chǎn)品值得去思考的。