關于産品開發的兩種方式

産品開發有兩種方式：

• 項目－産品－平台；
• 平台－産品－項目。

兩種方式各有個的特點，國内企業大多數都是從項目開始，逐漸積累摸索開始做産品，經曆了幾次的反複與陣痛後，逐漸發展成為平台。這種方式的特點是從項目中來，産品比較貼近項目，貼近特定使用者的需求。缺點是産品往往缺少平台級别的整體構架，缺少廣泛的适用性，在演化過程中往往要經曆幾次反複。

第二種方式從平台出發，其适用性就要廣泛了很多，反複過程也會相對平穩，整體開發成本及失敗的風險都會相對小一些。但是相對而言對于平台人員的能力、企業的技術積累等要求就要高了許多。這種方式往往是大部分有實力的公司采用的一種形式。

公司發展戰略上明确提出要開發平台級産品。但是現階段，公司的産品開發應該還是比較貼近前一種方式。我們現有的産品更加的貼近特定需求，相對而言就适用的廣泛性上就會有所欠缺。目前我們在産品項目的協調與融合上面臨的很多問題的根源是來自于此。項目需求的多樣化，而産品更加貼近特定需求，缺少靈活的結構。為了滿足目前項目需求，隻能對原有代碼進行入侵式的修改，項目需求逐漸侵食産品原有為特定需求而設計的構架，造成産品品質下降。而産品品質的下降使得實作新的項目需求變得更加困難。相信這也是公司上司提出“希望建立一種産品與項目融合協作機制”的原因之一。

其實不管是産品還是項目都存在着這樣一個事實－－開始是相當重要的，是以後良好發展的根基；是形成良性循環的根基。什麼問題開始時糾正的成本是最低的，随着項目、産品的發展這個成本将2倍，3倍甚至5倍10倍的提高。現在我們面臨着這樣一個困難的局面：産品我們有了，但是項目需求的多樣性是現在産品難以滿足的。怎麼辦？在現在的構架基礎上修改，隻能滿足一時之需，或者連這一時之需也難以滿足。而且随着項目需求對現在的産品代碼的入侵，産品将越來越難以維護，越來越難以往裡添加新的功能；而項目的風險也随着時間的推移越來越大。我們已經進入了一個惡性循環的開始，這是可以預見的。然而，完全抛棄現有的東西，對目前産品，開發人員的影響又是巨大的。對于公司也是難以接受的。怎麼辦？我們已經陷入了一種兩難的境地。

基于一般的認識，多數組織在這個時候都會慣性的采取一種“鴕鳥政策”或者說是“冰凍政策”。可預見的還未成為事實，況且不是每一個人的預見都是這樣。現在能用就這樣用着，等慢慢的問題暴露出來了，無法繼續了，大家都已經看到了，這時，已經成為事實，我們實際上已經沒有什麼選擇了，組織也隻能選擇接受。這樣作的明顯好處是對于組織中人員觸動是最小的，而且最後往往也是沒有人需要來承擔這個責任。唯一的缺點是組織在經濟上，項目上，進而是品牌上受到一定量的損失。

另一種方式，完全抛棄現有的東西，這對于目前的産品、開發人員的影響甚大。而且對于組織之前的一些工作也是一種否定，組織也是難以接受的。

那麼有沒有第三種方法呢？

讓我們換個角度來看待這個問題：實際上基于組織現在實際采取的産品開發方式（即從項目－産品－平台），那麼實際上這種反複是必然要經曆的。隻不過現在随着公司規模的擴大，人才的引進，我們人為的加快了這種反複。并且我們現在也有能力來加快這種反複，在反複的疊代過程中使産品快速成熟起來。很多公司在産品的開發過程中實際上都是這麼做的：在一個版本即将釋出時，下一個版本的規劃和開發實際上早已開始。這一版本發現的問題，收集的新的需求，按照一定的方式加入下一版本，以保證産品對于市場的及時回報與跟進。

現在，項目需求的多樣性，使的目前産品難以滿足，侵入式的修改到底能維系多久也是個疑問。或許這是我們啟動平台産品新版本開發的一個時機－－安排新平台的産品經理，新的設計人員，組建新的開發隊伍，依據目前問題重新設計構架，适當重用已有代碼。目前版本，由目前開發人員繼續開發，維護，以期能滿足一定的項目需求。這樣，當目前産品無法适應之時，我們的新版産品也能夠盡快的跟進，以盡量彌補可能的影響，将可能的風險與損失控制在一定範圍。