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

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

What1、澄清問題〔問題表象+原因+范圍與限定〕2、了解業(yè)務(wù)背景〔業(yè)務(wù)場景[誰、什么時候、怎么做]+業(yè)務(wù)術(shù)語+變化/約束/擴展……〕3、建議并確認解決方案〔問題有效解決+本錢適宜〕目錄由一個產(chǎn)品UI說開去由產(chǎn)品到需求溝通業(yè)務(wù)分析與表達12345技術(shù)開發(fā)、測試……產(chǎn)品需求、設(shè)計…博客商業(yè)市場、銷售……6業(yè)務(wù)規(guī)劃需求收集與管理用戶為什么說不清需求馬斯洛需求層級需求問題就是溝通問題溝通哲學產(chǎn)品做出來，還要賣出去。前者是“需求到功能〞，可以對應(yīng)到“產(chǎn)品設(shè)計〞的職能，后者是“功能到賣點〞，對應(yīng)產(chǎn)品運營。從功能到賣點目標用戶：人物；場景：時間、地點；碰到的問題：事情的起因，需求產(chǎn)生；產(chǎn)品/功能：事情的經(jīng)過，我們?nèi)绾谓鉀Q了問題；用戶收益：事情的結(jié)果，用了我們的產(chǎn)品以后，如何美好?！蓴“咐治?1)網(wǎng)上銀行孰優(yōu)孰劣？帳戶管理基本交易網(wǎng)上支付借記卡信用卡基金產(chǎn)品賣點需求全景右腦需求：感覺、情感、外觀、設(shè)計……左腦需求：實用、痛點、邏輯、功能……〔高層：解決問題/創(chuàng)造時機；中層：管理/控制〕關(guān)鍵需求詳細需求吸引購置再次購置目錄由一個產(chǎn)品UI說開去由產(chǎn)品到需求溝通業(yè)務(wù)分析與表達12345技術(shù)開發(fā)、測試……產(chǎn)品需求、設(shè)計…博客商業(yè)市場、銷售……6業(yè)務(wù)規(guī)劃需求收集與管理業(yè)務(wù)流程八要素分工活動規(guī)模風險專業(yè)協(xié)作并行串行異步產(chǎn)物關(guān)系分支審核異常規(guī)那么業(yè)務(wù)流程分析沒有最好的圖，只有最適宜的的圖，應(yīng)根據(jù)流程邏輯特點選擇從效勞請求到效勞滿足，整個過程涉及哪些角色參與其中一切正常的處理流程是什么樣的？需要相關(guān)的審核點嗎？在各個環(huán)節(jié)中會出現(xiàn)例外嗎？針對這些例外如何處理？有沒有完全不能夠按流程處理的情況？有沒有出錯的情況？業(yè)務(wù)流程vs.業(yè)務(wù)功能最終用戶管理者跨職能流程圖——視頻偵緝描述流程：選擇正確的工具

商業(yè)建模標準

復用性強

用戶最容易接受

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

流圖

IDEF建模標準

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

未表示出誰執(zhí)行

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

UML建模標準

語義最豐富

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

UML建模標準

強調(diào)行為流

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

技術(shù)類系統(tǒng)更常用現(xiàn)場出圖：流程分析加速器一聽二問三讀客戶代表陳述不要中途打斷繪出根本脈絡(luò)為指引忽略

細節(jié)草圖

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

+

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

用量化的語言2.

無法量化尋找標竿需求重要性權(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è)計期需求目標用戶：這件事，是為誰而做的，一旦售后填寫這個就可以自己排除掉很多需求了；問題描述：目標用戶碰到的痛點，只說“何時/何地，怎么難受〞即可；嚴重程度：對問題嚴重程度的判斷，“高/中/低〞即可，具體的判斷方法，可以根據(jù)用戶重要程度，問題出現(xiàn)的次數(shù)、頻率等因素考慮；現(xiàn)有方案：現(xiàn)在是如何解決此問題的。一般來說，一個值得解決的問題，通常已經(jīng)有人著手想方案了，也一定已經(jīng)有一些解決方案，而沒有現(xiàn)有方案的問題，通常不嚴重；建議方案：建議的產(chǎn)品改進

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

=

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