智慧社區(qū)SaaS服務(wù)平臺PRD需求規(guī)格說明書V0.0.1

產(chǎn)品管理規(guī)范編號：產(chǎn)品管理規(guī)范版號：V1.0頁碼：共41頁編制日期：審核：日期：批準：日期2022年8月目錄產(chǎn)品管理規(guī)范 1一、前言 41.1目的 41.2范圍 41.3職責 41.4內(nèi)容 4二、產(chǎn)品戰(zhàn)略規(guī)劃 52.1產(chǎn)品路線 52.2產(chǎn)品策略 52.3產(chǎn)品計劃 5三、產(chǎn)品需求階段 63.1需求層級 63.2需求獲取 63.3需求分析 83.4需求管理 93.5迭代規(guī)劃 13四、產(chǎn)品設(shè)計階段 144.1總體流程 144.2產(chǎn)品原型設(shè)計 154.3主流設(shè)計工具 184.4原型大綱 184.5界面原型及邏輯說明 194.6交互用例 204.7原型詳細規(guī)范 204.8流程制作規(guī)范 214.9頁面說明 22五、PRD文檔撰寫 245.1寫PRD的目的 245.2PRD撰寫的前提條件 245.3PRD內(nèi)容 255.4產(chǎn)品向各方需求文檔內(nèi)容 37六、版本命名、驗收規(guī)范、發(fā)版管理 376.1產(chǎn)品版本命名規(guī)則 376.2產(chǎn)品驗收流程 396.3產(chǎn)品發(fā)版管理 41一、前言1.1目的實現(xiàn)以市場為導(dǎo)向的產(chǎn)品規(guī)劃，有計劃有組織地進行研究與產(chǎn)品開發(fā)活動。有效地調(diào)動營銷部門以及生產(chǎn)部門的創(chuàng)造性思維，把市場與消費者的認識轉(zhuǎn)換在新產(chǎn)品中，確保產(chǎn)品開發(fā)和企業(yè)產(chǎn)品戰(zhàn)略的一致性，快速、合理應(yīng)對市場需求，規(guī)避產(chǎn)品投資風險，并為企業(yè)獲得最大限度的利潤。1.2范圍本制度適用于本公司產(chǎn)品開發(fā)、上線、管理全過程，對產(chǎn)品管理的流程做出規(guī)定，是公司管理產(chǎn)品規(guī)劃工作的依據(jù)。1.3職責產(chǎn)品管理是企業(yè)在產(chǎn)品生命周期中對產(chǎn)品規(guī)劃、設(shè)計、開發(fā)、運營和支持等環(huán)節(jié)進行管理的業(yè)務(wù)活動，包括需求管理、設(shè)計管理以及開發(fā)管理。1.4內(nèi)容1.4.1產(chǎn)品戰(zhàn)略規(guī)劃產(chǎn)品戰(zhàn)略包含：1產(chǎn)品路線2產(chǎn)品策略3產(chǎn)品計劃1.4.2產(chǎn)品研發(fā)產(chǎn)品研發(fā)包含：1需求階段2設(shè)計階段3開發(fā)階段4測試階段5發(fā)布階段（上線）1.4.3組織、主要人員及職責1.4.3.1組織結(jié)構(gòu)1.4.3.2重要角色重要角色負責人：產(chǎn)品負責人、研發(fā)負責人、產(chǎn)品管理負責人、運營負責人。重要角色包括：產(chǎn)品經(jīng)理、需求管理員、技術(shù)人員、運營人員。1.4.3.3其中對重要角色職責及相關(guān)要求定義如下：1)產(chǎn)品管理會產(chǎn)品管理會由產(chǎn)品中心、運營中心、產(chǎn)品研發(fā)中心總監(jiān)以及參與在產(chǎn)品生命周期過程中的產(chǎn)品規(guī)劃、用戶研究、產(chǎn)品負責人、開發(fā)負責人、運營負責人等共同組成。主要職責：（1）制定運營計劃，確定運營目標；（2）優(yōu)化產(chǎn)品，制定運營策略；（3）監(jiān)控產(chǎn)品質(zhì)量，把控經(jīng)營結(jié)果；（4）對產(chǎn)品進行全生命周期管理；（5）對產(chǎn)品需求的提出、終止和變更進行決策；（6）監(jiān)督產(chǎn)品管理相關(guān)制度的執(zhí)行。2)評審委員會由產(chǎn)品中心、產(chǎn)品規(guī)劃、運營中心及產(chǎn)品研發(fā)的總監(jiān)組成。主要職責：（1）對本中心項目進度和質(zhì)量進行管理，保障經(jīng)營結(jié)果達成；（2）對項目相關(guān)資源進行調(diào)配，以保證項目順利開展；（3）對產(chǎn)品定義的方向性提出建議并評審；（4）對產(chǎn)品是否具備上線條件進行評審，并給出意見；（5）對產(chǎn)品運營結(jié)果進行評審，對產(chǎn)品和運營目標提出意見并給予幫助；（6）對產(chǎn)品是否退市進行評審。二、產(chǎn)品戰(zhàn)略規(guī)劃戰(zhàn)略規(guī)劃是產(chǎn)品管理中最重要工作之一，主要是制定公司產(chǎn)品（產(chǎn)品線）的長期發(fā)展規(guī)劃和年度發(fā)展規(guī)劃，具體的工作分為以下三個流程。2.1產(chǎn)品路線產(chǎn)品路線規(guī)劃是屬于公司業(yè)務(wù)中戰(zhàn)略層面的制定工作之一，對于產(chǎn)品管理人員來說，每個大型項目需要對產(chǎn)品線進行產(chǎn)品（產(chǎn)品線）路線規(guī)劃，確定產(chǎn)品（產(chǎn)品線）長期的發(fā)展規(guī)劃和目標。2.2產(chǎn)品策略年度產(chǎn)品策略的制定是對產(chǎn)品路線規(guī)劃每一年度的進一步細化的工作，確定公司年度的產(chǎn)品發(fā)展規(guī)劃及相應(yīng)的措施，是每一年度產(chǎn)品發(fā)展的總綱領(lǐng)文件。2.3產(chǎn)品計劃年度產(chǎn)品計劃是年度產(chǎn)品策略中詳細產(chǎn)品管理工作的具體項目時間安排計劃一覽表，有利于更加明確年度需要確定的產(chǎn)品管理工作。以上的三個二級流程工作主要是解決公司業(yè)務(wù)發(fā)展和產(chǎn)品管理中的戰(zhàn)略性層面的問題，確定公司整體的產(chǎn)品發(fā)展方向及年度的工作內(nèi)容。具體產(chǎn)品戰(zhàn)略規(guī)劃步驟如下：1）產(chǎn)品管理部根據(jù)年度目標和戰(zhàn)略，結(jié)合市場情況和各相關(guān)部門提供的相關(guān)資料進行分析，形成“產(chǎn)品規(guī)劃討論稿”。

2）產(chǎn)品管理部經(jīng)理審核討論稿。

3）產(chǎn)品管理部經(jīng)理組織營銷公司相關(guān)部門對“產(chǎn)品規(guī)劃討論稿”進行討論修改，形成“產(chǎn)品規(guī)劃書”。

4）產(chǎn)品管理部將“產(chǎn)品規(guī)劃書”報產(chǎn)品委員會審批，若不通過，由產(chǎn)品部負責修改再報產(chǎn)品委員會審批。

5）產(chǎn)品委員會審批通過后下發(fā)各部門執(zhí)行。三、產(chǎn)品需求階段3.1需求層級3.1.1戰(zhàn)略性需求為產(chǎn)品定基調(diào)，定方向的需求，引起戰(zhàn)略性需求的因素可能有兩大部分：一部分是由外部因素引起（如新技術(shù)趨勢、市場變化、社會交流方式等出現(xiàn)的新機會）一部分是內(nèi)部的技術(shù)、資源整合再利用，在原有業(yè)務(wù)方向之外的拓展3.1.2戰(zhàn)術(shù)需求戰(zhàn)術(shù)需求比戰(zhàn)略需求低一層級，是戰(zhàn)略的拆分也即是通常意義說的產(chǎn)品實現(xiàn)路線的每個階段。3.1.3戰(zhàn)役需求戰(zhàn)役是對戰(zhàn)術(shù)的再拆分，也就是每一個階段性的具體實施。比如：合同電子簽如何實現(xiàn)，登錄方式如何處理。實際中短期需求也需要考慮到后期的可擴展性，否則做出來的東西后期改動成本會非常大。3.2需求獲取1）概述：從概括性的項目背景說明、價值分析，深入到目標用戶確認、業(yè)務(wù)現(xiàn)狀、業(yè)務(wù)問題和期望效果的梳理。2）需求來源：戰(zhàn)略規(guī)劃、競品分析、運營反饋、用戶反饋、市場調(diào)研3.2.1內(nèi)部客戶簡單說就是公司內(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)品進展到一定的程度之后，大概率也是按照一定的固定頻率進行更新。內(nèi)部需求收集的整體流程如下：3.2.2外部客戶外部客戶的調(diào)研，這要看產(chǎn)品是針對的B端用戶還是C端用戶，B端用戶的目標客戶群較為清晰。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端的程度深，但目標用戶的明確性，用戶的需求會不這么明顯，需求調(diào)研所花費的工作將會更多?？傮w來說，B、C都采用線上及線下的方式進行調(diào)研。線上調(diào)研一般是調(diào)研問卷的方式，以及參考行業(yè)相關(guān)資料，競對資料，線下一般采用拜訪（預(yù)設(shè)或不預(yù)設(shè)問題），邀請用戶集中溝通，頭腦風暴等方式。以下為外部需求收集的流程：3.3需求分析3.3.1概述產(chǎn)品經(jīng)理針對獲取的原始需求進行偽需求過濾，梳理得到真實需求并匯總進項目需求池，進行優(yōu)先級判斷和迭代規(guī)劃等管理。其中優(yōu)先級主要從核心需求難、基本需求、擴展需求三個維度進行判斷；迭代規(guī)劃則是權(quán)衡工期要求和開發(fā)資源，在當期版本中刪減優(yōu)先級低的需求，在后續(xù)版本中再開發(fā)。根據(jù)確認下來的當期需求，進行業(yè)務(wù)流程、功能架構(gòu)、工作流狀態(tài)定義的梳理工作——即進行框架層的需求設(shè)計。3.3.2注意事項《有效需求分析》中總結(jié)了這一現(xiàn)象：需求方往往提出“方案級需求”，需求分析則是要還原出“問題級需求”。過濾“偽需求”，得到“真實需求”。梳理出真實需求后，根據(jù)實際項目要求和資源限制，還需要從技術(shù)、業(yè)務(wù)、成本和收益、風險和策略等方面進行可行性分析。需求概要設(shè)計（包含業(yè)務(wù)流程圖、功能架構(gòu)圖和工作流狀態(tài)定義等）；需求清單；調(diào)研報告：郵件發(fā)送，同步雙方；會議紀要：記錄需求來源，重要等級3.3.3需求收集標準化文檔產(chǎn)品需求收集表：以下為需求收集表的樣式提出方需求名稱需求描述需求類型緊急程度對接的產(chǎn)品經(jīng)理對接時間--主要解決為什么做，做什么，怎么做這幾個問題，特別是解決為什么及做什么的問題新增、改進判斷排期得重要標準收到需求的時間3.4需求管理3.4.1需求池需求收集之后進入進入正式的需求池進行管理，每周一次從各方收集需求，并進行初步溝通之后，放進需求池。并根據(jù)需求本身的變動，調(diào)整需求池中的相關(guān)狀態(tài)，標注相關(guān)的記錄，批注。ID端口模塊需求名稱需求描述需求來源類型優(yōu)先級提出時間提出人狀態(tài)預(yù)計實現(xiàn)版本實際完成版本上線時間備注ID——需求的唯一ID號，需求身份標識，增加一個需求ID增加1。端口——需求所涉及的端口，前端如—安卓、iOS、小程序，后臺—平臺、供應(yīng)商、商家，這是對需求做初步劃分，如果涉及到多端，一般記為綜合或拆分成多條子需求對應(yīng)到各端口。模塊——需求所涉及到的模塊，例如會員管理、用戶管理、商品管理等。需求名稱——簡單描述需求是做什么的需求描述——更詳細描述需求的相關(guān)信息，例如需求提出的背景、需求要達成什么目的、需求的詳細說明等。需求來源——記錄需求的來源方，例如產(chǎn)品、市場、運營。類型——記錄當前需求的類型，a、新功能；b、功能優(yōu)化；c、bug修復(fù)。優(yōu)先級——記錄需求的優(yōu)先級，a、一般用高中低；b、數(shù)字表達；c、需求的優(yōu)先級是動態(tài)的，會隨著戰(zhàn)略、業(yè)務(wù)目標的變化而調(diào)整。提出時間——記錄需求被提出的時間提出人——提出這個需求的人及聯(lián)系方式，有助于在需求詳細設(shè)計時追蹤到原始需求。狀態(tài)——需求當前的狀態(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)閉——針對需求因各種原因提前終止其生命周期；i.預(yù)計版本——對需求計劃上線的版本進行規(guī)劃，產(chǎn)品部門規(guī)劃的實現(xiàn)版本往往會超前正在研發(fā)版本g.實際完成版本——版本上線后，更新需求實現(xiàn)的實際版本號k.上線時間——記錄版本實際上線的日期l.備注——各種情況的補充說明，例如需求關(guān)閉的原因，需求優(yōu)先級變動原因，版本規(guī)劃變動3.4.2需求優(yōu)先級需求優(yōu)先級的分析可以采用KANO模型、四象限法則、權(quán)重加權(quán)三種方式進行：3.4.2.1KANO模型以分析用戶需求對用戶滿意的影響為基礎(chǔ)，選擇了兩個維度：需求實現(xiàn)度、用戶滿意度。用這兩個維度將需求區(qū)分，將需求分為5種，分別是：興奮型需求——也稱魅力型需求：隨著滿足用戶期望程度的增加，用戶滿意度也會急劇上升，但一旦得到滿足，即使表現(xiàn)并不完善，用戶表現(xiàn)出的滿意狀況則也是非常高的。反之，即使在期望不滿足時，用戶也不會因而表現(xiàn)出明顯的不滿意。期望型需求——也稱為意愿型需求：是指顧客的滿意狀況與需求的滿足程度成比例關(guān)系的需求，此類需求得到滿足或表現(xiàn)良好的話，客戶滿意度會顯著增加，企業(yè)提供的產(chǎn)品和服務(wù)水平超出顧客期望越多，顧客的滿意狀況越好。比如說，支付方式，相對來說，是越多越好，這樣用戶會有更多選擇，當沒有一種支付或是其中一種沒有資金的時候還有別的可供選擇，能覆蓋更多的用戶。無差異需求——不論提供與否，對用戶體驗無影響，比如現(xiàn)在各平臺都有的簽到，打卡功能。基本型需求——也稱為必備型需求、理所當然需求：是用戶對企業(yè)提供的產(chǎn)品或服務(wù)因素的基本要求，比如現(xiàn)在互聯(lián)網(wǎng)基本都有的客服功能。反向需求——又稱逆向型需求：指引起強烈不滿的導(dǎo)致低水平滿意的需求，比如將產(chǎn)品流程設(shè)計的非常復(fù)雜，引起用戶反感。針對不同類型的需求，采取不同的措施。3.4.2.2四象限法則四象限法則將需求分為：重要且緊急、重要不緊急、不重要但緊急、不重要也不緊急四類，兩個選擇維度是：緊急和重要。第一象限——包含一些緊急而重要的需求，這類需求具有時間的緊迫性和影響的重要性，無法回避也不能拖延，必須首先處理優(yōu)先解決，比如支付功能出問題。第二象限——需求不具有時間上的緊迫性，但它具有重大的影響，需要ｗｂｓ方法分解任務(wù)、提前進行規(guī)劃，按照計劃逐步制性，比如數(shù)據(jù)埋點統(tǒng)計分析。第三象限——需求大多是些瑣碎的雜事，沒有時間的緊迫性，沒有任何的重要性，這種需求的提出本身就存在一定問題，沒有考慮清楚，可能是頭腦發(fā)熱，也可能是看著別人有就想做，與本身產(chǎn)品沒有任何關(guān)聯(lián)性，對這類需求可以放任不管，比如后臺標題欄的顏色美觀性第四象限——是那些緊急但不重要的需求，這些事情很緊急但并不重要，比如由于商品圖片過大導(dǎo)致的加載慢（可以通過優(yōu)化壓縮上傳圖片解決）等，可以先采用替代方案執(zhí)行3.4.2.3權(quán)重衡量對需求賦予一定的指標，進行量化分析，如工作量大小、對用戶價值大小，對公司價值大小、緊迫程度、與核心流程相關(guān)性，可以將各指標賦予一定的權(quán)重（所有指標項權(quán)重相加為1，各指標項確定各自的程度數(shù)值，工作量按天計算時間越大，賦值越低）進行加權(quán)，得出綜合值大的，則優(yōu)先級高。如下圖，需求2的綜合得分為6.8》需求2的綜合得分5.6，先做需求2：序號需求名稱工作量（權(quán)重0.2）用戶價值（0.3）公司價值（0.2）緊迫程度（0.2）核心流程相關(guān)性（0.1）綜合分數(shù)1XXX367585.62XXX576976.83.5迭代規(guī)劃3.5.1固定任務(wù)任務(wù)量固定，時間上可以進行調(diào)整，比如一個大的版本上線，新開的功能模塊上線，即使采用MVP的方式，也會超出一般迭代的周期。這種方式一定是以保證業(yè)務(wù)、功能需求的完整性，系統(tǒng)性為主，不能完全按照時間來。否則的話，功能邏輯的完整性和鏈條就會缺失，上線之后會帶來極壞的影響，如果功能不完整還不如不上線的好。3.5.2固定周期當產(chǎn)品進入穩(wěn)定期之后，業(yè)務(wù)也較為穩(wěn)定順暢，則按照固定周期進行迭代，比如兩周時間上新一個版本，則以時間為準，固定時間端，按照優(yōu)先級并考慮工作量合理安排需求。3.5.3緊急需求在上一個版本發(fā)布之后，發(fā)現(xiàn)重大bug，需要緊急修復(fù)上線，這種肯定不能按照常規(guī)方式處理，直接將優(yōu)先級提高，修復(fù)上線。3.5.4插入需求的處理緊急需求與插入需求有些類似，均是常規(guī)計劃之外的。兩者又有不同之處，緊急需求是不得不做的，不做將會帶來嚴重影響的。插入式需求是計劃已經(jīng)排定，但又有新的需求進來，比如業(yè)務(wù)部門，上級領(lǐng)導(dǎo)等。這個時候從幾個方面進行處理：1)根據(jù)需求規(guī)模，工作量大小，人力資源，是否能不動本次版本需求的基礎(chǔ)上進行增加。如果可以則直接增加進去，如果不行，則將優(yōu)先級低的需求進行刪減。2)需求優(yōu)先級不高，則溝通安排到之后的迭代四、產(chǎn)品設(shè)計階段4.1總體流程4.1.1產(chǎn)品規(guī)劃及評審與需求方對接需求，并經(jīng)過評估，確定要做之后，即進行產(chǎn)品的規(guī)劃。產(chǎn)品規(guī)劃，將商業(yè)模式、盈利點、產(chǎn)品路線演化、主業(yè)務(wù)流程、核心功能模塊確定之后，進行產(chǎn)規(guī)劃的評審；評審?fù)ㄟ^之后進行低保真原型的繪制及PRD編寫4.1.2產(chǎn)品設(shè)計及確認4.1.2.1概述產(chǎn)品經(jīng)理依據(jù)需求概要設(shè)計（業(yè)務(wù)流程圖+功能架構(gòu)圖+工作流狀態(tài)定義）向需求方再次確認需求內(nèi)容并闡述對應(yīng)的解決方案。4.1.2.2注意事項信息在表述、理解過程中容易失真，需求review則是盡可能避免信息失真。受限于產(chǎn)品能力，或者需求復(fù)雜度高，需要輸出系統(tǒng)級解決方案，“再確認”步驟必不可少。原型設(shè)計之后，進行評審，邀請評審的相關(guān)人員，中間可能會經(jīng)歷幾次調(diào)整。具體邀請人這部分看具體公司，一般而言除產(chǎn)品及業(yè)務(wù)團隊，研發(fā)介入越早越好，能夠?qū)Σ糠止δ艿膶崿F(xiàn)進行評估，產(chǎn)品在做原型設(shè)計的時候，也需要對相關(guān)功能進行調(diào)研，不能憑空想象。4.1.2.3輸出內(nèi)容完善低保真原型、完善PRD文檔；修正業(yè)務(wù)流程圖、功能架構(gòu)圖和工作流狀態(tài)定義等需求概要內(nèi)容。4.1.3視覺設(shè)計及評審原型設(shè)計評審?fù)ㄟ^，則移交資料給UI設(shè)計師并著手繪制高保真；UI設(shè)計師（如果有交互設(shè)計則相互配合，如果沒有，產(chǎn)品也需要涉及交互設(shè)計）根據(jù)原型出設(shè)計圖，UI設(shè)計師在產(chǎn)品原型評審階段也需要介入。UI設(shè)計師設(shè)計完成之后進行評審，評審?fù)ㄟ^，則移交資料給研發(fā)團隊。有些團隊產(chǎn)品經(jīng)理要承擔項目的職責，則需要和研發(fā)人員共同制定開發(fā)進度計劃。4.2產(chǎn)品原型設(shè)計4.2.1制定產(chǎn)品原型設(shè)計規(guī)范的目的及意義目的：產(chǎn)品原型的規(guī)范化，目的是清楚表達產(chǎn)品設(shè)計理念和功能交互及執(zhí)行邏輯，提高產(chǎn)品、研發(fā)、UI及業(yè)務(wù)部門之間的溝通效率，避免信息不對稱和信息傳達的遺漏和缺失而導(dǎo)致的整個項目進度延期問題。1）讓開發(fā)和設(shè)計團隊提高設(shè)計開發(fā)質(zhì)量及工作效率。2）統(tǒng)一設(shè)計規(guī)則，降低各方溝通成本。3）進行模塊式的設(shè)計，降低開發(fā)成本和減少開發(fā)時間，加快產(chǎn)品迭代上線的速度。4)改善交互設(shè)計的水平，提升用戶的使用體驗。對于個人來說：規(guī)范性產(chǎn)品原型繪制能夠提高個人的職業(yè)水平，標準，統(tǒng)一性，團隊內(nèi)部及協(xié)作單位的溝通成本也會降低，這能減少扯皮、反復(fù)溝通等問題，將更多時間放在產(chǎn)品的思考上，同時避免不必要的糾紛。4.2.2原型保真度比較4.2.2.1評價維度一般有五個維度來測量一個原型的真實（保真）程度。a、視覺精煉層次原型與最終產(chǎn)品看上去有多相似？一個低保真的原型也許就是一個手繪的草稿，而一個高保真原型就會是精確到像素，看上去和真實的產(chǎn)品沒什么區(qū)別。b、功能的廣度原型能夠包含多少的功能？一個低保真的原型聚焦于那些最重要的任務(wù)，而高保真原型會有更細節(jié)的任務(wù)c、功能的深度每一個功能能夠被多大程度地制作成原型？一個低保真的原型可以在頁面和頁面之間跳轉(zhuǎn)，并在已有典型數(shù)據(jù)的情況下，告訴你大概的用戶流程。一個高保真的原型可以讓你輸入數(shù)據(jù)，知道那些在進行不同的輸入時影響到輸出的區(qū)分。d、交互的豐富性原型中會有多少的交互？低保真原型也許會相當簡單，在用戶使用時沒有任何的反饋信息。高保真原型將會考慮動畫效果，表單驗證，和所有用戶與產(chǎn)品直接的細節(jié)交互。e、數(shù)據(jù)模型的豐富性你的原型中應(yīng)用的數(shù)據(jù)有多豐富？低保真原型使用的是有限的，典型的數(shù)據(jù)設(shè)置，顯示最常見的用例。高保真原型會包括邊緣的情況，比如非常長的用戶名（應(yīng)該減少用戶名的長度），無數(shù)據(jù)（提供默認人物頭像），第一次使用（使用空白狀態(tài)），或者極端大的數(shù)據(jù)量（使用翻頁或者過濾）。產(chǎn)品原型設(shè)計根據(jù)還原度，也就是與最終成本的逼真度，分為低保真、中保真，高保真原型。4.2.2.2保真度

a、低保真原型表現(xiàn)軟件的重點功能和基本交互過程，使用簡易的線框進行處理，。好處是：制作成本低，速度快，修改也方便，在功能簡單及團隊溝通順暢時可以使用b、

中度保真原型中度保真的產(chǎn)品添加了更多細節(jié)，對軟件的交互進行了更細致的設(shè)計，比如照片處有對應(yīng)內(nèi)容照片，選項卡有具體內(nèi)容，按鈕顏色做了區(qū)分，有動效模擬。在大部分情況下，中度保真原型已經(jīng)足夠，既表現(xiàn)了軟件的功能特性和交互過程，界面有一定的細節(jié)，而且使用者已經(jīng)能完整體驗到最終的產(chǎn)品，可以驗證產(chǎn)品的可行性，確保了不會在后面的開發(fā)過程中發(fā)現(xiàn)重大失誤。缺點是花費時間會多一些。c.

高保真原型幾乎完全按照最終產(chǎn)品來制作的原型，細節(jié)豐富，包括了產(chǎn)品的所有功能以及詳細的交互細節(jié)。制作高保真原型可以顯著降低溝通成本，原型更精準和精美。但是，保真度越高就意味著需要花更多的時間和開發(fā)精力，而且一旦有修改也會更加耗費時間。d、各類保真度優(yōu)劣總結(jié)低保真原型中保真原型高保真原型側(cè)重點核心功能與產(chǎn)品框架具體功能流程及交互視覺呈現(xiàn)優(yōu)點快速易修改適中的原型投入成本；較清晰的細節(jié)細節(jié)完善，溝通成本低缺點缺乏細節(jié)，溝通成本高仍缺乏一些細節(jié)，有一定的修改成本修改成本極高，容易分散精力4.3主流設(shè)計工具Axure：保密性更強，功能更強大，但是在線協(xié)作稍微差一點點。Xmind：繪制功能結(jié)構(gòu)圖（主要）；Visio：繪制用戶使用流程、系統(tǒng)業(yè)務(wù)流程、功能架構(gòu)等；Word：開發(fā)周期允許時撰寫PRD；Excel：項目時間計劃管理、項目會議紀要輸出；4.4原型大綱一個完整項目的產(chǎn)品原型需要有“大綱”，包含內(nèi)容如下：4.4.1產(chǎn)品的版本概況a、

版本記錄：需明確記錄原型的增刪改內(nèi)容及日期序號修訂時間版本號修訂內(nèi)容類型（新增/修改）修訂人備注12022.8.16V1.1.1登錄注冊修改XX增加第三方授權(quán)2b、功能點列表：列出該原型圖的功能點，明確開發(fā)任務(wù)及優(yōu)先級。對于分期開發(fā)，但原型已經(jīng)出完的，標注不同功能開發(fā)的階段，“1期”、“2期”等。模塊功能子功能描述備注優(yōu)先級首頁篩選查找熱門搜索1、系統(tǒng)設(shè)置的熱門搜索詞，可在后臺進行設(shè)置4.4.2功能結(jié)構(gòu)圖a、使用xmind繪制，讓開發(fā)人員了解整個功能框架、信息架構(gòu)，利于估算開發(fā)時間。b、

功能結(jié)構(gòu)圖中使用的功能及頁面名稱要和“功能清單列表”保持一致，示例：4.5界面原型及邏輯說明4.5.1原型界面設(shè)計在繪制產(chǎn)品原型時，按思維導(dǎo)圖的產(chǎn)品規(guī)劃，先搭框架，制作主頁面菜單，菜單支持多個級別，各頁面的層級關(guān)系需要明確，但一般不要超過3級到4級，級數(shù)過多則意味著用戶的使用層級深。設(shè)置母版，對于產(chǎn)品中的通用性功能、模塊、建立統(tǒng)一的母版組建，為后期原型繪制提高便利性，如統(tǒng)一調(diào)用母版，統(tǒng)一修改母版。4.5.2邏輯交互說明包含數(shù)據(jù)邏輯和操作交互，主要是面向開發(fā)人員和UI設(shè)計人員闡述。描述要有利于功能邏輯的實現(xiàn)”，比如說，以下兩種方式的準確性i.

點擊賬單結(jié)算按鈕，跳轉(zhuǎn)到賬單支付頁面。ii.

點擊賬單結(jié)算按鈕，需要判斷是否選中賬單條目，所選中賬單是否產(chǎn)生滯納金a、如果沒有選中賬單，點擊之后則當頁彈窗提醒“您尚未選中待支付賬單”，b、如果有選中賬單，則跳轉(zhuǎn)賬單支付頁面（對于不同情況下的點擊效果，需要做多個按鈕進行不同跳轉(zhuǎn)，），可進一步說明不同跳轉(zhuǎn)的切換效果，比如是左右滑動還是直接跳轉(zhuǎn)等。對比以上兩種方式，則第二種更明確，這也會減少溝通成本。4.5.3設(shè)計說明如果對設(shè)計有特殊要求的也需要做說明，比如支付的一般用明亮飽和的色調(diào)，專業(yè)性則一般采取藍色，或者有設(shè)計可供參考的，配色等方面。4.6交互用例給主要交互控件設(shè)置交互用例，完善的交互能夠幫助開發(fā)清晰的理解需求。4.7原型詳細規(guī)范4.7.1頁面層級樹及每個頁面命名的規(guī)則a、在頁面層級樹的第一個頂級菜單設(shè)置并填寫【產(chǎn)品名稱】，下面可以添加更多層級；b、版本號——采用子頁面進行管理，頁面名稱命名：版本號+【版本編號】如版本號V1.1.1；c、修訂記錄——采用子頁面進行管理，管理當前版本產(chǎn)品原型設(shè)計的修訂記錄——文章前部分已經(jīng)做了說明；d、功能清單說明——采用子頁面進行管理，使用表格說明本次產(chǎn)品原型中需求的主要內(nèi)容和功能；e、正式原型部分：i、產(chǎn)品頁面的層級，最高一般不超過4層；ii、產(chǎn)品模塊，命名規(guī)則為“【序號】+【產(chǎn)品模塊名稱】”；iii、產(chǎn)品功能級頁面，命名規(guī)則為“【序號】+【產(chǎn)品頁面名稱】”；命名規(guī)則與文章章節(jié)目錄類似4.7.2母版制作與引用復(fù)用元件/組件，必須使用母版設(shè)計，然后再統(tǒng)一添加到頁面上。在添加母版時，產(chǎn)品的背景，要求使用“位置鎖定”，防止在原型繪制的過程中，背景變動頻繁調(diào)整的情況；3.7.2.1頁面母版的名稱可自定義設(shè)置：“序號+自定義名稱”；3.7.2.2全局性的母版和局部使用母版，需要在命名規(guī)則上做區(qū)分，3.7.2.3盡可能將眾多頁面都會使用到的標題（如小程序的頭部）、元件（如日歷）以及交互組件放置在母版中；4.7.3頁面位置和尺寸規(guī)范4.7.3.1

PC默認尺寸為1280*960，APP/H5/小程序默認尺寸選擇375HYPERLINK*6HYPERLINK67，并在之后的原型沿用；4.7.3.2APP的框架設(shè)計不區(qū)分Android與IOS，僅在交互用例的設(shè)計上進行區(qū)分；4.8流程制作規(guī)范“流程頁面”設(shè)計并制作用戶對本功能的使用流程，使用泳道流程圖，一般而言是二維方式，橫軸為角色，縱軸為流程進展，在流程旁邊，給出必要的文字備注說明，對流程進行進一步的闡述。示例：4.9頁面說明4.9.1交互設(shè)計及說明需按照產(chǎn)品原型規(guī)范要求，使產(chǎn)品原型上的所有功能板塊能夠準備模擬用戶的操作情景，保證所有功能的動態(tài)面板交互、點擊效果、頁面跳轉(zhuǎn)鏈接等交互效果準確并正確。并且為準確描述頁面的交互效果需求?？稍陧撁媾赃呍黾印包c擊交互效果需求”的說明，來描述頁面中每一個功能的操作交互需求。示例：4.9.2頁面功能及邏輯的標注為了方便開發(fā)人員查看和理解，在產(chǎn)品原型中對功能的實現(xiàn)邏輯或使用的限制條件等進行說明。對頁面的功能點進行編號，在對應(yīng)編號進行說明備注范例：4.9.3頁面流程圖項目整體頁面之間的交互流向邏輯，可以設(shè)置/生成一個工作流，可以點擊進入之后，選擇需要展示流向的頁面，之后可以選擇：4.9.3.1每個頁面與頁面整體交互的方式；4.9.3.2所有控件交互的流向兩種方式進行自動生成。另一種頁面流程交互流如下，這是按照業(yè)務(wù)流程進行分拆，按一個業(yè)務(wù)流程從頭到尾，會走過哪些頁面。下圖即為示例，為訂單相關(guān)的流程交互，從最開始的進入APP或網(wǎng)站首頁》瀏覽商品》搜索》下單等，一直到最后支付成功，中間有異常流程也需要做說明。五、PRD文檔撰寫5.1寫PRD的目的產(chǎn)品需求文檔，即ProductRequirementDocumen，PRD的主要使用對象有：開發(fā)、測試、項目經(jīng)理、設(shè)計師、運營及其他業(yè)務(wù)人員。開發(fā)可以根據(jù)PRD獲知整個產(chǎn)品的邏輯；測試可以根據(jù)PRD建用例；項目經(jīng)理可以根據(jù)PRD拆分工作包，并分配開發(fā)人員；設(shè)計師可以通過PRD來設(shè)計交互細節(jié)。PRD文檔是將產(chǎn)品項目由“概念化”階段推進到“圖紙化”，將需求落實到可開發(fā)的。PRD文檔在產(chǎn)品項目中是一個“承上啟下”的作用，“向上”是對MRD內(nèi)容的繼承和發(fā)展，“向下”是要把MRD中的內(nèi)容技術(shù)化，側(cè)重的是對產(chǎn)品產(chǎn)品功能和性能（即“產(chǎn)品需求”）的說明，相對于MRD中的同樣內(nèi)容，要更加詳細，并進行量化。5.2PRD撰寫的前提條件進行了需求收集與分析，構(gòu)建了系統(tǒng)架構(gòu)，繪制了功能結(jié)構(gòu)圖、信息結(jié)構(gòu)圖、產(chǎn)品結(jié)構(gòu)圖，2大流程圖（業(yè)務(wù)、頁面流程圖）以及所有頁面的原型稿、交互稿。完成這些部分之后，對以上部分進行有機的整合，撰寫PRD文檔。5.3PRD內(nèi)容5.3.1文檔編寫記錄記錄文檔創(chuàng)建，修改的情況，文檔的編寫狀態(tài)，編寫人，示例：日期名稱版本狀態(tài)簽名2022.07.01建檔1.04XX2022.08.01修改1.11XX備注：狀態(tài)表示為：1.新建2.完成未審3.完成已審4.完成歸檔5.3.2文檔修訂記錄記錄每次修改的修改內(nèi)容，更詳細的進行記錄每次修改的情況，對修改情況做概要性的描述，使查看人能夠清晰的感知修訂情況，示例：編號版本描述（包括：日期，變更圖、表、段落號、標題或簡單描述）修改類型A/M/D1v1.02備注：修改類型表示為：A.增加M.修改D.刪除5.3.3目錄根據(jù)PRD文檔的章節(jié)自動生成生成，如果有變化進行更新整個目錄的更新即可，示例：5.3.4概述a.背景介紹：簡要說明產(chǎn)品/項目需求產(chǎn)生的背景，要達到的目的和需要實現(xiàn)的功能示例：通過建立招商加盟平臺的商戶管理系統(tǒng)，商戶（招商公司）能夠在商戶后臺直接發(fā)布項目、文章，進行自有項目的推廣。商戶（招商公司）能夠在商戶后臺支付會員、廣告宣傳、站外文章發(fā)布等增值服務(wù)費用?？梢越哟齺碜稍冊L問的用戶，并進行交談，記錄用戶線索，形成用戶檔案。商戶管理系統(tǒng)同時能為商戶提供數(shù)據(jù)分析功能，對在該商家的訪問、咨詢、成交用戶進行分析，對商戶發(fā)布文章的宣傳效果，廣告投放效果進行綜合分析，為商家的進一步業(yè)務(wù)開拓提供決策依據(jù)。b.涉及范圍：描述本次需求，主要涉及到公司內(nèi)部的哪些平臺，并簡要描述各平臺應(yīng)該做哪些事情示例：涉及范圍描述XX招商加盟PC端增加企業(yè)管理系統(tǒng)的相關(guān)改造（廣告投放、文章發(fā)布排名、咨詢接口）c.閱讀對象描述本文檔的的閱讀對象有哪些，一般包含：公司業(yè)務(wù)總負責人、各平級部門經(jīng)理、產(chǎn)品經(jīng)理、UI設(shè)計師、研發(fā)工程師、測試工程師等與本項目相關(guān)的所有人員。d.名詞解釋對項目或者行業(yè)的專業(yè)詞匯的解釋，對于較為獨特的行業(yè)，或者專有名詞的，復(fù)雜的系統(tǒng)，一定要進行名詞解釋。名詞解釋的目的：所有成員中達成認知的一致，防止一個事物多種命名的情況產(chǎn)生，提高信息的傳遞效率，消除歧義。名詞解釋普通用戶所有使用XX平臺內(nèi)容搜索和咨詢的外部用戶商戶在平臺注冊認證，發(fā)布招商項目，購買服務(wù)，進行項目推廣的招商公司客服人員主要負責處理前端普通用戶咨詢服務(wù)的用戶5.3.5結(jié)構(gòu)圖產(chǎn)品相關(guān)結(jié)構(gòu)圖一般包含3種：功能結(jié)構(gòu)圖、信息結(jié)構(gòu)圖、產(chǎn)品結(jié)構(gòu)圖a.功能結(jié)構(gòu)圖定義：

功能結(jié)構(gòu)圖就是以功能模塊為類別，介紹模塊下其各功能組成的圖。作用：

產(chǎn)品設(shè)計時，輔助思路梳理，避免功能概念模糊、缺失。繪制功能結(jié)構(gòu)時，盡量避免信息結(jié)構(gòu)要素出現(xiàn)的可能性，形容一個功能點時建議多采用“動詞+名詞”的語言描述形式。示例：b.信息結(jié)構(gòu)圖定義：指脫離產(chǎn)品的實際頁面，將產(chǎn)品的數(shù)據(jù)抽象出來，組合分類的圖表。作用：幫助PM梳理復(fù)雜內(nèi)容的信息組成，避免信息內(nèi)容在展示過程中出現(xiàn)遺漏、混亂、重復(fù)；作為開發(fā)工程師建立數(shù)據(jù)庫的參考依據(jù)；信息結(jié)構(gòu)圖的繪制通常晚于功能結(jié)構(gòu)圖，往往是在產(chǎn)品設(shè)計階段的概念化過程中，在產(chǎn)品功能框架已確定、功能結(jié)構(gòu)已完善好的情況下才對產(chǎn)品信息結(jié)構(gòu)進行分析設(shè)計。示例：c.產(chǎn)品結(jié)構(gòu)圖定義：

產(chǎn)品結(jié)構(gòu)圖是綜合展示產(chǎn)品信息和功能邏輯的圖表

。可以理解為產(chǎn)品結(jié)構(gòu)圖是對產(chǎn)品原型的簡化表達，產(chǎn)品結(jié)構(gòu)圖就是通過信息架構(gòu)設(shè)計，將功能和信息以一種合理自然的邏輯，把功能結(jié)構(gòu)圖和信息結(jié)構(gòu)圖中的內(nèi)容放入產(chǎn)品中的每一個頁面的結(jié)果。示例：一般而言，直接采用產(chǎn)品結(jié)構(gòu)圖，對于概要描述，根據(jù)情況使用功能結(jié)構(gòu)圖，使用xmind制作產(chǎn)品功能結(jié)構(gòu)圖，并對產(chǎn)品功能進行簡要描述。d.產(chǎn)品功能概要功能等級基本為三級+描述備注（模塊、功能、子功能或者其它叫法），根據(jù)功能結(jié)構(gòu)圖而來，控制好級別，并進一步描述功能的內(nèi)容和作用，對功能排列優(yōu)先級，功能是否要進行分期開發(fā)，如果需要分期開發(fā)，則對應(yīng)的開發(fā)周期需要注明，是否有另外的說明和備注，如果有則可以添加備注，盡量不要使用Excel中批注，很容易遺漏。示例：5.3.6核心業(yè)務(wù)流程對于本次需求中最核心的業(yè)務(wù)，采用泳道+文字描述的方式，對核心業(yè)務(wù)的階段、步驟以及異常情況及判斷進行描述。在畫業(yè)務(wù)流程之前，要深入了解核心業(yè)務(wù)，與相關(guān)業(yè)務(wù)人員進行深入的溝通，確認。確定泳道（即任務(wù)），確定產(chǎn)品階段，思考業(yè)務(wù)在各個階段的形態(tài)，如果業(yè)務(wù)流程涉及多個部門的，需要共同進行溝通探討，并可對部分流程進行優(yōu)化。思考清楚后開始畫業(yè)務(wù)流程圖，在畫的過程中也在頭腦中進行梳理，盡可能的不遺漏任何的分支或異常情況。可以采用的思考方法：1)MECE——是MutuallyExclusiveCollectivelyExhaustive，中文意思是“相互獨立，完全窮盡”。也就是對于一個重大的議題，能夠做到不重疊、不遺漏的分類，而且能夠藉此有效把握問題的核心，并解決問題的方法，也是找出異常流程的重要方法之一；2)5W1H分析——是對選定的事項、流程或操作，都要從原因（何因Why）、對象（何事What）、地點（何地Where）、時間（何時When）、人員（何人Who）、方法（何法How）等六個方面提出問題進行思考。可以尋找流程的改善方向，構(gòu)思新的工作方法，以取代現(xiàn)行的工作流程方法；3)運用ECRS四原則——即取消、合并、重組和簡化的原則，可以幫助人們找到更好的效能和更佳的工序方法）。業(yè)務(wù)流程圖并不是一成不變的，在多次討論會后中可能會有調(diào)整和變動。但每次調(diào)整或變動都需要進行明確，保證流程的清晰，不要存在核心流程的模糊死角。如果核心流程不清晰，則子流程以及后續(xù)很多工作都會導(dǎo)致極大的變動性，也會影響整體項目的進度，特別是在研發(fā)已經(jīng)介入的情況，如果流程還存在不清晰的地方，開發(fā)工作也會反復(fù)。5.6.1核心業(yè)務(wù)流程跨職能的泳道圖——泳道圖中需將業(yè)務(wù)數(shù)據(jù)流所涉及的所有業(yè)務(wù)平臺加入到泳道中，同時需區(qū)分正常流程和異常流程。示例：業(yè)務(wù)流程描述：用文字描述上述流程圖中的所有流程，用以作為流程的補充說明，注意，流程中的每一步需以單獨的數(shù)字序號進行描述。示例：優(yōu)惠券發(fā)放、使用、核銷流程（1）優(yōu)惠活動創(chuàng)建優(yōu)惠活動由平臺設(shè)置。平臺創(chuàng)建優(yōu)惠活動，費用由平臺、設(shè)備提供方、或其它方承擔，具體承擔方由運營進行設(shè)置之前與各方溝通確認，并在設(shè)置的之時進行確定。此處活動的設(shè)置，主要設(shè)置基本信息，如活動的優(yōu)惠類型（滿減、立減、折扣類型可適當減少，比如第一期只用滿減），針對什么商品類別或是單個商品，針對區(qū)域店鋪或者單個店鋪。（2）優(yōu)惠券發(fā)放從優(yōu)惠活動中選擇活動，設(shè)置優(yōu)惠投放方案，如發(fā)放時間，有效期，針對門店，針對用戶（新用戶or老用戶），自動發(fā)放還是用戶手動領(lǐng)取設(shè)置投放方案后是否立即啟用，如果啟用，則在設(shè)置的投放時間向用戶投放不支持正在投放的優(yōu)惠券臨時修改，只能停止作廢，后臺作廢之后，用戶端不管是否還在有效期內(nèi)，均不能領(lǐng)取及使用正在使用的優(yōu)惠券，優(yōu)惠活動原始模板不能更改，如要改變，需單獨創(chuàng)建。（3）領(lǐng)取使用如果是系統(tǒng)自動發(fā)放的優(yōu)惠券，用戶不需要單獨進行領(lǐng)取，優(yōu)惠券自動領(lǐng)取，在用戶端優(yōu)惠券中心可以看到如果需要用戶領(lǐng)取的，用戶可在領(lǐng)券中心進行領(lǐng)取用戶在領(lǐng)取優(yōu)惠券之后，升降柜的優(yōu)惠券使用可讓用戶自己選擇，雙開門柜為拿貨之后自動結(jié)算，則自動選擇優(yōu)惠券使用，以優(yōu)惠最大的券為準。（4）核銷結(jié)算用戶使用優(yōu)惠券購買商品之后，如果用戶發(fā)生退款，則優(yōu)惠券不退會，且不可再使用（即優(yōu)惠券只能使用一次）如果訂單中包含多個商品，均有使用優(yōu)惠券，如果退款退貨只退其中一部分，則優(yōu)惠券也只退其中一部分，按比例進行攤薄進入清分結(jié)算的訂單，有使用優(yōu)惠券時，則在清分中按實際支付進行清分，并標注使用優(yōu)惠券優(yōu)惠券不進入清分，優(yōu)惠券只進行費用承擔，但使用該優(yōu)惠券的訂單結(jié)算完成后，該筆優(yōu)惠券的費用承擔狀態(tài)為完成。備注：優(yōu)惠券采用創(chuàng)建與發(fā)放分開的形式，創(chuàng)建為創(chuàng)建優(yōu)惠活動，不配置具體的發(fā)送方案用戶領(lǐng)取優(yōu)惠券后，在購買商品時，進行金額的抵扣（用戶級別不一，則抵扣金額和券的類別有差異）系統(tǒng)異常處理流程：主要描述跨系統(tǒng)、角色間的業(yè)務(wù)流轉(zhuǎn)方面的異常處理邏輯。還有其它的一些通用異常處理：1)獲取地理位置權(quán)限失敗2)發(fā)送通知權(quán)限獲取失敗3)網(wǎng)絡(luò)情況優(yōu)惠券流程示例：1)優(yōu)惠券發(fā)放錯誤，停止活動，則已發(fā)放的優(yōu)惠券用戶不能再使用，優(yōu)惠券失效2)優(yōu)惠券過期失效，不能再使用，并標記已過期失效，并給予提示3)退款訂單中已使用的優(yōu)惠券，不再恢復(fù)到可使用狀態(tài)（即便未過期），直接作廢4)其它5.3.7產(chǎn)品界面級功能及交互需求說明根據(jù)產(chǎn)品原型上的頁面結(jié)構(gòu)，構(gòu)建功能需求說明樹。示例：5.3.7.1功能一（界面）粘貼產(chǎn)品功能界面，并對產(chǎn)品功能界面的功能、交互進行描述，示例：菜單招商管理-》合同管理-》合同創(chuàng)建-基本信息功能創(chuàng)建合同用戶場景當客戶有意向簽訂時，創(chuàng)建合同，確認合同費用金額及履約條款優(yōu)先級高前置條件已創(chuàng)建房源；已創(chuàng)建潛客后置條件-字段說明1.租客：從潛客列表中搜索2.租客聯(lián)系人：選擇租客后帶出，可修改3.租客聯(lián)系人電話：選擇聯(lián)系人后帶出，可修改頁面交互租客信息1.搜索租客時，輸入關(guān)鍵字，遠程搜索；選擇租客后，填入客戶聯(lián)系人列表，可編輯；客戶聯(lián)系人選擇后，填入聯(lián)系電話，可編輯異常流程使用流程：以任務(wù)流方式，描述用戶在完成該功能時的步驟、業(yè)務(wù)邏輯。示例（登錄）：菜單：頁面層級位置功能：模塊作用用戶場景：用戶在什么時間、哪里，做什么事情要達到什么目的的描述優(yōu)先級：決定HYPERLINK各模塊接受系統(tǒng)資源的優(yōu)先等級參數(shù)前置條件：發(fā)生這個用例的前提條件，滿足條件才可以發(fā)生這個用例后置條件：發(fā)生這個用例之后的結(jié)果，會產(chǎn)生的影響字段說明：對列表記錄字段進行解釋說明頁面交互：各頁面間的交互，互動鏈接關(guān)系，以一個功能所涉及的相關(guān)頁面為示例異常處理：描述業(yè)務(wù)發(fā)起過程中的異常處理流程。1.手機號做位數(shù)及類型限制，位數(shù)只能11位，只能是數(shù)字。2.密碼由字母+數(shù)字構(gòu)成，字母區(qū)分大小寫，密碼的組合方式為“大寫字母or小寫字母+數(shù)字”，如果用戶輸入字符與此規(guī)則不匹配，則進行提醒用戶按規(guī)范輸入3.如果用戶未輸入賬號密碼點擊登錄，手機賬號：提示“手機賬號未填寫”；密碼：提示“密碼未填寫”；賬號與密碼不匹配時，4.輸入的賬號未進行注冊，提交檢測在后臺無記錄，提示：用戶賬號不存在5.用戶輸入的賬號與密碼不匹配，則提示：用戶名或密碼輸入錯誤5.3.8安全需求描述項目需要遵循的安全標準及需要進行安全驗證等。驗證包括手機短信、身份信息、銀行信息，信用信息（芝麻信用）所有這些均有第三方接口進行驗證，支付費用即可進行驗證。5.3.9數(shù)據(jù)監(jiān)測分析5.3.9.1數(shù)據(jù)監(jiān)測采用數(shù)據(jù)埋點、數(shù)據(jù)采集等方法統(tǒng)計用戶行為數(shù)據(jù)。第一種方式：自己開發(fā)——優(yōu)點是保密性高，所有數(shù)據(jù)都在自己的平臺中，但是很費時間，要想做的好，對技術(shù)也有一定要求第二種方式：使用第三方接口——比如友盟、神策、growio、百度等均提供接口，能快速的解決問題，另外growio，百度都有無埋點方式，就是不需要一個個數(shù)據(jù)點進行單獨的埋點，而是監(jiān)測所有有數(shù)據(jù)傳輸，操作行為的點，接入sdk之后，可以自主選擇數(shù)據(jù)點進行分析。這種方式，不會存在遺漏，靈活度也非常高。5.3.9.2數(shù)據(jù)分析第一種方式也是完全自主開發(fā)，在早期的時候，數(shù)據(jù)量不大的時候，可以直接將數(shù)據(jù)導(dǎo)出進行Excel表的分析第二種方式是接入第三方接口，比如finebi、powerbi、DataFocus、tableau等，在選擇第三方的時候要注意，是否滿足企業(yè)要求（當下及后期），是否可以進行私有化部署，后期擴展的靈活性，是否簡單易用。5.3.10系統(tǒng)日志需求對系統(tǒng)處理業(yè)務(wù)的操作記錄或者邏輯記錄在日志中，便于后期查找、追溯。5.3.1其它產(chǎn)品需求5.3.11.1性能需求明確產(chǎn)品的性能，知道產(chǎn)品性能上限，隨著業(yè)務(wù)的發(fā)展，清楚改善節(jié)點。在早期考慮綜合成本的情況并滿足業(yè)務(wù)需求的情況下，可以對性能做一定的妥協(xié)。并發(fā)量：簡單的可以說，同一秒的登錄量，同時在線，訂單并發(fā)量最高可以允許多少。比如客服系統(tǒng)，允許同時對話200，也就是允許同時存在200對話通道。圖片加載：圖片加載的時間，頁面跳轉(zhuǎn)切換的時間，在不同網(wǎng)速下，允許的時長（不同網(wǎng)絡(luò)情況下，信號有強弱，可能根本4G、5G信號，或者用戶的卡是3G）5.3.11.2兼容性、適配需求PC——兼容目前主流的瀏覽器，比如IE8、及Firefox3.5、safari、chrome等主流瀏覽器的主流版本，將相關(guān)版本進行羅列，同時考慮H5的跨設(shè)備適用性問題機型——通過各種渠道（talkingdata，友盟）查目前的主流機型，市場占比，根據(jù)公司情況，選擇占比靠前的測試機型，或者采用第三方測試平臺（testin，testbird）5.3.12相關(guān)文檔A、原型地址B、消息通知模板用戶消息通知序號模塊具體功能消息接收人通知內(nèi)容形式1登錄注冊注冊用戶【XX】已經(jīng)注冊成為平臺的用戶短信2留言回復(fù)平臺回復(fù)留言用戶【XX】您預(yù)約的留言反饋已得到回復(fù)，回復(fù)內(nèi)容如下：XX，感謝您對我們的支持！消息通知C、其它商標，軟著，域名、服務(wù)器、支付平臺、消息接口、其它需要準備各類平臺賬號及及截止時間節(jié)點，部分事項可以并行，部分事項有嚴格的先后順序，在進行計劃安排時，需要作出區(qū)分，盡可能縮短時間，不要出現(xiàn)絕大部分人等一個人的情況出現(xiàn)。5.4產(chǎn)品向各方需求文檔內(nèi)容5.4.1給設(shè)計師文檔思維導(dǎo)圖、流程圖、功能清單、原型圖（含交互）。5.4.2給研發(fā)文檔思維導(dǎo)圖、功能清單、流程圖、原型圖、UI設(shè)計圖、PRD文檔、數(shù)據(jù)埋點文檔5.4.3給運營文檔思維導(dǎo)圖、流程圖、功能清單、PRD文檔、產(chǎn)品使用說明書，上線資料準備清單（上線前需要準備的比如需要錄入的商家信息）。六、版本命名、驗收規(guī)范、發(fā)版管理6.1產(chǎn)品版本命名規(guī)則6.1.1版本命名規(guī)范軟件版本號有四部分組成：第一部分為主版本號；第二部分為次版本號；第三部分為修訂版本號；第四部分為日期版本號加希臘字母版本號，希臘字母版本號共有五種，分別為base、alpha、beta

、RC

、

release。6.1.2版本號修改規(guī)則（1）主版本號：當功能模塊有較大的變動，比如增加模塊或是整體架構(gòu)發(fā)生變化。此版本

號由項目經(jīng)理決定是否修改。（2）次版本號：相對于主版本號而言，次版本號的升級對應(yīng)的只是局部的變動，但該局部

的變動造成程序和以前版本不能兼容，或者對該程序以前的協(xié)作關(guān)系產(chǎn)生了破壞，或者是功能上有大的改進或增強。此版本號由項目決定是否修改。（3）修訂版本號：一般是Bug

的修復(fù)或是一些小的變動或是一些功能的擴充，要經(jīng)常發(fā)布

修訂版，修復(fù)一個嚴重

Bug

即可發(fā)布一個修訂版。此版本號由項目經(jīng)理決定是否修改。（4）日期版本號：用于記錄修改項目的當前日期，每天對項目的修改都需要更改日期版本

號。此版本號由開發(fā)人員決定是否修改。（5）希臘字母版本號：此版本號用于標注當前版本的軟件處于哪個開發(fā)階段，當軟件進入到另一個階段時需要修改此版本號。此版本號由項目經(jīng)理決定是否修改。6.1.3版本階段說明Base：此版本表示該軟件僅僅是一個假頁面鏈接，通常包括所有的功能和頁面布局，但是頁面中的功能都沒有做完整的實現(xiàn)，只是做為整體網(wǎng)站的一個基礎(chǔ)架構(gòu)。Alpha

：軟件的初級版本，表示該軟件在此階段以實現(xiàn)軟件功能為主，通常只在軟件開發(fā)者

內(nèi)部交流，一般而言，該版本軟件的Bug較多，需要繼續(xù)修改，是測試版本。測試

人員提交Bug經(jīng)開發(fā)人員修改確認之后，發(fā)布到測試網(wǎng)址讓測試人員測試，此時可將軟件版本標注為alpha版。Beta

：該版本相對于Alpha

版已經(jīng)有了很大的進步，消除了嚴重錯誤，但還需要經(jīng)過多次

測試來進一步消除，此版本主要的修改對象是軟件的UI。修改的的Bug

經(jīng)測試人

員測試確認后可發(fā)布到外網(wǎng)上，此時可將軟件版本標注為

beta版。RC

：該版本已經(jīng)相當成熟了，基本上不存在導(dǎo)致錯誤的Bug，與即將發(fā)行的正式版本相差無幾。Release：該版本意味“最終版本”，在前面版本的一系列測試版之后，終歸會有一個正式的版本，是最終交付用戶使用的一個版本。該版本有時也稱標準版。6.1.4版本發(fā)布周期（1）非緊急情況：按照一般發(fā)包管理制度執(zhí)行（2）緊急情況：如