技術產品的發展與平臺復用

首先，這裡說的產品不是指的應用類產品，不是什麼app或exe。這裡的產品專指技術類產品，如MySQL，Redis這種。

產品的平臺化

技術類產品的相關平臺一般分為兩種。

一種是為了更好的使用技術類產品的平臺。這種平臺的產生一般是因為產品非常複雜，用起來很難，為了更好的使用產品而開發建設出出一套平臺。這種平臺本質是技術產品的延展。其實也可以歸類到產品本身中去。

另一種平臺是產品相關的運維平臺。快速部署產品，方便運維，簡化集羣管理。

產品的平臺化有這重要意義，這標誌著產品走向成熟，可以接納更多的用戶。

所以產品平臺化是很多產品管理者最願意看到的。公司一般也會非常支持這種行為。

但產品是否需要平臺化，什麼時候平臺化，怎樣平臺化，公司一般不會管的太細。有一些產品管理者就會趁著這裡的漏洞強行將產品平臺化，好拿到更好的KPI。這本身其實沒什麼，不管是產品和平臺都可以迭代發展，也就是產品增加新特性，平臺改動以貼合新特性。這是合理的。

一般大公司都會有很多已經建設好的平臺。這些平臺往往在公司裏經過了多年的積累，也往往更受公司領導的關注。所以公司一般都會強調復用平臺，而不是獨立做一個品臺。關鍵問題一般出在復用這些平臺上。要怎麼復用是個問題。

復用要看什麼情況。產品平臺的復用首先要看技術產品的架構是否貼合平臺已有的產品架構。

比如公司裏的MySQL有個管理平臺。現在團隊的技術產品是MySQL的插件類產品。那就應該掛到MySQL管理平臺上去。不要做無用的重複建設。

有一些技術管理者會強行對產品做平臺重複建設。這些管理者一般技術能力有問題，可能是沒有太關注公司的已有品臺。也可能是管理者私心太重，認為自己的產品掛到了其他平臺上，產品的歸屬權就不是自己的了。

不管出於什麼樣的原因，重複建設從公司層面上應該要極力的避免。

平臺復用確實可以減少人力投入。但有時候又會出現盲目復用情況，可能管理者是為了減少人力投入，也可能是為了儘快平臺化，好拿KPI。但盲目復用或錯誤復用很可能造成產品本身的發展受限。

比如把一套基於HBase開發的存儲系統掛到基於MySQL開發的平臺下做運維，往後產品的開發可能就受限於這個MySQL平臺。當產品要改造新架構的時候，往往需要平臺也進行改動。但MySQL平臺主要是管理MySQL的，不可能為了一個非MySQL產品而改動平臺，產品此時之後有兩條條路：

這時就會發現，如果一個產品的架構不貼合平臺，那麼平臺會限制住產品的技術發展。這是一件很不划算並且很不合理。平臺應該是幫助產品成長，此時卻反過來限制了產品的發展。

所以該做得建設必須要做，不該偷懶的時候不要偷懶。哪怕平臺的歸屬權不歸自己所有，但一切的建設都是圍繞產品發展來做的。產品自身的強大才是最重要的。

以上說的事情，很多時候是公司政治導致的。有些產品管理者的技術能力本身就很有問題，對技術沒什麼遠見。另一方面是這些管理者非常急功近利，為了眼前利益，把產品開向了一條不正確的道路，使用大量資源與人力浪費在無用的建設上，甚至限制產品本身的發展。