管理好產(chǎn)品的需求

歡迎閱讀本文檔，希望本文檔能對您有所幫助!歡迎閱讀本文檔，希望本文檔能對您有所幫助!感謝閱讀本文檔，希望本文檔能對您有所幫助!感謝閱讀本文檔，希望本文檔能對您有所幫助!歡迎閱讀本文檔，希望本文檔能對您有所幫助!感謝閱讀本文檔，希望本文檔能對您有所幫助!管理好產(chǎn)品的需求最近的一系列事情開始教育我，如果不能做好需求管理的工作，產(chǎn)品人員疲于應(yīng)付不斷變化的需求，導致無法正常開展產(chǎn)品的設(shè)計和管理工作。結(jié)果就是交付給開發(fā)人員的需求文檔不斷變動，開發(fā)人員也不知道自己究竟該做什么，項目進度越拖越慢。最后到了規(guī)定好的交付時間，因為拿不出需要的產(chǎn)出物，部門之間開始互相推諉、埋怨。思考良久，需求的變動固然是造成這種結(jié)果的主要原因，另一個不能忽視的因素則是需求沒有表述清楚，開發(fā)人員面對表述模糊的需求文檔，更加無法完成既定的開發(fā)工作。如何表述清楚需求?我們需要盡可能做好兩件事情： 1.完整建立產(chǎn)品的usercase;2.在需求文檔中力爭做到明確、完整、一致和可測試四點。那么對于產(chǎn)品、開發(fā)的工作影響就能降到最小，你的項目也越能在規(guī)定的時間內(nèi)完成。如何建立產(chǎn)品的UserCaseDiagramUserCaseDiagram也叫用例圖，基于面向?qū)ο蟮乃枷牒陀脩粢暯莵碓O(shè)計。如下圖就是一種非常簡單的用例圖，它有點類似創(chuàng)建產(chǎn)品的用戶角色，你需要能從使用的角度描述出用戶是如何一步步操作這個產(chǎn)品的。用例這種通過講故事來把需求描述清楚的辦法很有點黑盒的概念，很容易被用戶和開發(fā)者理解;但缺陷在于無法描述清楚該如何實現(xiàn)，也很少涉及內(nèi)部的信息。一旦我們遇到無法理解產(chǎn)品實現(xiàn)機制或者內(nèi)部流程架構(gòu)的情況時，就必須借助其他的方法來理解需求，這個過程可以理解為打開黑盒。這樣通過不斷地觀察黑盒，打開黑盒、分析黑盒，然后再打開黑盒的過程，我們就能做到對整個產(chǎn)品的需求有比較準確的把握?；ヂ?lián)網(wǎng)的一些事用例圖就是這樣一種能幫助我們了解需求的方式，當然如果指望讓程序員看完了用例圖就能把程序做出來，那是相當?shù)爻兜驗橛美龍D本身只是用來闡述用戶的需求，很難準確對產(chǎn)品的功能、架構(gòu)賦予嚴謹?shù)拿枋龊投x。因此，我們還需要另外一份交付物，來清楚表達產(chǎn)品的功能、流程和架構(gòu)，比如說產(chǎn)品需求文檔。產(chǎn)品需求文檔應(yīng)有的幾個基本要素：對應(yīng)的產(chǎn)品不同，需求的標準也不盡相同，不過有一些通用的要素，仍然是可以借鑒的：明確：很多撰寫需求文檔的人并沒有學習過形式化語言，因此我們看到的需求文檔很多都是采用自然語言寫出來的。這對需求分析帶來的最大弊病就是它的二義性。因此需要我們對文檔的表述進行一些限制，例如盡可能只用主謂賓的基本表達方式，避免修飾句，避免容易令人產(chǎn)生誤解的表達方式。比如我們是做一個社?？ㄏ到y(tǒng)，你可以這樣描述需求：每張公交IC卡只能屬于一個用戶，社保卡有卡號和金額數(shù)。社保卡可以在醫(yī)院使用，可以用來支付醫(yī)藥費。完整：既不要在提需求時說還有一些需求沒有確認，也不要開發(fā)接近完成了提出來有一些需求遺漏了。需求的不完整是導致開發(fā)返工的最直接因素，也是令人發(fā)指的行為。需求的完整需要產(chǎn)品人員有很好的產(chǎn)品管理技能，也需要對已有產(chǎn)品的架構(gòu)有清晰的了解，很多時候產(chǎn)品人員面對的都是拍腦袋或者臨時決定提出來的需求，很難第一時間提煉出完整的需求，怎么辦?問!問自己，問客戶，問開發(fā)。在你無法確認出完整需求或者起碼的核心需求之前，任何交付給開發(fā)的行為注定是不負責任的?；ヂ?lián)網(wǎng)的一些事一致：需求簡單來說可以分成業(yè)務(wù)需求、用戶需求和開發(fā)需求三個方面。用戶需求需要能和業(yè)務(wù)需求一致，開發(fā)需求需要能和用戶需求一致，這并不是在說廢話，而是三種需求之間的繼承關(guān)系。否則，辛苦開發(fā)出來的東西很可能會偏離當初的實現(xiàn)目標。在具象的實現(xiàn)過程中，這種一致性也必須細化。往往用戶需求在整個過程中不斷變化，產(chǎn)生所謂的”需求變動”，這種變化不應(yīng)該超出先前既定的范圍，至少不應(yīng)該超出最初的業(yè)務(wù)目標?？蓽y試：很多人認為項目、產(chǎn)品的測試應(yīng)該從寫完代碼輸出測試產(chǎn)品時開始算起或者說開發(fā)們在寫代碼的時候就該開始履行測試的職責了，這樣理解有它的道理。但實際上，和完整性的要求一樣，測試的過程應(yīng)該從需求一開始分析的時候就要開始。作為測試的輸入輸入和參照物，需求分析應(yīng)該是可測試的。比如我們說“設(shè)計一個網(wǎng)站，能讓用戶第一時間了解車票的行情”。這個需求是可測試的么?當然不是!車票是指的火車票、汽車票抑或二者都是?了解車票的行情包括哪些方面?這些在需求中都沒有做出說明，也意味著它是無法測試的，不具備可測試性?；ヂ?lián)網(wǎng)的一些事因此包括前幾項的需求因素在內(nèi)，我們的目的都是要保證需求的可測試性。當且只有當所有的需求是可以被測試的，才有可能保證產(chǎn)品從需求分析到設(shè)計開發(fā)再到最后的交付都是真的在圍繞業(yè)務(wù)目標和用戶需要的。產(chǎn)品才能更接近成功。究竟該如何解決“需求的變動”帶來的問題呢，對于這個“世界難題”我只能說見招拆招了，畢竟這屬于項目開發(fā)中不可抗的外因，很多時候并不是產(chǎn)品經(jīng)理或者項目經(jīng)理能左右的。在面向?qū)ο蟮拈_發(fā)模式下，管理者能做的就是盡可能避免變動可能造成的計劃延遲，而對于產(chǎn)品經(jīng)理來說，不僅要控制好進度，更要能把握好變動可能帶來的對核心功能的影響，因為你是掌舵者，你是“總設(shè)計師”。但是，有句說句：忽略需求過程或者需求的變動造成項目返工是項目失敗的最大因素，大量項目的失敗往往都是在需求階段就注定了的。正在做產(chǎn)品經(jīng)理的諸位不妨審視一下自己的工作，發(fā)現(xiàn)情況不妙的趕緊處理掉吧。舉兩個典型的需求變動的例子：1.需求人員口頭上把自己的想法和開發(fā)人員溝通以后，又扔下一句話：這些地方暫時沒有討論清楚，不用去管