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

需求分析是產品經理日常工作內容之一。本文分享了需求分析到產品方案的過程和需要注意的問題點，供大家參考學習。

本篇文章大約有6000字，主要圍繞3個點展開：

一、需求評估：即從海量的需求中如何抉擇做哪些需求

二、需求方案：即從方案前期如何規避風險，減少方案修改成本

三、需求設計小課堂：即從產品設計、數據庫、API層面說一下產品設計的注意事項與技術知識

正文開始，enjoy

一、需求評估之三步走

第一步：需求分析

1、還原場景

警匪片中，警察破案慣用手法之一，根據現場痕跡，還原罪犯作案過程，然后推測后續罪犯的動機。那類比到產品上來就是：在什么環境下，什么人做什么事，他為什么做這件事，最終產生的價值是什么等等。其中環境、人、行為、痛點收益指：

• 環境：可以是倉庫、辦公室等
• 人：什么身份、崗位、收入、語言、國家等
• 行為：用戶做什么事，操作流程是怎樣的
• 痛點&收益：在做這件事的過程中，用戶遇到了什么困難點；以及他預期想要獲得的結果或收益是怎么樣的

2、十萬個為什么

通過需求分析后，如果遇到有不理解的內容/或者似是而非/或者大概也許可能是這樣/或者感覺我以為我理解了/或者寫的有歧義的，那這種就需要警惕了，多追問幾個為什么，可能就能挖掘到需求的本質

第二步：需求評估

需求分析完成后，怎么定義這個需求要不要做，也可以按照幾個方法來

1、產品定位

看需求是否符合我們產品定位，例如某出海電商業務，應該以本土需求為主，結合處理跨境供應鏈業務（跨境供應鏈無非就生產、運輸、倉儲、報清關、配送等環節的處理）

2、戰略定位

例如目前產品的北極星指標是日活和營收，那就看這個功能能否為日活和營收添磚加瓦

3、產品階段

產品階段指種子期>成長期>成熟期>衰退期。這個只能根據當前產品所出階段，仁者見仁，智者見智了。

4、目標客戶

這個功能提出的用戶是不是我們的目標客戶。例如我們的目標用戶是本土發貨且相對精鋪/精品/品牌的客戶，那鋪貨用戶提出的需求，這種可能就要謹慎決策

5、需求價值

這個可以圍繞廣度（即是否通用功能，覆蓋用戶有多大？）、頻率（注意不是反饋頻率，而是用戶的使用頻率）、需要程度（剛需還是非剛需，沒有這個功能就跑路嗎？）、趨勢（反饋的用戶量有多少，是呈上升還是下降趨勢）、最后一個就是成本（做這個大概要多少人力，與上面哪些點帶來的價值是否呈正比）

第三步：需求優先級定義

使用kano模型+四象限法則+覆蓋用戶范圍基本就可以很好的定義需求優先級了。

1、Kano模型：

基本型需求（底線需求）

定義：用戶認為產品 “必須有” 的功能。如果產品缺少這些功能，用戶會極度不滿意甚至流失；但當產品具備這些功能時，顧客也不會因此而特別滿意，他們會認為這是理所當然的。

示例：對于一部手機來說，能夠正常撥打電話和發送短信就是基本型需求。如果手機無法打電話，用戶肯定會非常不滿意；但僅僅能打電話，用戶也不會覺得這有什么值得稱贊的，因為這是手機最基本的功能。

期望型需求（越多越好）

定義：期望型需求與用戶的滿意度呈線性關系。產品提供的這些功能越多、越好，用戶就越滿意；反之，用戶的滿意度就會降低。

示例：手機的電池續航時間。如果手機的電池續航時間長，用戶會比較滿意；如果續航時間短，用戶的滿意度就會下降。而且用戶對于電池續航時間往往有一定的期望，比如希望能滿足一周的正常使用。

興奮型需求（驚喜需求）

定義：這些是用戶意想不到的功能，能夠給用戶帶來驚喜，使用戶的滿意度大幅提升。即使產品沒有這些功能，用戶也不會不滿意，因為在用戶認知范圍內并沒有這些功能的存在

示例：例如天馬行空一點，如果現在手機能實現太陽能充電，這個可能并沒有在我們的預期內，當我們發現可以太陽能快充時，再也不會為手機沒電感到煩惱，然后哇一聲，太牛了（如果有老板感興趣這個項目，請務必聯系我…狗頭.jpg）

無差異型需求（夠用就好）

定義：用戶對這類功能并不在意，這些功能的有無不會影響用戶的滿意度。

示例：例如某果，手機攝像頭是三個橫著放還是交叉放，對于大部分用戶來說，這個并不會對他們使用手機的體驗和滿意度產生任何影響

反向型需求

定義：這類需求是指用戶不希望產品具有的。如果產品提供了這些功能，反而會導致顧客滿意度下降。

示例：例如現在APP滿天飛的內置廣告，用戶并不感興趣，但是還無法關閉（想關閉要當股東的…），這會讓用戶感到厭煩，降低滿意度。

2、四象限法則：

重要且緊急（危機任務）、重要但不緊急（戰略任務）、緊急但不重要（干擾任務）、不重要且不緊急（浪費時間任務）

二、需求方案之規避風險五步法

第一步：需求計劃制定

一般需求在前期大概知道是做什么，同時也要根據大概知道的內容制定一個最晚評審日期，那根據這個日期往前倒排計劃，分別制定需求拆解、競品調研、需求框架、需求設計、需求預審等各個節點的時間，然后根據計劃往前推進

第二步：需求拆解

首先獲取需求中的概念與流程，對于需求整體內容先建立認知

對概念和流程有認知后，然后對需求進行拆解，看下可能涉及哪些功能內容，粗略的寫一個功能內容&功能影響點

第三步：競品調研

需求拆解完成后，大概知道要做什么東西了，此時可以站在前人的肩膀上做設計，即進行競品調研，競品調研一定帶著目的去進行，把競品相關的截圖和流程梳理清楚，同時在調研的過程中思考下對方為什么這樣設計，優缺點分別是什么。最后所有競品調研完成后，輸出一個總的調研結論

第四步：需求清單

通過需求拆解與競品調研，基本可以確認我們的設計方案，此時第一步應該是整理該需求的影響點，最好是根據系統頁面挨個看，確認影響點后羅列詳細影響點&解決方案，形成需求清單

第五步：需求方案確認

有需求清單后，可以針對相關內容粗略的畫個草圖說明設計方案，如果有需要可以拉個正式會議與其他部門或領導快速對齊；如果感覺無風險，可以直接開工設計或者單獨拉群后將設計內容發出，讓大家看下是否有疑問或建議后在開工

三、需求設計小課堂

設計寄語

請牢記需求方案是寫給其他小伙伴看的，其他人看的好才是真的好

設計思路

1、啟動A計劃

前期通過腦?；蛘卟莞寮堖M行思路構建，當整體內容考慮清楚后，則可以啟動下一步動作

2、你先別急，請繼續構建B++計劃

不要滿足剛開始的創意，趁思路活躍時創造或探索更多的備選方案，太早喜歡你的創意會阻止你創造和探索更多的方案

3、方案抉擇

當窮盡認知內的方案后，可以分析根據每個方案的可行性&優劣性，挑選出你認為比較好的方案內容

4、曝光計劃

當認為方案左右為難時或者需要確認時，迅速曝光方案，從而尋求其他小伙伴或其他部門的反饋

設計注意事項、數據庫&API知識

請牢記“增刪改查顯算傳&數據庫&接口&異?！薄Ｔ敿毥忉屓缦拢?/p>

增：即新增、創建、添加等

定義

一般指內容的從無到有，即新增內容

注意事項

1、表單內容

1.1）字段：考慮字段類型（文本框、下拉等）、格式、數據源、上下限、默認值、唯一值（賬號唯一/全局唯一/某條件下唯一）、是否需要排序、字段之間聯動、系統生成字段值的編碼規則（例如文本+隨機數…）等

1.2）圖片/視頻：考慮尺寸、大小、格式、比例等

2、校驗

2.1）校驗時點：離焦校驗、實時校驗、點擊某控件后校驗等等

2.2）校驗內容：

2.2.1）必填校驗：必填項是否為空

2.2.2）異常校驗：是否有關聯引用數據，如果有被引用的數據不存在/過期/狀態不符合等如何處理；是否有添加數量上限，如果有超過如何處理

數據庫（SQL）語句

數據庫層面對應語句就是Insert into，代表插入/新增數據。例如：要向數據庫表名為“t_product”表中插入一條新的產品數據，表中有product_id（產品id）、product_name等字段，則SQL語句為：

Insert into t_product (product_id, product_name) values (001, ‘這是產品名稱’)

API體現

1、請求方法：一般使用POST方法（即向服務器提交數據），通常用于提交表單

2、定義接口路徑，例如api/addProduct

3、請求格式：一般是JSON對象，例如{product_id:001,product_name:“這是產品名稱”}

刪：即刪除

定義

一般指內容的從有到無，跟增剛好相反

注意事項

1、刪除方式：邏輯刪除or物理刪除？（邏輯刪除一般指假刪，即通過標記實現；物理刪除為真刪，即從數據庫刪除，這種刪除是不可恢復的）

2、刪除一般是不可逆且高危操作，注意增加二次確認彈窗

數據庫（SQL）語句

數據庫層面對應語句就是delete from，代表刪除數據。例如：要從數據庫表名為“t_product”表中刪除product_id=001的數據，則SQL語句為：

delete from t_product where product_id = 001;

API體現

1、請求方法：POST（HTTP通信規則中標準為Delete方法為刪除數據）

2、定義接口路徑，例如api/deleteProduct

3、請求格式：例如上述案例可以只傳ID到服務器，就可以使用form-data格式，例如productId:001（其實from data 和json區別并不大，都是鍵值對的格式，即key:value）

改：即編輯、修改、調整等

定義

一般指內容的從1到N，即修改內容

注意事項

本質基本同新增，主要考慮哪些內容可以修改、哪些內容不可以修改；其次就是修改后內容一定記得做操作日志記錄，方便后續追溯

數據庫（SQL）語句

數據庫層面對應語句就是update，代表更新數據。例如：要從數據庫表名為“t_product”表中更新product_id=001的產品名稱，則SQL語句為：

update t_product set product_name = “這是更新后產品名稱” where product_id = 001 ;

API體現

1、請求方法：POST（HTTP通信規則中標準為PUT方法為更新數據）

2、定義接口路徑，例如api/updateProduct

3、請求格式：基本同增

查：即查詢、查找、搜索

定義

一般指通過某些內容查詢符合條件的信息

注意事項

1、查詢方式

1.1）輸入框的查詢類型：前綴、模糊、精確、批量搜索

1.2）非輸入框的查詢方式：單選、復選、單/復選兼容等

2、技術注意事項

針對輸入框類型的內容，需要對SQL語句中的通配符（例如%、‘、“”等）做參數化查詢處理，防止產生SQL注入風險

數據庫（SQL）語句

1、數據庫層面對應語句就是selete，代表查詢數據。例如：要從數據庫表名為“t_product”表中查找product_id=001的數據，則SQL語句為：

selete * from t_product where product_id = 001;

其中*代表結果返回數據庫表中所有列，如果僅想返回產品名稱，則將*替換為product_name即可。where后面的就是查詢條件

API體現

1、請求方法：GET

2、定義接口路徑，例如api/selectProduct

3、請求格式：一般也采用form data，例如查詢字段為產品名稱，查詢內容為“這是更新后產品名稱”，查詢類型采用精確查詢，請求字段為：

searchFields：productName

searchContent：這是更新后產品名稱

searchType：精確查詢

顯：即顯示、回顯

定義

一般指將數據回顯到頁面上，供用戶查閱。前端術語一般叫渲染

注意事項

1、如果是表單類，其一注意數據來源，其二注意是否需要分組，其三注意排序（降序、升序）

2、其次注意權限，什么人可以看到什么數據，保護數據隱私

3、其三注意數據回顯方式，例如是否需要分頁、如果不需要分頁是一次性加載所有數據還是虛擬滾動加載或者某些字段加載過長時可以采用分步加載（即先加載主要數據，加載長的單獨請求，這樣不影響主要操作也減少用戶等待）等

數據庫（SQL）語句

本質對應的就是查詢語句，只是拓展一些排序的概念，例如排序用order by函數，其中降序=desc，升序=asc。例如從t_product表中查詢product_id大于1的，按照產品ID降序排，語句為：

select * from t_product where product_id>1 order by product_id desc;

算：即計算、算法

定義

一般指各種計算操作，例如求和、計數等

注意事項

一般算法涉及規則，需要明確規則的計算方式

數據庫（SQL）語句

一般對應分組語句，即group by函數。例如從product表中查詢平臺=shopee的產品總數，且按照不同店鋪聚合，語句為：

select shop,count(*) c_shop_count from t_product where platform=”shopee” group by shop;

其中c_shop_count為計數后的字段別名，用于承載計數后的結果。例如：t_product中有以下信息

執行上述計數語句后，則結果為：

其他一些算法函數，例如count計數、sum求和、avg求平均數、max求最大、min求最小，具體語法可自行某度

傳：上傳、導入等

定義

在設計中主要體現在上傳信息的地方，例如上傳圖片、上傳文件、上傳視頻等

注意事項

1、站在產品角度需要定義規則，保證傳入數據的合法性。例如文件格式是否合法、文件大小、文件中行數是否有限制、文件模板是否被篡改、文件內容是否為空、導入數據格式校驗等等

2、站在技術角度，以導入excel為例，處理流程就是：

2.1）讀取excel文件：獲取excel文件流 > 判斷excel格式

2.2）解析excel文件：獲取excel中sheet頁數量 > 遍歷所有sheet頁中的總行數 > 解析sheet表中的行和列獲取相應值

2.3）數據處理&存儲：數據處理-格式化數據/數據清洗（例如某些字段要過濾空格）/數據校驗等 > 數據存儲-寫入數據庫

異常：異常場景、極端場景等

定義

異常指的時不再正常流程范圍內，但是為了防止用戶犯錯，又需要增加的一些攔截措施

注意事項

1、系統內部交互時：考慮并發場景、考慮多人操作一條數據的情況、考慮數據狀態合法性、考慮操作過程網絡中斷等

2、與第三方系統交互時：考慮接口QPS、考慮數據傳輸是否會出現重復創建情況、考慮授權異常情況、考慮接口請求時長斷開請求后的補償機制等

文章到此處就結束了，總體來說描述的還是產品經理的基本功，相信大家只要把自己的基礎能力打扎實，肯定受益匪淺，因為基礎能力不管做哪個行業都是可以平移的。其次就是方案靠譜，自己的專業性更能體現出來，也會讓業務伙伴更信服。

大概啰嗦到這里了，也算一個入行N年的老朋友與其他朋友的交流，其次也希望作為新入行朋友的一個啟發，如果有不正確或有歧義的地方，歡迎大佬評論區交流補充。

下期再見，bye～