中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

G端因為行業的特殊性，與C端、B端的方法論有著諸多不同。本文作者分享的G端需求優先級的方法，希望可以幫到大家。

一、G端系統的需求是怎么來的呢？

政府的項目一般遵循”部級–省級–市級”的建設流程，一般由國家下發未來發展的綱要性文章（例如未來的十五五規劃），下發之后各省針對綱領性文章中的一些方向或者意見，細化產出本省的發展建議書，有的省可能會尋找某個市來進行試點，被選中的市再根據省級和部級的文件規劃建設內容。

當然有的市或者省也可能有自己的建設想法，不一定會嚴格按照三級的流程去進行逐級下發，但是有一點可以確定，政府的項目建設一定不會超過國家發布政策文件的范圍，政府主要是響應號召，圍繞黨的政策和方針走。

建設系統的時候，政府領導一般寫建設文件，主要對建設系統的背景、難點、建設方向等內容用高度概括的語言進行強有力的描述，這種文件主要是在內部進行流轉和學習，算作為項目的啟動書，我們作為承建單位也會得到一份，作為參考和學習。

二、G端的用戶劃分

實際建設項目過程中，大多數產品接觸的都是省級或者市級項目，部級項目很少，但是建設項目的領導班子組成往往都是類似的，基本上可以在下面的劃分中找到對應的角色，我們對領導班子進行如下的劃分：

• 最高權限的領導：一般就是省級的省長、省委書記，市級項目就是市長，市委書記，或者提出這個項目的最高層級領導
• 直屬領導：項目牽頭人，一般是項目的促成者和整個項目關鍵把控者，協調項目資金落實情況，平臺建設的整體方向，不關注大體細節，偶爾開會促進一下事情或者平臺建設過程受阻時，出面幫忙協調
• 分管領導：直接和你對接這個項目的負責人，對于平臺把控整體進度、建設思路的細節產出者。這個人對于平臺的整體建設有比較清晰的思路，有日常使用場景的規劃，當然直屬領導和分管領導可能是同一個人，視不同項目的情況而定
• 業務用戶：日常政府事物的主要處理者，穿梭在各個政務系統當中，高頻且全系列平臺的使用者

這些不同用戶掌握的話語權不同，對于平臺的需求也不同，自然需求的輕重緩急也不同

假如我們現在由政府牽頭建設“重點人員管控系統”，有“市–區（縣）–派出所”三個層級的用戶，現在項目馬上要啟動，在實際需求調研過程中，我們可能會出現以下需求：

• 最高權限的領導：重點人員管控系統，能夠幫助我們掌握和管控全市的重點人員，對人員的數據進行摸排，做到事前防范，事中掌握，事后總結
• 直屬領導：我們需要一個看板，我要看見整個市每日、每月、每年各區縣掌握的重點人員總數，不同等級重點人員的分布情況
• 分管領導：我需要看見我管轄區縣所有重點人員的基礎數據，定期排查數據，市級要求我們定期匯報各區的情況，我要方便導出統計表格，最好對接重點區域的監控數據，當有人出現的時候，推送預警數據，有的精神病人會跑到小學門口，我們擔心學生的安全
• 業務用戶：我們日常的工作流程是名單由上級下發，我們再去定點摸排人家，很多人不想跟我們溝通，但是我們得有一些基礎的情況需要了解，這個讓人很頭疼，再一個要我們定期上傳回訪的數據，這個能不能簡單一些

現在我們基于平臺的整體規劃，對不同用戶提出的需求進行拆解

（注：此處只針對提出需求進行分析，不是對系統的全盤規劃進行分析）

三、KANO模型拆分需求

KANO 模型是東京理工大學教授狩野紀昭(Noriaki Kano)發明的對用戶需求分類和優先排序的有用工具，以分析用戶需求對用戶滿意的影響為基礎，體現了產品性能和用戶滿意之間的非線性關系。

KANO模型將我們的需求分為五類：

1. 基本型需求：這是用戶對產品的基礎要求，如果不能滿足這些需求，用戶會非常不滿。例如，手機的通話功能就是一個基本型需求
2. 期望型需求：這些需求是用戶明確提出的期望，滿足這些需求可以顯著提高用戶滿意度
3. 興奮型需求：這些需求雖然不被用戶過分期望，但一旦滿足，用戶的滿意度會急劇上升
4. 無差異型需求：這些需求對用戶體驗沒有直接影響，既不會引起滿意也不會引起不滿
5. 反向型需求這些需求如果提供，反而會引起用戶的不滿

我們現在對用戶拆解之后的需求使用KANO模型進行分析，并且進行需求開發排序，需求開發的優先級按照從P0-P5進行排序，序號越小開發的順序等級越高

需求的拆分和優先級排序已經完成，在日常產品工作中，我們維護需求池的時候可以按照此模型進行應用，形成經驗之后很快就可以對需求進行優先級排序。

在系統真實上線過程中，客戶隨時還會調整需求，對需求有變更和刪減，我們要根據客戶的強硬程度和需求的緊急程度再進行排期。客戶提出的每個需求我們也不是都要進行響應，有的時候是真實的需求，有的時候就是想到了隨口說一下，如果我們響應每一個需求，那系統建設可能會遙遙無期。這種情況下，我們對需求進行簡單的判斷：

• 需求簡單：需求簡單，前后端不到半天可以解決完成，可以視建設情況快速迭代上線
• 需求難做，客戶就簡單提了：納入需求池，調研一下需求建設的難點和實際開發的工期，可以先行和客戶溝通說明難點，如果很難做，客戶不提你不提
• 需求難做，客戶反復提及好幾次：一般三次以上可以說明用戶對這個需求上心，再難做也要進行建設，這時我們可以開始進行產品設計和規劃

最后，政府的項目往往都很急，很多情況下實際要求上線時間很可能會打的我們措手不及，作為產品經理要合理平衡開發與客戶之間的關系。