(此文章同時發表在本人微信公衆號「dotNET每日精華文章」,歡迎右邊二維碼來關注。)微信
題記:今天的內容是個人一個簡單總結,但願讓沒有任何經驗的入門產品經理對產品設計和需求分析有一個大體的瞭解。固然因爲是我本身的心得體會,因此未必是正確和最有效的。工具
如何設計一個產品,並對其進行需求分析,實際上有不少著做供咱們學習和參考。從學院派的《軟件需求》,到創業派的《啓示錄:打造用戶喜好的產品》,還有雞湯派的《人人都是產品經理》,都值得咱們一讀。誠然經過閱讀經典書籍確實可讓咱們逐步入門需求分析和產品設計,好比我就是16年前備考MCSD的時候,經過一本《Analyzing Requirements and Defining Solution Architecture(英文原版)》入門需求分析的。可是在這裏我指望總結一個簡單步驟和使用的一些方法工具,來讓從未作過這方面工做的朋友也能夠快速瞭解並開始上手這方面的工做。學習
具體內容以下:ui
- 用一句話說出產品的願景(Vision)。我要爲誰(Who)提供什麼(What)產品,能夠爲他帶來什麼價值(Value)。願景是產品設計和需求分析最重要的事情,決定了一個產品的成敗。這一步也同時要對使用者進行剖面分析,又稱用戶角色分析。形式和工具沒有什麼固定的,通常而言就用順手的文檔工具寫出文字便可。
- 根據願景肯定產品的範圍(Scope)。即要回答產品要作什麼不作什麼,通俗而言通常就是產品特性列表。範圍在產品的不一樣發展階段有可能有所不一樣。可是要注意:什麼都作或者適用全部人的產品,要麼不存在,就算存在也是一文不值。Less is More。一樣,用Word寫一個文字或者附加少許圖示的文檔便可。
- 根據範圍肯定的特性,從使用者的角度構想使用場景和業務流程。場景描述的是使用者會如何使用每一個具體特性,而業務流程就是使用的過程。場景描述能夠用文字敘述,而業務流程用Visio等工具畫出流程圖。
- 根據業務流程,獲得UML用例。用例即系統和外部用戶交互的狀況。對於初學者而言,UML用例比較陌生也難以完成這方面的工做。因此從這裏開始,可能就須要開發工程師協助來完成。編寫用例的目的是把純粹從用戶視角的業務流程解析爲計算機視角的活動。只要是繪圖工具均可以繪製用例圖,固然比較專業一點軟件會比較順手,Visio也可完成。另外,此步驟若是比較困難也可省略。
- 根據特性和用例,來建立用戶故事。用戶故事就是用一個固定格式的話語「做爲何用戶,打算作什麼,以便獲得什麼好處」,來詳細描述需求點。用戶故事簡單而言就是對特性進行細化。能夠建立史詩級用戶故事,而後逐步細分,細分到容易評估工做量的粒度。用戶故事理論的最佳參考資料是《用戶故事與敏捷方法》。
- 編寫UI原型。在進行場景描述和業務流程設計的時候,就能夠開始用一些原型工具,好比Mockups或者PowerPoint來繪製UI原型圖。原型圖尤爲能夠補充用戶故事用文字沒法表達的內容。
因爲這是一個入門介紹,因此上述步驟其實不少細節都沒有深刻,也沒有考慮非功能性需求的分析步驟。同時,本文重點是講解需求分析過程,因此也省略了同設計、開發相關的一些步驟。設計
最後再次強調,這並不是最佳實踐,僅僅是給初學者的一點入門總結分享。開發