為什麼產品研發團隊要做一套自己的組件庫？

(閱讀時間: 大約 3 分鐘)

組件庫 (或者叫 「UI 控制項庫」) 是設計系統的組成部分之一。如果有能力，產品研發團隊應該構建並維護一套自己的組件庫。有些工程師可能會問：「為什麼要自己做組件庫？為什麼不用現成的，比如 Bootstrap? 」

產品研發團隊的目標是研發產品，而不是研發組件。因為用戶並不想要組件庫，而且產品團隊的條件往往十分有限: 需求不明確，資源不足，進度緊張。每天不是在改改改，就是在修 Bug。為什麼要把寶貴的時間和精力浪費在做組件上?

在回答這個問題之前，我想先談談 MVP (minimum viable product)。

最簡可行產品是指以最低成本儘可能展現核心概念的產品策略，即是指用最快、最簡明的方式建立一個可用的產品原型，這個原型要表達出你產品最終想要的效果，然後通過迭代來完善細節。

一個 MVP 是一種策略和流程指向製造和銷售產品給客戶。 它是構思一代，原型，演示，數據收集，分析和學習一個反覆的過程。

最簡可行產品 - MBA智庫百科

你可能看過敏捷專家 Henrik Kniberg 的這幅漫畫。面對產品/市場契合度的不確定性，MVP 是一個合理而且非常流行的模式。好產品不是閉門造車設計出來的，而是根據用戶的反饋不斷改出來的。

如果用戶想要代步工具，那麼當你賣給他一個頂級的輪胎時，他會滿意嗎？不會。儘管你可能知道汽車是由輪胎等零部件組裝出來，但對於用戶來說，這些組件毫無價值。所以，我們應該先做一個滑板，再升級成自行車、最後才變成我們想要的汽車。這樣，才可以儘早檢驗功能、快速試錯，打造出用戶滿意的產品。

但是，這張漫畫是不是缺了點什麼？

這是設計師 Luke Wroblewski 最近發的一張圖。同樣是從滑板，到自行車，再到汽車的例子，不同的是，這張圖裡展示了產品背後的組件，以及它們的種類和數量。用戶體驗越好，需要的組件就越多，組件的質量也越高。

不熟悉產品研發過程的人，很容易對第一張關於 MVP 的漫畫產生誤解: 是不是只要拿著滑板到市場里找到客戶，簽下訂單；然後用賺到的錢去買更好的原材料，找一個新的工廠，就可以拿著造好的自行車和汽車去賣了？

作為軟體的開發者，你不會有這種誤解。因為維護代碼的人是你，你知道代碼是不會從天上掉下來的，只有鍋會從天上掉下來。當你加入一個新團隊，最怕的就是前人留下的屎一樣的代碼。?? 研發團隊應該清楚，產品不僅需要做出來，還需要不斷維護。而可維護性，是研發團隊一直要解決的難題。(除非你的公司滿足於只賣滑板，或者研發工作可以外包。)

熟悉 MVP 理論、有經驗的產品經理也很清楚，團隊不應該先把精力都花在製造最好的汽車輪胎上。我們需要的是，做出一個足夠好的小輪子，讓滑板動起來，再把滑板拿到市場上尋找客戶；但與此同時，產品研發團隊必須對自己的小輪子負責。因為如果 MVP 能獲得良好的市場反饋，研發團隊接下來就必須把這個小輪子升級成自行車輪胎，最後經過研發和測試，改造成足夠結實、耐用的汽車輪胎，讓更多客戶滿意。

產品研發工作不是一蹴而就的，研發團隊需要持續地維護產品。所以，研發團隊也需要持續地升級已有組件、擴展組件庫的種類和數量。MVP 模式給產品的迭代爭取了時間。但是，當我們在打造產品的下一個迭代版本時，我們不能一直忽視打磨組件庫的工作。因為組件是產品的一部分；而組件庫為團隊工作提供了規範，降低了複雜性，提升了可維護性。

歡迎關注我的專欄: