精益創業術語“最小可用產品”或MVP，這個詞匯我們常常聽到。筆者基于工作實踐，結合設計案例，推導了MVP模型的數據導出功能。

MVP模型是最小可行產品（Minimum Viabe Product）的簡稱，由Eric Ries在《精益創業實戰》中提出，指的是用最快、最簡明的方式建立一個可用的產品模型，推向市場，測試用戶是否喜歡這個產品，進而迭代完善細節。

功能背景

本人任職于一家CRM公司，負責的是BI產品線，本文舉例的導出需求是大客戶的需求。之前的導出能力只支持到了10000條，而大客戶的數據量普遍在10萬條以上，因此決定增加『大批量跨對象數據導出』的能力。

雖然客戶只提了把導出數量加上去，但是從產品角度出發，這肯定是不夠的，長遠看，這必然得做成一個完整的功能。把功能一步做到位不現實，而且，客戶要求的實施交付期限也不允許。

這個時候，就需要有一個既能敏捷的滿足客戶需求，又可以滿足后期擴展的MVP方案。

開始設計一個MVP方案

1. 會議前

首先，先對系統現有的導出能力進行調研，明確我們的導出功能最終目標是做到什么程度；

然后，對當前正在實施的客戶進行調研，清楚知道客戶想要用導出實現什么，它的使用場景是什么；

最后，上面問題有結論之后，開始預訂日程、會議室，召集相關的同事進行討論，并準備便簽紙、筆、白板等。

2. 會議中

會上，首先確定一個主講人，先對背景、會議目的進行闡述。

然后，將調研結果分享給大家，目的是畫出用戶畫像，這個過程里，需要其他的人提問或者補充，以防漏掉一些信息，逐步完善用戶畫像。

這里的用戶畫像并不是標準意義上的，更多的目的是讓所有人了解什么樣的公司、什么樣的職位、什么樣的場景對該功能有需求

隨后，在用戶畫像完成之后，開始用便簽紙頭腦風暴，寫下『如果你是客戶，你想要用導出實現什么功能』，目的是發現客戶沒提但不排除以后提的點，這也是后續版本迭代的方案來源之一。

一張便簽紙只記錄一個觀點，便于后續的分類與整理。

之后，收集所有卡片，討論出『用戶使用導出功能必須經歷的大步驟』，寫在白板上，并把所有卡片貼在相應的步驟下。然后，挨個卡片進行討論，選出哪些點是『如果不做，就沒辦法滿足客戶這版本的需求』，選出來的這些點就是MVP。

在對卡片進行分類的過程中，以下情況是正常的：

1. 不是所有的卡片都有效。參會人員崗位不同，頭腦風暴的時候可能會帶一些各自的職業習慣，還有可能會有一些主觀性太強的想法，是否有效，需要斟酌；
2. 不是所有卡片都能進行歸類。有些不屬于本功能承擔的能力等，也有可能出現在記錄的卡片上，需要判斷是步驟劃分不合理，還是卡片上的想法不合理。

3. 會議后

及時整理會議記錄，在電腦端上選一個軟件進行輸出，我用的是axure，這比紙上記錄更容易進行整理和分類，control+F不要太好用。還有一個目的是功能實現是分多個版本迭代的，哪些功能點在哪個版本實現了，軟件里記錄更容易。我在輸出的時候是模仿項目管理的那種卡片式記錄的，拖拽排列是很方便。

到此為止，產品設計階段的MVP方案基本確定了，剩下的就出原型、出視覺稿、技術評審……

前期的調研、收集反饋所耗費的時間都是碎片進行的，MVP方案的討論不到兩個半小時完成，然后半小時內完成了原型……

總結這樣做的好處

• 加深對項目的理解。在無法面見客戶、了解客戶需求的時候，產品設計進行輸出時要么按客戶成功的反饋做，要么自我感覺良好，自嗨型輸出，最后的結果是要的你沒有，給的不想用；
• 節省溝通成本。在參與的過程中，會有各種各樣的問題拋出，然后得到回答、討論等，這比看PRD印象更深刻，也會大大節省溝通和信息傳遞所耗費的時間成本；
• 更多的成功參與感。推導MVP的過程可以讓一些非核心崗位的同事有更深的參與感，任何產品的成功都是團隊的成功，只有大家覺得這個產品值得我付出，并且一起努力了，才會有好的結果。

寫在最后

MVP方案確定了之后，在產品后續迭代的時候，只考慮會上討論出的功能點還是不夠的，還需要綜合產品、技術層面輸出一些內容才能進行下一步的設計。

比如：會上無人提到編碼格式，但技術上有限制，這是用戶在填寫表單時必須填的。

最后說點小廢話，MVP是產品設計中非常好用的一個方法，但是如果你的團隊中有人對你的方案持懷疑態度的時候，不妨挑選一些業務邏輯沒那么復雜的需求，來進行一次MVP的推導，成本不大，還會有意向不到的效果，比如，信任感、認同感~~

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

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