起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識關于 SaaS 產品模塊迭代的復盤與感悟
本文主要圍繞筆者參與的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 ，確?？尚行浴?/p>
04 落實推進
每個公司都有不一樣的流程，這里并沒有一個具體規則，說一下我們公司的情況——產品經理上傳 PRD 到藍湖 → 需求評審 → 開發過程中不斷答疑 → 聯調測試 → 上線。
這個流程存在最大的問題，就是信息不對稱，導致效率低、Bug 多。
因此我最近在嘗試推進團隊內部使用禪道，這件事之前一直是技術 leader 在推進，不過除了測試團隊在用，基本是失敗的。
那么在接下來的日子，我需要著重把這件事情做好，提高內部協作效率的同時，進一步提升我在公司的個人價值。
寫在最后
每次做功能的迭代，對我來說都是一次重新思考的過程，讓我重新審視自己的不足。
雖然這只是一個很小的功能設計，但在于客戶的溝通中不僅獲了直接的反饋，也讓我得到了認可，進而可以我做的這些決策是正確的。
「反饋」是做產品最重要的一個環節，缺少它不僅你做的會毫無成就感可言，甚至說無法看到自己的成長。
希望你我在之后工作的過程中，重視反饋、不斷復盤，下次做的比這次還好。
作者：空；公眾號：小木盒產品記
本文由 @空 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議。
- 目前還沒評論，等你發揮！
