理順軟件開發各個環節-3

4 需求管理

　　4.1 需求的三個層面

　　4.2 用戶需求收集

　　4.3 產品需求分析

　　　　4.3.1 產品可行性分析

　　　　4.3.2 產品版本規劃

　　　　4.3.3 MVP規劃

　　　　4.3.4 產品需求細化

　　　　4.3.5 產品需求評審

　　　　4.3.6 錄入用戶故事

 

4 需求管理

　　需求管理，屬於需求工程（Requirements Engineering,RE）範疇，通常狀況，不作區分。

　　需求（Requirements）是軟件產品的起點。詢問軟件人員，什麼對軟件產品最重要，大部分人的答案是需求，可見需求在軟件開發中佔據的重要位置。

　　然而，據我所知，大多數軟件人員對需求的理解並不許確，結果致使軟件開發經常遭遇需求困境。軟件開發沒有階段性里程碑，需求加入很隨意，結束更是遙遙無期，更有甚者，某些需求與本系統關係不大，也被硬塞進來，系統結構愈來愈臃腫，系統彈性愈來愈差，使人抓狂！

4.1 需求的三個層面

　　我認爲，需求分三個層面：用戶需求、產品需求和軟件需求。

　　用戶需求，是產品需求的驅動和源泉，來源有：競品分析，潛在客戶的調研，已有用戶的提供的資料、調研、建議和投訴，每每由市場人員、銷售人員、客服人員收集。有時候，用戶需求是不清晰的，由於用戶本身也沒法描述清楚其到底須要什麼！

　　產品需求，是從用戶需求中裁剪出來一個需求集合，這個需求集合可以發揮公司的優點或者符合公司的戰略發展方向。肯定產品需求的時候，必需要認可，企業資源和能力是有限的，不可能讓全部人都滿意，有所爲有所不爲，這就是產品經理的工做職責所在。

　　產品需求，是用業務語言表述的，基本是用戶可理解的，一般表現爲特性需求列表，即feature list。

 

　　軟件需求，是根據產品需求，進行分析，整理，並輔以初步的架構設計。針對每個需求項目，描述各種用戶類型的用戶場景，正常過程、可選過程、異常過程及非功能需求。還應包括性能需求和各類質量屬性需求、接口需求等。

　　軟件需求分析，是將產品需求轉換爲軟件開發人員可以理解的需求項，軟件需求和產品需求並不是一一對應關係，但軟件需求的全集應該能夠覆蓋全部的產品的需求，而且軟件需求還可能增長軟件自身的某些需求，如抽取某個公共模塊以提升模塊可重用性、提供多模塊化框架需求等。

 

4.2 用戶需求收集

　　用戶需求的收集是持續的。

　　產品在任何階段，都須要持續關注用戶需求。

　　不一樣用戶的需求權重是不一樣的，需求優先級也不一樣，通常狀況是市場或銷售會反饋用戶的需求，新的競品也須要研究。

　　對於項目類軟件，即便目標用戶單位肯定，也不意味着用戶是一類，仍然須要保持溝通，收集有用信息。

　　客戶投訴也是一類用戶需求，代表產品已有功能存在缺陷，影響用戶體驗或工做開展。

　　用戶需求應歸攏到產品經理那裏，由其組織人員進行需求分析，裁剪需求，肯定在哪一個版本支持新需求或對已有需求進行變動。

　　還有一類資料來自於客戶，但只是技術文檔，如接口文檔，這類能夠直接交給開發團隊，做爲外部接口文檔。

　　用戶需求有必要進行管理，如使用知識庫之類工具進行管理。

　　若是公司產品較多，客服、銷售或市場一時難以區分歸屬哪一個產品經理負責，公司也能夠安排一個需求收集的產品助理，由其與各產品經理溝通。

4.3 產品需求分析

　　產品需求分析是軟件產品的起點。產品需求分析的輸入是用戶需求，輸出是產品需求規格書。

　　一個合格的產品經理不是客戶需求的簡單傳遞者，而是將各種用戶需求綜合考慮，再結合公司的戰略發展方向和資源優點及限制，產品採用的商業模式，肯定產品需求集合。

　　產品經理對目標市場、目標用戶瞭解的程度，決定了產品需求分析的質量。

　　

　　我認爲，產品需求應重點考慮下列狀況：

• 可用性，不會由於某些功能缺失或性能障礙致使用戶實質上沒法使用產品；

• 產品有哪些類型的用戶，不一樣類型的用戶訴求是什麼？現狀狀況有哪些痛點？

• 競爭產品的哪些優勢必須保留，可否進一步強化；

• 不要輕易去改變用戶的使用習慣，若是須要，要準備付出市場教育的成本；

• 特點功能（賣點）的價值論證要充分；提升特點功能的易用性；

• 研究有哪些商業模式，對軟件產品的需求會有什麼影響？

4.3.1 產品可行性分析

　　理論上，產品可行性分析在產品立項時已經論證。但隨着產品需求的明確，各需求項的可行性仍然須要仔細分析，若是代價太大或有法律風險，應及早想法應對。

 

　　對用戶需求進行裁剪，分析整理出產品特性需求，即feature list。

　　針對每一條產品特性需求，應說明：

• 用戶類型是什麼？

• 提供什麼價值或解決什麼問題？

• 需求的優先級；

• 有何限制條件？

• 實現是否有技術障礙？

• 實現代價多大（大中小量級）？

• 是否有專利、監管等法律風險？

 

　　必要時，產品經理可組織預研工做，以驗證技術可行性，消除技術障礙。

 

　　若是一切沒有問題，即與最初的可行性研究報告沒有大的衝突，代表一切順利；不然就須要評審或公司高層決定進行相應調整。

　　而後可進入下一個環節。

4.3.2 產品版本規劃

　　產品版本規劃，即將產品需求集合劃分不一樣的子集合，並計劃產品路線圖，明確各里程碑的功能集合。

　　產品版本規劃，能夠給各方一個總體產品輪廓，在哪一個時間節點提供哪些產品特性。

　　實際上，不少時候前幾個階段規劃相對靠譜，後面的階段隨着用戶使用產品給出的反饋，每每會有較大的調整。

4.3.3 MVP規劃

　　最小可行產品（Minimum Viable Product，簡稱MVP）。快速地構建出符合產品預期功能的最小功能集合，這個最小集合所包含的功能足以知足產品部署的要求並可以檢驗有關客戶與產品交互的關鍵假設。用最快、最簡明的方式創建一個可用的產品原型，這個原型要表達出產品最終想要的效果，而後經過迭代來完善細節。

　　若是採用MVP開發模式，須要肯定當前MVP及下一個MVP迭代的產品需求集合。

　　MVP的迭代方法，至關因而先從產品需求集合中抽取出骨架，而後逐漸豐富血肉，從粗糙的原型逐步過渡到精細的產品。

　　MVP迭代方法，能夠確保核心功能和系統結構的穩定性，即便有問題，也是最先被驗證和發現的，所以，開發代價最小，且始終與用戶保持着溝通，反饋，符合敏捷開發的精神。所以，值得提倡和推廣。

　　規劃MVP需求集合，可從回答下列問題出發：

• 核心用戶是誰？

• 核心功能是什麼？

• 圍繞核心用戶和核心功能，還須要哪些次級功能和更周邊功能？

• 次級功能和更周邊是否必須開發實現？可否直接先配置數據，暫不開發？

• 性能指標、併發可用性、系統可靠性、數據規模和積累速度等有何需求？

 

　　規劃了MVP迭代的功能集合，而後進入產品需求細化階段。

4.3.4 產品需求細化

　　不論是否使用MVP迭代開發模式，產品的feature list對於開發來講，實在是太粗線條了，所以須要細化。

　　若是有交互的功能需求，通常會進行UI&UE的交互設計，這方面有一些交互設計軟件，如比較流行的Axure RP軟件。

　　UI&UE設計，若是採用MVP迭代，沒必要一開始作得很精細，即採用低保真模型便可，避免原型有問題被丟棄產生太大浪費。

　　在瀑布式開發模式時代，會要求整理一份產品需求規格書，如今，即便是敏捷開發模式，這份文檔一樣須要。有時候，爲了減小文檔工做量，能夠針對相關的功能集合，出一份腦圖。

4.3.5 產品需求評審

　　產品需求評審，因爲涉及人員較多，分不一樣目的評審爲佳。

 

　　產品版本規劃或MVP評審：

• 用戶表明（市場、銷售、運營、客服人員等）：審查需求優先級和需求完整性；

• 公司管理者：瞭解產品的成本、開發代價、產品特點和競爭力；

• 項目經理：項目實施組織者；

• 技術人員：通常是系統分析員，審查需求的技術可行性；

• 開發項目經理：瞭解產品的需求，開發資源是否能夠保障項目實施；

• 測試經理：瞭解產品的需求，測試資源是否能夠保障項目實施；

• 運維經理：瞭解產品的部署需求，運維資源是否能夠保障項目實施；

• 其它必要的人員：如法務等。

 

　　產品需求評審：

• 用戶表明（市場、銷售、運營、客服人員等）：審查需求優先級、完整性和需求描述是否清晰；

• 項目經理：項目實施組織者；

• 技術人員：通常是系統分析員，審查需求的技術可行性；

• 開發項目經理（或表明）：瞭解產品的需求，開發資源是否能夠保障項目實施；

• 測試經理（或表明）：瞭解產品的需求，測試資源是否能夠保障項目實施；

• 運維經理（或表明）：瞭解產品的部署需求，運維資源是否能夠保障項目實施；

• 開發組成員：瞭解產品的需求，便於後續開發工做；

• 測試組成員：瞭解產品的需求，便於後續測試工做。

 

　　評審是軟件產品質量保障體系的一個重要環節。是集公司衆人之能力，減小差錯、下降風險的一個流程節點。

 

4.3.6 錄入用戶故事

　　在敏捷開發時代，用戶故事是一個高頻詞彙。

　　用戶故事表明了一個產品的需求項，固然一個用戶故事能夠分拆爲更多下一級的用戶故事。

　　很是認同網上的一個觀點，用戶故事是產品經理與開發的一個約定，你們一塊兒將此需求澄清。

　　所以，那種認爲用戶故事就是產品經理的事的觀點，絕對有問題。這種觀點的結果，每每是開發人員常常抱怨產品經理給的需求不清晰，相互扯皮，影響開發進度和質量。

　　關於用戶故事怎麼寫，網上有太多的資料，個人理解：

• 故事名稱：含義明晰，無二義；

• 故事描述：角色、需求、目的表述準確；

• 故事惟一的產品需求編號：穩定性；

• 需求優先級必須有；

• 驗收標準：必需項，如一時沒法肯定，可留待軟件需求分析後補上；避免標準過於嚴苛或太寬鬆。

  用戶故事可能包含的附件有：交互設計原型，外部接口文檔；還有部分須要軟件需求分析後進行補充，包括軟件需求規格書（SRS）和數據字典（DD）。用戶故事能夠引用相關章節或編號。