產品經理應該如何描述需求?

2020-12-12 騰訊網

編輯導語:產品經理的日常,往往與需求離不開,其中很關鍵的一步就是描述需求。需求的描述需要一定的技巧,優秀的產品經理不僅可以清晰地描述自己的需求,還能讓他人聽懂並且知道接下來該如何進行。在本篇文章中,作者為我們分享的是規範產品體系中與需求描述技巧相關的內容。

一、開場白

「小美, 咱們到會議室去開個會,討論下這個版本的新需求」

開發、測試、美工濟濟一堂, 產品經理把這個版本的需求概要地「說」了一遍,然後就打開小美設計好的「產品原型」講了起來。

產品原型是個好東西, 非常直觀, 一看就知道到底要做成什麼樣子, 頁面之間的跳轉關係也一目了然。

工程師一邊聽,一邊心裡琢磨著更細節的內容。資料庫表該怎麼設計, 表該怎麼改,怎麼做數據遷移,界面的流程該怎麼跳轉, 後臺需要提供什麼樣的服務…

大家嘰嘰喳喳的討論了一個下午,終於安靜了。

看到大家的理解基本一致了, 經理開始做最後的總結陳述: 「怎麼樣? 還有問題嗎? 沒有問題的話小美按今天討論的結果,把界面修改一下, 大家估算一下自己的工作量,下班之間報到我這裡。」

工程師心想,估算也沒啥用, 反正上線日期都確定了。

就這樣,越來越多更加細節的深層邏輯僅僅進入了工程師的腦海, 而沒有形成文檔,存在嚴重的項目「信息失真」隱患。

二、大背景

IBM Developer 的目的就是將程式設計師集結在一起,形成一個社區,進而挖掘我們的集體創新能力。換言之,我們有機會分享自己的一些訣竅,並學習到產品研發管理類的高效方法論。

IBM社區的工程師Donald Bell分享到:「序列圖非常有效」。

對於研發人員,序列圖能澄清業務在未來系統中如何體現;對於非研發人員(產品經理、架構師、業務人員),序列圖能澄清未來系統中,不同對象間的交互,從而進一步傳達清楚整個系統設計方案。

研發人員一般認為序列圖僅對他們有意義,然而,深入了解過序列圖之後,非研發人員(產品經理、架構師、業務人員)也會發現,序列圖顯示不同的業務對象如何交互,對於交流當前業務如何進行很有用。

除記錄組織的當前事件外,一個業務級的序列圖能被當作一個需求文件使用,為實現一個未來系統傳遞需求。在項目的需求階段,產品經理能通過提供一個更加正式層次的表達,把用例帶入下一層次。

那種情況下,用例常常被細化為一個或者更多的序列圖。

序列圖除了在設計新系統方面的用途外,它們還能用來記錄一個存在系統(稱它為「遺產」)的對象現在如何交互。當把這個系統移交給另一個人或組織時,這個文檔很有用。

三、序列圖

1. 概念

序列圖(Sequence Diagram),亦稱為循序圖,是一種UML行為圖。有的人翻譯為時序圖,實際上是不準確的,sequence這個單詞並無」時間」的意思,只有序列,順序等意思。

根據UML規範中對Sequence Diagram的描述:

A sequence diagram describes an Interaction by focusing on the sequence of Messages that are exchanged, along with their corresponding Occurrence Specifications on the Lifelines.

它描述了消息在生命線上按照約定順序執行一種交互行為。它可以表示用例的行為順序,當執行一個用例行為時,序列圖中的每條消息對應了一個類操作或狀態機中引起轉換的觸發事件。

2. 構成

序列圖是由5種元素構成:對象(Object)、生命線(LifeLine)、激活(Activation)、消息(Message)和「組合片段」。其中前4種是常用且重要的元素,剩餘的一種「組合片段」元素不是很常用,但是比較複雜。

我們先介紹前4種元素,再單獨介紹「組合片段」元素。

1)對象(Object)

對象位於序列圖的頂部,以一個矩形表示,對象的命名方式一般有三種:

顯示「對象名」 + 「類名」,例如:手機 – 華為手機;

顯示「類名」,不顯示「對象」,例如:手機;

顯示「對象名」,不顯示「類名」,例如:華為手機。

2)生命線(LifeLine)

生命線是一條垂直的虛線,每個對象底部中心都有。對象與生命線結合在一起就是對象的生命線,其長度取決於交互的時間。

3)激活(Activation)

激活代表時序圖中在對象時間線上某段時期執行的操作,以一個很窄的矩形表示:

4)消息(Message)

消息是對象和對象之間,在發生「交互」和「協作」時,用於交換信息的媒介。可以根據是否並發,簡單的分為兩類:

同步消息(Synchronous Message):消息的發送者把控制傳遞給消息的接收者,然後停止活動,等待消息的接收者放棄或者返回控制。用來表示同步的意義。

異步消息(Asynchronous Message):消息發送者通過消息把信號傳遞給消息的接收者,然後繼續自己的活動,不等待接受者返回消息或者控制。異步消息的接收者和發送者是並發工作的。

5)組合片段

組合片段用來解決交互執行的條件和方式,它允許在序列圖中直接表示邏輯組件,用於通過指定條件或子進程的應用區域,為任何生命線的任何部分定義特殊條件和子進程。組合片段共有13種,名稱及含義如下:

抉擇(Alt):抉擇在任何場合下只發生一個序列。

可以在每個片段中設置一個臨界來指示該片段可以運行的條件。else 的臨界指示其他任何臨界都不為 True 時應運行的片段。如果所有臨界都為 False 並且沒有 else,則不執行任何片段,Alt片段組合可以理解為if..else if…else條件語句。

我們還拿微信支付的時序圖舉例,如果7.3向商家匯款的成功或失敗流程需要在時序圖中體現出來,可以這麼使用Alt片段組合。

引用(InteractionUse):表示引用的意思,某部分交互被定義在另一個圖中。可將一個規模較大的圖劃分為若干個規模較小的圖,方便圖的管理和復用,ref不用要填寫參數。

選項(Option):表示當警戒值為真(符合條件)的情況下進行執行處理的意思,opt需要填寫參數。

循環(Loop):表示循環執行的意思,當條件為真的時候執行循環。也可以寫成loop(n)來表示循環n次,與java或者C#等中的for循環比較相似,loop需填寫參數。

中斷(Break):表示中斷處理,跳轉的意思,類似java代碼中break語句,break需填寫參數。

3. 竅門

1)工具

工欲善其事,必先利其器。推薦使用微軟旗下的 Visio。

2)步驟

劃清邊界,識別交互語境:所謂劃清邊界是是指要確定好繪製序列圖的範圍。在微信支付例子中省略列商家打開微信、輸入收款金額等交互消息,這些不是我們需要體現的,我們主要體現的是用戶的掃碼支付流程。

所謂識別交互語境就是要知道自己繪製時序圖的前提和背景,在微信支付的例子中用戶登錄了微信、開通了支付功能是前提,背景是用戶需要掃描付款買東西。

梳理時序圖中的角色和對象都有哪些:微信支付的例子中角色只有一個,即用戶。對象有華為手機:手機、微信、商家。

對象之間有哪些交互消息:對象之間交互的消息詳見以上序列圖。

3)技巧

從初始消息開始畫,依次畫出隨後消息,並給每個消息分配序號,方便理解;

角色和對象用名詞,消息用動詞;

角色放在序列圖的開始位置,對象重要程度或使用頻率從左到右排列。這就要根據時間的流程考慮了,是一個比較主觀的事情;

控制焦點兩端要以消息元素封頂,控制焦點不要超過消息元素。

參考資料:

https://developer.ibm.com/zh/

https://baike.baidu.com/item/%E5%BA%8F%E5%88%97%E5%9B%BE/1943112?fr=aladdin

https://book.51cto.com/art/201003/190167.htm

四、結束語

產品經理的前進道路,不應該是一場孤獨求索的旅行 。沿途那些美好的風景,有趣的人文,我願意沉澱下來,分享與同行的你,或者是在路上的他。

作者:木深、木小深;公眾號:異世治人錄

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

題圖來自Unsplash,基於CC0協議

相關焦點

  • 初級產品經理如何進行需求通氣會?
    而將「通氣會」和產品工作放在一起稱之為「需求通氣會」的目的,在於邀請需求相關方進行參加,向需求相關方透露接下來準備開展的需求,並請求各位相關方在開發過程中予以支持。既然明確了需求通氣會的含義,那麼作為產品經理,需求通氣會的全流程該怎麼做呢?本文主要從會議前、會議中、會以後的全流程進行介紹。
  • 對比C端產品,B端產品如何做需求分析?
    出資者通常不是產品經理來搞定,由銷售人員或企業高管來直接對接,出資者在實際執行中不會直接向產品經理提需求,而是經由銷售人員或企業高管來轉達需求。通常出資者如果有需求的話,也都是定性需求,如系統可以提升業務效率、系統安全性應該有保障等,很少會出現具體的、定量的需求。
  • 醫療產品經理應該具備哪些能力?
    在工作要點,設計邏輯等等方面我們面對的是複雜的用戶群體,醫院分為民營非民營,用戶角色可以按照病種劃分、可以按健康狀況劃分、可以按照醫護患者劃分、等等每一個角色的不同,那麼我們呢的產品設計思維就不同。面對多樣化的需求,我們該如何去設計項目化與產品化?那麼我們該如何配合相關的工作人員?我們產品設計思維如何做出調整?
  • 產品經理與程式設計師之間如何破局?
    華為雲DevCloud資深產品經理受邀分享主題「如何讓團隊在高度共識中完成需求與設計溝通」,介紹針對項目需求設計中經常出現的項目團隊需求理解不一致、需求共識不到位,從而導致需求返工、項目延期、團隊成員積極性不高等問題的應對方案。  在日常項目管理的需求設計中,相信大家都會遇到許多的為什麼:  1.為什麼需求不合乎用戶的想法啊?
  • 產品新人應該如何用好「原型」?
    原型,是產品經理日常生活中必不可少的一樣東西,畫原型、講原型,每天幾乎佔了一個產品新人50%的時間。如何做好這件事情,成為了每一個產品新人心中的困擾。本文作者就以自身一年多以來的實習經歷,來總結一下如何做好一份令大家滿意的原型。一、過於追求樣式特效剛開始實習的時候,上級會分配到一些新功能需求,往往會需要去從0-1去畫原型。
  • 一個產品新人如何通過產品經理大會破解迷茫
    我要去哪個行業做產品經理?於是帶著許許多多的疑惑我來參加了2020產品經理大會上海站,來聽一聽前輩們的故事。在這裡我找到了一些答案,並且在和老師們的溝通中知道了接下來應該要做的事情。我在這裡將對我印象比較深刻的幾點筆記分享給大家,希望也能對大家有所幫助。
  • 產品經理是誰?產品經理是做什麼的人?產品經理調色板
    詩人洞察用戶需求,描繪美好願景。是科學家。不管如何,產品經理這個職業的盛名卻是大得很,一本《人人都是產品經理》又似乎將產品經理的門檻降至海平面,好多開發、運營、銷售、測試的同事都找過我希望轉行做產品,這讓我時常捫心自問,真的所有人都是產品經理麼?
  • 產品經理如何寫出一份「簡練」的PRD
    所以讓我們重新梳理一下BRD、MRD和PRD在一個產品調研、設計、開發、上市中分別起到怎樣的作用,以及它的受眾是誰,需要如何影響受眾 (熟悉的概念的朋友可以跳過這一部分)。 理清三者的關係後有助於產品新手明白哪些內容是應該在BRD和MRD中完成的,哪些內容才是PRD的核心,進而明白為何PRD可以很「簡練」。
  • 如何合理的設計B端產品經理的考核目標?
    對於負責基礎服務的產品經理,考核其接入下遊系統數量,可以倒逼產品經理更加主動地推進基礎服務在企業內的推廣和落地。雖然很多時候這種基礎服務的推廣應該由上而下推進,但是在考核目標上給出直接要求,肯定對產品的推廣有所幫助。 第二,考核需求或項目的按時上線和質量。
  • SaaS產品|如何用場景需求清單梳理場景
    小編 | 一騎紅塵妃子笑學習來源 : #三節課#預計閱讀時間:4分鐘前面我們整理了關於SaaS產品的定義以及調研方法,今天我們用一種通俗易懂的方法來進行場景化描述小王是某創業公司的產品經理,由於昨晚忘了定鬧鐘導致起床比較晚。平時走到公司樓下的時間綽綽有餘,今天只剩下了2分鐘,想起了公司的規定晚到30分鐘會罰款100元,於是快速的掏出了手機,打開釘釘,快速的完成了打卡。你看是不是這麼描述你在腦海裡可以大致想起來小王的一系列動作。
  • 「滑鼠加水泥」時代,產品經理要如何應對?
    而在時代趨勢下,企業對產品經理的要求越來越高、產品經理的群體競爭也愈發激烈,這時候產品人該怎麼做呢?前言從事8年產品經理工作,我經歷了產品經理行業的變革……記得12年的時候找產品經理的工作,只要會畫原型、寫需求具備產品經理的基本素質,2周內就可以找到一份工作。
  • 工作了3-5的產品經理,你真的應該好好學學產品規劃了
    新項目需要一位懂產品規劃,並且可以拆解落地的負責人。大概面試了20來位3-5年工作經驗的產品經理候選人後,一直沒有找到合適的人選,李哥心情十分複雜。不禁在飯桌上吐槽道:現在的產品經理,工作三五年,很多還是浮在執行的表面,對功能、界面、項目跟進有很多研究,但一講到產品目標和戰略規劃,不是一頭霧水就是單憑過往的經驗做決策。
  • 全媒派 | 新聞業需要產品思維嗎?詳述記者如何成為產品經理
    所以,如果媒介產品想要爭奪受眾的注意力,就必須要和其他產品競爭。 如何生產成功的產品已經成為了媒體人必須要考慮的問題。首先,必須要了解受眾的需求,找到更能滿足受眾需求的方法,同時找到好的盈利模式。
  • 好書推薦《人人都是產品經理》PDF網盤分享
    定量——問卷調查、數據分析、日誌分析《長尾理論》「沉默的大多數」定性——定量——對於數據的敏感,對商業的敏感;善於發現數據背後的原因;在需求提出或者說產品設計、迭代階段就應該將數據分析結果呈現出來。產品經理vs項目經理產品經理是靠想,產品經理是做正確的事,其領導的產品能否符合市場需求,是否能給公司帶來利潤;項目經理是靠做,項目經理是把事情做正確,把事情做的完美,在時間成本和資源約束的的條件下完成目標。
  • 產品經理的六大核心能力是什麼?
    產品經理的核心職責,永遠是創造需求,而非僅僅解決問題。經過幾年之後,產品經理成長的障礙更多來自於自我認知。遺憾的是不是每個人都能頂上CEO的帽子,而且產品經理通常手無縛雞之力——設計需要設計師,開發需要工程師。如何在非授權的前提下,贏得客戶、設計團隊、工程團隊的尊重,達到自己設定中裡程碑,這其中存在大量的溝通、個人魅力、對結果的承諾、從錯誤中學習的內省過程。好的產品經理一定是可靠的,勇於承擔責任的。 分析能力 這個無需多言。
  • B端產品如何進行業務全場景的需求梳理?
    如果你不能回到業務場景,回到用戶使用產品的場景,不能從用戶使用場景的角度來回答、溝通問題,那麼很多時候會造成溝通的不順暢,以及產品推進受阻的現象。2.回到原點思考, 我們經常講,產品經理在具體工作的過程中,往往思考的時間要比畫原型圖、寫文檔的時間還要多,才是比較合理的時間分配。
  • 高級產品經理必備|需求太多優先級怎麼排?完爆KANO模型的WSJF模型
    編輯導語:對於高級產品經理來說,在面對需求很多的情況下,應該如何去安排優先級呢?本文作者分析了常用的KANO模型和四象限法的缺點,推薦了WSJF模型,並且詳細地介紹了其使用方法,希望能夠帶給各位產品經理們一點啟發。
  • 轉崗產品經理,應該準備些什麼?
    編輯導語:我們經常會遇到一些職位轉崗產品經理,比如研發、技術、設計等職位轉崗,當時是針對一個崗位,而產品經理需要掌握的技能變多,需要怎麼轉變?本文作者分享了關於轉崗產品經理需要準備的一些能力,我們一起來學習一下。
  • Google產品主管Ken Norton的6條心得:如何招聘一位優秀的產品經理?
    在那段時間裡我只招聘了一小撮產品經理。但是有人是一直負責招聘產品經理,而我也一直在面試小組裡。你應該知道的第一件事就是大公司是專門化的,而創業公司是每個人都做所有事的一小部分,所以你需要一個很強的通才。更重要的是,因為很難預測未來,所以你需要適應能力強的人。你可能想你在招聘某人去做某項特定的工作,當那件特定的事可能在幾個月裡改變。
  • B端產品經理入門的第一年做了什麼?
    其中,在《B端產品經理必修課》裡作者對產品經理的必備技能做了如下歸納:通過書中的技能描述及結合我的工作實際情況,我先學習了產品原型設計軟體的使用、產品文檔的撰寫、項目管理的知識以及進行了一些軟技能的磨練。