在中國，精益創(chuàng)業(yè)更像是一種世界觀而不是一種方法論。所謂世界觀，就是當你拿出一個簡陋原型的時候對投資人和市場用戶的說法，但是如果連你自己都相信這個說法那你就沒救了。

具體來說，精益創(chuàng)業(yè)在國內有以下四個障礙。

原因 1：比競爭對手更敏捷開發(fā)的唯一方法是放棄精益創(chuàng)業(yè)

在精益創(chuàng)業(yè)中一個重要的方法論是做任何事情都要有認知。從開發(fā)的領域來說，就是你添加一個按鈕并不是工程師或產品經理說了算的，而是要做出兩個版本一個版本有安妮和一個版本沒按鈕讓兩個版本都接觸到用戶。根據用戶行為數據的變化，最終決定采用某一個版本作為正式版本。這聽起來是一個十分美妙的事情，工程師再也不是想當然的開發(fā)出用戶根本不需要的蹩腳的產品，產品終于腳踏實地的每一步都踩在用戶的痛點上。

但是，現實是什么樣的呢？

現實是，在中國，幾乎每一個產品類目下都會有至少兩個競品（如果沒有，你要考慮是不是你們的產品形態(tài)根本是作死）。而每個競品的工程師都是在全速開發(fā)的，根本沒有時間在同一個功能上并行開發(fā)出兩個版本來進行這樣的測試。

因此，在中國的創(chuàng)業(yè)環(huán)境下，產品經理或者說創(chuàng)業(yè)團隊的頂頭上司的判斷其實往往決定著一個公司的生死。從全局來看，基于用戶需求反饋的開發(fā)循環(huán)和 ABTest 也在進行，只不過是在不同的創(chuàng)業(yè)團隊之間進行。在做同一個產品形態(tài)的時候，A 團隊選擇了 A 增長引擎，B 團隊選擇了 B 增長引擎。等到的 B 團隊發(fā)現 A 增長引擎是正確的時候幾乎是無法追上 A 團隊的。而 C 團隊如果選擇在自己的產品線上驗證 AB 兩種增長引擎是否能夠成功，那么幾乎可以肯定的是他必將敗給 A 和 B 團隊中的某一個。

原因 2：開會并不比開發(fā)更重要

精益創(chuàng)業(yè)可以說是一本產品經理的紅寶書，它的發(fā)源地是工程師資源過剩、全棧工程師遍地跑的硅谷。

在精益創(chuàng)業(yè)中曾經很明確的描述過這一點：媒體總是將那些大公司的創(chuàng)始人描述成一個天才，他們總是一拍腦子想出一個點子然后在經歷一段蒙太奇的開發(fā)鏡頭之后就邁向了人生的成功。硅谷的許多創(chuàng)業(yè)者因為自身是工程師，他們認為那段被蒙太奇的內容自己一個人就能干的過來。而確實，全棧工程師也有著這樣的優(yōu)勢，他們能夠憑借自己的力量將想法變?yōu)楝F實。

精益創(chuàng)業(yè)就是這樣一本告訴工程師們：好了，我知道你們開發(fā)能力很強，但是你們開發(fā)出來的東西都是屎，在沒有數據驅動，用戶需求拉動的情況下，無論走多遠你們都只是在錯誤的路線上掙扎。

因此，在精益創(chuàng)業(yè)的方法論中，會議和溝通成為了一項比開發(fā)更為重要的事情。

理由很簡單：找到方向比邁腿更重要。

所有的創(chuàng)業(yè)者和投資人不用我列舉數字你也會對國內的技術人員公司占比有一個直觀的印象——我見到的大多數創(chuàng)業(yè)團隊中三個創(chuàng)始人里有一個技術創(chuàng)始人就不錯了。有的創(chuàng)業(yè)者甚至從一開始就沒打算找技術創(chuàng)始人，而是雇傭了一名員工來解決所有的開發(fā)問題。

國內創(chuàng)業(yè)項目中，負責邁腿的人本來比例就要低上不少。那些非研發(fā)崗的聯合創(chuàng)始人他們在跑展、站臺、融資之外的基礎性工作就應當是掌握公司的方向。

在這種情況下，如果仍然要求邁腿的人每天拿出大量的時間來開會討論該往哪邊邁腿，這個企業(yè)基本也就不用邁腿了。

原因 3：并不是創(chuàng)業(yè)團隊中的所有人都需要知道什么是精益創(chuàng)業(yè)

作為一個工程師、程序猿或者隨便你怎么叫的研發(fā)崗位人員，不論他在大公司還是在創(chuàng)業(yè)公司，無論是在五道口還是在硅谷。他們都討厭一件事：編程的時候被打斷。

研發(fā)人員的普遍認識是：打斷我們編碼（拉我們去開會討論需求）是大幅度降低效率的一件事。

而精益創(chuàng)業(yè)方法論從硅谷的實際情況告訴硅谷的工程師：不，你們離開了有數據驅動的專業(yè)產品經理，效率再高開發(fā)的還是一坨屎。你們停下 Coding 的手開始開會的話，可以挽救這個致命的現象。

然而這顯然并不符合中國的實際情況，中國的實際情況是即使產品經理、你的部門上司、你團隊的正牌創(chuàng)始人找你去開會，他們也不會給你的研發(fā)帶來任何幫助。你們會在吵架中度過一個下午，他會沒有任何數據支撐的告訴你「這是用戶需求」，你會異常抵觸的告訴他「這技術上實現不了」。最后浪費了一下午的時間，由于你的創(chuàng)始人根本不懂技術，最后你還是按照原先的計劃開發(fā)但是你的進度晚了一整天，并且你的創(chuàng)始人已經開始準備在下一輪融資中把你的股權稀釋了。

在一個優(yōu)秀的創(chuàng)業(yè)團隊中，創(chuàng)始人（如果不是技術創(chuàng)始人）和開發(fā)崗位之間應該是彼此相信并了解對方的水平的。優(yōu)秀的創(chuàng)始人（在中國的產品經理人創(chuàng)業(yè)和媒體人創(chuàng)業(yè)的氛圍下，我們假定他不是一個開發(fā)）應該閱讀精益創(chuàng)業(yè)并深知自己要做的不是拍腦袋而是去做需求調研和數據反饋，并在了解創(chuàng)業(yè)團隊（自身）所使用的核心技術和信任研發(fā)崗（不論他是你的聯合創(chuàng)始人還是員工）的基礎上提出「技術上可行的需求方案」，成為市場與研發(fā)之間的緩沖。

如果能夠達到這種平衡，創(chuàng)業(yè)公司就完全不需要將技術研發(fā)崗卷入到精益創(chuàng)業(yè)無比復雜不斷打斷程序猿入定 Coding 模式的會議流程中來。

精益創(chuàng)業(yè)對中國創(chuàng)業(yè)者的啟發(fā)應該是告誡那些在創(chuàng)業(yè)團隊中拿著大頭充當產品經理的創(chuàng)世人們：多了解技術，少拍腦瓜，給你的聯合創(chuàng)始人提需求之前問問自己想沒想好怎么驗證假設，如何進行創(chuàng)新測量。而不是把這些事情統統丟給你那個身兼研發(fā)、測試、產品經理的技術創(chuàng)始人，然后當他的開發(fā)循環(huán)剛跑起來就踢開他的辦公室神采奕奕的喊一聲：「嘿！我又想到了個新點子?！?/p>

原因 4：在超過 50 人的創(chuàng)業(yè)團隊精益創(chuàng)業(yè)？瘋了么？

精益創(chuàng)業(yè)的一個原則是充分的溝通，在創(chuàng)業(yè)公司中每一個人都可以貢獻自己的知識與力量。這是一句非常漂亮的話，而作者則用「創(chuàng)業(yè)企業(yè)家」這一虛職企圖告訴大家在一家不論多大的企業(yè)里精益創(chuàng)業(yè)的理論體系都是適用的。但是實際情況是，在大公司中必須實現信息的隔離才能保證組織正常的運轉，否則的話設想一下如果公司的每一個動作，公司中每一個人的想法都要讓公司里所有的人知道的話，那么這個公司要么有 100 間會議室，要么每個人每天都能收到 100 封以上的郵件。

忙于處理溝通，就會擠掉所有的工作時間。

搞出精益創(chuàng)業(yè)的硅谷在傳統組織構架和精益創(chuàng)業(yè)之間妥協出了一種叫合弄制的東西，但是其實合弄制并不是什么新鮮玩意兒，在經典公司管理里這叫項目組制。

合弄制創(chuàng)造性的認為，在新組成的小項目組里重新選擇領導構成一個完整的團體會讓事情變得好起來，但最終的結果是事與愿違——「合弄制仍然在非常大的程度體現的是傳統的上下級制度，而且出現了一個非常奇怪而有趣現象：一個人可以成為另一個人的上級，同時也是這個人的下級」。

我并不認為如此復雜的關系網絡在中國國情下會形成良好的辦公室政治環(huán)境。