本文基于工作以來實際項目情況，總結(jié)歸納出一些針對G端項目需求相關(guān)的經(jīng)驗，希望對你有所幫助。

一、G端業(yè)務(wù)分類

目前G端數(shù)據(jù)化項目根據(jù)其服務(wù)內(nèi)容和目標的不同，主要分為公共服務(wù)類、內(nèi)部服務(wù)類、行業(yè)監(jiān)管類這三種類型，主要在提高政府服務(wù)效率、優(yōu)化內(nèi)部管理流程以及加強行業(yè)監(jiān)管等方面發(fā)揮著重要作用，以下是這三種分類的一些介紹和特點：

我目前接觸的只有內(nèi)部服務(wù)類和治理監(jiān)管類的政府項目，都是從0-1開始，主要包括建筑行業(yè)、審計業(yè)務(wù)這兩個行業(yè)。接下來我也是以這些項目經(jīng)驗為例子，講解G端項目在需求調(diào)研、需求溝通、以及需求設(shè)計方面需要考慮和注意的一些事項。

二、需求來源與收集

一般對于B端項目的需求，一般可以通過市場分析和行業(yè)需求、客戶反饋、競品分析、銷售和客服團隊反饋、內(nèi)部團隊協(xié)作與反饋以及數(shù)據(jù)分析潛在的需求和改進點。

但是G端的項目比較特殊，就我目前接觸的內(nèi)部服務(wù)類和治理監(jiān)管類 這兩種類型來說，基本都屬于定制類開發(fā)，基本都是內(nèi)部系統(tǒng)和固定群體使用，市面上沒有競品作為參考，他們的需求主要來自于客戶需求調(diào)研以及政策文獻，也有部分來自于內(nèi)部老板的需求。

1. 來自客戶的需求

針對G端項目，需求調(diào)研的對象主要分為三類：

A： 核心領(lǐng)導類：比如，局里大領(lǐng)導。一般只關(guān)注駕駛艙內(nèi)容和設(shè)計 ，他們對具體業(yè)務(wù)的操作過程不關(guān)注。一般只有節(jié)點性的對內(nèi)對外匯報時會重點關(guān)注下。

關(guān)注的內(nèi)容主要是，上一段時間的成果匯總統(tǒng)計，本階段的一些成果展示，部分領(lǐng)導也會關(guān)注未來存在的一些隱患問題或者可提升方向。

B：業(yè)務(wù)領(lǐng)導類：比如，處/科室領(lǐng)導或者局里的分管領(lǐng)導。他們不僅會通過駕駛艙去實際關(guān)注自己分管處室/自己處室各種事項大概情況以及進度，也會在后臺中處理（比如任務(wù)分配、審批）和自己相關(guān)的一些業(yè)務(wù)信息。

C：一般業(yè)務(wù)人員：比如，具體處/科室業(yè)務(wù)人員。他們才是真正關(guān)注這個系統(tǒng)是否符合實際業(yè)務(wù)操作，怎么用，哪些功能點不對，哪些功能應該用著不舒服。

這類客戶他們其實是后臺管理系統(tǒng)主要的需求調(diào)研對象，以及也是后續(xù)系統(tǒng)試用過程中，以及系統(tǒng)迭代更新的主要需求來源。

在針對G端項目用戶需求調(diào)研的時候，這三類用戶我們都要去做調(diào)研，可以結(jié)合每種對象的關(guān)注點去收集需求，我們和客戶溝通獲取需求的方式，可能是面對面或者線上溝通，可能是通過歷史文件獲取信息，也可能是通過具體的政策文獻等方式，具體需要看每個業(yè)主的需求情況。

建議第一次正式需求溝通，以及后期整理后的需求匯報或者節(jié)點性的需求匯報，都能采取面對面交流。

B 端产品经理如何快速成长？

产品与业务架构主要是将整个业务工作流进行分层，梳理，然后抽象出一个个需求，将业务需求与产品合情合理的映射起来，最终使业务数据在产品中流动，执行，记录，使用。

查看详情 >

比如：審計整改管理系統(tǒng)是市縣兩用的，系統(tǒng)核心業(yè)務(wù)流程 主要是 新建項目信息（科室/股室負責人或主審）→編制整改問題清單（主審）→利用模板起草告知函（主審）→告知函審核（主審、科長/股長、分管領(lǐng)導）→發(fā)送告知函、問題清單及審計報告等給被審單位（主審）→被審單位接收告知函、問題清單、審計報告等（被審單位整改聯(lián)系人）→被審單位上傳其落實審計整改責任主體的佐證資料（即研究如何落實審計查出問題整改措施的有關(guān)會議記錄）→被審單位通過平臺反饋整改情況及佐證資料（整改聯(lián)系人）→審計機關(guān)（主審、科長/股長、分管領(lǐng)導）審核其反饋的整改信息資料，符合整改標準的進行銷號操作。項目整改清單下所有問題銷號，則該項目整改結(jié)束。

針對整體業(yè)務(wù)流程的需求調(diào)研，我們主要是根據(jù)審計服務(wù)中心領(lǐng)導對接，通過客戶在講解局里目前實際業(yè)務(wù)過程中，其實就已經(jīng)把大致的需求邏輯理順了，包括有哪些事項節(jié)點，每個節(jié)點是哪些角色人員去操作。

至于里面的一些細節(jié)信息，比如新建項目所需信息、整改問題所需信息、以及大概在什么業(yè)務(wù)階段會進行到下一流程情況，都需要根據(jù)具體業(yè)務(wù)處室提供的一些脫敏文件（如歷史項目計劃表、項目臺賬、問題臺賬、歷年匯報統(tǒng)計的問題數(shù)據(jù)需求等）基礎(chǔ)上進行設(shè)計。

針對業(yè)務(wù)細節(jié)的設(shè)計，遇到業(yè)務(wù)不通暢，以及需求準確性的確認都是需要跟具體業(yè)務(wù)處室的業(yè)務(wù)人員代表溝通確定。

基于以上的需求調(diào)研，已經(jīng)滿足后臺管理的需求設(shè)計了。至于駕駛艙的需求，主要是面向局領(lǐng)導的設(shè)計。

但是在系統(tǒng)沒有出現(xiàn)，無法感受到真實信息，因此領(lǐng)導一般都會提出一些大概的要點展示，但是這些已經(jīng)可以填充駕駛艙的版面模塊信息了，至于里面放哪些數(shù)據(jù)哪些信息，還是要看整個系統(tǒng)中能夠產(chǎn)生哪些數(shù)據(jù)，以及通過數(shù)據(jù)能夠哪些可決策的，客戶是一時半會是看不出來的；所以在這個項目中，駕駛艙的設(shè)計我們是根據(jù)領(lǐng)導提出的這幾個要點，設(shè)計了審計項目情況、整改概況、審計文書、整改成效、審計移送情況、整改預警等。

至于每個模塊的信息，我們根據(jù)系統(tǒng)數(shù)據(jù)情況，我們是先設(shè)計出一版，給到客戶看了之后，客戶就可以在這個版本基礎(chǔ)上，提出自己的看法和建議，我們也可以針對性的修改設(shè)計。

2. 針對具體政策文件

一般在做政府項目中，具體的政策文件參考是少不了的，比如我剛接觸審計業(yè)務(wù)的時候，需要做審計整改管理系統(tǒng)，當時我們是研讀了《審計署8號令》《浙江省審計條例》，以及地方的一些審計辦法，基于這些文件，我們基本上可以整理出整體的審計業(yè)務(wù)的流程，以及每個節(jié)點產(chǎn)出文件，至于具體細節(jié)要根據(jù)各地市各客戶的需求定制。

不過在客戶需求清晰、溝通積極性很高的情況下，政策文件不作為主要需求采集來源，更多的是提供行業(yè)的背景支持，能夠幫助產(chǎn)品經(jīng)理快速準確的理解客戶表達含義。

但是針對一些非正式立項的或者其他情況下的政府項目，部分業(yè)主的需求溝通積極性不高，可能會存在問一句，答一句，不問，也不會答的情況下，我們就需要多去查找一些政策文件，作為參考，以輔助需求溝通和需求確認。

這種情況存在的原因可能是，業(yè)主不重視這個項目，也可能是具體對接人員，不了解全貌業(yè)務(wù)流程或者部分業(yè)務(wù)細節(jié)。一般遇到這種情況時，我們在需求調(diào)研的時候就需要積極主動去主導，盡量去推動客戶去提供信息。

至少要在客戶那邊把系統(tǒng)的核心業(yè)務(wù)邏輯理清楚，弄清楚每個流程節(jié)點情況，如果無法通過客戶理清楚，就需要參考當?shù)卣l(fā)布的一些政策文件作為參考，然后自己梳理出具體的邏輯信息，然后反推客戶，讓客戶確認已梳理邏輯是否正確，如果不正確，客戶自己就會提出不合理的點。

就比如我之前負責的工地自助服務(wù)管理平臺就屬于這種情況，這個系統(tǒng)主要是建筑行業(yè)政府監(jiān)管類型的項目，系統(tǒng)的核心業(yè)務(wù)為企業(yè)、項目、項目關(guān)鍵考勤人員三大審批業(yè)務(wù)，其中企業(yè)端主要提供自助申報服務(wù)，政府端主要提供審批以及管理服務(wù)。

當時這個項目，客戶積極性很不高，領(lǐng)導層面基本上不主動推進項目，但是我們老板很主動，而且我們負責對接的住建部門基層的業(yè)務(wù)人員，無法對整體的業(yè)務(wù)邏輯準確表達，很多點都比較模糊，我們考慮到客戶他們可能清楚業(yè)務(wù)，但是一時想不起來或者不知道怎樣表達和描述。

因此我們當時更多是參考建筑行業(yè)政策文件，以及熟悉行業(yè)流程的土建B端客戶的溝通情況，來主動引導客戶去說更多關(guān)于業(yè)務(wù)流程的細節(jié)信息，通過我們的梳理，讓客戶去確定業(yè)務(wù)的整體邏輯準確性。

至于細節(jié)信息，當時考慮到這種情況，我們只能先按照最簡單的信息情況設(shè)計，然后給客戶看的時候，他們能知道缺了哪些，哪些不對，我們才有根據(jù)的修改信息，但這個過程也是不斷反復的過程，因此當時的這個項目做的其實還是蠻累的，不過也幸好是正式使用起來了。

3. 來自老板的需求

在產(chǎn)品設(shè)計環(huán)節(jié)，不同的老板在項目中參與的程度是不同的，這個也和他們對業(yè)務(wù)的理解程度有關(guān)。

有的老板只是在參與項目進度-原型設(shè)計匯報時，對整體上或者部分細節(jié)提出大致的疑問或者修改建議，一般會比較關(guān)注大屏的內(nèi)容和展示效果，有的會直接參與到需求討論階段，會融入自己對業(yè)務(wù)的理解和需要，以及會提出一些市場戰(zhàn)略方面的一些需求，這種一般對業(yè)務(wù)很熟悉，能夠針對業(yè)務(wù)細節(jié)提出針對性的建議。

但是很多時候，客戶的有些需求我們是可以做些取舍，但是老板的需求如果不合理很難去反駁，只能看具體需求具體分析。

當然內(nèi)外部需求可能也有沖突的時候，這個時候，就來到了產(chǎn)品經(jīng)理最難受的點，客戶和老板需求不統(tǒng)一該怎么辦？ 我目前是要看具體需求，如果牽涉到一些邏輯性的、客戶堅持的需求，得說服老板聽客戶的。

如果是一些非客戶堅持的，我就比較狗腿子，這個時候聽老板的。

以上其實就是G端目前主要的需求來源，一般在項目過程中，這三種情況都會同時存在，具體需要看實際情況參考使用。

三、需求管理

需求采集過之后，就要開始進行需求分析，經(jīng)過篩選后確定后再開始設(shè)計，畢竟不是所有的需求，都需要全部實現(xiàn)，有些需求可能也是偽需求，因此對于需求的分析和篩選，需要多方面考慮，包括項目的總體目標、項目的限制條件，如預算、時間、資源、以及開發(fā)能力等。

在整個需求分析和篩選過程中，我是這樣操作的：

1. 需求整理

個人覺得需求池還是蠻重要的，這個主要是由產(chǎn)品經(jīng)理管理維護。

在項目初期，我會把所有需求都記錄在需求池中。

在每次客戶需求對接后，可以將客戶所有的需求整理在這里，按照時間、模塊、需求描述、需求來源、需求類型、需求狀態(tài)、產(chǎn)品設(shè)計狀態(tài)、需求處理版本、是否實現(xiàn)等情況，方便產(chǎn)品經(jīng)理管理哪些需求是否需要做？要在哪個版本做？對于一些暫時無法確定的或者需要暫時擱置的需求，后期也可以在這個文件中找到。

也便于后期整理系統(tǒng)二期的需求和預算。

2. 初步擬定項目框架

需求溝通后，基本上每個大致的模塊已經(jīng)清晰了，可以先把收集好的需求整理到對應模塊下，然后再確定這個需求是否要在這么模塊使用和保留，這個步驟我般都是和需求池文件一起整理。

3. 需求分析和確認

在分析需求的時候，我會先判斷確定系統(tǒng)的核心邏輯，需要這些是必須要實現(xiàn)的。

至于在整體邏輯實現(xiàn)時，需要看客戶提出的具體節(jié)點需求，是否合理或者是否時客戶真實想要的需求，如果合理及真實，就可以確定要設(shè)計，如果不合理，但是要保證核心邏輯實現(xiàn)，就要學會需求轉(zhuǎn)化實現(xiàn)。過程中我會搭配業(yè)務(wù)流程圖一起進行分析，如果節(jié)點有疑問的，會順便備注在旁邊，方便后期咨詢。

就比如審計整改管理系統(tǒng)中，整改掛號階段，當時客戶需求的是通知書必須要采用在線編輯套用模板的形式，然后通過在線編輯生成通知書，開始走內(nèi)部通知書審核流程。

但是考慮到國產(chǎn)系統(tǒng)在線編輯插件適配、額外費用情況（局目前使用的國產(chǎn)系統(tǒng)有好多種，每一個如果使用都會產(chǎn)生插件費用），我們當時是改成通知書主體上通過手動上傳文件，支持下一個審批人員下載編輯和再上傳，然后購買了一個使用范圍多國產(chǎn)系統(tǒng)插件，支持部分人員可在線編輯使用。

其他各模塊需求也是要按照，是否客戶確定要實現(xiàn)，客戶需求是否是真實需求、功能開發(fā)是否能夠?qū)崿F(xiàn)、功能實現(xiàn)起來需要耗費的時間精力、整體預算方面多方考慮。

比如客戶需求是否真實：比如在做整改管理時，我們設(shè)計思路時，是通過整改項目-問題管理-整改掛號-新增問題/整改反饋-銷號審批 。當時我們設(shè)計路徑太深了，每次找的時候會很麻煩，客戶想讓我們直接用問題維度，只直接展示出來，這樣更加方便操作一些。

但是客戶的這個需求就不是很合理，如果直接按照客戶說的意思去設(shè)計，這個模塊就直接變成了問題維度下新增通知書、新增問題、以及問題跟進。后期使用時，會更加麻煩，也無法統(tǒng)計查看，因此當時就覺得不太合適，還是要最大程度的保留以項目維度去新增設(shè)計。因此我們將需求轉(zhuǎn)化成了，按照項目-問題掛號-新增；項目-通知書-新增；項目-問題銷號-問題跟進和審核銷號。這樣客戶進入這個模塊就清楚，在這個模塊下可以做這些事情，也方面項目維度統(tǒng)計查詢，同時也簡化了操作步驟

比如預算方面：我之前負責過一個審計委員會管理項目，客戶提出的需求很多，既需要日常業(yè)務(wù)功能管理，也需要整體督辦流程管理，還需要市縣一起改造使用，但是客戶的預算有限，只有十幾萬，市局負責一半，各區(qū)縣分攤承擔一半，這種情況下我們只能砍需求，最后是把督辦的業(yè)務(wù)流程基本上砍掉了，先做最簡單的事項錄入和辦結(jié)。

基本上通過以上的要素就可以確定下要實現(xiàn)的需求內(nèi)容了，接下來就可以開始原型設(shè)計和需求文檔產(chǎn)出環(huán)節(jié)了。

以上是我對G端產(chǎn)品包括需求采集、需求分析、需求確認相關(guān)的一些經(jīng)驗分享，文章內(nèi)容純個人經(jīng)驗和見解，如有不對，望各位大佬能夠留言指出，謝謝～