產品經理都該是需求分析師課件

產品經理都該是需求分析師@淘寶陶謙I什么是產品經理？一個故事一天晚上，一個孩子和媽媽走在回家的路上，突然孩子說：“媽媽，我要吃雞腿”，但是現在附近沒有肯德基之類的店鋪啊，媽媽犯愁了，怎么辦呢？可不能餓著孩子啊，媽媽又突然想起來中午買的皮薩還有一些，于是拿出來給孩子吃，孩子一看還有皮薩，很高興的接過來開心的吃著了。雞腿=皮薩嗎？潛在需求是：餓+好吃的什么是需求？廣義了說：需求來源于用戶的一些“需要”，這些“需要”被分析、確認后形成完整的文檔，該文檔詳細地說明了產品“必須或應當”做什么。誤解：1、用戶說出來的就是需求2、用戶說的需求就是應該做的重視“間接用戶”，千萬別“大意失荊州”間接用戶既不掏錢買該軟件產品，也不使用該軟件，但是它可能對軟件產品有很大的影響。例如，財務軟件開發(fā)商在把“財務軟件”賣給客戶之前，這個“財務軟件”必須得到國家財政部的批準。否則即使該軟件的功能是完美的，但卻被政府認為是非法的。所以國家財政部就是所有財務軟件的間接用戶，它不僅不付錢給財務軟件開發(fā)商，反而要收取鑒定費、手續(xù)費等。同理，市面上流通的信息安全軟件、殺病毒軟件必須得到國家公安部的批準，否則軟件開發(fā)商被逮住后戴上“非法經營”的帽子就慘了。我們的用戶是誰？目前我們如何溝通的？如何正確引導用戶說清楚自己的需求？把所有與需求直接相關的活動通稱為需求工程什么是需求工程1、用戶有他自己的想法：

“我回答了你們的問題，講了該講的。我還要干自己的事情，別打擾我了。你們自己想辦法把活干好吧

……”2、用戶說不清楚需求

“比如說買鞋子。我們非常了解自已的腳，但很難用語言說清楚腳的大小和形狀。通常拿鞋子去試，試穿時感覺到舒服才會買鞋”3、雙方誤解需求

有個外星人間諜潛伏到地球刺探情報，它給上司寫了一份報告：“主宰地球的是車。它們喝汽油，靠四個輪子滾動前進。嗓門極大，在夜里雙眼能射出強光?！腥さ氖?，車里住著一種叫作‘人’的寄生蟲，這些寄生蟲完全控制了車。”4、用戶經常變更需求

如果在項目開發(fā)的初始階段，開發(fā)人員和用戶沒有搞清楚需求或者搞錯了需求，到了項目開發(fā)后期才將需求糾正過來，導致產品的部分內容需要重新開發(fā)。毫無疑問，這種需求變更將使項目付出額外的代價。需求開發(fā)的主要困難與對策1.有權要求開發(fā)方采用用戶熟悉的語言來描述需求，即開發(fā)方必須提供用戶看得懂得需求文檔。2.有權審查需求文檔，并對有爭議的需求作出決策。3.如果用戶想要變更需求，有權要求開發(fā)方對該變更將產生的影響作出真實可信的評估，以便用戶決定是否變更需求。用戶在需求工程中的“權利”以積極友善的態(tài)度交流、協作樂意接受的采訪，在不泄漏機密的前提下盡可能地回答問題。在不泄漏機密的前提下，盡可能地提供與需求相關的材料。與PD共同評審需求文檔，確保需求文檔準確地反映用戶真實的意愿。用戶在需求工程中的“義務”用戶需求說明書的參考模板6.如何進行需求分析6.2問答分析方法問答分析方法很簡單：刨根究底地問，如果問題都被解答了，那么需求也就分析清楚了。一個人可以“自問自答”地分析需求，幾個人分析需求則稱為“研討”。問答分析最重要的問題是：“是什么”和“為什么”。每個需求都應當用陳述句說明“是什么”，如果“是什么”的內涵不夠清晰，則應補充說明“不是什么”。如果“是什么”和“不是什么”并不是“理所當然”的，那么應當解釋“為什么”，以便加深讀者的理解。追究“是什么”和“為什么”的目的是獲得正確、清楚的需求。其它常見的問題有：需求存在二義性嗎？需求文檔的上下文有矛盾嗎？需求完備嗎？需求是必要的嗎？需求可實現嗎？需求可驗證嗎？需求的優(yōu)先級確定了嗎？6.如何進行需求分析6.3建模分析法人們都有這樣地感受：有些時候用語言描述某個問題特別費勁，而采用圖形則使人一目了然，所謂“一圖低千言”就是這個道理。在需求開發(fā)過程中，對于某些類型的信息，用圖形表示要比文本表示更加有效。所以將圖形與文本結合起來描述需求是很自然的方法。需求建模就是指用圖形符號來表示、刻畫需求。建模分析方法主要有兩大類：“結構化分析法”和“面向對象分析法”。恰當地使用圖形符號：現代建模工具如Rose有非常豐富的圖形符號和文字標注，能很好地表達模型的細節(jié)。要注意的是：在建模時使用花樣過多的圖形符號或文字意味著模型表示的復雜化，將使開發(fā)人員更難掌握，而且使圖形文檔更加雜亂。世上不存在一個包羅萬象的圖——它能完整地描述需求。需求建模不可能取代文字描述。在需求文檔中，文字描述是第一重要的，建模主要是起分析、解釋作用。建議將模型存放在需求文檔的附錄中，便于正文引用。什么是好的需求規(guī)格說明書正確需求規(guī)格說明書應當正確地反映用戶的真實意圖，“正確”是《產品需求規(guī)格說明書》最重要的屬性。如果“不正確”僅僅是由于錯別字造成的，那么多檢查幾遍文檔就能解決問題。真正的困難是開發(fā)者和用戶自己都不明白用戶究竟“想要什么”和“不要什么”。為確保需求是正確的，開發(fā)方和用戶必須對《需求規(guī)格說明書》進行確認。7.2清楚清楚的需求讓人易讀易懂。清楚的反義詞是“難讀”、“難理解”。你可以采用反問的方式來判斷需求文檔是否清楚：文檔的結構、段落是否亂七八糟？上下文是否不連貫？文檔的語句是否含糊其詞、羅里羅嗦？看了半天是否還不明白需求究竟是什么？7.3無二義性“無二義性”是指每個需求只有唯一的含義。如果一個人說的話，不同的人可能有不同的理解，那么這句話就有二義性。如果需求存在二義性，將會導致人們誤解需求而開發(fā)出偏離需求的產品。為了使需求無二義性，人們在寫《產品需求規(guī)格說明書》時措詞應當準確，切勿模棱兩可。7.什么是好的需求規(guī)格說明書7.4一致“一致”（Consistent）是指《產品需求規(guī)格說明書》中各個需求之間不會發(fā)生矛盾。矛盾常常潛伏在需求文檔的上下文中。7.5必要《產品需求規(guī)格說明書》中的各項需求對用戶而言應當都是必要的?？梢园选氨匾北扔鳛椤把┲兴吞俊薄！氨匾蓖耙徊?，要么是“畫蛇添足”要么是“錦上添花”?！爱嬌咛碜恪憋@然是壞事，會導致開發(fā)人員多干一些吃力不討好的工作。所以要盡量剔除需求規(guī)格說明書中“畫蛇添足”的那些需求?！板\上添花”是好事，可能會讓用戶獲得比期望更多的喜悅，但是眼前用戶不會為此多付錢。開發(fā)者應當集中精力先完成必要的需求，如果條件允許則再做“錦上添花”的需求。為了避免主次顛倒，應當在《產品需求規(guī)格說明書》中將那些“錦上添花”的需求設置為較低的優(yōu)先級。7.6完備“完備”（Complete）是指《產品需求規(guī)格說明書》中沒有遺漏一些必要的需求。人們往往傾向于關注系統的特色功能，而忽視了其它一些不起眼的但卻是必需的功能。不完備的《產品需求規(guī)格說明書》將導致產生功能不完整的軟件，用戶在使用該軟件時可能無法完成預期的任務。7.什么是好的需求規(guī)格說明書7.7可實現《產品需求規(guī)格說明書》中的各項需求對開發(fā)方而言應當都是可實現的（Attainable）?！翱蓪崿F”意味著在技術上是可行的，并且滿足時間、費用、質量等約束。營銷人員和用戶談生意時，為了能拿到“單子”，他們往往對用戶提出的需求“來者不拒”。吹牛皮雖然不犯法，但是《產品需求規(guī)格說明書》可是白紙黑字啊。經過雙方確認的《產品需求規(guī)格說明書》相當于商業(yè)合同，如果開發(fā)方不能夠實現《產品需求規(guī)格說明書》中的內容，那就是違約，可能會被罰款的。對于合同項目，如果開發(fā)方不能確信某些需求是否可實現，則應事先與用戶協商，達成一致的處理意見，避免將來發(fā)生商業(yè)糾紛。7.8可驗證《產品需求規(guī)格說明書》中的各項需求對用戶方而言應當都是可驗證的（Verifiable）。如果需求是不可驗證的，那么用戶就無法驗收軟件，可能會發(fā)生商業(yè)糾紛。例如，摩天大樓的一項需求是“抗十二級臺風”，這個需求看起來堂而皇之，但是如何驗證呢？當摩天大樓完工后驗收時，用戶又不是巫師，他怎能造個十二級臺風來試驗？如果雙方都認可“采用計算機模擬十二級臺風”等效于實際測試，那么這項需求就是“可驗證”的。提升與舉措原則客戶陳述需求描述（正確）需求描述（錯誤）“什么”而非“怎樣”“有時灰塵會進入系統，給我?guī)砺闊！毕到y提供灰塵防護能力。系統通過防護網提供相應的灰塵防護功能。特點“工作中，我總是一不小心就把螺絲刀掉到地上了?！痹诒凰み^幾次后螺絲刀仍然能正常工作。螺絲刀很不好，經常被掉在地上。肯定而非否定“根據公司規(guī)定，無論刮風下雨，我都需要堅持在戶外工作?！甭萁z刀在雨中仍能正常工作。螺絲刀在雨中不會不能使用。產品屬性“我希望能用我的打火機給電池充電”可以用自動打火機給螺絲刀的電池充電自動打火機器使用者可以給螺絲刀電池充電避免“必須”和“應該”“當我不知道螺絲刀的電池還有多少電量時，我會很煩。”螺絲刀提供電池能量多少的顯示。螺絲刀應該提供電池能量多少的顯示。9.需求管理：確認、跟蹤、變更控制9.1需求確認（評審和承諾）需求確認是指開發(fā)方和客戶方共同對《產品需求規(guī)格說明書》進行評審，雙方對需求達成共識后作出承諾。需求確認包含兩個重要工作：“需求評審”和“需求承諾”。9.2需求評審面臨的困難需求評審的一個通病是“虎頭蛇尾”。需求評審的確乏味，也比較費腦子。剛開始評審時，大家都比較認真，越到后頭越馬虎。需求評審涉及的人員可能比較多，有些時候讓這么多人聚在一起花費比較長的時間開會并不容易（例如有些人可能出差在外，有些人可能事務纏身）。沒有必要把所有事情擠在一塊做，需求開發(fā)是循序漸進的過程，需求評審也可以分段進行。這樣每次評審的時間比較短，參加評審的人員也少一些，組織會議就比較容易。開評審會議時經常會“跑題”，導致評審效率很低。有時話匣子一打開后關不上，大家越扯越遠，結果評審會議變成了聊天會議。主持人應當控制話題，避免大家討論與主題無關的東西。開評審會議時經常會發(fā)生爭議。適當的爭議有利于澄清問題，比什么東西都一致贊成要好。然而當爭議變?yōu)闋幊硶r就壞事了，爭吵不僅對評審工作沒有好處，而且會無意中傷害同事們的感情。人們在很多時候分不清楚自己究竟是“堅持真理”還是“固執(zhí)己見”。毫不妥協或者輕易妥協都不是好辦法。我們應當養(yǎng)成良好的習慣：不要一棍子打死異己的觀點，嘗試著讓自己站在他人的立場思考問題，這樣你會找到比較滿意的答案。9.需求管理：確認、跟蹤、變更控制9.3需求承諾需求承諾是指開發(fā)方和客戶方的責任人對通過了正式技術評審的《產品需求規(guī)格說明書》作出承諾，該承諾具有商業(yè)合同的效果。需求承諾的“八股文”如下：本《產品需求規(guī)格說明書》建立在雙方對需求的共同理解基礎之上，我同意后續(xù)的開發(fā)工作根據該《產品需求規(guī)格說明書》開展。如果需求發(fā)生變化，我們將按照“變更控制規(guī)程”執(zhí)行。我明白需求的變更將導致雙方重新協商成本、資源和進度等。甲方簽字乙方簽字人們在作出承諾之前務必要認真閱讀文檔，一定要明白簽字意味著什么。9.需求管理：確認、跟蹤、變更控制9.5需求變更控制需求發(fā)生變更的起因主要有：隨著項目的進展，人們（包括開發(fā)方和客戶方）對需求的了解越來越深入。原先的需求文檔可能存在這樣那樣的錯誤或不足，因此要變更需求。市場發(fā)生了變化，原先的需求文檔可能跟不上當前的市場需求，因此要變更需求。提出需求變更的動機是好的，目的是希望產品更加符合用戶的需求。對項目開發(fā)小組而言，變更需求意味著要調整資源、重新分配任務、修改前期工作成果等，開發(fā)小組要為此付出較重的代價。如果每次需求變更請求都被采納的話，這個項目也許永遠不能按時完成。需求變更控制的目的：如果需求變更帶來的好處大于壞處，那么允許變更，但必須按照已定義的變更規(guī)程執(zhí)行，以免變更失去控制。如果需求變更帶來的壞處大于好處，那么拒絕變更。需求變更控制過程中最難辦的事情是莫過于“拒絕客戶提出的需求變更請求”。通常情況下開發(fā)方是不敢得罪客戶的，但是無原則地退讓將使開發(fā)小組陷