最小可行產品與良好的特性集合
最小可行產品是和敏捷開發的理念一致的一個概念。下面是InfoQ的Shane Hastie對近日一次有關最小可行產品相關訪談的整理，看了這篇文章會對其大致的概念以及優點增進了解。
在Venture Hacks（Advice for Entrepreneurs）網站上最近的一次訪談里面，評論員Eric Ries討論了最小可行產品（Minimum Viable Product，簡寫為MVP）的概念——只是“剛剛好”滿足客戶的需求，這樣的產品人們樂意付費，而且可以盡快推向市場。正如Reis所言：
最小可行產品應該只包含那些足以讓你交付產品的特性，早期的潛在客戶可以查看該產品，而且至少有一部分人會認可、并愿意購買產品，開始向你提供反饋。
他把這種做法和非常典型的“構建所有能想到的特性”的“散射式”做法進行了對比：
“散射式”做法的問題在于：你只有在完成了所有不同的產品特性之后，才能獲得反饋。為了滿足那些不同的特性，你必須在產品中實現不計其數的特性。而且一般來說，等到產品完成的時候，一切已經太晚，根本無法確保你行進在正確的道路上。
只關注于最小可行產品是有益的，因為基本上你只用說“看，我們的愿景是構建一個產品，解決客戶的這個核心問題，以及這些類型的一般特性領域”，我們認為：對于期冀這種解決方案的前期潛在客戶而言，這些是可以接受的。
如果我們向他們交付了核心的、綱領性的特性，而這些特性可以指出我們下一步的方向，他們就能想象出產品現在暫時不具備但是將來會有的特性。
在訪談中，他舉了一些他的公司如何通過關注于MVP從而達成良好結果的例子，并講述了在沒有這么做時他們所遇到的問題。
他建議使用MVP以真正地驗證產品的愿景——如果你不能識別出MVP，你很可能正在構建一件錯誤的產品——趁早結束它！
將會有一些創業的人找到我，跟我說：“但是等等，我的客戶并不知道他們想要什么。如果我問他們‘你需要這個東西嗎？’雖然答案應該為‘是’，但他們卻可能說‘不’?！?
然而，這只是一個被濫用的借口而已，雖然在有些情況下的確是那樣的。判斷的關鍵在于：哪些才是最小的特性集合？在一些案例中，比如娛樂產品，也許你得先構建出一個早期的原型，或者一個圖樣，或者甚至產品的第一個版本，其中包括你認為可行的最小特性集合。
一個最小特性集合的好處是你有了一系列中間點，可以經常詢問自己“我現在是在關注最小特性集合嗎？我現在是在關注最小特性集合嗎？”
只要你不害怕做錯的負面評論，也就是說，假如你構建好了系統最初的紙質原型，并且向人們做了展示，但卻沒有人想要它，而你不會為此覺得沮喪。這并不意味著，你要因為“忘記它吧，我們永遠做不好”的言論而放棄，你可以說：“好吧，讓我們多重復幾次?！?
如果你堅持對產品進行迭代式的改善，你能一直讓它進一步地經受考驗。在這樣反復10次之后的某個時候，你卻仍然絲毫沒有弄清楚，而且你從客戶那里得到的反饋只是哈欠連連，你可能會告訴自己：“知道嗎？我們走錯了方向。事實上，我們超出了最小可行產品的邊界。這已經不再是可行的產品了?！?
他接著探討了比如TDD、短迭代周期和最小設計這樣的敏捷實踐的應用如何允許了產品的不斷演化，從而交付了價值和競爭優勢。他比較了特性的流動和非線性的網絡結構，比如互聯網：
我現在覺得：與其把特性的流動看成是線性的順序，我更傾向于認為把它看作一個很大的網絡。問題是：對于給定的任何特性，它會在網絡中沿著哪條路徑傳遞？不同的特性應該沿不同路徑傳遞，就好像互聯網上我們在必要時沿著不同的路徑傳遞包一樣。
他舉了一個例子，例子中的特性從來沒有被真正地構建，沒有獲得客戶反饋，也就無從得知它是否給客戶添加了價值（如果我們構建它，客戶真的想要它么？），一直到部署：
即使特性非常大而復雜，在某個關鍵頁面上也要有一個鏈接，告訴用戶可以去做其他的事情，或者用戶在某個關鍵時刻會收到一封郵件。
一般來說，對特性的訪問只能通過一個單一的入口。我們經常在分開的測試里面添加這樣的入口點，看最初是否有人會去點擊它們？這樣我們就能看到相信那里存在這個特性的人們的點進率。
我們同樣可以看到一個有趣的現象，有時只要特性存在，即使沒有人點擊，仍然會在其他方面影響人們的行為。
【編輯推薦】
