前天值乎開始刷屏，馮爺一個人就賺了好幾千。

話說，你說我是不是羨慕呢？其實，前天晚上值乎的負責人就跟我說，你寫條好的我們推一下，然而我沒想出來能寫啥讓人掏錢來看。 

但今天說這個呢，是因為這個產(chǎn)品負責人，恰好是十年前老同事，他告訴我這個東西，其實從開發(fā)到上線，只用了30個小時，也就是不到兩個工作日的時間。 當然，可能有些做技術(shù)的會覺得，這玩意其實也蠻簡單，開發(fā)工作量也就這么多，但是我們知道在很多公司，要想啟動一個項目，哪怕是很小很簡單的項目，也需要很久，很長時間，各種流程，各種低效無意義的溝通，各種奇怪而無實際意義的想法和顧慮，都夾雜在一起，極大拖累了整個項目的實施和執(zhí)行。

說來慚愧，我自己的公司也存在這個問題。

我這邊的程序員其實水平并不低，遇到性能或其他異常問題的分析能力和解決能力，不敢說跟一線互聯(lián)網(wǎng)公司的架構(gòu)師們?nèi)ケ龋么跏俏遗嘤栠^的，肯定要超過平均水準，這塊我基本不操心，但是在項目規(guī)劃和執(zhí)行上，就一直存在一些問題，主要就是系統(tǒng)設計的想法太多，總是把簡單的東西想復雜，把簡單的東西做復雜，這也導致很多東西實現(xiàn)不了。

其實我們說技術(shù)，設計系統(tǒng)，設計架構(gòu)，不管是多小，多簡單的東西，一開始呢，入門級的技術(shù)人員，想法簡單，但是對風險，對拓展，對未來需求變更的適應，都沒什么概念，所以做出來的東西雖然簡單，但是可維護性很差，安全性也不好，實話說，各種眾包網(wǎng)站里，那些廉價和不廉價的技術(shù)外包團隊，大部分都處于這個階段。

上升一個階段后呢，對技術(shù)有一定了解和概念了，知道未來的擴容考慮，知道需求變更和擴展考慮，知道安全性的考慮了，然而考慮的太多，設計系統(tǒng)就特復雜，恨不得每個小功能都弄出一個獨立可擴展的模塊，結(jié)果很簡單的事情就復雜化了，這是第二個階段。

第三個階段，我們可以認為是重劍無鋒，大巧不工的階段。如果你看代碼，不仔細去琢磨邏輯，可能感覺回到第一階段了，怎么這么簡單，這么少的代碼就把這個做了，而且看上去好像也沒什么特別牛逼的地方，但是你仔細琢磨發(fā)現(xiàn)，其實很多地方的設計都是有預留的，就是這地方我啥都沒寫，但是以后有業(yè)務訴求的時候，我不需要大改，我這里插個東西就行了。

這就有點像以前說看書，先從薄到厚，再從厚到薄，你需要挺過這個過程，把所有復雜的問題簡單化了，你才能進入更高的境界和層次。

我跟程序員這樣講過，我說到了這個階段，你其實不是說什么都需要提前準備好，你要達到境界是想到但不需要做到。就是這些未來可能的需求，可能的訴求，你都想到了，但你知道如何快速的擴展和響應，而現(xiàn)在你結(jié)構(gòu)很輕簡，很靈活，你就把現(xiàn)在邏輯按照合理的結(jié)構(gòu)實現(xiàn)了，然后留幾行備注，這里的接口以后可以干嘛，這里的設計未來可以增加什么，不需要去實現(xiàn)，低耦合的結(jié)構(gòu)做好就足夠了。

以前我請大牛云風給我們講過課，講系統(tǒng)架構(gòu)設計，他口頭語也是，這個什么什么其實很簡單，從頭到尾你看不到他賣弄什么技術(shù)，講什么特別高深玄奧的東西，但是人家搞出來的系統(tǒng)確實好用，后來提問環(huán)節(jié)我們有員工問過一些新的技術(shù)名詞相關(guān)的什么什么，云風也很直白，很務實的說我們目前這個需求，用不上什么什么的。我就覺得這是重劍無鋒的一個典范；現(xiàn)在云風他們團隊分享的skynet開源引擎已經(jīng)有非常多游戲團隊在用，代碼量也不復雜，功能也不算豐富，但是很實用的一個輕架構(gòu)，能極大減少某些類型游戲的服務端開發(fā)成本。

其實我的要求就是這么簡單，低耦合，擴展需求想到而不做到。快速實現(xiàn)，快速產(chǎn)品化，但這個要求，依然很難執(zhí)行到位。這就是我很羨慕和佩服值乎的地方。

一個創(chuàng)業(yè)團隊，需要極強的執(zhí)行力，才能在競爭中脫穎而出，而實際上，一個小團隊，一個優(yōu)秀的技術(shù)人員，是可以在很短的時間內(nèi)完成一個好產(chǎn)品的，我以前講過，現(xiàn)在互聯(lián)網(wǎng)上給一個技術(shù)產(chǎn)品評定的標準是，有多少用戶在使用，而不是有多少代碼行。  

我年輕的時候?qū)戇^一個WEB OA，代碼行多的要死，但是沒任何價值，因為當時產(chǎn)品設計思路不對，所以根本發(fā)展不了用戶；后來做CNZZ的時候，第一個版本就寫了兩周，就自己一個人，當然比較簡單，升級版本的時候也差不多兩周，從數(shù)據(jù)結(jié)構(gòu)到代碼結(jié)構(gòu)大調(diào)整，也就兩周，而且不是全職寫的。代碼量并不多，問題也不少，但產(chǎn)品價值體現(xiàn)出來了。代碼量可能只有那個oa的1/100，但是價值可能超出了那個oa的100倍。

現(xiàn)在互聯(lián)網(wǎng)上依然有很多，類似值乎這樣，輕簡而又容易爆發(fā)的產(chǎn)品需求點，你不能說它一定可以成為一個偉大的產(chǎn)品，但是如果你可以低成本，快速試錯，快速迭代，也許很多機會就會從中產(chǎn)生。實話說，在技術(shù)門檻不高的領(lǐng)域，快魚吃慢魚依然是有效的一個發(fā)展準則。

下面我說一個范例，我跟我的團隊提過的一個想法，我今天免費公開出來，也對我的讀者群做一個測試。

比如我這樣的公眾號，比如馮爺，池建強這樣的大V，經(jīng)常會有廣告投放的訴求，有些是真的花錢的廣告主，有些是利益相關(guān)的公司，也有一些是朋友推薦或換量，很多情況下都會帶一個二維碼鏈接給對方，那么這里有一個特別強的需求，我肯定想知道說，通過我這里，刷對方二維碼的有多少。而目前，這個數(shù)字是沒法直接統(tǒng)計的，只能對方通過數(shù)據(jù)變化來估算。

這里我就想提出一個需求

二維碼轉(zhuǎn)換跟蹤工具

當你獲得一個二維碼，或直接一個鏈接，你可以到這個平臺（網(wǎng)頁，或者公眾號），生成一個新的二維碼，這個新的二維碼包括了一個跳轉(zhuǎn)頁，然后重定向到原始的目標鏈接，對推廣效果來說，就是增加了一次跳轉(zhuǎn)的過程。

而跳轉(zhuǎn)頁，其實也就是一個跟蹤器，其實什么代碼都不用寫，就是執(zhí)行一個跳轉(zhuǎn)操作就可以。然后記錄一條日志。

分析程序在后臺通過對日志的讀取和處理，得到這個廣告的點擊次數(shù)，及點擊的用戶構(gòu)成，比如用戶點擊時間構(gòu)成，用戶地區(qū)構(gòu)成，用戶客戶端構(gòu)成，然后當自媒體登錄后臺的時候，可以看到這個報表。

就是這么一個東西，但是要超級輕簡，好用，如果有人能做出來，只要確保你的跳轉(zhuǎn)頁是安全的，我是愿意用的。

那么，問題來了，這樣一個東西，開發(fā)周期和開發(fā)成本應該是多少呢？我個人認為，如果只是web版本的簡單原型２天足矣。二維碼識別和生成的代碼，你去搜github都有，google都有共享過高質(zhì)量代碼，調(diào)試通了做一個調(diào)用頁面就可以。后臺統(tǒng)計如果不做復雜的話其實非常簡單的結(jié)構(gòu)就能完成。而且你的分析程序是異步處理的，基本都不用擔心負載問題。甚至這樣的分析程序也有很多開源軟件可以拿來用。