小產品需求用例:如何維護一份可讀性高的產品說明書?

5 評論 28804 瀏覽 137 收藏 11 分鐘

文章主要圍繞如何制作一份可讀性高的產品說明書展開,與大家分享,希望能夠給大家的工作帶來啟發。

新入職產品經理助理的同學,或者是需求人員面對的第一個問題可能不是市場分析、競品分析、原型設計、產品體驗、也不是復雜的業務邏輯,而是把公司的產品文檔通通讀一遍,從而熟悉公司的整個業務流程,了解公司的整個產品線,然而事實是殘酷的,很多同學在第一步就被前輩們坑了,臉上露出大寫的懵B。

很多公司由于開發進度緊,加上產品管理不規范,在開發一個新的產品或者是功能的時候沒能很好的管理和規范文檔,從而導致新來的同學面對一大堆雜亂文字也無從下手。那么究竟怎么維護一份可讀性高的產品說明書呢?

最初進行傳統的軟件開發,我們都要撰寫軟件需求說明書,那時候需求說明書特別重要,因為那時候還沒有原型工具,所有的信息都要開發人員通過閱讀需求說明書來進行編程。好處是大家會認真的對待和迭代文檔。每一個細節,每一處邏輯都會以用例圖,流程圖,活動圖,協作圖,順序圖詳細的進行說明。缺點是那時候還沒有提出敏捷開發的概念,從而導致開發一個大規模的項目需要較多的精力進行維護文檔,而且這個周期特別長,有點繁瑣。而現在我們有大量的工具和文檔工具進行原型以及產品的輸出,最終的目的也只有一個,讓開發人員快速的,更加清楚的理解產品的邏輯和原型設計。下面我們以一個生活小例子來說明。

大家都知道我們做產品通常是解決了用戶在某一個場景下的痛點。幫助用戶解決問題,或者實現價值。打個比方,現在小明下班回家了,但是到了家門口突然發現鑰匙不見了,進不了家門。這時候我們作為產品人員應該怎么辦?小紅遇到這樣的情況傻了眼,馬上求助于小明如何開門,小明由于擁有多年的產品經驗,并且是個動手能力非常強的人,面對小紅的慌張并沒有打亂他的陣腳,小明開始思考起來。

  1. 是誰提出的需求?(小紅提出來的,她是我的女朋友,她的問題就是我的問題,必須解決)
  2. 在什么樣的地方會出現這樣的需求?(鑰匙忘在公司,鑰匙被偷,鑰匙掉在路上)
  3. 發生問題的描述(鑰匙找不到了導致我開不了家里的門)
  4. 為什么會出現這樣的問題(粗心大意,可能是鑰匙被偷竊了)
  5. 需求是否重要緊急?(回不了家當然非常緊急)
  6. 一次性需求還是需要持續的跟進(只要能讓我回家,家里有備用鑰匙,下次注意鑰匙安全)
  7. 需要哪些支持(鑰匙店?門鎖商?開鎖匠?警察?鐵棍撬開?梯子爬窗?消防隊天梯。)

第一步 ?提出問題,分辨真偽需求(需求概要說明)

那我們從上可以知道小明思考這么7個問題無非是想確定小紅真的遇到了大問題,遇到的問題是什么樣的,這個問題會導致什么后果。這個問題是否需必須馬上解決。需要什么資源進行配合。在任何情況下回答清楚這7個問題都有助于幫助我們理清楚現在的境況,從而更好的解決問題。

第二步 ?提出解決辦法(業務流程說明:邏輯整理,提出業務解決辦法。)

既然這個問題現在已經清楚是個非常重要的需求了,那么我們應該怎么解決它呢?

  1. 把門砸開。
  2. 去配一把鑰匙。
  3. 打車回公司看是否落在公司。
  4. 叫開鎖師傅來開鎖
  5. 樓層低的話梯子爬進去。
  6. 自己制作一把鑰匙。

綜合考慮實際情況小明是個動手能力非常強的人,小明決定用第六種方案自己制作一把鑰匙來解決這個問題。(假設小明有這個手藝哦,哈哈)。因為考慮到其他方案可能都是不最好的解決方案,因為砸門可能會引起更大的損失導致門的損壞,因小失大,而且成本不太劃算,其他解決方案也不是太讓人滿意。解決方法,把每條業務方案詳細說明后,梳理出最可行的業務流程解決方案,那么就可以確定我們制作的產品每個場景需要有什么功能了。

第三步 ?把可行性業務流程用例化(業務流抽象成用例)

這步需要我們去明確用例。

第四步 ?把業務用例功能化(產品功能概要:把各個場景下的業務用例功能化)

為了簡單的說明,下面舉的都是簡單的用例:

  1. 為了保證我們的鑰匙能以后能打開門,我們必須要造出一把萬能鑰匙。如果等下自己的門都開不了那就尷尬了,所以我們這里提出要有開自己家鎖的功能,但是小明藝高人膽大,能造出萬能鑰匙(核心功能。
  2. 為了鑰匙不會再掉,我們有報警模塊。模塊可以和手機藍牙綁定,鑰匙離開手機一定距離報警(鑰匙和手機通常是不會有很大距離的,一個人外出時鑰匙和手機通常是配對攜帶,做功能時一定要考慮到場景)。
  3. 鑰匙必須綁定到皮帶上,不脫褲子解不下來,除非不穿褲子。(鑰匙沒了,我還要褲子干嘛?裸奔算了,產品要有自己的特點,差異化。雖然挺弱智的 ,但是也是差異化解決方案)。

第五步 功能流程化(流程圖:利用流程圖把各個功能點串聯起來)

以上的功能是最粗粒度的功能,我們可能在實際過程中需要去不斷細化功能粒度,不斷的去優化調整流程圖,在這一步我建議對每個功能進行順序圖,流程圖,協作圖,活動圖,狀態圖的繪制,盡可能全的描述出各個功能模塊是如何串聯起來工作的。

第六步 流程產品化,且建立產品地圖(設計原型:把功能在原型上體現出來)

上圖就是原型圖,雖然丑了點,但是產品經理的核心在于理清功能邏輯,后面還有UI,UE的工作呢,這里請忽略美。在這里我們必須對原型上的每個關鍵元素進行描述(鑰匙孔,藍牙模塊,核心機關)我們必須在原型上給以注釋。幫助其他人理解產品原型上的元素。

藍牙模塊由于和手機上存在聯系,那么還需要對藍牙模塊進行說明從而制作我們說的產品地圖。下圖就是點擊藍牙模塊顏色按鈕產品的各個界面狀態的展示。在我們做網站中我們需要對各個重要按鈕的跳轉做一個產品地圖,幫助我們更好的理解邏輯。

第七步 產品地圖元素化(頁面元素的詳細說明)

到了這個階段,產品的原型以及產品各個狀態之間的切換,頁面之間的跳轉邏輯關系已經很清晰了,但是對于開發人員來說,他們需要不僅僅對邏輯結構徐璈非常清楚,而且需要對每一處細節都需要把控,這樣的情況下,我們需要去把產品各個頁面也就是產品地圖上的元素進行描述,這樣會更加清楚的幫助程序員去定義字段,以及字段規則,字段之間的聯系。這個層面是我們原型設計的最后一步,一個半成品差不多就在這里誕生了。

PRD和產品原型設計到這里可以說是完成了最基本的撰寫。至于這之后的內容怎么去完成,以及如何提升產品UI,UE我將會再下一篇文章告訴大家,這篇文章雖然沒有告訴大家具體的文檔目錄,但是我已經大概的告訴大家應該以什么樣的方式去引導自己的思路去形成自己的產品說明書,謝謝大家支持。

 

本文由 @Pm_cosmo 原創發布于人人都是產品經理。未經許可,禁止轉載。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 邏輯清晰

    來自廣東 回復
  2. 不錯不錯

    回復
  3. 贊一個,淺顯易懂。

    來自湖南 回復
    1. 嗯嗯

      來自海南 回復
    2. 不錯

      來自海南 回復