摘要：從公司層面講，也不能以產品進行團隊劃分，比如騰訊，可以用一個游戲劃分一個團隊，但是在，除了大產品模塊的劃分比如桌面端產品，端產品，其他業務產品，其實沒有具體的產品團隊，更多的是開發團隊，而開發團隊內部才劃分到具體的產品線上。

從大學開始接觸Web開發，到現在已經是第9個年頭了，但是感覺自己才剛剛開始入門。特別是開發模式（這個稱法待議），不同的公司不一樣，團隊結構，團隊合作方式都有很大的區別。我雖然經歷的公司不多，但是接觸了一些，自然有些比較。今天主要分享一下morningstar的產品開發模式。

一個產品的上線，需要經歷非常多的步驟，單就產品開發這個方面，主要可以分成幾個塊。不同的年代，方式也不同，分塊的依據也各異。下面是我總結的傳統的產品開發模式：

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

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

早期的時候，前后端其實也分得不是很清楚，后端用PHP，順帶就使用MVC框架那一套，把HTML+CSS的部分全部完成了。比如你用PHP框架進行開發，完全是后端主導，因為所有的頁面HTML模板全部是后端定義的。

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

中間通過Node將前端和后臺完全分離。后端完全專注于數據和數據業務邏輯，前端則通過node實現界面和交互，對后端僅有數據接口依賴。

這種改變使得web開發從“CMS向APP”轉變，以前的MVC更多的是CMS的思想，而現在的MVC更多的是APP思想。

作為外企，Morningstar的產品架構都是在芝加哥完成的，深圳團隊主要是在架構思想上進行具體的實現，老外的思想總比國內激進一些，國內PHP還盛行的時候，我們的產品僅留下Java和JavaScript兩門語言。Java開發data api，而JavaScript實現剩下的全部產品開發。如果你關注我的微博，應該有發現我提到過這點。

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

和傳統的產品開發有很大的不同，在這種模式下，一個程序員無法給自己在產品線上定位，程序員不知道自己在為哪一個產品開發（或者說程序員在為所有的產品做開發）。

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

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

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

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

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

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

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

1. 公司成長階段

如果一個公司只有一個產品，剛開始創業，當然是傳統模式更占優勢，比如開發知乎的團隊，為了讓產品趕緊上線，迅速迭代，當然要開發團隊自己拿主意。如果采用第二種模式，前端開發受到后端的制約，后端受到數據庫的制約，component受到framework的制約，framework受到具體需求的制約，制約來制約去，消耗的就是時間。

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

2. 模塊重用可能性

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

但是如果產品之間的模塊重用性很大，就應該考慮新的開發模式。

Morningstar的所有產品之間具有非常大的相似性，產品界面幾乎長一個樣，但具體的細節卻不同，不同的基金經理需要的數據不一樣，所以得到的產品也不一樣。這就非常適合使用這種新的開發模式。

3. 敏捷開發（團隊）

敏捷開發的前提是，有一個非常強有力的團隊，而團隊意味著集中在某些具體的開發上面。但是敏捷開發一般都是針對產品，產品的需求、設計、測試、迭代，都要快。但是在Morningstar的這種模式下，根本無所謂敏捷不敏捷。

程序員所在的團隊可能只有開發和測試，而沒有設計，甚至連產品都沒有。從公司層面講，也不能以產品進行團隊劃分，比如騰訊，可以用一個游戲劃分一個團隊，但是在Morningstar，除了大產品模塊的劃分（比如桌面端產品，web端產品，其他業務產品），其實沒有具體的產品團隊，更多的是開發團隊，而開發團隊內部才劃分到具體的產品線上。

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

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

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