本文主要圍繞筆者參與的SaaS產(chǎn)品中的「如何規(guī)劃并設計數(shù)據(jù)看板內(nèi)容」展開，并復盤了整個歷程以及心得體會。

公司 3 月份的產(chǎn)品規(guī)劃，一是解決標桿客戶提供的 9 個業(yè)務問題，二是在使用過程中發(fā)現(xiàn)問題，并做相應的優(yōu)化調(diào)整。

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

這篇文章的主題，主要是圍繞「如何規(guī)劃并設計數(shù)據(jù)看板內(nèi)容」做展開，復盤一下整個歷程。

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

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

01 需求評估

SaaS 產(chǎn)品的本質(zhì)是能夠解決對方的業(yè)務問題，因此對方提出的業(yè)務問題永遠是我們需要優(yōu)先考慮的。

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

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

接下來說一下數(shù)據(jù)看板的情況。

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

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

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

1. 門店完成情況

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

2. 巡檢得分情況

通常是以月為單位，對比這段時間內(nèi)巡檢的平均得分，同時關注每個分數(shù)區(qū)間內(nèi)的門店數(shù)量。

3. 巡檢問題占比

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

4. 紅線項違規(guī)情況

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

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

02 迭代規(guī)劃

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

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

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

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

計劃總是美好的，但客戶不會為規(guī)劃買單，尤其是對于 SaaS 產(chǎn)品來說。

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

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

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

2. 對內(nèi)，團隊成員的壓力

（1）前端開發(fā)的挑戰(zhàn)

之前做數(shù)據(jù)看板的前端已經(jīng)離職，而接手的前端還不熟悉這塊內(nèi)容。因此我們不得不考慮系統(tǒng)的穩(wěn)定性和上線后的實際效果，控制第一個階段的內(nèi)容。

（2）對方案的深入思考

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

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

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

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

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

03 方案制定與溝通

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

1. 先發(fā)散，再收斂

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

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

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

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

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

2. 畫原型，做交互

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

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

直到?jīng)]有大問題后，開始做線框圖的交互，使用真實的數(shù)據(jù)，并做到每個維度下的數(shù)據(jù)填充。

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

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

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

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

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

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

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

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

4. 出最終 PRD

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

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

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

04 落實推進

每個公司都有不一樣的流程，這里并沒有一個具體規(guī)則，說一下我們公司的情況——產(chǎn)品經(jīng)理上傳 PRD 到藍湖 → 需求評審 → 開發(fā)過程中不斷答疑 → 聯(lián)調(diào)測試 → 上線。

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

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

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

寫在最后

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

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

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

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

作者：空；公眾號：小木盒產(chǎn)品記

本文由 @空 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載

題圖來自Unsplash，基于CC0協(xié)議。