摘要：從公司層面講，也不能以產(chǎn)品進(jìn)行團(tuán)隊(duì)劃分，比如騰訊，可以用一個(gè)游戲劃分一個(gè)團(tuán)隊(duì)，但是在，除了大產(chǎn)品模塊的劃分比如桌面端產(chǎn)品，端產(chǎn)品，其他業(yè)務(wù)產(chǎn)品，其實(shí)沒有具體的產(chǎn)品團(tuán)隊(duì)，更多的是開發(fā)團(tuán)隊(duì)，而開發(fā)團(tuán)隊(duì)內(nèi)部才劃分到具體的產(chǎn)品線上。

從大學(xué)開始接觸Web開發(fā)，到現(xiàn)在已經(jīng)是第9個(gè)年頭了，但是感覺自己才剛剛開始入門。特別是開發(fā)模式（這個(gè)稱法待議），不同的公司不一樣，團(tuán)隊(duì)結(jié)構(gòu)，團(tuán)隊(duì)合作方式都有很大的區(qū)別。我雖然經(jīng)歷的公司不多，但是接觸了一些，自然有些比較。今天主要分享一下morningstar的產(chǎn)品開發(fā)模式。

一個(gè)產(chǎn)品的上線，需要經(jīng)歷非常多的步驟，單就產(chǎn)品開發(fā)這個(gè)方面，主要可以分成幾個(gè)塊。不同的年代，方式也不同，分塊的依據(jù)也各異。下面是我總結(jié)的傳統(tǒng)的產(chǎn)品開發(fā)模式：

這種模式非常清晰，特別是對于程序員而言，非常容易定位。一個(gè)程序員，是做哪一個(gè)產(chǎn)品，是前端還是后臺還是數(shù)據(jù)庫開發(fā)，都可以找到自己的位置。

而且這種開發(fā)模式有很多有點(diǎn)，比較適合敏捷開發(fā)。大公司小公司都在用，小公司可能只有一個(gè)產(chǎn)品，一個(gè)團(tuán)隊(duì)，大公司可以多個(gè)產(chǎn)品線，多個(gè)團(tuán)隊(duì)，團(tuán)隊(duì)之間有人員流動，但所有的研發(fā)人員都可以非常明確的用“在開發(fā)哪個(gè)產(chǎn)品，自己是哪個(gè)端”來給自己在公司里面定位。

早期的時(shí)候，前后端其實(shí)也分得不是很清楚，后端用PHP，順帶就使用MVC框架那一套，把HTML+CSS的部分全部完成了。比如你用PHP框架進(jìn)行開發(fā)，完全是后端主導(dǎo)，因?yàn)樗械捻撁鍴TML模板全部是后端定義的。

隨著前后端分離的思想出現(xiàn)之后，上面這種完全后端主導(dǎo)的局面也逐漸瓦解了，前后端分離是指前端和后端專注（甚至只）做一件事，所以在我寫的《從web架構(gòu)來認(rèn)識nodejs》這篇文章里，就勾畫了大致的新的前后端分工：

中間通過Node將前端和后臺完全分離。后端完全專注于數(shù)據(jù)和數(shù)據(jù)業(yè)務(wù)邏輯，前端則通過node實(shí)現(xiàn)界面和交互，對后端僅有數(shù)據(jù)接口依賴。

這種改變使得web開發(fā)從“CMS向APP”轉(zhuǎn)變，以前的MVC更多的是CMS的思想，而現(xiàn)在的MVC更多的是APP思想。

作為外企，Morningstar的產(chǎn)品架構(gòu)都是在芝加哥完成的，深圳團(tuán)隊(duì)主要是在架構(gòu)思想上進(jìn)行具體的實(shí)現(xiàn)，老外的思想總比國內(nèi)激進(jìn)一些，國內(nèi)PHP還盛行的時(shí)候，我們的產(chǎn)品僅留下Java和JavaScript兩門語言。Java開發(fā)data api，而JavaScript實(shí)現(xiàn)剩下的全部產(chǎn)品開發(fā)。如果你關(guān)注我的微博，應(yīng)該有發(fā)現(xiàn)我提到過這點(diǎn)。

昨天在rong給我們講解了公司目前的產(chǎn)品研發(fā)的思想后，我覺得這可能是未來產(chǎn)品研發(fā)的趨勢，特別是經(jīng)過十多年發(fā)展之后，開發(fā)已經(jīng)不再僅僅是橫向的工具，而逐漸成為企業(yè)縱向的血液，不僅要控制成本，而且要保證產(chǎn)品群是公司想要的結(jié)果。于是，就有了下面的結(jié)構(gòu)：

和傳統(tǒng)的產(chǎn)品開發(fā)有很大的不同，在這種模式下，一個(gè)程序員無法給自己在產(chǎn)品線上定位，程序員不知道自己在為哪一個(gè)產(chǎn)品開發(fā)（或者說程序員在為所有的產(chǎn)品做開發(fā)）。

在傳統(tǒng)模式下，前后端分離，后端開發(fā)者調(diào)用數(shù)據(jù)庫為前端提供api，但是往往基于某一個(gè)產(chǎn)品的特定需求，相當(dāng)于定制。而現(xiàn)在data層的開發(fā)并不為產(chǎn)品服務(wù)，而直接為整體業(yè)務(wù)服務(wù)，data api不再從業(yè)務(wù)邏輯出發(fā)，而是以data point為目標(biāo)。data api團(tuán)隊(duì)接到的需求絕對不是產(chǎn)品需求，而是非常明確的“需要哪些（數(shù)據(jù)）點(diǎn)，可以按照xx進(jìn)行區(qū)間和步幅查詢，可以按照xx排序，可以按照xx分組”類似這樣的需求，它完全脫離了業(yè)務(wù)邏輯，開發(fā)者并不需要知道自己的開發(fā)具體是為哪一個(gè)產(chǎn)品服務(wù)，也不知道自己的api具體要實(shí)現(xiàn)什么業(yè)務(wù)邏輯，程序員只需要專注于算法和性能。

最大的不同莫過于capability這一層。因?yàn)楣粳F(xiàn)在也不知道怎么來定義這一層，所以目前暫時(shí)用capability稱呼。這一層是開發(fā)者集中的一層，也就是前端開發(fā)（后端在data層）。這一層你可以看到，總體層面有一個(gè)framework，當(dāng)然也不一定只有一個(gè)framework，可能有多個(gè)framework實(shí)現(xiàn)不同的邏輯，但總體上就是要有framework，用來裝component，所有的功能都被制作為component，用戶需要什么功能，就把component塞到framework里面去，打包好之后，就成了一個(gè)product，可以賣給客戶。

實(shí)例說下：我們有一個(gè)產(chǎn)品，叫Asset Manager，是向基金經(jīng)理提供資產(chǎn)管理分析的產(chǎn)品。我們還有一個(gè)產(chǎn)品，叫Wealth Manager，是向更高級別的用戶提供資產(chǎn)管理者分析的產(chǎn)品。這兩個(gè)產(chǎn)品的目的不同，前者是要讓用戶（基金經(jīng)理）更好的管理資產(chǎn)和進(jìn)行預(yù)測分析，而后者更多的想讓用戶（投資機(jī)構(gòu)）挑選合適的基金（通過看這個(gè)基金經(jīng)理的業(yè)績來確定是否值得挑選），所以這兩個(gè)產(chǎn)品的需求不同。但是雖然需求不同，可是有些方面，在數(shù)據(jù)呈現(xiàn)上是一樣的，比如單支基金在某個(gè)時(shí)段的流入流出，這兩個(gè)產(chǎn)品都可以查看這個(gè)情況，所以實(shí)際上它們使用同一個(gè)component，在類似的其他某些點(diǎn)上，也可以使用相同的component塞到不同的產(chǎn)品里面去。

所以，實(shí)際上，capability一層為product一層提供了原材料，或者叫“組件，模塊”，product是對這些“模塊”的組裝。而這些component就是零件，它們可以被復(fù)用，甚至通過修改配置，來使得連接到不同的data api上，以適應(yīng)更好的product。

這種開發(fā)模式的意義非常大，它相當(dāng)于解放了所有開發(fā)者，讓他們更專注，同時(shí)在公司層面，可以極大的降低成本，產(chǎn)品更加快速，可以說有多少種component的組合，就可以有多少個(gè)產(chǎn)品。

我在Morningstar開始的時(shí)候很迷茫，不知道自己到底是要做什么，而且component的開發(fā)有自己的一套規(guī)則，所以大部分時(shí)間都在研究這些規(guī)則，研究完規(guī)則之后，跟以前寫前端沒有什么差別，只不過還是不知道自己是在為哪一個(gè)產(chǎn)品服務(wù)。后來在理解這種模式之后，我就對自己的狀況有了更多的了解。

那么這兩種模式哪一種更好呢？答案當(dāng)然是不確定，只能說“適合就好”。

1. 公司成長階段

如果一個(gè)公司只有一個(gè)產(chǎn)品，剛開始創(chuàng)業(yè)，當(dāng)然是傳統(tǒng)模式更占優(yōu)勢，比如開發(fā)知乎的團(tuán)隊(duì)，為了讓產(chǎn)品趕緊上線，迅速迭代，當(dāng)然要開發(fā)團(tuán)隊(duì)自己拿主意。如果采用第二種模式，前端開發(fā)受到后端的制約，后端受到數(shù)據(jù)庫的制約，component受到framework的制約，framework受到具體需求的制約，制約來制約去，消耗的就是時(shí)間。

但是當(dāng)公司成長起來，到了一個(gè)特定的階段的時(shí)候，產(chǎn)品就有可能這樣去分。比如微信，把通訊錄、公眾號、朋友圈兒、支付看成component，那么整個(gè)微信就是framework。但是在騰訊公司這樣一個(gè)大的環(huán)境里，仍然保持著傳統(tǒng)的開發(fā)模式，很多資源重復(fù)開發(fā)，不知道會不會是制約騰訊的一個(gè)點(diǎn)。

2. 模塊重用可能性

一個(gè)公司的產(chǎn)品雖然多，但是都不是同類產(chǎn)品，自然要將這些開發(fā)分開。比如淘寶和支付寶，不可能放在一起，但是它們底層的數(shù)據(jù)可以共享。比如QQ和騰訊視頻，如果作為兩個(gè)多帶帶的產(chǎn)品，也不可能有什么地方可以重用。如果一個(gè)公司，做了一款電商產(chǎn)品，過了一點(diǎn)時(shí)間又做醫(yī)療產(chǎn)品，那也不能重用。

但是如果產(chǎn)品之間的模塊重用性很大，就應(yīng)該考慮新的開發(fā)模式。

Morningstar的所有產(chǎn)品之間具有非常大的相似性，產(chǎn)品界面幾乎長一個(gè)樣，但具體的細(xì)節(jié)卻不同，不同的基金經(jīng)理需要的數(shù)據(jù)不一樣，所以得到的產(chǎn)品也不一樣。這就非常適合使用這種新的開發(fā)模式。

3. 敏捷開發(fā)（團(tuán)隊(duì)）

敏捷開發(fā)的前提是，有一個(gè)非常強(qiáng)有力的團(tuán)隊(duì)，而團(tuán)隊(duì)意味著集中在某些具體的開發(fā)上面。但是敏捷開發(fā)一般都是針對產(chǎn)品，產(chǎn)品的需求、設(shè)計(jì)、測試、迭代，都要快。但是在Morningstar的這種模式下，根本無所謂敏捷不敏捷。

程序員所在的團(tuán)隊(duì)可能只有開發(fā)和測試，而沒有設(shè)計(jì)，甚至連產(chǎn)品都沒有。從公司層面講，也不能以產(chǎn)品進(jìn)行團(tuán)隊(duì)劃分，比如騰訊，可以用一個(gè)游戲劃分一個(gè)團(tuán)隊(duì)，但是在Morningstar，除了大產(chǎn)品模塊的劃分（比如桌面端產(chǎn)品，web端產(chǎn)品，其他業(yè)務(wù)產(chǎn)品），其實(shí)沒有具體的產(chǎn)品團(tuán)隊(duì)，更多的是開發(fā)團(tuán)隊(duì)，而開發(fā)團(tuán)隊(duì)內(nèi)部才劃分到具體的產(chǎn)品線上。

我只能從自己的感覺去理解，Morningstar作為核心技術(shù)架構(gòu)在美國的公司，有很多技術(shù)上先進(jìn)的地方是值得思考的，但是作為個(gè)人，開發(fā)者也要為自己的成長考慮。如果按照Morningstar的模式發(fā)展下去，不出幾年，這種架構(gòu)就會穩(wěn)定下來，一個(gè)開發(fā)者很快會成為這種穩(wěn)定結(jié)構(gòu)中的一個(gè)節(jié)點(diǎn)，就像流水線上的工人，需要用自己熟練的操作，在規(guī)定的時(shí)間快速完成規(guī)定的動作。比如有一個(gè)新的component要做，實(shí)際上component的規(guī)則已經(jīng)定好了，你必須先把這些框架性質(zhì)的代碼先寫好，然后開始發(fā)揮，但是眾所周知，這種發(fā)揮的空間并不算大，而且很有可能只是利用經(jīng)驗(yàn)，而非學(xué)到東西。

但是作為公司層面，甚至作為社會協(xié)作層面，這種模式值得借鑒，它可以更好的降低開發(fā)成本，特別適合擁有數(shù)據(jù)資源的公司，像微博、騰訊、阿里這些公司，已經(jīng)在數(shù)據(jù)服務(wù)上開始思考了。作為開發(fā)者，也可以在拿到相同報(bào)酬的情況下獲得更多的休息時(shí)間，這或許是解決國內(nèi)程序員加班問題的一條途徑吧。而且有了這套模式，把眾包模式具體化也是有想象空間的。

本文先發(fā)布在我的博客，歡迎到我的博客拍磚探討
作者：@否子戈
微信：wwwtangshuangnet