產(chǎn)品設(shè)計與需求分析

產(chǎn)品與需求本文檔共53頁；當(dāng)前第1頁；編輯于星期一\9點19分目錄由一個產(chǎn)品UI說開去由產(chǎn)品到需求溝通業(yè)務(wù)分析與表達(dá)12345技術(shù)開發(fā)、測試……產(chǎn)品需求、設(shè)計…博客商業(yè)市場、銷售……6業(yè)務(wù)規(guī)劃需求收集與管理本文檔共53頁；當(dāng)前第2頁；編輯于星期一\9點19分任務(wù)的目的是展示美國的幾個城市在不同月份的平均降水量。UI演進舉例——產(chǎn)品需求確定后的表現(xiàn)差異本文檔共53頁；當(dāng)前第3頁；編輯于星期一\9點19分體驗設(shè)計要點貼心功能功能呈現(xiàn)信息展現(xiàn)交互感受輔助指引本文檔共53頁；當(dāng)前第4頁；編輯于星期一\9點19分用戶體驗場景是核心重視情感需求場景下行為分析業(yè)務(wù)價值抽象本文檔共53頁；當(dāng)前第5頁；編輯于星期一\9點19分目錄由一個產(chǎn)品UI說開去由產(chǎn)品到需求溝通業(yè)務(wù)分析與表達(dá)12345技術(shù)開發(fā)、測試……產(chǎn)品需求、設(shè)計…博客商業(yè)市場、銷售……6業(yè)務(wù)規(guī)劃需求收集與管理本文檔共53頁；當(dāng)前第6頁；編輯于星期一\9點19分目錄需求產(chǎn)品博客用戶產(chǎn)品本文檔共53頁；當(dāng)前第7頁；編輯于星期一\9點19分項目是定制的，個性化的，為了滿足一個或一批特定的客戶需求；而產(chǎn)品是服務(wù)一個用戶群的，通用的。這就意味著，項目要服務(wù)好那個特定的客戶；而產(chǎn)品不能為了個別用戶的需求去定制，必須考慮用有限的資源去滿足更多的、能有更多回報的用戶。產(chǎn)品與項目的區(qū)別項目是相對短期的，較少后續(xù)工作的，可以結(jié)束的（稱為“結(jié)項”）；產(chǎn)品是相對長期的，不存在所謂的“結(jié)束”，只能是“生命周期完結(jié)”。所以不可能有一個已經(jīng)“完成”的產(chǎn)品，只存在不斷完善中的產(chǎn)品，直到這個產(chǎn)品被新產(chǎn)品替代，已經(jīng)沒有存在的價值，它才會“生命周期完結(jié)”。為了避免把產(chǎn)品做成項目的集合體而臃腫不堪，我們需要細(xì)分市場，這時產(chǎn)品可能就要升級為“產(chǎn)品線”，按不同的細(xì)分市場，推出不同的產(chǎn)品。本文檔共53頁；當(dāng)前第8頁；編輯于星期一\9點19分產(chǎn)品團隊PMPDUIUEPM：產(chǎn)品經(jīng)理。一個產(chǎn)品，首先由PM來進行商業(yè)上的規(guī)劃，比如細(xì)分市場、目標(biāo)客戶、主要賣點等等，通常PD已經(jīng)介入這個過程。在這個層面，商業(yè)問題、業(yè)務(wù)邏輯的流暢是思考的焦點。PD：產(chǎn)品設(shè)計師/產(chǎn)品規(guī)劃師/需求分析師。PD側(cè)重于做功能級的設(shè)計，在某個模塊上，PD類似一個小產(chǎn)品經(jīng)理。技術(shù)團隊中的架構(gòu)師/系統(tǒng)分析師/開發(fā)組長會與PD緊密合作，這時候開始考慮技術(shù)可行性，性價比，確定方案。UE：用戶體驗師/交互設(shè)計師/界面設(shè)計師。UE負(fù)責(zé)產(chǎn)品和用戶交互方面的設(shè)計，這方面在技術(shù)部門的配合角色應(yīng)該是前端工程師/客戶端開發(fā)。PD與UE要充分溝通，UE必須要了解商業(yè)層面的內(nèi)容，理解功能的商業(yè)價值。。UI：界面設(shè)計師/視覺設(shè)計師/美工，與UE的界限模糊。到了UI層面，基本是界面的表現(xiàn)，是用戶第一眼看到的效果，比如配色、頁面結(jié)構(gòu)、按鈕形狀、字體字號等等本文檔共53頁；當(dāng)前第9頁；編輯于星期一\9點19分最基本的句式：解決了什么用戶的什么需求？練習(xí)的時候，切忌求多，說一點即可，找到你感覺最貼切的那一種用戶，和他最迫切的那一個需求。主要擴展有如下幾種：產(chǎn)生需求的場合是什么？需求的應(yīng)用場景，時間地點等，要有“故事感”，盡量找一個能讓人會心一笑的。產(chǎn)品的主要功能有哪些？需求和功能的區(qū)別在于，前者是從用戶角度說的，是一種希望，利益點，這時候還沒有產(chǎn)品，后者是從產(chǎn)品屬性上說的。產(chǎn)品定位—規(guī)劃練習(xí)技術(shù)基礎(chǔ)是什么？主要考察產(chǎn)品的實現(xiàn)成本，從而評估性價比，是否值得做。沒有這個產(chǎn)品的時候，用戶是怎么解決問題的？幫助思考，這個產(chǎn)品是否是“不做會死人”的，我們盡量不要做有很多替代方案的產(chǎn)品。競爭對手是什么？這個問題不用局限，盡量展開了想，比上一個問題更廣，可以考慮潛在的競爭對手。順應(yīng)了什么趨勢？好的產(chǎn)品是順勢而為的，滿足未來的某種根本需求是更進一步的基礎(chǔ)，嘗試預(yù)測未來。本文檔共53頁；當(dāng)前第10頁；編輯于星期一\9點19分解決了什么用戶的什么需求？產(chǎn)生需求的場合是什么？產(chǎn)品的主要功能有哪些？技術(shù)基礎(chǔ)是什么？沒有這個產(chǎn)品的時候，用戶是怎么解決問題的？競爭對手是什么？順應(yīng)了什么趨勢？方便面產(chǎn)品本文檔共53頁；當(dāng)前第11頁；編輯于星期一\9點19分3+1思考法：測量產(chǎn)品/項目“靠譜程度”需求是從哪里來的？目標(biāo)客戶是誰？有多少人有這樣的需求？這個需求緊迫嗎？他們的痛是什么？場景是什么？（用產(chǎn)品之前/之后）解決之后在軟件數(shù)據(jù)上會有二次挖掘價值嗎？本文檔共53頁；當(dāng)前第12頁；編輯于星期一\9點19分目錄需求產(chǎn)品博客用戶用戶本文檔共53頁；當(dāng)前第13頁；編輯于星期一\9點19分找到種子用戶受要解決的問題困擾最深的人！愿意配合可以提供很多有價值的信息可以忍受缺陷樂意成為義務(wù)推銷員本文檔共53頁；當(dāng)前第14頁；編輯于星期一\9點19分除了最終用戶外，還有……Stakeholder分析Stakeholder列表：籌碼量分析—優(yōu)先級Stakeholder檔案：籌碼付出—關(guān)注點需求平衡與跟蹤：沖突識別、實現(xiàn)跟蹤123評價者運營者購買者本文檔共53頁；當(dāng)前第15頁；編輯于星期一\9點19分不同層次的用戶，其需求的價值不同業(yè)績差距(問題)項目目標(biāo)Stakeholder操作層要求機會差距(機會)Stakeholder列表Stakeholder關(guān)注點效率質(zhì)量業(yè)務(wù)價值本文檔共53頁；當(dāng)前第16頁；編輯于星期一\9點19分Stakeholder分析影響度興趣度高低低高保持溝通關(guān)鍵玩家盡力滿足最小努力本文檔共53頁；當(dāng)前第17頁；編輯于星期一\9點19分目錄需求產(chǎn)品博客用戶需求本文檔共53頁；當(dāng)前第18頁；編輯于星期一\9點19分產(chǎn)品設(shè)計是端到端的過程，端即用戶，也就是從用戶中來到用戶中去，最最開始的源頭就是“為用戶解決問題，滿足其需求”。產(chǎn)品需求過程三步驟：產(chǎn)品設(shè)計中與需求相關(guān)的部分需求管理需求分析需求采集本文檔共53頁；當(dāng)前第19頁；編輯于星期一\9點19分產(chǎn)品創(chuàng)意源于三新新技術(shù)新人群新業(yè)務(wù)技術(shù)創(chuàng)新帶來的機會新業(yè)務(wù)模式帶來的機會人群特點變化帶來的機會手段特點模式本文檔共53頁；當(dāng)前第20頁；編輯于星期一\9點19分產(chǎn)品靈感源于需求洞察產(chǎn)品現(xiàn)狀預(yù)期預(yù)期現(xiàn)狀預(yù)期現(xiàn)狀預(yù)期現(xiàn)狀預(yù)期現(xiàn)狀問題機會本文檔共53頁；當(dāng)前第21頁；編輯于星期一\9點19分需求的三層次WantNeedWin小張問店老板：你這里有賣沖擊鉆嗎？店主問：您為什么想在墻上打個孔呢？小張答：我想在墻上掛幅畫。店主問：您為什么想在墻上掛幅畫呢？小張答：我下班回家，單身一人太冷清，掛幅畫熱鬧點。店主問：你想用沖擊鉆來解決什么問題呢？小張答：想在墻上打個孔店主答：對不起，我們這沒有沖擊鉆賣，你到別處看看。暴食、貪婪、懶惰、嫉妒、驕傲、淫欲、憤怒本文檔共53頁；當(dāng)前第22頁；編輯于星期一\9點19分意識：需求三要素業(yè)務(wù)背景：花盆種類、擺放位置解決方案：木制的小板凳問題：放花盆木樁什么形狀，釘在什么位置？要幾枚鐵釘，多長多大？板多大、多寬、多厚？本文檔共53頁；當(dāng)前第23頁；編輯于星期一\9點19分意識：需求三要素問題Why業(yè)務(wù)背景Context解決方案

What1、澄清問題（問題表象+原因+范圍與限定）2、了解業(yè)務(wù)背景（業(yè)務(wù)場景[誰、什么時候、怎么做]+

業(yè)務(wù)術(shù)語+變化/約束/擴展……）3、建議并確認(rèn)解決方案（問題有效解決+成本合適）本文檔共53頁；當(dāng)前第24頁；編輯于星期一\9點19分目錄由一個產(chǎn)品UI說開去由產(chǎn)品到需求溝通業(yè)務(wù)分析與表達(dá)12345技術(shù)開發(fā)、測試……產(chǎn)品需求、設(shè)計…博客商業(yè)市場、銷售……6業(yè)務(wù)規(guī)劃需求收集與管理本文檔共53頁；當(dāng)前第25頁；編輯于星期一\9點19分用戶為什么說不清需求易于放大需求不講需求背后的原因需求零散，思考不足問Why結(jié)構(gòu)化提問本文檔共53頁；當(dāng)前第26頁；編輯于星期一\9點19分馬斯洛需求層級本文檔共53頁；當(dāng)前第27頁；編輯于星期一\9點19分需求問題就是溝通問題本文檔共53頁；當(dāng)前第28頁；編輯于星期一\9點19分溝通哲學(xué)本文檔共53頁；當(dāng)前第29頁；編輯于星期一\9點19分產(chǎn)品做出來，還要賣出去。前者是“需求到功能”，可以對應(yīng)到“產(chǎn)品設(shè)計”的職能，后者是“功能到賣點”，對應(yīng)產(chǎn)品運營。從功能到賣點目標(biāo)用戶：人物；場景：時間、地點；碰到的問題：事情的起因，需求產(chǎn)生；產(chǎn)品/功能：事情的經(jīng)過，我們?nèi)绾谓鉀Q了問題；用戶收益：事情的結(jié)果，用了我們的產(chǎn)品以后，如何美好。本文檔共53頁；當(dāng)前第30頁；編輯于星期一\9點19分…………成敗案例分析(1)網(wǎng)上銀行孰優(yōu)孰劣？帳戶管理基本交易網(wǎng)上支付借記卡信用卡基金本文檔共53頁；當(dāng)前第31頁；編輯于星期一\9點19分產(chǎn)品賣點需求全景右腦需求：感覺、情感、外觀、設(shè)計……左腦需求：實用、痛點、邏輯、功能……（高層：解決問題/創(chuàng)造機會；中層：管理/控制）關(guān)鍵需求詳細(xì)需求吸引購買業(yè)務(wù)子系統(tǒng)/功能域行為數(shù)據(jù)質(zhì)量再次購買本文檔共53頁；當(dāng)前第32頁；編輯于星期一\9點19分目錄由一個產(chǎn)品UI說開去由產(chǎn)品到需求溝通業(yè)務(wù)分析與表達(dá)12345技術(shù)開發(fā)、測試……產(chǎn)品需求、設(shè)計…博客商業(yè)市場、銷售……6業(yè)務(wù)規(guī)劃需求收集與管理本文檔共53頁；當(dāng)前第33頁；編輯于星期一\9點19分業(yè)務(wù)流程八要素分工活動規(guī)模風(fēng)險專業(yè)協(xié)作并行串行異步產(chǎn)物關(guān)系分支審核異常規(guī)則本文檔共53頁；當(dāng)前第34頁；編輯于星期一\9點19分業(yè)務(wù)流程分析選擇合適的流程圖描述方式標(biāo)識流程中各參與角色梳理主流程梳理分支分析異常情況沒有最好的圖，只有最合適的的圖，應(yīng)根據(jù)流程邏輯特點選擇從服務(wù)請求到服務(wù)滿足，整個過程涉及哪些角色參與其中一切正常的處理流程是什么樣的？需要相關(guān)的審核點嗎？在各個環(huán)節(jié)中會出現(xiàn)例外嗎？針對這些例外如何處理？有沒有完全不能夠按流程處理的情況？有沒有出錯的情況？本文檔共53頁；當(dāng)前第35頁；編輯于星期一\9點19分業(yè)務(wù)流程vs.業(yè)務(wù)功能最終用戶管理者本文檔共53頁；當(dāng)前第36頁；編輯于星期一\9點19分跨職能流程圖——視頻偵緝本文檔共53頁；當(dāng)前第37頁；編輯于星期一\9點19分描述流程：選擇正確的工具

商業(yè)建模標(biāo)準(zhǔn)

復(fù)用性強

用戶最容易接受

并行、異步支持差跨職能流程圖活動圖時序圖數(shù)據(jù)

流圖

IDEF建模標(biāo)準(zhǔn)

強調(diào)數(shù)據(jù)流

未表示出誰執(zhí)行

計費類系統(tǒng)最適用

UML建模標(biāo)準(zhǔn)

語義最豐富

強調(diào)行為流強調(diào)活動內(nèi)容

UML建模標(biāo)準(zhǔn)

強調(diào)行為流

強調(diào)協(xié)作

技術(shù)類系統(tǒng)更常用本文檔共53頁；當(dāng)前第38頁；編輯于星期一\9點19分現(xiàn)場出圖：流程分析加速器一聽二問三讀客戶代表陳述不要中途打斷繪出基本脈絡(luò)為指引忽略

細(xì)節(jié)草圖

演化具體的崗位分支與異常其他細(xì)節(jié)繪圖者復(fù)述客戶代表驗證達(dá)成共識本文檔共53頁；當(dāng)前第39頁；編輯于星期一\9點19分閱讀用例圖本文檔共53頁；當(dāng)前第40頁；編輯于星期一\9點19分目錄由一個產(chǎn)品UI說開去由產(chǎn)品到需求溝通業(yè)務(wù)分析與表達(dá)12345技術(shù)開發(fā)、測試……產(chǎn)品需求、設(shè)計…博客商業(yè)市場、銷售……6業(yè)務(wù)規(guī)劃需求收集與管理本文檔共53頁；當(dāng)前第41頁；編輯于星期一\9點19分需求編號：包含“采集時刻

+

采集者”信息需求類型：（在進行評審時填寫）功能需求、非功能需求……來源（Who）：（方便追根溯源）公司提供者：需求提供者的部門、聯(lián)系方式產(chǎn)生需求的客戶：用戶需求的公司、部門、聯(lián)系方式客戶背景資料：受教育程度、崗位經(jīng)驗、其他與本單項需求相關(guān)經(jīng)驗場景（Where、When）：產(chǎn)生該需求的用戶活動特定的時間、地理、環(huán)境描述（What）：用（主語+謂語+賓語）的語法結(jié)構(gòu)，禁止使用修飾語句原因（Why）：（保持懷疑的心，很多時候理由是假想出來的）驗收標(biāo)準(zhǔn)（How）：1.

用量化的語言2.

無法量化尋找標(biāo)竿需求重要性權(quán)重（Howmuch）：滿足后（1一般~5非常高興）未實現(xiàn)（1略感遺憾~5非常懊惱）需求生命特征（When）：1.

需求的緊急度2.

時間持續(xù)性需求關(guān)聯(lián)（Which）：1.

人：需求關(guān)聯(lián)的用戶影響人物2.

事：需求關(guān)聯(lián)的用戶業(yè)務(wù)與關(guān)聯(lián)需求編號3.

物：需求關(guān)聯(lián)的客戶系統(tǒng)、設(shè)備；需求關(guān)聯(lián)的公司產(chǎn)品及版本參考材料：在需求采集活動中的輸入材料，僅僅輸入援用的條目、章節(jié)競爭者對比：（按照1分差~10分好進行評估）1.

競爭者對該需求的滿足方式2.

用戶、客戶對競爭者及公司在該需求的評價產(chǎn)品設(shè)計期需求本文檔共53頁；當(dāng)前第42頁；編輯于星期一\9點19分目標(biāo)用戶：這件事，是為誰而做的，一旦售后填寫這個就可以自己排除掉很多需求了；問題描述：目標(biāo)用戶碰到的痛點，只說“何時/何地，怎么難受”即可；嚴(yán)重程度：對問題嚴(yán)重程度的判斷，“高/中/低”即可，具體的判斷方法，可以根據(jù)用戶重要程度，問題出現(xiàn)的次數(shù)、頻率等因素考慮；現(xiàn)有方案：現(xiàn)在是如何解決此問題的。一般來說，一個值得解決的問題，通常已經(jīng)有人著手想方案了，也一定已經(jīng)有一些解決方案，而沒有現(xiàn)有方案的問題，通常不嚴(yán)重；建議方案：建議的產(chǎn)品改進

，催促售后換位思考，產(chǎn)品不一定采納；價值描述：改進方案帶來的額外價值，比如：省時間；能更精準(zhǔn)的找到某某……改進成本：建議方案的成本評估，“高/中/低”，同樣，僅供參考。產(chǎn)品拿到一堆需求以后，主要根據(jù)性價比決定接下來做什么。性價比

=

嚴(yán)重程度/改進成本，問題（用戶需求）決定嚴(yán)重程度，解決方案（產(chǎn)品功能）決定改進成本。售后/運營該如何提需求本文檔共53頁；當(dāng)前第43頁；編輯于星期一\9點19分質(zhì)量屬性的常見誤區(qū)定性描述普遍重視不足全局描述盲目定量需求簡單復(fù)制開發(fā)直接翻過需求寫不出開發(fā)看不懂顧此失彼未能有效實現(xiàn)本文檔共53頁；當(dāng)前第44頁；編輯于星期一\9點19分模塊：一般來說，每個模塊下分3~10個子模塊是合理的，否則要考慮重新劃分。子模塊：稍大一點的產(chǎn)品至少要給功能模塊做二級分類了。功能：要給用戶提供什么功能，功能名字。功能描述：這里可以說具體一點。需求列表到功能列表商業(yè)價值描述：賣點是什么，可以給用戶提供什么價值。商業(yè)屬性：簡單分為基本，擴展，增值。商業(yè)優(yōu)先級：這塊是整個FeatureList工作中核心的部分，判斷的準(zhǔn)確直接影響著將來產(chǎn)品的方向。先基于自己對商業(yè)目標(biāo)的理解，主觀定級別，然后再PD團隊pk，如有必要，再去客戶處確認(rèn)。開發(fā)量：一般由技術(shù)部門的項目經(jīng)理或者系統(tǒng)分析師/架構(gòu)師來確定。性價比：綜合商業(yè)屬性、優(yōu)先級與開發(fā)量來確定一個合適產(chǎn)品的計算方法。備注：本文檔共53頁；當(dāng)前第45頁；編輯于星期一\9點19分需求確認(rèn)動態(tài)功能列表是對每個需求加上跟蹤狀態(tài)屬性，能實時看到“何時做，誰來做，狀態(tài)如何”。負(fù)責(zé)人：細(xì)分為需求提出者（備注原始需求）、需求負(fù)責(zé)人、開發(fā)負(fù)責(zé)人、測試負(fù)責(zé)人，屬于哪個項目……需求狀態(tài)：通常有“待討論”、“拒絕”、“暫緩”、“需求中”、“開發(fā)中”、“已完成”幾個狀態(tài)，可按實際情況增減。時間信息：提出時間、錄入時間、發(fā)布時間……本文檔共53頁；當(dāng)前第46頁；編輯于星期一\9點19分采集產(chǎn)品干系人（廣義用戶）提出的各種需求，整理轉(zhuǎn)化為產(chǎn)品需求，即“需求轉(zhuǎn)化”?！按_定屬性”即這個需求是屬于產(chǎn)品的哪個模塊？是基本/擴展/增值功能？是功能/性能/用戶體驗方面？等。屬性的維度可按照產(chǎn)品的不同自由定義，原則是為了便于需求管理。需求管理featurelist，每隔一段時間、或新需求積累到一定數(shù)量、或是由特別事件觸發(fā)，進行“確定商業(yè)價值（產(chǎn)品內(nèi)PK）”。會議上討論所有狀態(tài)為“待討論”的功能點，需求狀態(tài)一定要變化，進入“需求中”/“拒絕”/“暫緩”。拒絕的需求是被認(rèn)為對產(chǎn)品的商業(yè)目的沒有價值的，而暫緩的需求是“有價值，但是現(xiàn)在不做”的，通常要表明重啟的條件。狀態(tài)變?yōu)椤靶枨笾小钡墓δ茳c，下一步就是初定工作量，只是簡單的評估，和真實情況的匹配程度很取決于經(jīng)驗,要靠不斷的實踐來反復(fù)修正。有了每個功能點的商業(yè)價值和工作量，很自然的就能算出性價比，簡單的說即“商業(yè)價值/開發(fā)工作量”，我們把featurelist按照性價比從大到小排序，再對應(yīng)考察每行評估出來的開發(fā)工作量，從上到下依次納入項目，我們的可用工作量能做多少個功能點，一目了然。第二，需求依賴，功能點互相之間有依賴關(guān)系，只能先做某些功能，應(yīng)在featurelist里注明；功能點與人力資源之間的依賴關(guān)系也會經(jīng)常存在，在這里評估工作量的時候不會考慮“誰來做”的問題，但是在后續(xù)立項，組建團隊的時候需要注意。第三，功能點的粒度大小問題，商業(yè)價值很高的功能，如果細(xì)分的話，我們也會發(fā)現(xiàn)其中有價值相對低的部分，所以功能點的粒度應(yīng)該盡量細(xì)，前提是細(xì)化引起的管理成本上升在可接受的范圍內(nèi)。第一，需求打包最好打類似的功能點，是否類似取決于需求的屬性，“確定屬性”這步做的事情起作用了，一般來說業(yè)務(wù)上有邏輯關(guān)系的需求才會包含一個項目里，否則就是一個純粹修修補補的“小需求項目”了。本文檔共53頁；當(dāng)前第47頁；編輯于星期一\9點19分需求發(fā)布流程本文檔共53頁；當(dāng)前第48頁；編輯于星期一\9點19分目錄由一個產(chǎn)品UI說開去由產(chǎn)品到需求溝通業(yè)務(wù)分析與表達(dá)12345技術(shù)開發(fā)、測試……產(chǎn)品需求、設(shè)計…博客商業(yè)市場、銷售……6業(yè)務(wù)規(guī)劃需求收集與管理本文檔共53頁；當(dāng)前第49頁；編輯于星期一\9點19分業(yè)務(wù)規(guī)劃--Why？What？How？可做的事想做的事能做的事一句話的業(yè)務(wù)定位一個商業(yè)模型幾個個業(yè)務(wù)關(guān)鍵點資源保障計劃安排效果預(yù)估業(yè)務(wù)規(guī)劃HowWhatWhy本文檔共53頁；當(dāng)前第50頁；編輯于星期一\9點19分首先，明確目的，最最重要，其實做一個會議和做一個產(chǎn)品也是一樣的。不要試圖在一個會議中解決所有的問題，就算你要連著召集兩個參與人大部分相同的會議，我也建議你把它們分開，甚至，更好的做法，合理安排一