互聯網時代產品研發的思考

傳統軟體企業向互聯網企業的轉型

2005年我提出將公司CRM產品向SaaS化發展的戰略時，很多人都認為那是一個巨大的冒險，而如今已經沒有人再質疑傳統軟體向SaaS化發展的趨勢。很多決心向互聯網產品轉型的企業，都會遇到這樣一個問題，傳統的項目化的業務模式利潤越來越薄，而投向互聯網的產品又屢屢碰壁，不是產品遲遲無法成型，就是資金燒不起。怎樣才能順利的完成這樣的轉化，本文將在這方面進行探索。

三大誤區

近些年互聯網在商業上的巨大成功，特別是這幾年移動互聯網的迅猛發展，許多新的產品和新的企業驟然崛起，在牆外的人們總不自覺的看著成功企業靚麗的光環，並誤以為那就是其本質。我常見到的誤區有三個：互聯網必須燒錢、要先明確盈利模式、沉迷於新技術和新概念。這一章節，我們對這些想法一一抽絲剝繭。

誤區一：燒錢就是互聯網

近十年互聯網企業的燒錢模式是深入人心，可燒錢的背後是什麼呢？我們先看一看燒錢成功的案例。

首先是京東，眾人皆知京東持續虧損，直到2017年才真正實現盈利，但這是不是燒錢模式呢？我們來看看下圖。

從2012年到2017年，京東整個公司的總資產和固定資產都急劇攀升十倍以上，而其平台的GMV（商品交易總額）更是從2012年的733億擴大到2017年的將近1.3萬億，增長將近20倍。於此同時，淘寶和天貓的GMV總額，從2012年過萬億到2017年的3.77萬億，增長不足4倍。

京東是在虧損，但虧損的背後我們要看到幾點：

一、京東是有毛利的，對於他們所銷售的單品來看，基本都是高於進價銷售的，所以會有毛利，但是均攤掉公司運營成本、物流建設成本、營銷成本等，最後就變成了虧損的狀態。

二、京東的虧損是有意控制在一定範圍，相比京東的資產、估值，虧損只是非常小的一部分，京東一直將虧損控制在合理可接受的範圍內，並未對企業的經營造成什麼不良的影響。

三、京東每年營收都急劇擴大（年均超過50%）。 假設京東今年360億營收，虧20億，延期還款一個月，那麼京東到年底手裡的錢反而多出了10億！（30億應付賬款，減20億虧損）。假設明年京東營收540億，又虧20億，但年底手裡只會減少5億（45億應付賬款，減20億虧損，再付掉去年留下的30億應付賬款）。所以只要京東的營收越來越多，而虧損不是大幅增加的話，京東手裡的現金流足夠用很多年！

京東這種靠現金結算流的燒錢模式，是互聯網才有的嗎？根本不是，相比稍微年長一些的人都會記得當年國美和蘇寧瘋狂開店的時代。是的，美蘇就是靠現金結算流進行資本動作來賺錢的。舉個例子：假如我每天給你1萬，注意是每天都給，要求你3個月之後還我1萬，注意也是每天都還，你一年的現金流就是365萬。你掙錢了嗎？天天有進有出，他們賺的就是起初的90萬和365萬的現金流還有銀行的利息，道理很簡單。美蘇，假設一年100億營收，延遲三個月還款，手裡就是25億現金流！延遲六個月還款，手裡就是50億！假設瘋狂開店擴大現金流，一年200億營收了，延遲三個月還款，手裡就是50億，延遲六個月，就是100億！

所以我們可以得出一個結論，京東的燒錢模式並不是互聯網才出現的，國美的開店潮，房地產的快速發展都是這種模式，在快速成長的行業里，只要現金流充足，一定幅度的虧損並不意味著是在燒錢，而京東通過壓低產品價格，投入自營物流配送和提供優質的售後服務，雖然增加了成本，降低了利潤，但在用戶快速成長的生命周期里，他獲得了最快速的增長。

接著我們來回顧滴滴和快的燒錢大戰。

微信5.0改版後，2013年9月份滴滴接入微信與手Q，打車服務用戶群體與移動支付用戶天然重合，騰訊開始借滴滴推送微信支付。2014年1月份，隨著騰訊1億美金融資到位，滴滴補貼大戰陷入瘋狂狀態，隨後在阿里支持下快的跟進，這場補貼/支付大戰一直打到5月份才告一段落，雙方燒掉近20億元，堪稱慘烈。

前些日子，馬化騰在長江商學院的一次內部分享會上坦言，這場補貼燒錢大戰教育了用戶，推動了移動支付在中國的普及，這是讓他意想不到的一個收穫。說是意想不到，恐怕不見得，這場大戰雖然迅速拉高了滴滴和快的日訂單數飆升到數十萬，但其真實目的卻不在於此，君不見燒錢大戰三年後的現如今，各種專車打車APP又開始增多，滴滴的日訂單量也緩慢回落到15萬，可是你見到滴滴還有挑起新的補貼大戰嗎？當時騰訊和滴滴發起，阿里和快的跟進之迅速，足以說明這場大戰根本目的不在於打車市場，而在於爭奪更龐大的移動支付市場。

我們可以看到成功的產品，他們的一個共同點在於利用互聯網以及移動互聯網的特性，為用戶帶了更方便快捷的體驗，京東為用戶提供了更方便卻更有品質的購物體驗，滴滴快的為用戶解決了打的難的問題，移動支付更是改變了整個中國的支付習慣。而支付只是在他們產品已經得到用戶認可，商業模型已經得到基本驗證後，為了快速擴大用戶數，搶佔市場，獲取壟斷地位的一種手段，而不是天真的以為燒錢就可以換來用戶的認可。

我們也來看一個燒錢失敗的案例。

不知是否還有人記得2000年的時候，各一線城市街頭出現的大大小小的億唐廣告牌，「今天你是否億唐」的那句仿效雅虎的廣告詞，讓億唐整個網站一時風光無限。億唐從兩家著名美國風險投資DFJ、SevinRosen手中拿到兩期共5000萬美元左右的融資，在全國範圍快速「燒錢」：除了在北京、廣州、深圳三地建立分公司外，億唐還廣招人手，並在各地進行規模浩大的宣傳造勢活動。2000年年底，互聯網的寒冬突如其來，億唐錢燒光了大半，仍然無法盈利。此後的轉型也一直沒有取得成功，2008年的億唐公司只剩下空殼，昔日的「夢幻團隊」在公司燒光錢後也紛紛選擇出走。2009年5月，http://etang.com域名由於無續費被公開競拍，最終的競投人以3.5萬美元的價格投得。

說完這些，大家或許還記得這個公司名，可是這個公司到底做什麼的，還有人記得嗎？那時的億唐網內容貪大求全，毫無特色：幾乎門戶有的東西，億唐當時都有。作為一個綜合性網站，億唐擁有億唐主題、新聞報道、蝶女性網、億唐校園、億唐卡、職業直通車、財經縱橫、億唐房屋八個縱深頻道。但沒有一樣真正拿得出手，互聯網「一白遮百丑」的規則被視而不見。在那段瘋狂燒錢的歲月里，唐海松及其領導的億唐從網站到手錶全都做，甚至投資250萬元參與拍攝了20集電視連續劇《真情告白》的續集。更有傳聞稱億唐在兩個月里，就「燒」掉了1億元人民幣。

大部分燒錢失敗的產品背後的團隊都多少有這樣一個特點：缺乏對自身的清晰定位，人浮於事，沒有沉下心做出幫用戶解決實際問題的產品，而只是幻想用錢就可以砸出一個互聯網的企業。而實際上一個成熟的互聯網產品在需要極速擴大用戶群的時候或許需要使用燒錢的方式作為手段，但切不可反過來以為燒錢就有可能砸出一個產品。

誤區二：必須先明確盈利模式

如果在你產品的初期，整個業務模型還沒有成型，也未得到第一批鐵杆用戶的認可，就開始精細的打量這個產品的盈利模式，這就有些像建立空中樓閣了。產品為客戶解決什麼問題，可以帶來怎樣的便利，客戶為何會喜歡並長期使用這個產品，這才是一開始需要琢磨和思考的最基本的事情。

事實上作為一個企業的戰略級的產品，其本身是可以不盈利的，因為它可以幫助你的其他產品獲得利潤。比如微信。靠微信上的位置，先後入股了京東、點評、美團點評、滴滴、摩拜等小巨頭。靠微信上的位置，給遊戲導流，進而獲得利潤。靠微信和手Q，強推了應用寶，進而使應用寶的裝機量變得特別大，然後收開發者的錢。靠微信上的騰訊新聞插件強推了騰訊新聞和天天快報，進而賣騰訊新聞和天天快報的廣告位。靠微信公眾號上的視頻強推了騰訊視頻，進而做大騰訊視頻，買視頻貼片廣告，這是通過戰略產品的引流在其他產品上變現的路徑。

對於一個在傳統軟體領域已經有一定規模的企業，向互聯網方向轉型時首先不應該想某一個產品，而應是規劃服務的方向和未來面對的用戶群體。方向和用戶群體不能太寬泛，一定要知道自己的最終目標是什麼，基於這個目標，哪些是可以為其他產品引流的戰略級產品，哪些是有利潤爆發點的產品，哪些是賠本賺吆喝的產品。對於不同層次的產品要區別對待。戰略級產品即使盈利點不明朗也應當全力做大做強，有利潤爆發點的產品應當集中資源開發迅速鋪向市場，賠本賺吆喝的產品應當用最少的投入維持基本運作。互聯網產品，尤其是移動互聯網產品，其生命力的關鍵是用戶的粘性，一個能幫用戶解決問題，並且提供長期高頻使用場景的產品應當就是公司的戰略級產品，在原有的優勢之上找到這樣的產品是一個傳統軟體企業轉型期需要時刻牢記並積極探索的重中之重。

誤區三：沉迷於新技術和新概念

近些年好多新的技術名詞和新的概念隨著互聯網的發展應運而生，身邊一個個做項目開發的公司也開始在自己的產品裡面套用起這些新的名詞，比如幾年前還挺新潮的OLAP（聯機分析處理，俗稱報表）沒人提了，都在說大數據了；幾年前還挺牛掰的數據挖掘也沒人說了，都在說深度學習了；甚至剛流行起來的分散式概念也好像要被區塊鏈取代了。似乎沒有產品沒有革命性的突破，不用一點新潮流的技術，就不是互聯網的產品似的。企業為了營銷，為了迎合客戶，不得已使用這些名詞也就罷了，如果企業內部搞產品的研究技術的人們，也被這些概念牽著鼻子走，那就真是把自己給忽悠瘸了。

新技術的使用首先要取決於產品的實際需求，比如一個明顯的關係型結構的數據環境，僅僅因為預估數據量會達到了千萬或億級，就迫不及待的宣布要在一開始就用MongoDB等NoSQL的資料庫，而忽視了這些資料庫因為沒有ACID可能導致的問題，在這些資料庫中的數據一致性是需要額外的代碼去小心翼翼的維護的，實際上我就在多個項目中看到缺乏實際經驗盲目使用NoSQL資料庫帶來了數據不一致的嚴重問題。如果當你知道淘寶的核心資料庫依然在用MySQL，並可以支持TB級的日訪問，會有何感想呢？

OLAP就可以實現的產品功能，卻一定要用Hadoop的Map/Reduce；用簡單的分析模型就可以得出的數據挖掘方案，卻一定要用深度學習去展開訓練；更適合傳統關係型資料庫的場景，卻盲目相信NoSQL資料庫的高效；企業沒有經歷過插件化和模塊化的沉澱，項目內代碼的可復用性還很低的時候，卻相信微服務的魔力。這些天真浪漫的以為新技術可以解決所有問題的想法，常常使一個本來有希望的產品在孕育初期就人為的疊加了重重困難。

互聯網產品初期通常並不會太過複雜，使用合適的技術快速上線、快速試錯、小版本快迭代，是互聯網產品不同於傳統型軟體開發的重要特點。但這不是代表我們排斥新技術，而是要在合適的時間使用合適的技術，這也需要技術決策者們對技術的了解有一定的寬廣度。比如產品以簡單的Document式的數據為主，沒有副本，沒有數據不一致的可能，那為何不一開始就使用更合適的NoSQL資料庫，而抱著關係型資料庫不放呢？

互聯網的產品有時會遇到爆發性的增長，在產品的發展過程中如果還抱著初期的架構不放，不與時俱進，那也是不行，在埋頭疊加新功能的時候，作為產品的開發者，必須也做好在架構中引入新技術的規劃。合適的時間做合適的事情，說起來容易，真正做到卻是很難的。

產品轉型三步走

討論到產品轉型的問題，為了更流暢的描述問題，這一章節將主要以傳統的CRM服務提供商的角度進行探討。典型的傳統的CRM服務提供商，通常都是有一個基礎的產品，然後根據每一個客戶的需求不同進行二次開發。有些產品模塊化做的好一些，積累的模塊多一些，二次開發周期就短一些；有些模塊化做的不足的，客戶需求特例比較多的，二次開發周期就長一些。產品轉型要順利實現三步走，必須在思維上就有所轉變。

首先是業務規劃。傳統項目的思維是：開會，討論，定義清楚方向，然後再討論，方向實現的細節，然後再討論。有時碰到問題，發現走不通了，甚至會推翻重來。互聯網的思維是：挑一個方向，先做起來，如果錯了，改方向，繼續走。快速上線、快速試錯、快速決策、共同負責。

其次是需求梳理。傳統項目的思維是：自己無法提出有效需求，只能按用戶表面需求走，不看數據（因為沒上線根本沒有），遇到問題拍腦袋。互聯網的思維是：開始階段拍腦袋，運營一段看實際數據，從用戶、運營、產品、商務各個方面收集需求，由產品經理牽頭處理。

然後是產品設計。傳統項目的思維是：先按一個個功能點計算人天工作量，根據工期定人員或者反過來根據人員定工期，遇到工期太短的情況，砍功能。互聯網的思維是：需求全部列出來，按緊急重要程度排序，按順序開發。

最後是運營心態。傳統項目的思維是：定項目範圍、定需求，開發完了了事。互聯網的思維是：讓消費者進入到產品的整個生命周期中來。消費者不再是那個只面對銷售終端的對象。而是應該讓消費者融入到售前，包括需求調研、產品研發、產品改進中來。同時企業應與消費者建立直接的聯繫，利用新媒體手段與消費者產生情感連接，形成品牌印象。

第一步：已有產品向互聯網和移動互聯網轉化

已有產品加上多用戶管理就照抄到互聯網之上，是最容易設想的方式，但實際上這樣並不符合互聯網產品的思維。首先照抄上去的產品規模較大，無法做到快速上線、快速試錯，鐵杆用戶將無法參與到產品的生命周期中來；其次產品功能分散，重點不明確，難上手。已有產品向互聯網的轉化應當突出重點，針對一個場景將少部分的重點功能先移植上去。

在前幾年各大品牌紛紛在天貓、京東這樣的電商平台開旗艦店的契機，傳統CRM就可以有針對性的將一些功能打包成為一個針對電商平台的SaaS系統。電商的促銷活動與傳統商場的促銷有過之而不及，那麼原來的促銷模塊就可以加強後移植到線上；銷售運營分析部分（主要是OLAP）依然很重要，需要移植到線上；電商渠道不再需要大區庫房和零售店鋪庫房，那麼庫房管理部分就可以簡化；原有的會員卡服務在電商渠道不再重要，就可以省略掉。在需要移植的功能中，又可以根據重要程度分優先順序，以最快速度的上線第一個版本為前提，迅速讓鐵杆用戶試用，快速試錯快速迭代新版本。

第二步：明確未來整體方向和服務對象

將已有產品移植到線上，是一個傳統企業體會互聯網產品的過程，這個過程中，需要同步的思考企業未來的整體方向。

傳統的CRM服務提供商，一直以來都缺乏對C端用戶的直接聯繫，同時原有客戶現如今也紛紛在電商平台轉移，未來還會進一步有互聯網化的需求，對於這些客戶來說如何打通線上線下也是未來生存的關鍵問題，由此繼續專註於B端客戶群，幫助他們解決互聯網運營的一系列問題，提供線上線下的經營提供全天候的支持，這無疑是很適合的一個方向。

這個方向是不是真的適合企業，並不是憑空想像就可以知道的，只有在實踐中去發現問題去尋找解決方案。有可能因為產品的規劃缺失和開發能力的不足，喪失了佔領市場的先機；有可能因為市場營銷的互聯網轉變不夠，無法承載支撐整個方向的產品，而只能將精力集中在小部分的細分領域。本文專註於討論產品設計和研發在企業轉型中的問題，但實際上一個傳統的企業要真正轉向互聯網的企業，從來不是一兩個部門的事情，而是從上至下，上下一心的結果。

第三步：形成自己的互聯網及移動互聯網的產品組合

將自身產品以一個切入點進入互聯網，並明確未來方向之後，就應當謀劃整套產品體系了。一個企業的產品體系可以是騰訊這樣的一兩個戰略級產品作為引流入口，其他產品附加之上實現利潤。也可以是今日頭條這樣的，數個產品（今日頭條、西瓜視頻、抖音短視頻、火山小視頻、悟空問答、內涵段子）都與內容分發相關，數個戰略產品並存，均以廣告收益為主的體系。

CRM服務提供商們可以為傳統的品牌商們提供怎樣的產品體系呢？

首先是幫助有一定規模客戶代運營，包括電商店鋪管理、品牌營銷、網路推廣（精準廣告）、客服以及倉儲。對於傳統的品牌商或許已有客服和倉儲，但他們對互聯網化的推廣方式和營銷手段了解並不深；對於電商興起之後的新興的品牌商通常客服和倉儲都是缺失的。

其次是現在的新零售的概念。新零售不僅僅是線上線下與物流結合的一體化銷售，而是像互聯網產品一樣，讓消費者深入到品牌產品的方方面面，用數據打通消費者認知、興趣、購買、忠誠及分享反饋的全鏈路，並在品牌策略、品牌傳播和品牌運營全方位精細支撐。今後VR技術在零售店鋪的引入，RFID和各種體感感測器的使用，客戶購買訴求的精準分析和廣告更為精確的投放，產品的各種個性化定製，這些都將徹底改變零售業態，要實現這些，各品牌商們更加需要強大的IT服務的支撐。這些產品都是傳統CRM企業轉型去思考和選擇的方向。

互聯網時代，傳統軟體企業，特別是項目為主的企業，利潤率越來越低，但互聯網帶來了生存危機的同時，又提供了更廣闊的可能。因為互聯網的格局下，其他行業對信息化產品的需求不是降低了，而是更高了。中國IT服務的整個市場規模這些年都以20%的幅度增長，以「智研諮詢集團」的預計，2021年中國整個IT服務的市場規模將超過萬億。

技術轉型三步走

這二十年軟體架構的體系的演進過程大致可以歸納為四個階段，從早到晚分別是：單體架構、模塊化架構（垂直架構）、SOA架構和微服務架構。架構的演變只有一個目的，就是化整為零，將一個大的系統拆分成可以組裝的小系統，從而將軟體系統的耦合性儘可能的降低，並讓小系統可以變得可重複使用。

結合我原來的工作經歷，我們來看看架構的變化可以帶來哪些好處。

任何一種軟體系統都遍布著查詢的功能，尤其是CRM這樣的企業信息管理系統，銷售查詢、庫房查詢、客戶查詢、採購查詢等等。一個單體架構的系統，常常也會使用一些表格控制項，來輔助開發眾多的查詢，如基於JQuery的表格控制項datatables.js，使用這樣的表格控制項就是模塊化了嗎？不，還不算。因為開發者依然要深層次的將這些控制項嵌入到代碼中，耦合度依然不低。

以使用datatables.js為例，我們在前端WEB頁面要嵌入這樣的代碼：

還要在服務後端嵌入類似這樣的代碼（PHP代碼）：

完成這些代碼，我們可以看到以下的界面：

如果我們需要加上分頁和過濾的功能，還需要分別在前端和後端加上更多的代碼。不僅如此，每開發一個查詢功能，我們都要重複以上的工作。

那麼一個模塊化的查詢控制項需要做什麼呢？只需要配置一句SQL：

如果沒有配置映射字典，那麼配置文件要稍微增加一句，變為：

完成這樣簡單的配置，就可以得到如下的界面：

可以看到，不僅可以按欄位進行過濾，還包含了分頁。這就是模塊化架構相比單體架構的一個重要優勢：開發效率更高。但不可否認，完成這樣的查詢模塊也是有代價的，它需要為模塊的開發投入工作量，但只要是可以重複使用的場景，模塊化都是非常值得的，因為隨著在今後的使用功能越來越多，邊際成本將越來越低。

除了開發效率更高，模塊化另一個重要作用是功能擴展成本低。例如，在上面的查詢基礎上，產品經理提出要加入實時統計的功能，如果還是傳統的模式，必然導致需要重構該功能點，而模塊化之後，不需要任何改變，就可以得到：

當然我們也不是魔法師，雖然不需要對業務功能點改動任何代碼，但還是需要對該模塊增加統計分析的功能的。在我們的實踐中，模塊的重構遠遠低於每一個功能點的重構，而使用該模塊的功能點越多，這個成本優勢會越來越明顯。

互聯網的今天模塊化不是終點，微服務架構開始盛行，它又帶來什麼變化？

傳統軟體企業，無論是新產品上線還是定製新的功能，都會經歷需求分析、設計、開發和測試這麼幾個階段，周期都會比較長。但互聯網的產品有所不同，前文已經闡述，互聯網的產品版本迭代周期都很短，遵循著快速上線、快速試錯的原則。周期越來越短，但對系統穩定性要求卻越來越高，模塊化架構的思路開始出現瓶頸。

我們依然以查詢統計控制項為例，隨著數據越來越多，部分日誌型數據將轉用elasticsearch（ES）資料庫，這時我們需要在控制項中支持ES的查詢。假如此時因為開發人員在連接的控制上出現BUG，某種情況觸發了內存泄漏，可想而知，這時候會導致整個查詢模塊的崩潰，如果垂直切分不夠完善，嚴重的情況下甚至可能導致整個系統的崩潰。微服務架構下會有幫助嗎？

我們來看看微服務架構下查詢統計控制項的架構的新變化。

左邊的模塊化架構，雖然已經在控制項內部做了功能切分，但是新增ES執行組件（橙色）後，查詢控制項需要重新打包代碼後部署上線，由於控制項是作為一個整體部署在一個應用容器中，新增組件的嚴重BUG將有可能導致整個控制項的崩潰。

右邊的微服務架構，原有的查詢服務、SQL服務與新增的ES服務（橙色）是三個獨立的小系統，分別部署在不同的應用容器中，此時若ES服務內部出現BUG，只會導致ES服務的崩潰，這一分離的架構將新的服務引發的問題與原有服務隔絕開，而不會影響原有應用的正常運行。不僅如此，相比較整個查詢控制項的重新測試和部署，測試和部署一個微服務的速度要快得多，這正符合互聯網產品的需要。

但微服務架構不是軟體行業的銀彈，帶來了好處的同時，也會帶來一些問題：

一、測試難度增加，必須用自動化測試來替代傳統的手工測試。因為微服務對外的介面只是Service API，而不是用戶可以看到的界面，如果沒有編寫自動化測試腳本的能力，微服務的測試無從開展。

二、運維難度增加。從原來只需要管理一個系統，變為管理多個微服務的子系統，多個微服務之間也需要用配置文件將他們連接起來，這種網狀的結構，隨著微服務的數量增加，其運維工作的複雜度將幾何級數的增長。傳統的開發人員打包程序，交給運維工程師去手動部署上線的運維方式已經無法適應微服務架構，正因為如此，「誰開發誰運行（You build it, you run it）」的DevOps理念開始流行。

三、監控難度增加。每個微服務就是一個子系統，都運行在一個應用容器之上，每個容器都有自身的服務狀態、介面調用情況、異常告警等諸多信息，監控的複雜度成倍增長。正因為這一特點，互聯網的SaaS產品可以用微服務架構，但部署在客戶伺服器或私有雲上的傳統軟體產品就很難採取微服務架構，因為這對集中監控有很高的要求。但後續篇章我們會談到，Docker這一事物或許將改變這一問題，並帶來新的可能性。

微服務架構是現在最適合互聯網產品的一種技術架構，但不代表傳統軟體企業就可以直接拿過來使用。在技術方面，如果你的自動化測試、自動化運維和監控沒有達到要求，微服務架構只會給你增加工作量；在管理方面，如果你還是傳統的開發流程和組織架構，做不到向DevOps的方向靠攏，無法適應小版本快迭代的要求，微服務架構同樣會給你帶來很多的混亂。

第一步：模塊化架構

模塊化的架構，不僅僅適用於互聯網產品，對於一些還處於單體架構階段的傳統軟體企業，應首先向模塊化架構轉型。在實踐過程中有幾點心得：

一、敢想敢做。在事務性的工作壓力面前，由於對模塊化額外工作量的擔憂，企業的技術管理者們常常會在第一步就停滯不前，設想的多，但遲遲不動手。實際上只要在實際工作中有共性的，可重複性的功能集合，都可以考慮模塊化的思路將他們整合為一個模塊。

二、從小到大。模塊化設計的時候，人們常常會想的太多，希望一次解決所有想到的問題，使得一開始的複雜度就很高。過高的期望，過於複雜的設想，會導致模塊化的工作量太大，這導致要麼畏懼工作量而中止工作，要麼周期過長而最終出來的產品事與願違。在我們的實踐中，好的模塊第一版的開發工作都會控制在兩周的時間，這樣儘快上線一個版本，然後交給其他團隊去使用，在使用的過程中收集意見，不斷迭代新的功能，往往比一開始就設計很周全的效果好的多。

三、眼界寬廣。開源組織的發展已經很多年了，各種開源工具和產品層出不窮，多關注開源社區的發展，多看看別人的項目，不僅可以擴展自己的思路，還常常可以找到合適的項目加以改造和重新組合後，成為適合自己企業的模塊。

四、包容失敗。模塊化之路有成功，也可能有失敗，如果遇到失敗的情況，應當檢討事情哪些做的不好，也可以檢討人選哪裡選的不對，但不能遇到失敗就放棄模塊化的道路。

五、臨時組建。有些企業在一開始就會組建專業化的組織（如架構組、控制項組等）去專心開發模塊，但這樣做會很容易使他們與業務工作分離，成員逐漸脫離生產的實際需要，出現閉門造車的問題。事實上應該是在實際的開發工作中發掘出模塊化的功能需求，這時應當有少數的幾個人臨時組建一個開發組，快速開發出來，然後推廣使用。如果一個模塊功能越來越複雜，平時維護和升級的工作量都很大，那麼可以針對這一個模塊成立固定的開發組，專門負責它的開發工作。從生產實踐中尋找模塊化的需求，會比成立只負責模塊開發的專業組的效率更高，開發出來的產品也更能符合業務的需要。

第二步：敏捷型組織

技術的轉型不僅僅是架構的問題，還是組織形式的問題和開發流程的問題。敏捷開發模式不僅僅適用於微服務架構的技術體系，也可以為傳統產品的開發提供幫助。組織的敏捷化主要體現四方面：

一、小版本快迭代，不要試圖一次開發一個大版本，一個版本的開發周期應當儘可能的縮短。

二、測試驅動開發（TDD），TDD不是說產品不需要思考和設計就直接開始構建測試代碼，而是將需求分解為任務列表，再從列表中挑選一批任務，轉換為一組測試用例，然後不斷循環去實現。

三、持續集成持續交付，不要試圖在版本的末期才提交整套代碼，而應當至少每天實現一次構建和集成，充分利用測試用例的覆蓋，在代碼提交的當時就立刻發現問題解決問題。

四、開發與運營的緊密結合，打破傳統項目型企業中開發、QA、運維、運營之間各部門的鴻溝，建立以業務為主線的整套協作流程。

第三步：微服務架構

當你的技術人員適應了模塊化的思維方式，當你的組織與開發流程進行了敏捷化的改造了，更重要的是當你的產品逐漸往互聯網發展了，你一定會自然而然的產生向微服務架構的體系轉型的衝動。這時可以著手在五個方面進行準備：

一、業務拆分，體現在設計環節：在設計的時候，要有足夠的判斷力來合理的規劃服務之間的界限。

二、服務治理，底層技術的支持：首先要選一款適合自己實際情況的分散式服務基礎框架，對於服務的發現、治理、熔斷、降級，都要做好相應的技術準備。

三、自動化測試用例高度覆蓋：微服務架構一個明顯的變化就是隨著服務的增多，測試的複雜度顯著增加。如果繼續沿用傳統的測試模式就會遇到瓶頸，為了保證高效的迭代，盡量做到更多的環節實現自動化。

四、自動運維 ：微服務拆分之後，每個服務都可以獨立部署，進而言之應該是隨時隨地可以升級。尤其當互聯網發展到今天，業務要保持對市場變化的一個高效響應，自動化運維就是提升交付速度的一個重要環節。

五、監控：包括硬體環境、服務狀態、系統健康度、介面調用情況、異常的實時告警以及潛在問題的事先預警等等。監控在實施微服務過程中會重要到什麼程度呢?一句話：沒準備好監控，就不要搞微服務架構。

沒有什麼事情是一撮而就的，微服務的架構也不是一步就能全面實施的，在工作中有規劃的推進，逐步的準備，微服務架構的建設也就順理成章完成了。

三點注意

第一點：要注意從傳統項目孵化互聯網產品的思想

很多時候企業會得到一些看起來與市面上互聯網產品類似的項目，於是乎決策者們就開始設想完成這個項目後順帶孵化出一款互聯網的產品，我就曾經在工作中遇到這樣的事情，這樣的思維邏輯下會產生以下三個無法調和的矛盾。

首先項目與互聯網產品的迭代方式不同，項目通常以交付工期作為迭代周期，而互聯網產品要求快發布快驗證。如果項目裡面也採取互聯網產品的快發布快驗證，項目的最終客戶會有耐心去幫你審核半成品嗎？

其次項目與互聯網產品的目標不同，我之前就遇到過的希望通過運營商的用戶感知體驗的項目孵化出APM產品，而運營商側重的是終端用戶的測試結果，而APM的目標群體是各ICP，而ICP更側重的是結合終端用戶的測試結果查看伺服器端的運行問題。這不同的客戶群體不同的產品目的，兩個產品的需求和體驗截然不同，甚至應當是完全不同的產品。

最後是項目與互聯網產品的管理模式不同，不同的管理模式就意味著不同的考核辦法，考核辦法又間接影響開發人員的思想。當你想做好項目時，它離互聯網產品的體驗就越來越遠；當你想更符合互聯網產品的體驗時，項目的範圍和工期將不可控。魚與熊掌不可兼得也。

或許這時候有人會問，那我開發完項目之後，有了一定的技術經驗再去開發互聯網產品不是就可以了嗎？首先我們在上面就指出項目與互聯網產品可以說是兩個南轅北轍的事物，重新再開發互聯網的產品並不一定能規避什麼技術風險，反而因為原來項目的慣性思維可能會固化你的思路。這樣又不省錢又固化思維的事情，做起來又有什麼意義呢？

第二點：要注意大而全的閉門造車的思想

一個產品如果初期版本設計太過龐大，就很容易陷入閉門造車的怪圈，因為你無法最快速的獲得運營數據，也無法與客戶有效的進行交流，獲取真實的體驗和需求。只能採取悶頭瞎想，下意識或者自動忽略對於產品基本需求的科學性調研，只是單方面地認為某個群體有某種需求。

產品上線後，也要避免不自覺地虛擬出用戶的需求或者片面擴大用戶的需求。不要去主觀想，不要去替用戶考慮，要做的只是訪談，有引導的焦點會議，有導向性的用戶研討會，設計思路清晰的調查問卷，同時要在產品中採集實際的運營數據，學習結合實際數據去分析用戶的需求。

第三點：要注意生搬硬套沿用傳統項目的KPI考核模式

傳統項目的考核總是避不開利潤計算、工作效率、責任歸屬等指標的劃分，而這種呆板的考核模式並不符合互聯網產品的思維。互聯網產品強調快速上線、快速試錯，出了問題快速決策，集體負責，根本沒有時間給你劃分責任的歸屬問題，自然也無法很有效的用KPI去計算工作效率，互聯網產品的特性則更加難以計算一個開發周期的利潤指標。

未來的可能

隨著微服務架構與基於容器的虛擬化（Docker為代表）的發展，未來十年的軟體行業會產生非常大的變化，應用將由各種微服務組合而成，軟體開發領域將劃分為兩類人群，一類是微服務的開發者，另一類是微服務的組裝者。軟體應用的開發將越來越像現代工業產品的開發模式：零部件的開發與產品的組裝。微服務的開發者專註於單一微服務功能的實現；微服務的組裝者關注如何將已有的微服務組裝起來成為客戶需要的完整產品，組裝者需要只是為不同微服務的連接開發一些適配程序，而不再關注單一功能的細節如何實現。

在這樣的遠景的前提下，未來的軟體領域還可能出現一些新的事物：

一、微服務商城。類似於App Store，提供各種微服務的購買、下載與安裝，商城不僅提供單一的微服務，還提供各種打包好的套件。

二、微服務外包。不同於現在的軟體外包形式，未來IT服務提供商們不再考慮一個項目完全由自己開發，而是專註於設計業務模型，將市面上已有的微服務的組裝成自己的產品提供給客戶。對於一些特例的需要單獨開發的微服務則採取外包的方式交給第三方的微服務開發者。

三、新的雲形態。一方面未來企業對涉及商業機密的數據要求越來越高，同時基於容器的運維管理工具越來越豐富，而容器很容易移植的特點，私有雲將逐漸在企業市場佔據主導地位。另一方面隨著物聯網的發展，每個家庭都遍布各種智能設備，個人隱私信息的保護也將逐漸嚴格起來，管理自身設備的家庭雲和個人雲也將開始出現。

四、服務標準化。對於查詢、統計、報表、許可權、工作流等通用服務，業界內部將逐漸形成標準化的服務介面；對於庫房、訂單、採購等行業內通用服務，在該行業內部也可能逐漸形成統一的標準。

微服務的商城如何運作，微服務如何定價並保護知識產權，開源社區將有哪些新發展，服務標準如何形成，組織形式和開發流程又會有哪些新的改變，未來軟體從業人員的有哪些新的要求，以上問題的思考我將在今後的系列文章《未來十年的互聯網》一一闡述。