MVP：平衡「可行性」和「最小化」

原文做者：Jeremy Bird

原文地址：https://uxplanet.org/lean-product-strategy-balancing-value-and-minimums-aae06e754f68

譯者：付新圓&柴曉燕

「 MVP」或「最小化可行產品」是技術中使用最多，卻最難理解的概念之一。該術語由弗蘭克·羅賓遜（Frank Robinson）於2001年提出，現在這個詞有不少種解釋，但大部分失去了最初的含義。你們如今彷佛都只專一於「最小化」，但忘記了產品的「可行」或「有價值」的部分。

如今大多數技術公司都把MVP定義爲一個「可用的最小功能集合」。可是什麼是可用的最小功能集合呢？這樣作的目的是什麼呢？

弗蘭克·羅賓遜（Frank Robinson）清楚地定義了他所說的「 MVP」。

MVP是爲您的公司和客戶量身定作的產品。它有足夠大的規模，能讓公司和客戶滿意的接受，並能夠正常銷售；但又不至於太大，以致於膨脹到充滿風險的程度。

—弗蘭克·羅賓遜（Frank Robinson）, 2001

換句話說，MVP是一種解決問題的方法，它能夠從三個方面提升用戶體驗：有效性、效率和滿意度。

爲了最小化風險而且獲得最大的投資回報，MVP是精益的。換句話說，MVP是每次迭代都要交付一個可用的最小功能集合，這個集合的功能能夠知足用戶的基本需求，雖不完善但至少可用。Jeff Gothelf和Josh Seidon在他們的書《精益UX》中這樣寫道：

每一個設計都是一個被提議的業務解決方案——一個假設。經過客戶反饋，逐步修正產品設計和解決方案，MVP就能夠來驗證產品是否知足客戶的需求。

—Jeff Gothelf和Josh Seidon，「精益UX」

大多數公司的問題在於，他們對MVP的理解還只停留在「最小的代價」部分。只是急於作出一個版本，用來告訴公司上層項目取得了良好的進展。還有一些公司他們的問題是，徹底忽略了客戶的體驗和反饋。假設你正在開發一個產品，客戶有Frank Robinson、Jeff Gothelf、Josh Seidon，可是他們歷來都沒有使用和反饋過產品，那就不會有MVP了。

MVP首先着眼於基本的客戶需求，快速構建一個可知足客戶須要的初步產品原型。作出最小可用產品，經過銷售數字、應用商店評級等形式得到客戶反饋後，逐步調整產品戰略，儘快達成短時間目標。即便它沒有任何效益，但知足用戶的基本需求，雖不完善但至少可用。爲了不消耗過多精力和費用獲得一個有效的、精益的MVP，基於客戶需求進行開發很重要。

滑板&汽車車架

關於MVP這個概念，我最喜歡的總結之一是Henrik Kniberg撰寫的《賽車vs滑板》(如下是個人團隊成員對原版的改編):

圖片來源：Bethany Larsen和Jason Baddley

在這個假設的示例中，咱們正在改善步行通勤用戶的交通情況。請注意，咱們不是從產品功能角度出發達到客戶需求，而是把重點放在改善步行交通情況的結果上。從A到達B滑板的速度比步行快；踏板車吸引了更多人，而且更易於使用；自行車速度很快；摩托車比自行車還要快；汽車更安全，而且能夠容納更多人。經過以上分析，咱們能夠迅速地將產品價值傳遞到用戶手中，經過客戶的反饋和時間的推移還能不斷增長這種價值。

實現一輛汽車傳統的產品設計思路是一步一步，從車輪、車軲轆、外殼、動力裝置、內部裝飾一個流程一個流程作起，一樣須要不少時間來完成。可是在上面的方法中，咱們在完成的同時還能爲客戶提供了更高的價值(所以也提升了效率、效果和滿意度)。

這裏還要強調的是，從自行車到摩托車是須要一個過程的，不管是製造自行車仍是摩托車，都不是一蹴而就的。經過用戶的反饋，你能夠用MVP的思想不斷的改進、迭代，從而推進得到更好的產品，這就是敏捷和產品進步的意義所在。即便你們都懂得這個道理，但仍是有不少開發人員和領導會由於用戶的反饋而感到困惑。值得再次重複的是：沒有什麼工做是一蹴而就的，若是想要產品進步，那麼它的改善必定離不開你的客戶，只有不斷的改進、迭代、收集反饋，才能獲得更優質的產品。

若是不是由於從自行車中獲得用戶的反饋，也許咱們永遠不會製造出摩托車。若是咱們製造了摩托車後，獲得的客戶反饋是摩托車已經知足了全部需求，那麼咱們就不用去造汽車了，防止浪費時間和資源。

MVP和怎麼去作MVP

但另外一方面，若是咱們要作的項目是城市交通呢？在這種狀況下，滑板是否仍是MVP嗎？固然不是。可是我看到的許多公司都會犯一個錯誤，他們只作到了「最小的代價」部分，卻忘記了產品的有效性，效率和客戶的滿意度。

爲何會這樣？我觀察到，當公司只專一於根據產出衡量成功時，他們就沒法預測結果，就會發生這種狀況。在Scrum世界中，大多數開發團隊都是在完成全部事務、提升迭代速度和準確估計時間點的基礎上進行產出評估的。當你沿着這個鏈走下去的時候，就會進入發佈時間表會比實際改善用戶體驗更重要的誤區。

快速行動雖然很重要（這就是精益用戶體驗的意義所在），可是咱們應該牢記快速行動的方向：提升效率，有效性和客戶滿意度。

引導公司專一於成果

那麼，在持續產出的敏捷世界中，咱們如何將重點轉移到結果上呢？尋找一種讓本身的敏捷團隊以及利益相關者可以按期與用戶溝通的方法。這種溝通方法能夠是遠程的，也能夠是不按期式的。一開始須要一些技巧的，甚至須要對潛在客戶（而不是實際用戶）進行不按期式研究，若是你這樣作並找到一種簡單的方法彙總結果，與團隊其餘成員分享學習經驗，就會發現你的團隊會有很大的轉變。

我過去不得不使用了這種方法。我帶領的是一支徹底不肯意分配時間並拒絕與用戶聯繫的團隊，但經過這種方法，咱們的用戶研究做爲競爭優點爲公司贏得了數百萬美圓的交易。

最後一點，不要認爲這種變化會在一晚上之間發生的，這是一個過程。就像在用戶界面中同樣，在這個過程當中收集用戶需求，採訪用戶（團隊成員，利益相關者，業務主管）體驗。瞭解爲何他們以爲沒有時間了，而後想辦法讓他們知道獲得想要的東西的方式。（例如，更快的更新版本）。

當人們認爲您試圖說服他們改變優先順序時，他們很難被說服。若是你發現什麼對他們來講是重要的，並向他們展現用戶研究將如何幫助他們實現他們想要的，事情就會變得容易得多。

另外一個有幫助的想法是制定在各個階段都有成功標準的路線圖。你的「MVP」步驟是什麼？如何快速地作到這一點，如何進行學習和調整呢？下一步能夠看到什麼？以這種方式設計組織中的流程更改，可以最大限度地減小挫敗感，並隨着您的前進而看到遞增的結果

總結

隨着社會愈來愈發達，用戶的需求愈來愈高會給開發者很大的壓力。可是，當咱們將「最小的努力」和短期的精力集中在用戶反饋和學習上，以提升用戶對產品的有效性，效率和滿意度時，咱們會對開發的產品更有信心，用戶會有更好的體驗感和購買慾。若是用戶仍是不滿意，咱們就迅速進行調整，以減小失敗的損失。