? ? 這周讓我們一起學(xué)習(xí)需求管理，需求管理是產(chǎn)品經(jīng)理的核心能力，很多初入行的產(chǎn)品經(jīng)理認(rèn)為需求管理就是把用戶需求收集過來，按照優(yōu)先級排序提交PRD給研發(fā)的過程，這個過程其實更像需求的搬運工，忽略了需求分析以及在產(chǎn)品生命周期發(fā)展扮演的角色和地位，本周我們?nèi)鎸W(xué)習(xí)下作為產(chǎn)品經(jīng)理應(yīng)該如何認(rèn)識、管理需求
一 認(rèn)識需求
1.1 什么是需求
? ? 通常需求從個體角度出發(fā)被認(rèn)為是用戶需求，比如我希望能通過一款時間管理APP去管理我的工作、學(xué)習(xí)時間，減少不必要時間浪費；如果從群體角度出發(fā)往往分為企業(yè)需求和市場需求，通常企業(yè)需求是為了滿足市場需求而存在，比如特斯拉公司希望開發(fā)一款續(xù)航能力超過1000公里蓄電池滿足市場對于電動汽車?yán)m(xù)航能力要求，說到這里大家可以看到市場需求和用戶需求關(guān)系：用戶需求組成了某一特定的群體的市場需求，特斯拉希望通過開發(fā)1000公里蓄電池希望解決的那些想買特斯拉但是又擔(dān)心充電續(xù)航能力不足人群顧慮，那么對于始終想買燃油汽車的用戶來說，特斯拉是否研發(fā)1000公里的蓄電池似乎沒那么重要，那么可以看出不同用戶需求組成了不同群體的市場需求，企業(yè)就是為了滿足不同群體市場需求而存在或者說研發(fā)產(chǎn)品，這也說明為什么一個企業(yè)、一個產(chǎn)品定位有多么重要，因為企業(yè)及其產(chǎn)品往往聚焦在某一個特定用戶人群身上，延伸下思維：大家想想用戶人群可以從哪些方面分類
? ? 總結(jié)下，需求定義：解決某一類用戶或者群體需要、問題，這種需求和問題可能是精神層面、有可能是實際生活、或者實際工作需要的
? ?思考題：你負(fù)責(zé)的產(chǎn)品聚焦到哪一類用戶？他們有什么特征？競爭對手是否也具備同樣的能力？
1.2 詳解用戶需求
? ? 在《人人都是產(chǎn)品經(jīng)理》這部書中，用戶需求定義：用戶自以為的需求，并且經(jīng)常表達(dá)為用戶的解決方案，大家想想用戶需求和解決方案等同嗎？舉個例子：‘我希望下班出地鐵口時候能少走路就能到家‘這是用戶需求，’我可以通過打車或者拼順風(fēng)車到家‘這是解決方案，但是現(xiàn)實中往往把用戶需求和解決方案混淆，用戶需求要素：什么對象，什么時/環(huán)境，做什么，達(dá)到什么效果，沒錯這就是我們常說的場景，用戶需求往往和場景關(guān)聯(lián)：既什么樣用戶在什么時間在什么地方/環(huán)境向?qū)崿F(xiàn)什么目標(biāo)？用戶需求更多是WHAT；為了解決下班出地鐵口時候能少走了就能到家這個用戶需求，可以乘坐公共汽車，但是需要花時間等，可以拼車，但是不一定有合適拼單，費用似乎也有點貴，這個時候共享單車出現(xiàn)了，共享單車成立之初就是為了解決最后一公里到家、到學(xué)校需求，只需要很少押金，每次騎行花費只有一元錢解決想快點回家又不想等公交、不想花費太多的用戶需求，所以共享單車是一種解決方案，它更多是通過產(chǎn)品或者產(chǎn)品功能解決HOW，所以用戶需求不是解決方案。
? ? ?互聯(lián)網(wǎng)產(chǎn)品本質(zhì)就是解決用戶各種場景化需求，在不同的場景戰(zhàn)場上搶用戶、拼效能、比體驗。
? ? ?作業(yè)題：你所負(fù)責(zé)的產(chǎn)品解決哪些場景下的用戶需求，如何評價解決的好與壞？
1.3 真需求和偽需求
? ? 我之前在做數(shù)據(jù)產(chǎn)品經(jīng)理的時候，公司沒有BI分析平臺，面對運營、產(chǎn)品經(jīng)理、數(shù)據(jù)分析人員各種數(shù)據(jù)需求，有的要明細(xì)數(shù)據(jù)，有的要TOP排名數(shù)據(jù)，有的要統(tǒng)計占比數(shù)據(jù)，當(dāng)時基本上一股腦的做掉了，可事后想想好像少了什么，對！少了對需求分析，初入產(chǎn)品經(jīng)理面對需求時候除了上述提到混淆用戶需求和解決方案，也常常被偽需求迷惑，舉一個極端例子：用戶提出我想乘坐飛船去火星需求，那么是不是產(chǎn)品經(jīng)理就要開始調(diào)研往返火星的條件比如飛船的大小、火箭的動力、火星的生存條件等等，經(jīng)過數(shù)月調(diào)研發(fā)現(xiàn)如果實現(xiàn)往返火星需求大致造價十億美金，需要1000名工程師耗時十年以上，可是作為產(chǎn)品經(jīng)理我們是不是首先鑒別下用戶這個需求真?zhèn)?，為什么用戶會提出向乘坐宇宙飛船區(qū)火星，答案可能是用戶希望體驗完全不一樣的旅行，乘坐不一樣的交通工具，去往不一樣的目的地，至于是否乘坐火箭飛船，是否前往火星其實沒有那么重要，最后為了滿足用戶需求的解決方案可能是乘坐熱氣球橫跨太平洋。
? ? ? ? 需求真?zhèn)沃苯佑绊懏a(chǎn)品設(shè)計及發(fā)展方向，我們在回顧下之前我在做數(shù)據(jù)產(chǎn)品經(jīng)理時候面對的需求：
? ? ? ? 明細(xì)數(shù)據(jù)需求：用戶希望能導(dǎo)入EXCEL，通過數(shù)據(jù)透視功能多維度分析用戶支付情況
? ? ? ? TOP排名：用戶希望指導(dǎo)首頁下載推薦位和廣告位中哪些應(yīng)用下載量最多
? ? ? ? ?統(tǒng)計占比：用戶希望看到每日支付類型占比多數(shù)？
? ? ?最后數(shù)據(jù)產(chǎn)品方案如下：
? ? ? ? ? 明細(xì)數(shù)據(jù)需求：我們通過KYLIN定義用戶需要的維度和指標(biāo)，通過托拉拽方式實現(xiàn)維度和指標(biāo)組合
? ? ? ? ? TOP排名：我們給用戶建立每日下載DATABORD，每日監(jiān)測首頁不同位置下載情況
? ? ? ? ? 統(tǒng)計占比：我們構(gòu)建關(guān)于支付主題的報表，包括支付請求率、支付成功率、支付類型等主題分析
? ? 如何辨別需求真?zhèn)?，通常可以從以下幾個因素分析：
? ? ? ? 使用頻率：用戶是否會經(jīng)常使用？想乘坐火箭飛船登錄火星這種需求其實發(fā)生頻率極低，比如音樂播放中單曲播放以及QQ用戶分組就是高頻率的需求
? ? ? ?實現(xiàn)代價：乘坐火箭飛船登錄火星代價是十億美金，1000名工程師參與，最終用戶可能只有幾百名，即便最后實現(xiàn)了這樣飛船，解決了火星生存條件，這樣一張船票可能會是天價。通常需求實現(xiàn)代價需要考慮人力成本、技術(shù)預(yù)研（解決新的需求），開發(fā)成本（主要是時間）
? ? ? 可復(fù)用性：登錄火星飛船使用火箭一次性，這種復(fù)用性就是0，產(chǎn)品經(jīng)理需要考慮用戶需求是否在其他在其他相似場景也會出現(xiàn)？
? ? ? 可持續(xù)性：登錄火星需求很可能持續(xù)很短，因為愿意花費天價、并且往返時間可能超過一年用戶少之又少，這樣用戶不太可能隨著時間推移有較大規(guī)模的增長
? ? ? 實現(xiàn)效果：互聯(lián)網(wǎng)產(chǎn)品實現(xiàn)效果其實本質(zhì)就兩個收益和用戶量，實現(xiàn)某一個新的需求能帶來多少用戶增長，實現(xiàn)多少收益（或者提升收益轉(zhuǎn)換）
? ? ?作業(yè)題：從上述角度分析你現(xiàn)有產(chǎn)品需求真?zhèn)涡?/b>
1.3 功能和需求關(guān)系
? ? 產(chǎn)品經(jīng)理談需求離不開功能，那么功能和需求是什么關(guān)系？功能是產(chǎn)品客觀存在比如登錄功能、手機(jī)支付功能，朋友圈轉(zhuǎn)發(fā)功能，二維碼掃描開鎖功能，用戶使用與否，功能都是客觀存在的，但是功能通常為了解決用戶需求而存在，所以離開用戶需求功能大多無用功能，試想沒有用戶使用的功能有何意義呢？用戶通常會把功能和需求混淆比如：我需要人臉識別功能，我需要多目標(biāo)追蹤和定位功能，產(chǎn)品經(jīng)理對用戶談需求，設(shè)計產(chǎn)品談功能，所以遇到類似用戶這樣訴求，按照需求定義試問：通過人臉識別解決什么？達(dá)到什么效果？用戶回答是通過人臉識別實現(xiàn)手機(jī)安全驗證，通過人臉識別實現(xiàn)自動化門鎖解禁，通過人臉識別實現(xiàn)最煩快速匹配等等，在上述各種用戶場景中使用技術(shù)以及產(chǎn)品功能可能有比較大差異，所以產(chǎn)品經(jīng)理區(qū)分功能和需求，那么如何將產(chǎn)品需求轉(zhuǎn)化為功能，我個人常用兩種工具：
E-R圖：
? ? E-R圖是對現(xiàn)實世界的抽象，通過E-R圖實現(xiàn)對現(xiàn)實世界概念模型建立，包括實體，關(guān)系，屬性
? ? ?實體：用于描述現(xiàn)實世界的數(shù)據(jù)對象，用方括號表示，比如人、動物、車
? ? ?屬性：客觀描述對象的屬性，比如人屬性有性別、年齡、身高、職業(yè)、愛好
? ? ?關(guān)系：描述對象和對象之間的聯(lián)系，用菱形表示，聯(lián)系存在3種一般性約束：一對一約束、一對多約束和多對多約束
? ? 以下是一個用戶購買商品并且產(chǎn)生訂單ER示例圖：
UML圖：
? ? 鑒于UML較為復(fù)雜，單獨開一章節(jié)寫這個
二 管理需求
2.1 需求來源獲取
? ? 用戶訪談：基本沒有用過，個人認(rèn)為效率比較低下
? ? 問卷調(diào)查：采用問題方式，通過封閉的回答調(diào)研用戶集中關(guān)注點
? ? 頭腦風(fēng)暴：用的比較少的方式，通過不同觀點迸發(fā)一些不一樣觀點
? ? 競爭對手調(diào)研：用的比較多的方式，通常對競爭對手調(diào)研及功能學(xué)習(xí)，成為產(chǎn)品改進(jìn)的重要途徑
2.2 需求管理
? ? ?需求獲取以后，要對需求進(jìn)行初步加工，這是將用戶需求轉(zhuǎn)化為產(chǎn)品需求第一步，EXCEL方式將需求以列表方式輸出需求詳情描述比如來自用戶群體、實現(xiàn)的商業(yè)價值、優(yōu)先級等，以下是我早些年做傳統(tǒng)IT需求分類示例：
2.3 需求分析
? ? 需求收集以后，需要將需求進(jìn)行分析，這是將需求轉(zhuǎn)換為產(chǎn)品功能第二部，常見的需求分析方法如下：
? ? 黃金圈思維法則
? ? 黃金圈思維法則是一種底層的知識規(guī)律，也是我個人非常推崇的分析問題的方法，我單獨寫一個認(rèn)知系列的文章提到如何發(fā)現(xiàn)底層知識規(guī)律，并且運用，黃金圈思維法則的核心遇到一個問題首先不是想這個問題解決策略還是考慮問題本質(zhì)，就是WHY層面，為什么用戶會有這個需求？產(chǎn)生這個用戶核心需求的背景是什么？
? ? 我們看早些年諾基亞廣告：科技以人為本，諾基亞通過這則廣告語向用戶傳遞諾基亞并非一個手機(jī)公司，而是一家科技公司，并且以用戶為本，滿足用戶服務(wù)用戶為宗旨，早些年諾基亞造出形狀各異的手機(jī)，都會有人買單，因為對于消費者而言傳遞價值不只是手機(jī)功能而是諾基亞的科技服務(wù)理念，科技以人為本就是諾基亞制造、營銷手機(jī)的WHY，但是很可惜諾基亞最終敗給了自己。
? ?現(xiàn)實中我們往往迷惑于WHAT層面--用戶需要一個可以登錄火星的飛船，可是用戶WHY層面--獵奇體驗，通過黃金圈法則更容易讓產(chǎn)品經(jīng)理認(rèn)識用戶需求產(chǎn)生的核心原因和背景，理解不同使用場景的用戶訴求。產(chǎn)品經(jīng)理構(gòu)件產(chǎn)品戰(zhàn)略的過程其實就是不斷將WHY--WHAT--HOW的過程，本質(zhì)是開放問題到封閉問題：反復(fù)的推演、求證。
? ? KANO模型
? ? KANO模型從滿足和滿意度兩個維度把需求劃分為基本型需求、期望型需求和興奮型需求三大類:
? ? 基本型需求：顧客認(rèn)為產(chǎn)品“必須有”的屬性或功能。當(dāng)其特性不充足時，顧客很不滿意；當(dāng)其特性充足時，對客戶滿意度沒有多少影響，顧客充其量是滿意。比如我們在電商購買商品時候，必須先注冊后才能購買，注冊功能就是滿足基本型需求而存在，沒有注冊功能，嚴(yán)重影響用戶購買
? ? 期望型需求：要求提供的產(chǎn)品或服務(wù)比較優(yōu)秀，但并不是“必須”的產(chǎn)品屬性，有些期望型需求連顧客都不太清楚，但是是他們卻希望得到 的。顧客通常談?wù)摰氖瞧谕托枨?，期望型需求又叫做線性需求，這類需求越多越好。線性需求在產(chǎn)品中實現(xiàn)的越多，顧客就越滿意，當(dāng)沒有滿意這些需求時，顧客 就不滿意。因此，產(chǎn)品的價格通常和線性特性相關(guān)。用戶在電商平臺選擇購買商品時候不僅希望通過信用卡、借記卡、也希望通過支付寶、微信等第三方支付，額外的支付類型就是滿足期望型存在。
? ? 興奮型需求：提供給顧客一些完全出乎意料的產(chǎn)品屬性，使顧客產(chǎn)生驚喜。興奮點和驚喜點常常是一些未被用戶了解的需求，客戶在看到這 些功能之前并不知道自己需要它們。當(dāng)其特性不充足時，并且是無關(guān)緊要的特性，則顧客無所謂，當(dāng)產(chǎn)品提供了這類需求中的服務(wù)時，顧客就會對產(chǎn)品非常滿意，從 而提高顧客的忠誠度。這類需求可以為產(chǎn)品增加額外價格。比如蘋果的鍵盤、鼠標(biāo)、Apple?Pencil這些都是滿足興奮型需求存在
? ?作業(yè)題：目前你負(fù)責(zé)的產(chǎn)品哪些功能是滿足基本型需求、哪些滿足期望型需求
? ? ?由圖可以看出，
? ? ?右下方箭頭：一旦實現(xiàn)了一定數(shù)量的必須功能，就無法再通過增加這類功能來提高客戶的滿意度了。無論增加多少必須功能，客戶滿意度都不會超過中點以上。
? ? ?左上方箭頭：只是實現(xiàn)一部分興奮點就可以明顯的提升客戶滿意度，這也是為什么企業(yè)把追求卓越作為企業(yè)的價值觀之一
? ? 中間的箭頭：期望型功能的增加和客戶滿意度呈線性增長，所以這類需求越多越好
? ? 通過以上分析，我們會對這三類需求分別對待：
? ? 對于必須完成的功能，在產(chǎn)品發(fā)布時需要完成，但并不是要求在第一次迭代時就開發(fā)完成。
? ? 完成盡可能多的線性需求
? ? 如果時間允許，至少應(yīng)該確定少量的興奮點優(yōu)先級，把它們包含進(jìn)發(fā)布計劃
? ? ? ?生命周期法
? ? 幾年前，有一個來自優(yōu)酷產(chǎn)品總監(jiān)給我們培訓(xùn)時，列舉了當(dāng)時微信第一個版本所涉及功能比如：通過手機(jī)號注冊、通過郵箱注冊、支持文字形式發(fā)朋友圈，支持視頻通話、支持通訊錄導(dǎo)入、支持語音通話、支持文字對話、通過QQ關(guān)聯(lián)登錄等等，要求我們挑選出微信實際第一個版本開發(fā)的功能，當(dāng)時印象中沒有一個人準(zhǔn)確或者接近正確答案，為什么沒有人選中接近問題答案，后來我總結(jié)了兩個重要原因：
? ? ?產(chǎn)品經(jīng)理傾向設(shè)計一個功能完善的產(chǎn)品思維
? ? ?不清楚目前產(chǎn)品所處的生命周期位置
? ? ?回到微信第一個版本如何選擇功能問題上，微信第一個版本處于產(chǎn)品成長期，成長期運營特點需要大量獲客，產(chǎn)品特點是需要1-2個核心的功能解決用戶痛點，讓用戶認(rèn)同，那么用戶核心痛點是什么？微信最初定位建立熟悉朋友的社交平臺，這里面有兩個關(guān)鍵字一個是熟悉朋友，第二就是社交，微信第一個版本就是解決熟悉朋友聯(lián)系，最便捷方式就是通訊錄導(dǎo)入，通過熟人之間通訊錄導(dǎo)入很快達(dá)到獲客效果；社交最常用的就是文字對話和語音通話，考慮實現(xiàn)難度和代價，最終語音對話可能不是第一個版本必需功能，而選擇文字錄入、表情、圖片等功能則能快速實現(xiàn)社交目標(biāo)。
?作業(yè)題：你負(fù)責(zé)產(chǎn)品目前處在哪個生命周期，對應(yīng)核心功能有哪些？ ??
2.4 PRD撰寫
? ? 產(chǎn)品經(jīng)理另外一項核心技能就是PRD撰寫，這是用戶需求轉(zhuǎn)化為產(chǎn)品功能第三步,也是向研發(fā)同學(xué)交接最重要一個環(huán)節(jié)，PRD核心就是撰寫開發(fā)同學(xué)可以理解并且參考的功能或者流程說明，PRD沒有固定格式，詳細(xì)PRD包括項目背景、項目目標(biāo)、功能詳情說明、非功能詳情說明等
? ? 項目背景：描述開發(fā)產(chǎn)品或者項目必要性，可以從用戶需求、市場需求、競爭對手等方面描述
? ? 項目目標(biāo)：描述項目或者產(chǎn)品開發(fā)的意義以及實現(xiàn)目標(biāo)，帶來什么樣收入以及用戶增長
? ? 功能詳情說明：描述產(chǎn)品實現(xiàn)業(yè)務(wù)邏輯以及參與系統(tǒng)各個角色職責(zé)、權(quán)限和前后置依賴關(guān)系等
? ? 非功能詳情說明：產(chǎn)品性能說明、埋點說明、報表需求等
? ? 功能詳情說明中通過用例對功能說明，而用例則是對需求可視化表示，之前提到ER、UML都是可視化建模語言，常用的UML有用例圖、類圖、狀態(tài)圖
? ? 以下對UML常見用例圖進(jìn)行說明：
? ? ?用例圖是UML建模的一部分，也是UML里面最基礎(chǔ)的部分，最主要的功能就是用來表達(dá)系統(tǒng)的功能性需求或行為。用例圖是由軟件需求分析到最終實現(xiàn)的第一步，它描述人們?nèi)绾问褂靡粋€系統(tǒng)，是尾部參與者所能觀察到的系統(tǒng)功能模型圖，該圖呈現(xiàn)了一些參與者和一些用例，以及它們之間的關(guān)系，主要用于對系統(tǒng)、子系統(tǒng)或類的功能行為進(jìn)行建模，用畫圖的方法來完成。用例圖展示了用例之間以及用例與參與者之間是怎樣相互聯(lián)系的。
??? 用例圖包含留個元素：參與者、用例、關(guān)聯(lián)關(guān)系、包含關(guān)系、擴(kuò)展關(guān)系、泛化關(guān)系。
??? 參與者（Actor）：系統(tǒng)外部的一個實體，參與用例執(zhí)行過程，通過向系統(tǒng)輸入或請求系統(tǒng)輸入某些事件來觸發(fā)系統(tǒng)的執(zhí)行。參與者的種類概括為三種：系統(tǒng)用戶、與所建造的系統(tǒng)交互的其他系統(tǒng)以及一些可以運行的進(jìn)程。注意：參與者表示人和事物與系統(tǒng)發(fā)生交互時所扮演的角色，而不是特定的人或特定的事物；每個參與者需要一個具有業(yè)務(wù)一樣的名字；一個人或事物在與系統(tǒng)交互時，可以同時或不同時扮演多個角色。
??? 用例（Use Case）：用例是對一個活動者使用系統(tǒng)的一項功能是所進(jìn)行的交互過程的一個文字描述序列，是系統(tǒng)、子系統(tǒng)或類和尾部參與者交互動作序列的說明，包括可選的動作徐磊嗯哼會出現(xiàn)異常的動作序列。用例是岱廟系統(tǒng)各種各個項目相關(guān)人員之間就系統(tǒng)的行為所達(dá)成的契約，軟件開發(fā)過程是用例驅(qū)動的。用例粒度（規(guī)模大?。?。
??? 關(guān)聯(lián)關(guān)系（Association）：表示參與者用例之間進(jìn)行通信
??? 包含關(guān)系（Include）：客戶用例可以簡單地包含提供者用例具有的行為，并把他所包含的用例行為作為自身行為的一部分。調(diào)用用例執(zhí)行到包含點，然后執(zhí)行傳遞給被調(diào)用用例，當(dāng)被調(diào)用用例完成時，控制在次返回調(diào)用用例。
??? 擴(kuò)展關(guān)系（Extend）：擴(kuò)展用例被定義為基礎(chǔ)用例的增量擴(kuò)展，擴(kuò)展關(guān)系指的是一個用例可以增強(qiáng)另一個用例的行為，提供了一個離散的行為，可以將自己添加到基礎(chǔ)用例作用，表示的箭頭從擴(kuò)展用例指向執(zhí)行用例。使用擴(kuò)展可以使我們在不改變基礎(chǔ)用例的同事，根據(jù)需要自由的往系統(tǒng)中添加行為
??? 泛化關(guān)系（Generalization）：代表一般與特殊的關(guān)系，與繼承類似。在泛化關(guān)系中，子用例繼承了父用例的行為和含義，子用例也可以增加新的行為和含義或覆蓋父用例中的行為和含義。
? 一個用例圖示例：
用例說明
詳細(xì)用例說明包括模塊描述、功能描述、需求說明、優(yōu)先級等：
以微信登錄示例文檔描述：
針對一個用例詳細(xì)說明，通常需有UI圖，以下是我之前做的一個H5流量積分領(lǐng)取的UI:
? ?如果要對UI圖進(jìn)行說明，可以參考《人人都是產(chǎn)品經(jīng)理》P133頁面UC模板部分
? ? 產(chǎn)品功能往往實現(xiàn)功能是動態(tài)、可交互的，那么UI完整實現(xiàn)交互流程，可以通過墨刀工具實現(xiàn)動態(tài)交互，甚至可以下載APK包達(dá)到高保真效果。研發(fā)同學(xué)比較喜歡整體功能交互，如下圖：
? ? 至此一個相對完整的PRD就告一段落，剛從業(yè)產(chǎn)品經(jīng)理針對上述內(nèi)容多加練習(xí)，參考微信、QQ或者其他的APP練習(xí)交互原型以及功能用例，我也期待你們上傳分享自己的作品
2.6 需求評審
? ? UI評審：技術(shù)同學(xué)、運營同學(xué)、BD同學(xué)會對整體UI進(jìn)行評審，針對UI或者流程不合理地方進(jìn)行修改和建議
? ? 需求評審：通常面向研發(fā)人員，經(jīng)過探討后會發(fā)現(xiàn)PRD中各種瑕疵或者缺陷，極有可能造成需求評審不通過返工結(jié)果，所以在正式需求評審前不妨和產(chǎn)品內(nèi)部同事多交流，聽聽產(chǎn)品同學(xué)建議。
? ? 測試評審：測試同學(xué)參與，主要明確待測試功能用例或者性能要求以便更好完成測試，通常業(yè)務(wù)邏輯較為復(fù)雜時候產(chǎn)品經(jīng)理需要和測試同學(xué)一起制定測試策略和方案
2.7? 需求驗收
? ?需求評審?fù)ㄟ^后，會進(jìn)入項目開發(fā)排期，開發(fā)完成后，會經(jīng)過測試同學(xué)測試驗證，不可避免發(fā)現(xiàn)BUG和需求設(shè)計不合理問題，產(chǎn)品經(jīng)理保持時刻跟蹤，bug在全部CLOSED后產(chǎn)品進(jìn)入驗收階段。在正式上線之前，需要產(chǎn)品經(jīng)理簽收《產(chǎn)品發(fā)布確認(rèn)單》，《產(chǎn)品發(fā)布確認(rèn)單》包括：
? ?研發(fā)意見：數(shù)據(jù)庫環(huán)境/產(chǎn)品版本/數(shù)據(jù)準(zhǔn)確性
? ?產(chǎn)品意見：產(chǎn)品功能完整/產(chǎn)品性能達(dá)到要求/UI是否一致
? ?運營意見：內(nèi)容與功能滿足運營需求
? ?注：其他交付物：《產(chǎn)品測試清單》 《遺留問題》 《產(chǎn)品使用說明》
