chinesefreesexvideos高潮,欧美极品少妇性运交,久久久国产一区二区三区,99久久婷婷国产综合精品,成人国产一区二区三区

　　編輯導(dǎo)語：產(chǎn)品管理流程是很復(fù)雜的，稍不注意就會出現(xiàn)差錯，然而規(guī)范的流程是怎樣的？流程不規(guī)范有什么危害？需要注意些什么？可能很多人都還不知道，基于此，本文作者總結(jié)了那些踩過的坑，為大家詳細的羅列出了規(guī)范的產(chǎn)品管理流程，希望看后對你能夠有所幫助。

　　1）親身經(jīng)歷

　　產(chǎn)品流程混亂無序開發(fā)直接對接業(yè)務(wù)隨時插入新的開發(fā)功能交接資料為零接手的工作未畫流程圖進入業(yè)務(wù)之后，發(fā)現(xiàn)流程等各種產(chǎn)品文檔缺失嚴(yán)重版本更新內(nèi)容未記錄產(chǎn)品記錄資料中間連續(xù)斷層在與眾多產(chǎn)品溝通的時候，發(fā)現(xiàn)這是一個很普遍的問題，我基于已經(jīng)趟過的坑，想聊一下。

　　2）產(chǎn)品流程管理及文檔不規(guī)范有什么害處

　　增加了額外的成本及問題，這些成本包括：

　　新人對項目的上手時間成本；因資料缺失導(dǎo)致的溝通成本；研發(fā)周期加長導(dǎo)致的進度問題；無文本信息，問題反復(fù)，理解不一致導(dǎo)致的團隊信任成本；人員流失導(dǎo)致信息斷層的問題。特別在業(yè)務(wù)不斷擴張，人員團隊擴容，任務(wù)復(fù)雜度增加，管理及文檔的規(guī)范化將發(fā)揮巨大作用。

　　基于這個認知，在我的產(chǎn)品經(jīng)理職業(yè)生涯中，逐步搭建了一套產(chǎn)品流程及規(guī)范文檔，進行了實踐，取得了一定的效果：內(nèi)部認知語言統(tǒng)一、溝通時間更短、各方效率提高、文檔可追溯查詢、人員變動流失影響更小、權(quán)責(zé)清晰等。

　　此系列文章將對此套管理流程及規(guī)范做分享，主要約定公司產(chǎn)品從立項到產(chǎn)品上線的整個過程，產(chǎn)品經(jīng)理的做事流程，產(chǎn)品經(jīng)理需要完成哪些事情，需要產(chǎn)生哪些文檔以及文檔產(chǎn)出的規(guī)范。

　　本系列文章主要涉及方面包括：

　　產(chǎn)品需求的收集產(chǎn)品需求管理產(chǎn)品規(guī)劃產(chǎn)品原型設(shè)計產(chǎn)品需求的輸出文檔產(chǎn)品驗收產(chǎn)品版本命名規(guī)則產(chǎn)品發(fā)版管理

　　為產(chǎn)品定基調(diào)，定方向的需求，比如說，我們要做一個母嬰方向的垂直電商平臺。

　　引起戰(zhàn)略性需求的因素可能有兩大部分：

　　一部分是由外部因素引起（如新技術(shù)趨勢、市場變化、社會交流方式等出現(xiàn)的新機會）；一部分是內(nèi)部的技術(shù)、資源整合再利用，在原有業(yè)務(wù)方向之外的拓展（比如華為利用他的技術(shù)積累往手機方向發(fā)展，滴滴利用在出行上的數(shù)據(jù)積累做無人駕駛汽車）。這會延伸出新增及拓展的兩類，新增比如原來做團購，現(xiàn)在增加外賣業(yè)務(wù)。拓展比如本身做外賣業(yè)務(wù)，配送團隊由第三方完成，現(xiàn)在外賣訂單量大之后自己做配送，拓展有橫向及縱向擴展，縱向是上下游產(chǎn)業(yè)鏈整合，橫向是業(yè)務(wù)多元化。

　　此部分參與人員一般是公司最高層，至少是項目的最高層核心人員參與。

　　這涉及到商業(yè)模式的綜合分析，在本文中不做過多擴展，后期將專門寫一些文章專門分析。本文主要還是集中在產(chǎn)品需求收集、管理流程及規(guī)范上。

　　戰(zhàn)術(shù)需求比戰(zhàn)略需求低一層級，是對戰(zhàn)略的拆分，也即是通常意義說的產(chǎn)品實現(xiàn)路線的每個階段。

　　比如說：做本地生活服務(wù)平臺，前期商家體量小，盡快的實現(xiàn)業(yè)務(wù)流轉(zhuǎn)，前期合同可以線下簽訂，可以只做PC端；后期逐步的實現(xiàn)電子合同，手機APP，網(wǎng)頁適配等。

　　戰(zhàn)役是對戰(zhàn)術(shù)的再拆分，也就是每一個階段性的具體實施。

　　比如：商家合同電子簽如何實現(xiàn)，登錄方式如何處理。當(dāng)然，這是簡單的區(qū)分，實際中短期需求也需要考慮到后期的可擴展性，否則做出來的東西后期改動成本會非常大。

　　比如說登錄方式，如果不考慮各平臺，各渠道賬戶打通等，后期的對接，用戶數(shù)據(jù)的集中處理將會面臨很大的問題。

　　簡單說就是公司內(nèi)部決策高層及各部門具體使用人員，對產(chǎn)品在使用中發(fā)現(xiàn)的問題，提出的優(yōu)化改善運營策劃方案。

　　如運營使用頻率最高，客服部與用戶溝通頻率最高，都能發(fā)現(xiàn)很多需求及問題。

　　此部分需求，具體使用部門一般主要集中在對現(xiàn)有產(chǎn)品的優(yōu)化迭代，在流程的優(yōu)化、體驗的優(yōu)化，業(yè)務(wù)線的深化拓展。

　　內(nèi)部客戶的需求收集整個流程：

　　由內(nèi)部用戶填寫需求功能收集表，按照一定的周期提交產(chǎn)品經(jīng)理，并進行溝通討論，根據(jù)商業(yè)價值、技術(shù)可實現(xiàn)度、優(yōu)先級、產(chǎn)品路線節(jié)奏規(guī)劃等考慮點判斷是否要做，及做的安排。短期內(nèi)不做，或者有其它方法可解決的情況下，與需求提出方溝通其它解決方案（如：在項目的早期，以MVP方式做，則很多分析類的需求，在數(shù)據(jù)量較小，工作復(fù)雜程度較小的時候，是可以通過將相關(guān)數(shù)據(jù)埋點進行導(dǎo)出手動分析，則這個時候做大量的系統(tǒng)數(shù)據(jù)分析需求及實用性不大）。

　　如果需求溝通之后確認要做，則將需求放入排期中，并將需求對接清楚，各方通過簽字或其它方式進行確認。

　　一般來說，如果不是非常緊急的需求及bug修復(fù)等，按照一周一次的提交頻率進行是一種較好的方式，因為產(chǎn)品進展到一定的程度之后，大概率也是按照一定的固定頻率進行更新。

　　這樣一方面給產(chǎn)品經(jīng)理可以留下其它時間來完成手上的工作，不至于經(jīng)常打亂節(jié)奏，另一方面可以給需求提出方一定的思考完善時間，補足一些明顯的業(yè)務(wù)邏輯漏洞。

　　但這個需要前期進行部門之間的溝通，形成一定的機制。

　　其它部門很容易出現(xiàn)的狀況是，有一個想法就想立即與產(chǎn)品經(jīng)理進行溝通，這是人的一種本能，有任何問題及疑問，想法就想立即溝通。但產(chǎn)品及業(yè)務(wù)的工作，是屬于較為復(fù)雜的知識性工作，這種工作的方式是要進行大量的決策及權(quán)衡，不如一些潛意識的行為方式，直覺的判斷。

　　要克服這一點，只有各部門之間達成一個溝通機制，做一定的固化。

　　內(nèi)部需求收集的整體流程如下：

　　外部客戶的調(diào)研，這要看產(chǎn)品是針對的B端用戶還是C端用戶，B端用戶的目標(biāo)客戶群較為清晰。

　　B端用戶要分決策購買人和使用者，最好的方式是同時滿足兩者的需求。

　　這兩者有不同點，比如決策者的依據(jù)是對企業(yè)好（其它目的不進行討論），比如員工行為數(shù)據(jù)可視化、流程線上化。這樣可以對員工進行監(jiān)管，同時數(shù)據(jù)更為實時，后期商業(yè)決策更加有依據(jù)。

　　實際在做的時候，需要深入業(yè)務(wù)中調(diào)研，也需要對流程進行優(yōu)化，不能只是簡單的將原有的流程完全搬到線上，或者簡單的搞高大上的可視化顯示，因為這樣會增加實際操作人員的成本，并未能提高效率，縮減成本。

　　一般B端業(yè)務(wù)，深入業(yè)務(wù)，對相關(guān)關(guān)系人進行足夠的溝通，則需求將比較明顯能夠提煉出來。

　　C端的用戶，業(yè)務(wù)縱深一般沒有B端的程度深，但目標(biāo)用戶的明確性，用戶的需求會不這么明顯，需求調(diào)研所花費的工作將會更多。

　　總體來說，B、C都采用線上及線下的方式進行調(diào)研。線上調(diào)研一般是調(diào)研問卷的方式，以及參考行業(yè)相關(guān)資料，競對資料，線下一般采用拜訪（預(yù)設(shè)或不預(yù)設(shè)問題），邀請用戶集中溝通，頭腦風(fēng)暴等方式。

　　不同的調(diào)研方式適用的階段，操作的方式都不一樣，這一方面要多注意。具體的調(diào)研方式，大家可以進行網(wǎng)絡(luò)搜索查看詳情，后期我也可以針對不同階段，不同類型業(yè)務(wù)采用何種調(diào)研方法寫文章闡述。

　　以下為外部需求收集的流程：

　　產(chǎn)品需求收集表：以下為需求收集表的樣式，需要說明需求提出方，需求的名稱，將需求描述清楚（主要解決為什么做，做什么，怎么做這幾個問題，特別是解決為什么及做什么的問題），需求的類型是新增、改進，緊急重要程度（判斷排期得重要標(biāo)準(zhǔn)），對接的產(chǎn)品經(jīng)理，對接的時間（收到需求的時間）

　　需求收集之后進入進入正式的需求池進行管理，可以按照一定的時間比如每周一次從各方收集需求，并進行初步溝通之后，放進需求池。并根據(jù)需求本身的變動，調(diào)整需求池中的相關(guān)狀態(tài)，標(biāo)注相關(guān)的記錄，批注。

　　ID——需求的唯一ID號，需求身份標(biāo)識，增加一個需求ID增加1。端口——需求所涉及的端口，前端如—安卓、iOS、小程序，后臺—平臺、供應(yīng)商、商家，這是對需求做初步劃分，如果涉及到多端，一般記為綜合或拆分成多條子需求對應(yīng)到各端口。模塊——需求所涉及到的模塊，例如會員管理、用戶管理、商品管理等。需求名稱——簡單描述需求是做什么的需求描述——更詳細描述需求的相關(guān)信息，例如需求提出的背景、需求要達成什么目的、需求的詳細說明等。需求來源——記錄需求的來源方，例如產(chǎn)品、市場、運營。類型——記錄當(dāng)前需求的類型，a、新功能；b、功能優(yōu)化；c、bug修復(fù)。優(yōu)先級——記錄需求的優(yōu)先級，a、一般用高中低；b、數(shù)字表達；c、需求的優(yōu)先級是動態(tài)的，會隨著戰(zhàn)略、業(yè)務(wù)目標(biāo)的變化而調(diào)整。提出時間——記錄需求被提出的時間提出人——提出這個需求的人及聯(lián)系方式，有助于在需求詳細設(shè)計時追蹤到原始需求。狀態(tài)——需求當(dāng)前的狀態(tài)，根據(jù)不同的階段，可以大致分為：a、記錄——進入需求池（初始狀態(tài)）；b、論證——需求開始評估論證；c、待設(shè)計——論證完成后有價值并決定近期開展后續(xù)工作；d、設(shè)計中——正在進行詳細設(shè)計；e、設(shè)計完成——原型及UI已經(jīng)設(shè)計完成；f、研發(fā)中——已正式安排研發(fā)周期；g、已上線——需求正式上線；h、已關(guān)閉——針對需求因各種原因提前終止其生命周期；預(yù)計版本——對需求計劃上線的版本進行規(guī)劃，產(chǎn)品部門規(guī)劃的實現(xiàn)版本往往會超前正在研發(fā)版本實際完成版本——版本上線后，更新需求實現(xiàn)的實際版本號上線時間——記錄版本實際上線的日期備注——各種情況的補充說明，例如需求關(guān)閉的原因，需求優(yōu)先級變動原因，版本規(guī)劃變動

　　需求優(yōu)先級的分析可以采用KANO模型、四象限法則、權(quán)重加權(quán)三種方式進行：

　　2.1 KANO模型

　　以分析用戶需求對用戶滿意的影響為基礎(chǔ)，選擇了兩個維度：需求實現(xiàn)度、用戶滿意度。

　　用這兩個維度將需求區(qū)分，將需求分為5種，分別是：

　　興奮型需求——也稱魅力型需求：隨著滿足用戶期望程度的增加，用戶滿意度也會急劇上升，但一旦得到滿足，即使表現(xiàn)并不完善，用戶表現(xiàn)出的滿意狀況則也是非常高的。反之，即使在期望不滿足時，用戶也不會因而表現(xiàn)出明顯的不滿意。期望型需求——也稱為意愿型需求：是指顧客的滿意狀況與需求的滿足程度成比例關(guān)系的需求，此類需求得到滿足或表現(xiàn)良好的話，客戶滿意度會顯著增加，企業(yè)提供的產(chǎn)品和服務(wù)水平超出顧客期望越多，顧客的滿意狀況越好。比如說，支付方式，相對來說，是越多越好，這樣用戶會有更多選擇，當(dāng)沒有一種支付或是其中一種沒有資金的時候還有別的可供選擇，能覆蓋更多的用戶。無差異需求——不論提供與否，對用戶體驗無影響，比如現(xiàn)在各平臺都有的簽到，打卡功能?；拘托枨蟆卜Q為必備型需求、理所當(dāng)然需求：是用戶對企業(yè)提供的產(chǎn)品或服務(wù)因素的基本要求，比如現(xiàn)在互聯(lián)網(wǎng)基本都有的客服功能。反向需求——又稱逆向型需求：指引起強烈不滿的導(dǎo)致低水平滿意的需求，比如將產(chǎn)品流程設(shè)計的非常復(fù)雜，引起用戶反感。針對不同類型的需求，采取不同的措施。

　　2.2 四象限法則

　　四象限法則將需求分為：重要且緊急、重要不緊急、不重要但緊急、不重要也不緊急四類，兩個選擇維度是：緊急和重要。

　　第一象限——包含一些緊急而重要的需求，這類需求具有時間的緊迫性和影響的重要性，無法回避也不能拖延，必須首先處理優(yōu)先解決，比如支付功能出問題。第二象限——需求不具有時間上的緊迫性，但它具有重大的影響，需要ｗｂｓ方法分解任務(wù)、提前進行規(guī)劃，按照計劃逐步制性，比如數(shù)據(jù)埋點統(tǒng)計分析。第三象限——需求大多是些瑣碎的雜事，沒有時間的緊迫性，沒有任何的重要性，這種需求的提出本身就存在一定問題，沒有考慮清楚，可能是頭腦發(fā)熱，也可能是看著別人有就想做，與本身產(chǎn)品沒有任何關(guān)聯(lián)性，對這類需求可以放任不管，比如后臺標(biāo)題欄的顏色美觀性第四象限——是那些緊急但不重要的需求，這些事情很緊急但并不重要，比如由于商品圖片過大導(dǎo)致的加載慢（可以通過優(yōu)化壓縮上傳圖片解決）等，可以先采用替代方案執(zhí)行2.3 權(quán)重衡量

　　對需求賦予一定的指標(biāo)，進行量化分析，如工作量大小、對用戶價值大小，對公司價值大小、緊迫程度、與核心流程相關(guān)性，可以將各指標(biāo)賦予一定的權(quán)重（所有指標(biāo)項權(quán)重相加為1，各指標(biāo)項確定各自的程度數(shù)值，工作量按天計算時間越大，賦值越低）進行加權(quán)，得出綜合值大的，則優(yōu)先級高。

　　如下圖，需求2的綜合得分為6.8》需求2的綜合得分5.6，先做需求2：

　　任務(wù)量固定，時間上可以進行調(diào)整，比如一個大的版本上線，新開的功能模塊上線，即使采用MVP的方式，也會超出一般迭代的周期。

　　這種方式一定是以保證業(yè)務(wù)、功能需求的完整性，系統(tǒng)性為主，不能完全按照時間來。

　　否則的話，功能邏輯的完整性和鏈條就會缺失，上線之后會帶來極壞的影響，如果功能不完整還不如不上線的好。

　　當(dāng)產(chǎn)品進入穩(wěn)定期之后，業(yè)務(wù)也較為穩(wěn)定順暢，則按照固定周期進行迭代，比如兩周時間上新一個版本，則以時間為準(zhǔn)，固定時間端，按照優(yōu)先級并考慮工作量合理安排需求。

　　在上一個版本發(fā)布之后，發(fā)現(xiàn)重大bug，需要緊急修復(fù)上線，這種肯定不能按照常規(guī)方式處理，直接將優(yōu)先級提高，修復(fù)上線。

　　緊急需求與插入需求有些類似，均是常規(guī)計劃之外的。兩者又有不同之處，緊急需求是不得不做的，不做將會帶來嚴(yán)重影響的。

　　插入式需求是計劃已經(jīng)排定，但又有新的需求進來，比如業(yè)務(wù)部門，上級領(lǐng)導(dǎo)等。

　　這個時候從幾個方面進行處理：

　　先不急著拒絕，先分析需求的優(yōu)先級，如果需求確實優(yōu)先級高，看需求規(guī)模，工作量大小，人力資源，是否能不動本次版本需求的基礎(chǔ)上進行增加。如果可以則直接增加進去，如果不行，則將優(yōu)先級低的需求進行刪減。需求優(yōu)先級不高，則溝通安排到之后的迭代，并講明原因

　　本文主要對需求的層級、需求來源、需求收集方法、需求管理池、優(yōu)先級的確定及需求迭代進行了分析，產(chǎn)品管理流程及規(guī)范系列文章地址為：

　　產(chǎn)品管理流程及規(guī)范2——產(chǎn)品規(guī)劃及相關(guān)文檔

　　產(chǎn)品管理流程及規(guī)范3：產(chǎn)品原型設(shè)計

　　產(chǎn)品管理流程及規(guī)范4：PRD文檔撰寫

　　產(chǎn)品管理流程及規(guī)范5——版本命名、驗收規(guī)范、發(fā)版管理

　　本文由 @markzou 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

　　題圖來自Unsplash，基于CC0協(xié)議。