面對客戶各種復雜多變的報表需求，我們如何能快速抓住要點，梳理出清晰的報表邏輯，從而設計出滿足用戶需求的報表，是產品人員在需求調研和分析中很重要的工作，本文把報表分析過程拆解成三個關鍵要素，幫助產品人員快速理解和掌握到報表分析的要點。

在我們的軟件產品設計里面，報表很多時候是不可或缺的一部分，并且報表通常是管理者、高層領導要看的東西，是不是能很好滿足他們的分析需求，往往對項目的成功起著重要的作用。

在今天的互聯網產品里面，報表分析已經轉化為日常的數據分析，成為產品運營的核心工作，所以，如何清晰的理解報表分析中的關鍵點，就顯得尤為重要。

接下來，我們以某互聯網產品統計工具的報表為例，來講述報表分析的關鍵點：

1. ?報表的三要素

要理解的報表的三要素，先上圖：

如上圖所示，每個報表都有三個關鍵要素：報表主題，報表指標，分析維度，我們逐一說明如下：

?報表主題

報表主題，很多時候你也會把它當標題看待，事實上我們也是以主題對標題來進行命名的。

但核心點是，每個報表主題一定清晰的對應著某個分析的目標，代表了客戶期望從這個報表中獲取到的信息，比如上圖中留存分析，通常是基于客戶想分析產品的使用情況，為版本功能優化、用戶體驗改版等提供數據支撐。

但很多時候，特別在一些 TO B項目里面，客戶往往是直接告訴你我需要什么報表，背后分析目的和目標并不一定明確告知你， 這就需要我們在調研的時候，多問幾句“您是用來做哪方便分析的，希望達到什么目標”之類的問題。

只有把報表期望得到的目標理解清楚了，你才能確定一個清晰的報表主題出來。

報表指標

有了報表主題后，很自然的，我們需要用哪些指標來支撐該主題的分析呢，還用上面的留存分析為例， 你看到，事實上是從4個關鍵指標來進行分析的：使用時長、使用頻率、訪問頁面、使用間隔。

這4個指標從不同的方面來對用戶使用產品的行為進行量化、從而幫我們對產品使用情況進行分析。

當然，具體在指標值上，可以有數值，也有基于數值衍生出來的各種百分比，如同比、環比、方差等等多種形式。

另外，指標還可以是復合指標的體現，比如對于績效考核的得分來說，分值就是一個復合指標，而復合指標里面，還蘊含著子指標。

但無論是哪種形式的指標，關鍵點還是要想清楚，圍繞著報表主題，我應該用哪些指標數據來進行衡量。

分析維度

有了報表主題，有了分析指標后，接下來就是分析維度。

上面的留存分析，初看過去， 好像沒看到具體的分析維度，實際上因為這個報表相對簡單，所以分析維度也比較明確，就是圍繞著時間維度來開展的，而實際上對于留存分析，我們經常可以看到“日留存”、“周留存”、“月留存”，這里面的“日”，“周”、“月”就代表了三個不同粒度的時間分析維度。

從分析維度來講，通常就是時間維度、空間維度，不同的維度支撐起我們對趨勢、對發展分布、地域之間差異間進行對比分析，找出存在的問題點。

除開大面上的時間和空間維度，更細化的產品維度、服務類別維度等等對于更具體的定位到問題所在，有著重要作用；

更多的時候，我們還會對多個維度進行組合分析，然后找到其中的趨勢、或者問題所在。

把握住了上面的三個關鍵要素，你也就能比較清晰的來設計一個報表的，但如何來展示報表了，這就是我們要說的第二點。

2.? 報表展現形式

設計出報表了，該如何展示呢，報表的展示形式其實非常多，我們對常用的展示形式說明如下：

• 折線圖： 通常用于趨勢的分析，所以其分析維度通常都是時間維度；

• 柱狀圖：通常用于對比分析，如果趨勢分析是縱向，那么柱狀圖就是橫向的對比分析；

• 點狀圖：多用于多個變量的回歸分析；

• 雷達圖：多用于一個復合指標，存在多個子指標的分析展示；

• 漏斗圖： 銷售分析的經典圖，其主要用于來看轉化率；

• 餅圖： 主要用于看各分支的占比分析，也是一種橫向對比的展示；

• 儀表盤：主要用于展示可以量化成分值類的指標，通常給企業高層管理者，喜歡這種儀表盤的展示，一是因為畢竟直觀，二是因為儀表盤代表著一種企業駕駛、駕馭的感覺，所以很多人直接稱這種圖表分析的組合為企業駕駛倉；

• 熱點圖：是參考氣象云圖的方式來進行展示， 通常用于展示有地域特征分布，并且實施動態變化比較快的數據；

• 地圖：使用地圖來進行展示，通常都是和地域、地區統計分布相關的；

展現形式還有很多，在很多時候也會以多種形式來從不同維度、不同組合方面來展示數據，以求得更直觀、簡單的呈現數據的信息，實際中需要我們靈活應用；

3. 報表的穿透

有了報表的要素、報表的展示形式后， 為了實現某個分析目的，我們還需要考慮報表數據之間的穿透，穿透實質上有兩個方向，一是縱向的穿透，一種是橫向的穿透，用一句話總結是：橫到邊，縱到底。

對于縱向穿透，比如一個部門的績效考核得分，90分， 你需要了解90分里面的各項組成指標的得分情況，然后你向下穿透，分布看到子項的：工作業績完成得分、團隊建設得分、成本支出得分等幾個子項指標；然后可能這些子項指標還有進一步的子指標組成，你需要進行逐級的穿透，最后到每個人得分，每個人的指標情況，從而有效幫你從宏觀到微觀，掌握到整個數據的全貌和細節。

橫向穿透，那即從對比分析方向， 看不同部門之間的、不同區域、不同產品等等方面上的差異，從而為你找到差距提供分析支撐。

綜合以上，當我們在需求調研及分析過程中， 始終從報表的主題出發，抓住報表設計的三個要素，再選擇好報表的展示形式，并做好報表的穿透分析，那么，報表需求和設計工作將變得不那么復雜。

我們結合一個“用戶自助寄件”的需求，分析了從業務需求、用戶需求，向產品功能需求轉化的過程，本節，我們繼續沿用該案例，向大家展示如何高效快捷的繪制出業務流程圖。

在業務流程圖的形式中，對于產品人員來說，最經典的莫過于“泳道圖”，從百度圖片里面搜集的泳道圖說明如下：

（圖片自百度圖片中搜集過來）

泳道圖之所以應用比較廣泛，是因為其：

1. 清晰的展示了該流程里面涉及多少個“角色”；

2. 該業務流程分成了多少個“階段”；

3. 角色活動的邊界、流向清晰；

但一開始要直接來繪制泳道圖，我們總覺得比較復雜，好像有些無從下手，又或是擔心漏掉很多細節，那么到底如何有效的繪制出一個清晰明了，簡單實用的泳道圖呢？

下面我們以“用戶自助寄件”的案例來進行說明。 （該案例來自上一節的連載文章，建議可先查閱上節的該案例：需求分析篇｜從實例分析中理解業務需求、用戶需求、功能需求的轉化）

第一步：將業務分拆成多個階段

用戶自助寄件是一個業務，你也可以理解成一個任務，那么在自助寄件里面，大致可以拆解成幾個階段呢，在上一節里面，我們已經知道，可以拆解成三個階段：

• 階段1：在線填單階段

• 階段2：找柜子放件階段

• 階段3：支付階段

具體階段應該怎么拆，如何拆得比較合理，其實還是在于我們對業務流程的理解程度，我們在調研和需求分析中，是不是真正將業務場景、用戶場景理解透了。

通常對一個任務的階段拆解，你可以從任務執行時間上進行拆解，比如這個例子，填單和找柜子放件，是有時間分隔的，因為往往并不是填完單馬上就會去放件。

然后，你可以從任務執行的位置、操作對象上來進行分割，還以填單和放件來說，地理位置上變了，特別是操作對象上變了，那么也是適合拆成兩個階段。

事實上，對任務階段的拆解，你更多的是從時間、地理位置和操作對象幾個維度上的不同來最后確定要區分幾個階段。

當然，一開始分得不合理也沒關系，因為對階段進一步細節分解、梳理過程中，會幫你發現不合理的地方，然后你還可以繼續修正。

那么，當你第一步進行了業務的階段拆分后，其實你可以簡單的繪制階段流程圖，示意如下：

這個很簡單，我們接著往下說。

第二步：階段內各角色流程活動的梳理

有了第一步的分階段，我們需要對每個階段的細節內容進行梳理，階段細節的梳理，其實要弄清楚的這里面會涉及那幾個角色，這里的角色，不僅僅指用戶，系統或者某個實體作為和任務有交互的地方，都是一個角色。

以“在線填單”為例，這里面有那幾個角色呢，首先，肯定有：

• 用戶角色：就是自助寄件的人；

• 系統：在線填單后，系統要接收處理快遞單，肯定也是一個角色；

• 快遞柜：是用于用戶后續放件的地方，它也是一個角色；

這個案例里面，主要是這三個角色；有了角色后，那么我們就需要對每個角色，在這個階段里面的具體的活動來進行整理。

在“在線填單”的階段，任務的發起角色是“用戶”，主要的活動也是他來觸發的，所以，我們肯定要從用戶這個角色開始梳理他的階段內的活動。

那么用戶在這個“在線填單”里面都需要執行哪些活動呢，其實聯系現實中寄件填單過程，你很快就能理解到用戶主要有“填寫收件人信息”、“填寫物品信息”、“寄件人信息”、“需要的柜子大小等”，整理成流程圖，就是這樣：

這個流程圖里面的活動，其實都是蠻容易就能想到，唯一剛開始可能缺漏的是活動“4”，但其實一開始有缺漏沒關系，后面進一步的分析會幫你發現這個缺漏。

理完用戶這個角色，那么接下來要繼續梳理“系統”這個角色流程活動。

很顯然，用戶在線填完單后，系統要接收該快遞單，要考慮分配怎樣的柜子，以何種方式來讓用戶找到柜子、開啟柜子等內容，那么你會逐步梳理出系統的流程活動是這樣的：

其實系統的活動也還蠻簡單，也是只有5步，梳理完系統后，還有快遞柜，顯然，快遞柜的位置和空閑狀態是由快遞柜本身的系統來返回的，它的流程圖我們在這里暫略，在后面的總圖中會看到。（需說明的是，實際上快遞柜和快遞公司，由于不是一家公司，所以，這里面快遞柜是一個獨立的角色）。

按照角色梳理完階段內各自的活動后，接下來就是整合的操作。

第三步：使用泳道圖來整合各角色的流程活動

有了上面的各個角色的階段內活動圖后，我們這個時候來把它們整合成泳道流程圖，顯然就很容易。

還以自主寄件中“用戶在線填單”為例，最后整合出的泳道流程圖如下：

看起來這個流程圖一眼望去還是比較復雜的，但其實如果你按照上面的三步：

• 第一步，將業務分拆成多個階段；

• 第二步，階段內各角色流程活動的梳理；

• 第三步，使用泳道圖來整合各角色的流程活動；

你一定可以比較輕松的完成整個業務流程圖的繪制。

當然，在具體的整合過程，以及整合后，我們還需要對很多細節進行推敲，完善，很多時候也不是一次性就完成的，這里面還有很多正常、異常的情況需要去考慮，但有了上面的基本方法，你的框架定下來了，細節逐步去完善就不會很難了。

?

在產品的需求里面，經常有這三個概念：業務需求、用戶需求、功能需求，但往往，我們很容易搞混，不清楚他們之間的關系和差異，我們先引用一下比較官方的解釋：

業務需求（ Business requirement ）表示組織或客戶高層次的目標。業務需求通常來自項目投資人、購買產品的客戶、實際用戶的管理者、市場營銷部門或產品策劃部門。業務需求描述了組織為什么要開發一個系統，即組織希望達到的目標。

用戶需求（ user requirement ）描述的是用戶的目標，或用戶要求系統必須能完成的任務。用例、場景描述和事件――響應表都是表達用戶需求的有效途徑。也就是說用戶需求描述了用戶能使用系統來做些什么。

功能需求（ functional requirement ）規定開發人員必須在產品中實現的軟件功能，用戶利用這些功能來完成任務，滿足業務需求

這個解釋其實還是蠻明確的，其實理解這三者的關鍵點，是要先認清楚每個需求針對的對象不一樣：

• 業務需求———對應的是組織或者客戶，實質就是業務的建設方；你也可以類比房地產市場的開發商；

• 用戶需求———對應的是使用產品的用戶；你也可以類比買房的人；

• 功能需求———對應的是產品，即產品要具備怎樣的功能，才能滿足相應的業務需求和用戶需求；類比房地產市場，那就是房子本身。

類比成房地產三個角色后，你發現，開發商通常的訴求是想多賺錢，買房的人訴求是買到物有所值，甚至物超所值的房子；但不管二者怎么想，最終都是需要通過房子來實現，必須建設的房子的屬性達到某個標準才能滿足二者的訴求；

所以，這么一看，你就明白了，其實這三者之間的關系是：

即，業務需求和用戶需求，只有經過需求分析的轉化，變成產品的功能需求后，才能得到實現。

需求實例

接下來，我們用一個簡單的實例來進行說明：

案例：用戶自助寄件的需求

業務建設方：某快遞公司

需求描述：目前很多城市的小區都已經有了快遞柜，但快遞柜主要是用于送件使用，而對于快遞公司收件，用得比較少，某快遞公司，就希望利用快遞柜，來實現用戶自助寄件的需求。

首先，我們來分析其業務需求

這個案例的業務建設方是：快遞公司，其業務需求也很明確，就是：用戶自助寄件。

業務方之所以要建設這個需求，其目的是：希望利用快遞柜，實現更高效的收件服務，減少人工上門收件的等待、低效、人力投入成本高等問題。

其次，我們來看用戶需求

這個案例的用戶，就是每一個要寄快遞的人，那么他們的需求是什么了？

他們的需求，其實就是在進行“自助寄件”的過程中，你盡量讓我簡單、易用，高效、快捷。

接下來，我們進行需求分析的轉化

需求分析的轉化，核心是兩個點，一是對這個業務的場景進行充分的理解和認知，二是想明白業務場景中需求點，要通過何種方式來滿足它。

業務需求是“用戶自助寄件”，這個業務要實現，我們結合寄快遞的實際場景，其實還是蠻容易就能想到，有3個關鍵環節：

1. 用戶要填寫單據：即填寫收發件人的相關信息；

2. 用戶要能找到周邊的快遞柜，并且能打開它；

3. 還需要進行計量、支付快遞費的問題

這三個環節，基本把這個業務的三個關鍵階段說明出來了，它就是：填單——>找柜子放件——>支付。

然后，逐一對三個階段進行具體的分析：

填單階段：

• 業務方需求：必須收件人、聯系電話、寄件人信息清楚、明確等等。

• 用戶需求：能選的就選，能簡單填寫的就簡單填。

轉化為功能需求，你發現，無非是通過表單形式讓用戶把相關信息填上來，而為了滿足用戶需求，你肯定需要設計對收件人的記憶功能，讓用戶填寫一次，后續每次只需要選擇而已（相關的細節還很多，這里只做舉例）。

找柜子放件階段：

• 業務需求：把最方便最合適的柜子告訴用戶，并確保用戶能安全、準確的找到快遞柜、放入快遞件；

• 用戶需求：我就想知道我要把快遞件放到哪里，別讓我多走；

這個業務需求和用戶需求說起來簡單，轉化成功能需求時，其實里面還蠻多細節的：

1. 位置服務肯定需要，一是為滿足發現柜子的需求，二是也有導航的需求；

2. 如何打開柜子呢？從我們的產品經驗或者競品參考來看，可以有掃描開啟、驗證碼等方式；

3. 如何保證用戶去到快遞柜，一定就有其空的柜子可以給他放了，這里面就涉及一個快遞柜忙閑資源的管理；

所以，這里轉化為功能需求時，你發現：有位置服務功能、掃描開啟/驗證碼開啟功能，柜子資源分配管理功能等；

支付階段：

• 業務需求：根據收費標準，準確無誤、及時收到用戶快遞費。

• 用戶需求：支付方便。

• 功能需求：

1. 如何來計量，由于是自助寄件，稱重顯然不合適，那么按體積是一種較簡便的方式，而如何按體積了，其實根據可快遞柜的柜子；

2. 如何支付，這個還簡單，可以使用比較常用的幾種支付方式就好；

以上，都只是簡單的需求分析和轉化的過程，實際的需求過程中，我們經常講需要結合業務場景、用戶場景把一些關鍵細節挖掘出來，并能在產品設計時考慮進去，以給用戶一個良好的體驗。

業務場景細節的挖掘

比如：在上面的開啟柜子的方式中，到底用掃描開啟還是驗證碼的方式呢？

其實用“驗證碼開啟”會更合適，因為會存在很多這樣的場景，某個寄快遞的人，剛好家里有人下樓，或者認識的鄰居下樓，而快遞柜就在小區門口，那么找人代勞一下放件是一種很正常的事情，那么這時候，使用驗證碼就是一種最合適、簡便的方式。

又比如：某用戶希望自己的快遞能更快的被寄出去。

那么，如果在給用戶呈現周邊分布的快遞柜的同時，還告訴用戶，該快遞柜的收件時間，目前快遞員的分布位置，是不是能讓用戶更好的去選擇呢。

這樣的細節還很多，需要在實際分析中，更好的去理解用戶場景、挖掘細節，并逐步的完善。

通過上面的分析，我們發現，只要你充分認清楚業務需求方的訴求、用戶在執行具體任務時的訴求，并對產品的常規實現方式有了解的話，需求分析并不是一個多復雜的過程，就是這么一步步去推理、去轉化的過程。

而要把每個細節做透，就必須在實際中多去磨練，在生活中多體驗，學會場景化的思維方式。

來源：pm28

?