本文主要圍繞筆者參與的SaaS產品中的「如何規劃并設計數據看板內容」展開，并復盤了整個歷程以及心得體會。

公司 3 月份的產品規劃，一是解決標桿客戶提供的 9 個業務問題，二是在使用過程中發現問題，并做相應的優化調整。

而最終的結果，是在 3 月份推進并完成了 20 個需求，目前還有 2 個業務問題沒有解決。這其中包括 App 端創建任務，以及數據看板第二階段的重構。

這篇文章的主題，主要是圍繞「如何規劃并設計數據看板內容」做展開，復盤一下整個歷程。

目的是提升自己的產品設計能力，并爭取下一次能做得更好。

接下來，我闡述一下了這整個過程。

01 需求評估

SaaS 產品的本質是能夠解決對方的業務問題，因此對方提出的業務問題永遠是我們需要優先考慮的。

重點在于做不做、怎么做、先做哪個后做哪個，這都需要提前想好并與上級達成一致。

把這些我們在梳理清楚后，隨后反饋給了對方，這樣可以做到彼此間心中有數。

接下來說一下數據看板的情況。

由于之前做的很粗糙，只能做到演示的效果，但根本無法解決實際的業務問題。而隨著版本的更新迭代，客戶數據量的不斷增加，對方慢慢地開始重視數據看板的內容——這不僅能幫助客戶提供業務決策的依據，同時直接影響公司營收。

因此數據看板重構這件事肯定是板上釘釘，在能解決對方業務問題的同時，盡可能的做到通用性。

最后我們將數據看板迭代的目標，拆分為如下 4 個小需求。

1. 門店完成情況

解決任務下派后，具體哪些區域或者說門店存在「未完成」的情況。

2. 巡檢得分情況

通常是以月為單位，對比這段時間內巡檢的平均得分，同時關注每個分數區間內的門店數量。

3. 巡檢問題占比

關注某個巡檢模板中，巡檢大類里的巡檢項違規情況。

4. 紅線項違規情況

必須重點具體到某家門店，違規了哪個紅線項，以及督導提交的內容說明。

分析完要做什么之后，接下來就是做迭代規劃了。

02 迭代規劃

在之前的文章《SaaS 產品設計中，如何理解產品與需求？》，我有詳細講到需求的優先級判斷。

如果只是簡單的判斷，你會覺得這 4 個小需求的優先級是并列的，應該一起做。

但要知道這會導致開發周期會很長，將會面臨這么幾個問題。

1. 對外，客戶的焦慮催促

計劃總是美好的，但客戶不會為規劃買單，尤其是對于 SaaS 產品來說。

在我們告知他們產品接下來會上的功能時，還需要說明大約上線的時間。

從心理的角度上來說，我們得「先有后加」。也就是剛開始可以少一點，在對方使用的過程中我們繼續做開發迭代。

而這個想法最終的實施方案，可以參考后面的圖片。

2. 對內，團隊成員的壓力

（1）前端開發的挑戰

之前做數據看板的前端已經離職，而接手的前端還不熟悉這塊內容。因此我們不得不考慮系統的穩定性和上線后的實際效果，控制第一個階段的內容。

（2）對方案的深入思考

雖然有了方向，但重點是如何呈現，并且對方能夠看得懂，并且用得明白。

這個過程需要多次的碰撞和交流，而 4 個小需求必然會導致精力分攤，未必能真正的解決對方的業務問題。

為了解決這個問題，我們需要考慮的是平級間需求的優先級。

核心理念比較簡單，就是優先解決對方的底層問題，讓對方先用起來。

不知道你有沒有發現，這個 4 個小需求存在先后的邏輯關系，如下圖。

03 方案制定與溝通

這一步就開始上手做了，我目前的習慣分為這么幾步。

1. 先發散，再收斂

簡單來說就是畫腦圖，大類上分為業務問題、對比緯度、數學模型、注意點等。

首先是在過程中想到什么就寫下來，但需要不斷回顧每個點是否脫離了業務問題、是否不夠通用、是否真的能解決問題。

然后再將這一個個的點聚合起來，這個過程可能會打亂你原來的分類。

但是不要緊，邏輯上清晰就行，畢竟沒有什么是一成不變的。

最后再做整體的回顧，重新審視一遍，避免低級的邏輯錯誤。

2. 畫原型，做交互

這一步并不是直接產出 PRD，而是出線框圖與你的上級溝通，彼此在早期達成意見上一致。

過程中一定存在很多問題，慢慢探討，一步步去修改。

直到沒有大問題后，開始做線框圖的交互，使用真實的數據，并做到每個維度下的數據填充。

之后就是拿這個跟客戶面對面交談，通過演示讓對方提出意見。

需要注意，溝通過程中你需要把控節奏，并隨時記錄信息。比如對方想要導出功能，你可以適當詢問原因、導出頻率、給誰看等等。

但需要牢記你的目標，這個版本要解決的「可用」問題，貫徹 MVP 原則。

而記錄對方的信息是為了日后的溝通，做到心中有數，但絕不可以許諾對方這個版本能夠解決。

3. 修改出圖，與對方確認

在跟對方達成一致后，會議后及時做出調整，根據情況推進 UI 出顆粒度較粗的圖。

一是因為原型線框圖粗糙，而 UI 圖能夠讓對方眼前一亮，覺得我們很上心；二是對方可以拿來做匯報用，效果很直觀。

做服務就要做全套，心理這套打法在任何領域都是一樣的，畢竟與你溝通的是人。

4. 出最終 PRD

這一步相信大家都很熟悉，有了前面的線框圖，這里開始做邏輯補充。

需要注意數據看板的邏輯比較復雜，這時可以借助比如「交互與邏輯自查表」，避免出紕漏。

在關鍵邏輯上可以咨詢開發或技術 leader ，確?？尚行?。

04 落實推進

每個公司都有不一樣的流程，這里并沒有一個具體規則，說一下我們公司的情況——產品經理上傳 PRD 到藍湖 → 需求評審 → 開發過程中不斷答疑 → 聯調測試 → 上線。

這個流程存在最大的問題，就是信息不對稱，導致效率低、Bug 多。

因此我最近在嘗試推進團隊內部使用禪道，這件事之前一直是技術 leader 在推進，不過除了測試團隊在用，基本是失敗的。

那么在接下來的日子，我需要著重把這件事情做好，提高內部協作效率的同時，進一步提升我在公司的個人價值。

寫在最后

每次做功能的迭代，對我來說都是一次重新思考的過程，讓我重新審視自己的不足。

雖然這只是一個很小的功能設計，但在于客戶的溝通中不僅獲了直接的反饋，也讓我得到了認可，進而可以我做的這些決策是正確的。

「反饋」是做產品最重要的一個環節，缺少它不僅你做的會毫無成就感可言，甚至說無法看到自己的成長。

希望你我在之后工作的過程中，重視反饋、不斷復盤，下次做的比這次還好。

作者：空；公眾號：小木盒產品記

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

題圖來自Unsplash，基于CC0協議。