《精益創(chuàng)業(yè)》是每一個創(chuàng)業(yè)者洋访，或者創(chuàng)新者必讀的書。書中提到了一個很重要的概念：MVP（Minimum Viable Product）——最小可行產(chǎn)品谴餐∫稣可以說是精益創(chuàng)業(yè)的核心，用白話解釋一下：
愿景不重要岂嗓，最快速最低成本的找到市場痛點(diǎn)需求最重要
概念本身很好理解汁展，但是實踐起來卻不是那么容易。甚至在實踐過程中厌殉，有人會認(rèn)為MVP過于理想食绿，不切實際，或者是沒有必要公罕。我們這里器紧，就結(jié)合我們自己的經(jīng)驗，和大家一起聊聊MVP的重要性熏兄，以及在實施過程中會遇到的問題。這里要先強(qiáng)調(diào)一點(diǎn)，精益創(chuàng)業(yè)不是只適合創(chuàng)業(yè)公司摩桶，在大公司中同樣適用桥状。當(dāng)你的團(tuán)隊要做一個新的產(chǎn)品，要在一個未知領(lǐng)域開拓的時候硝清，就可以考慮精益創(chuàng)業(yè)的實踐了辅斟。
我們做的產(chǎn)品是互聯(lián)網(wǎng)領(lǐng)域的，所以就以一個互聯(lián)網(wǎng)產(chǎn)品舉例芦拿，要做出一款互聯(lián)網(wǎng)產(chǎn)品士飒，從調(diào)研、產(chǎn)品規(guī)劃蔗崎、設(shè)計酵幕、開發(fā)、到測試缓苛，再到推向市場芳撒，往往周期都比較長。參與過這其中變數(shù)太多未桥，大家對于需求的理解多種多樣笔刹，做出來的產(chǎn)品滿足需求的可能性很小，成功率非常低冬耿。這里有很多失敗的經(jīng)典例子舌菜，大家可以搜一下，引以為戒亦镶。但做一個產(chǎn)品日月，確實需要這么多步驟，產(chǎn)品經(jīng)理染乌、設(shè)計師山孔、開發(fā)測試、市場推廣荷憋。一個一個步驟走下來台颠，是不是很無奈？所以是時候轉(zhuǎn)變一下思路：開發(fā)產(chǎn)品時先做出一個簡單的原型——最小化可行產(chǎn)品勒庄，然后通過測試并收集用戶的反饋串前，快速迭代，不斷修正產(chǎn)品实蔽，最終適應(yīng)市場的需求荡碾。甚至在很多時候，并不需要原型局装，就可以測試產(chǎn)品的設(shè)計是否能夠滿足大家的需要坛吁。我想這個時候劳殖，有同學(xué)應(yīng)該會想起來Dropbox的例子了。
如何降低風(fēng)險拨脉，提高速度哆姻，就應(yīng)該盡可能的縮短每一次的迭代。那其實很簡單玫膀，盡量每一次循環(huán)矛缨、迭代，只驗證少量的核心功能帖旨，整個過程就會快起來箕昭，如果在一開始，就想做很多解阅，一個迭代下來的時間落竹，相應(yīng)會長。
那么瓮钥，在實踐的過程當(dāng)中筋量，會面臨哪些問題呢？
最大的問題碉熄，就是愿景桨武。這是公司戰(zhàn)略層的問題。愿景這個東西很美好锈津，也很可怕呀酸。美好在于可以鼓舞大家的士氣，激發(fā)大家的斗志琼梆⌒杂可怕在于，這個愿景不一定能夠?qū)崿F(xiàn)茎杂，并不是你希望错览，或者強(qiáng)烈希望，你的產(chǎn)品就成了煌往。很多公司的管理層覺得我的戰(zhàn)略規(guī)劃很好倾哺，愿景非常清晰，你們產(chǎn)品研發(fā)就按照這個目標(biāo)刽脖，進(jìn)行產(chǎn)品設(shè)計羞海，之后就得天下了。這里有點(diǎn)一廂情愿曲管，并且忽略了戰(zhàn)略和實施之間的鴻溝却邓。也許戰(zhàn)略上確實很正確、很明確院水，但是產(chǎn)品的設(shè)計腊徙，能否實現(xiàn)這個戰(zhàn)略也是一個很大的問題简十，我們要一步到位么？還是說把戰(zhàn)略目標(biāo)進(jìn)行分解撬腾，得到一個個可行的目標(biāo)勺远，不斷的迭代，到市場上驗證时鸵？哪一種風(fēng)險更低，收益更高厅瞎，顯然是后者饰潜，可以隨時調(diào)整，并且可以使得戰(zhàn)略上越來越清晰和簸。試想我們設(shè)計了一個產(chǎn)品彭雾，做了一年上線。用戶的需求锁保，還和一年之前一樣么薯酝？一年中競爭對手，也沒有變化么爽柒？風(fēng)險大大的吴菠。
解決了公司高層的問題，其次就是產(chǎn)品設(shè)計的問題浩村。一個MVP的實踐過程中做葵，就怕產(chǎn)品經(jīng)理不能夠辨別真?zhèn)蔚男枨螅M(jìn)而不斷的加功能心墅，導(dǎo)致上線的時間一而再酿矢、再而三的延期。然而這個過程中怎燥，產(chǎn)出的功能瘫筐，都沒有經(jīng)過用戶的驗證，當(dāng)用戶拿到產(chǎn)品的時候铐姚，一臉懵逼策肝，我該怎么用呢？所以產(chǎn)品經(jīng)理在MVP的過程當(dāng)中谦屑，起到了至關(guān)重要的作用驳糯。在這個過程當(dāng)中，產(chǎn)品經(jīng)理甚至要犧牲某些方面的追求：細(xì)節(jié)的追求氢橙、用戶體驗的追求等酝枢。快速設(shè)計功能悍手，解決主要問題帘睦，滿足用戶需求之后袍患，在后續(xù)版本中迭代改進(jìn)。一個產(chǎn)品最好的體驗是什么竣付，就是解決問題诡延。至于用戶的操作感受，并不是第一位的古胆。MVP適用的并不僅僅是C端產(chǎn)品肆良，需要較大創(chuàng)新的B端產(chǎn)品，也同樣適合逸绎。眾所周知惹恃，B端產(chǎn)品的功能很多，邏輯很多棺牧，似乎難以削減巫糙。那么怎么辦呢？回歸當(dāng)前的需求颊乘、回歸要解決的問題参淹，梳理出主要邏輯，去掉偽需求乏悄，規(guī)劃出來功能點(diǎn)的優(yōu)先級浙值。按照順序來。
技術(shù)研發(fā)這邊檩小，首先要從技術(shù)架構(gòu)上亥鸠，支持快速試錯。選擇輕量的架構(gòu)识啦，適當(dāng)追求技術(shù)的完美负蚊。工程師接觸的是細(xì)節(jié)，也容易陷入細(xì)節(jié)之中颓哮。某一個點(diǎn)可以優(yōu)化一下家妆，或者另外一個點(diǎn)可以通用一些，這樣的點(diǎn)多了冕茅，進(jìn)度就慢了下來伤极。技術(shù)的負(fù)責(zé)人、或者架構(gòu)師在細(xì)節(jié)的把握上姨伤，要有度哨坪。比如說，要實現(xiàn)一個搜索的功能乍楚，驗證產(chǎn)品的可行性当编，沒必要從頭做一個搜索引擎，展示自己高超的技術(shù)徒溪，通過使用開源的技術(shù)忿偷，就可以很好的解決金顿。另外，架構(gòu)上也要輕量鲤桥。舉例來說揍拆，從一些大公司出來的技術(shù)專家，容易做什么都想著畫架構(gòu)圖茶凳，做分層嫂拴、做高可用、做分片贮喧、做負(fù)載均衡顷牌。實際上，在試錯的過程中塞淹，需要這些么？同學(xué)們一定要記住一點(diǎn)罪裹，架構(gòu)是演化出來的饱普，不是一開始就設(shè)計好的。比方說状共，大的架構(gòu)套耕，一定要分層，可以很好的擴(kuò)展峡继，具有很強(qiáng)的靈活性冯袍。但是在產(chǎn)品還比較小的時候，就是浪費(fèi)時間碾牌，所以再合適的階段康愤，設(shè)計合適的架構(gòu)，留著可以擴(kuò)展的點(diǎn)就好舶吗。沒必要一開始就設(shè)計得很好征冷。
上面提到的三個問題，是實施MVP過程中誓琼，比較大的障礙检激。其實說明清楚了問題，就很好解決了問題腹侣∈迨眨總結(jié)起來，如何玩轉(zhuǎn)MVP傲隶？就一點(diǎn)：
快速實踐是檢驗功能的唯一標(biāo)準(zhǔn)饺律。
