1、關于研發規劃模式變革思路的匯報2013.7.17 對思源軟件規劃模式發展歷史的反思低水平、閉門造車、對外界缺乏關注，規劃能力落后于需要混亂階段：無規劃、見事就上，各行其是無數個版本起步階段：嘗試把需求歸并到一個體系中來不斷發現新的問題，原體系無法包容，只能被動應付上升階段：嘗試通過主動思考和研究，試圖定義一個整體、有高度能引領方向、有靈活性能自由擴展的新體系，包括引入“分步實存、用戶干預”等機制由于行業的發展和“知識圈”原理（不知道的永遠比知道的更多），多年努力仍無法走出怪圈。新的階段：必須改變，否則看不到成功的希望。學習了解、擴寬眼界、思考成果：二種模式的類比。傳統的研發規劃模式造船模式大而

2、全：在出海之前，必須把所有需求都考慮到，所有問題都解決完，一旦離港，茫茫大海一片汪洋，一切都只能靠自己，必須到下一個港口才能升級，而且還不一定能解決問題因為在造船廠里就得把外型，內部基本架構都要定死，后面的發展和變動全受初始框架的限制。（如船寬、主機功率等）問題和缺點：規劃周期長，建造周期長，成本高，投資周期長，團隊相對僵化。需求變更支持差，響應周期長，成本高，依靠階段性升級難以滿足客戶對變更的時間期望，而且不一定支持。互聯網軟件研發與傳統軟件研發的根本性區別關鍵：快魚吃慢魚（思科CEO錢伯斯）快是最關鍵的，慢了就根本沒有機會。只要快了，只要拉來了客戶，有的是機會和資金去改進，實在不好的部分可

3、以換掉重來（只要符合核心需求的規范就可以平穩升級）。但如果慢了，做的最好也沒用了，因為客戶已經被先行者拉走了這是由互聯網應用中固有的粘性和慣性決定的，成功的互聯網企業基本上都走過這條路。互聯網研發中的成功經驗小步快跑、階段提升、策略性重復研發等方法在互聯網研發中的成功應用免費郵件系統、淘寶等網購平臺的升級策略思考結果：我們需要顛覆性的變革新的模式學習和思考，規劃模式的變革鐵路模式區分核心需求和外圍需求：喬治。斯蒂芬森在1781年發明實用的火車及鐵路體系時，只定義了二個核心需求鐵路軌距（1435mm）和鐵路車輛外型尺寸限制（以保證列車順利通過隧道），僅此二項而已。歷經230年的發展，這二個核心需

4、求已經成為全世界事實上的鐵路標準。雖然斯蒂芬森在發明火車時，只考慮到載客和運輸散裝煤炭這二種功能。但是，他定義的核心需求非常準確和精干，人們在此基礎上不斷擴充，發展出了從硬座到軟臥，從平板到悶罐到冷藏，以及更多的特種車廂（油罐、起重、特殊運輸、工程直到運輸火箭甚至發射鐵路機動型洲際彈道導彈）等一系列的擴展應用這些統統全都是外圍需求。從軟件研發規劃出發，分析鐵路模式的特點1、快速啟動：一開始不用把后面的事情全想清楚，也不可能想清楚斯蒂芬森當年發明火車時肯定不會預料到火車會用來發射導彈，但這并不妨礙他提出準確的核心需求，也不妨礙后人在這些核心需求的基礎上發展出龐大而復雜的鐵路車廂家族。所以核心需求

5、必須非常準確和精干（精干這一點至關重要。因為精干代表了不過度干預細節，代表了足夠的發展空間）。剛開始，我們把機車和最簡單的平板貨車發明出來，符合核心需求的規范，就可以上路開跑了。一邊運營，一邊發現新的需求，發明新的車廂，再加進去提升（或者早就知道更多需求，慢慢做）這個發明的過程可以與運營的過程一樣長鐵路發展到今天，新型的車廂（如動車、高鐵）仍在不斷出現，最簡單和最復雜的列車可以在同一套線路中運行。從軟件研發規劃出發，分析鐵路模式的特點2、個性化定制和靈活編組：現代鐵路的編組站里，各類不同的車廂，根據客戶的需求靈活編組成新的列車，編組過程中完全不用考慮各個車廂是干什么用的，裝了什么貨物，只要其目

6、的地相同就直接掛在一起，發車前往下一站。當需求變化時，只要摘下幾節車廂另掛幾節，馬上就可以再上路。前提松耦合：以冷藏車廂為例，從供電供水到供冷，所有需求全在一節車廂內實現，形成相對封閉的小環境，與其他車廂之間僅有索引系統和剎車系統的連接，典型的松耦合模式，也只有這樣才能實現方便的重組和調整。3、受控的策略性重復研發：投資保護非常重要，重復研發會造成浪費，損害投資人利益。但在互聯網研發中，這個現象并不是一定、完全地不能有。在必要時可以考慮少量受控的策略性重復研發投入。而這也是由互聯網應用的特性“快魚吃慢魚”決定的。這里要看的是投資人的根本利益，如果目標是把這個項目做成，傳統的謹慎開發因為慢，可能

7、導致被吃，目標無法達成，投資100%失敗。那投資人更看好多花個10%甚至更多一點，但能快，項目有成功達成目標的可能。鐵路剛開始出現的只有平板車廂，但有些貨物需要密封運輸，于是出現了悶罐車廂，但平板車廂沒必要當廢鐵回爐、也沒必要扔那不用，完全可以同時使用，同時列入產品清單，供客戶根據需要自行選擇。當然也有部分類型的車廂會因為升級換代而被永久放棄，甚至蒸汽機車也被內燃機車和電力機車取代。這里確實存在重復研發的一些投資浪費，但這是受控的，前提：只要符合規范就能保證順利發展：機車剛開始是蒸汽的，后來發展到內燃、電力、動車，發展過程中可能出現升級換代，但只要符合規范，就能保證順利發展，就象幾代機車能同時

8、服役，又象火車也可以坐海船只要軌道能對上就行。從軟件研發規劃出發，分析鐵路模式的特點從軟件研發規劃出發，分析鐵路模式的特點4、工廠化的定制開發：建造貨車車廂的車間可以完全不知道客運車廂是什么回事，只需要根據設計要求做好自己的事，大家只要遵守相同的核心需求規范，就能很容易地接在一起。這種模式特別適合于編碼團隊技術能力強，但對整個行業不大了解，時間又緊的情況，他們可以分成小團隊，每個小團隊只盯住一小塊需求（一種類型的車廂）完成開發工作。5、開發工作可以攤薄了，永續進行：進入一個新的市場區域，或業務領域，只需要了解需求，補充開發掛接就行了。如果發現原來開發過類似的車廂，但不適用了。不用去管原來的車廂

9、（原來的車廂在舊的市場區域很可能還有用），復制一份設計修改成新的車廂設計就可以開工，用于新的區域。新舊車廂互不干涉，不會引發舊組件的衍生BUG。從軟件研發規劃出發，鐵路模式與軟件研發的類比鐵路模式與軟件研發的類比：機車：在我們的互聯網研發中，可以將機車類比為數據庫平臺和架構體系，以及贏利模式。它帶動著我們的體系前進，而且也肯定會有升級換代。車廂：車廂就是實現客戶需求的各類組件，最開始只有平板，后來發展成體系和家族。軌距和外型尺寸限制：那在互聯網研發中，哪些是象鐵路的軌距和外型尺寸限制這樣的核心需求和核心規范呢？核心需求和核心規范我們必須堅持不變和持續保護的內容：房檔和客檔：這是大數據庫的基礎和

10、核心。必須先想清楚架構，以后最多增補字段，保持穩定和平滑升級。（收費在物業軟件是核心，但在大數據庫體系中，只是一個邊緣功能了）；基礎財務架構：應收實收應付實付，這四個表的體系必須固定。基礎工單架構：各類工單統一在工作流架構上跑SAAS軟件一樣需要工作流。目前看來，核心需求和核心規范就這么多精干！其他的都屬于外圍需求。但這只是目前的看法，回頭在規劃前期要進行專題研討確定下來。下文詳述。外圍需求可以長年不斷增補的內容外圍需求可以長年不斷增補的內容：應收計算模型：可以說過去的16年，我和研發同事們，80%的精力都在轉著這一塊轉，太多的模式、太多的參數、太多的特殊情況，我們一直在造船，想把全部問題全裝

11、進去，用開關、用配置，用一套架構，一個整體、極為復雜的模型解決所有問題。但總發現架構不完整，總發現模型無法包容新需求。我們需要跳出這個圈子，用鐵路模式來打破這個怪圈。計算模型組件化：應收就是應收，它就是軌距，只要是應收就行。至于應收是客戶員工自己手工輸入的（手搖車），還是用最簡單的公式計算生成（平板車），或者最復雜的公式生成（冷藏車），有些復雜的公式還有多個版本（各種類型的車廂）。不論多復雜的生成形式，都向標準的應收表里插入，遵守松耦合模式，從基礎數據庫中提取基礎數據，本計算模型所需用到的各類參數、計算依據獨立設置，獨立配置，獨立錄入。盡量減少和避免與其他計算模型的共用數據，以避免相互之間的干

12、擾帶來衍生BUG。組件超市，不僅應收、包括應付、客服項目都可以考慮組件化：每個組件開發完成后就加入組件庫，供客戶根據自己的情況來選擇租用。簡單的、基礎的、常用的，免費（其實加在基礎套餐包里了），復雜的、個性的，根據實際情況收一段時間的費，過一段時也可以免費后面又開發了更新的組件，可以收費。二種規劃模式的另一種形象比較整體計算模型共用參數和依據庫造船模式需求1需求2需求3需求n變革成果需求1需求2需求3需求n獨立計算模型和參數依據庫基礎數據基礎數據獨立計算模型和參數依據庫獨立計算模型和參數依據庫獨立計算模型和參數依據庫成果鐵路模式技術分析對比二種模式的相同點和區別相同點：目標都為了滿足客戶需求：

13、無論怎么做，最終目標都是滿足客戶需求。以應收生成為例，都是要求根據客戶的需求和客戶人工操作時的計算模型，在系統中完成應收生成，結果與客戶手工計算的結果相符。過程都為了生產成果這二種模式，都需要材料，包括原始材料（如房客設備基礎數據）和中間材料（如水電讀數）等，都需要生產設備（計算模型），都將產出成果（應收應付等）；最終結果，都必須是正確的；技術分析對比二種模式的相同點和區別造船模式思路：用一套復雜的模型完成所有客戶需求。優點是：思路簡單，把雞蛋全放在一個藍子里，打理好這個藍子就行了。缺點是：必須花很多時間去前期規劃，希望能把所有問題和需求全包容住，但實際上不可能我們接觸到的永遠不會是全部，就算

14、我們了解了現在的全部，隨著行業和管理的發展我們的認識也會過時，新的問題和需求永遠不斷。前期花再多的時間也不可能完全包容住后面的新問題和新需求，實際上，也就是能想多少就想多少，想不到的以后遇上了再補。所以說這部分的時間消耗很多情況下是無謂的，是浪費的。鐵路模式一開始整的也是蒸汽機車，如果一開始就按高鐵的要求來整，很可能到現在咱們都坐不上火車難度太大周期太長，還沒整明白大家都沒信心撐不下去了。而且各類需求之間可能會出現沖突“一個藍子里雞蛋放太多了，上面雞蛋的重量會把下面的雞蛋壓破的。”，因為是統一的模型，剛開始沒有想到的，后來要補，可不一定補得進去，因為跟以前的規劃架構可能不匹配，有一些勉強能補進

15、去，但可能會對原有功能造成影響，帶來衍生BUG。技術分析對比二種模式的相同點和區別鐵路模式思路：用一套簡單的模型完成一個客戶需求，包裝成一個相對獨立的組件。用多個組件的靈活組合來滿足每個客戶的綜合需求。優點是：在區分好關鍵需求（軌距/如基礎數據）、共用需求（剎車/如水電讀數）和外圍需求之后，只要把關鍵需求、部分共用需求、少量啟動時就要用的外圍需求規劃好，就可以開工，后面可以長年增補。在啟動時只想應該想的，必須想的，能夠想的，馬上就需要用的。其他的，在有足夠發展空間保證的基礎上，以后再想。符合規范就能掛得進來。個人感覺：更加匹配SAAS產品的長遠贏利模式基礎功能包免費（實際上打包在年租金里了，包括一些常用的組件），如果客戶提出或自行了解到新的功能要求，開發新的組件掛上去，啟動用戶試用正常后，普通的也免費，高價值的加入組件超市明碼標價（建議不貴，一年幾元到二十元左右），收費一段后也改為免費，后面不斷有新的收費組件加入組件超市，擴展贏利空間。缺點是：新思路，風險大通過仔細討論，廣泛研討盡量降低承受壓力，承擔責任；關鍵需求的界定是否準確至關重要，而且做到這一點是非常困難的；長期堅持方向，遇到問題解決問題，遇到困難突破困難，這一點比制定方向更難；必然存在一定的，策略性的重復性研發投入，因此有一定的投資