我們公司一直是做軟件產品的，這個產品在市場上也做了有10多年了。那麼必定在產品的版本上就要有很好的控制才行。
作爲一個不是很大的軟件企業來說，當然不能像微軟的Windows或者是Apple的Mac OS。Windows的版本策略，原則上當維護成本大於版本更替成本時，就可以考慮更換版本。一般來說，每一個版本3-5年的有效期。5年以後不再維護。而我們公司以前的策略是，有一個主線版本也就是大版本，還有很多的支線版本也就是補丁版本。多個版本並行一起開發維護。當支線版本有普遍應用的需求或者功能點時，可以考慮移植到主線版本中。這樣既保持了主線版本的通用性和穩定性，又比較靈活有一定的延續性。
而目前存在的問題是，大版本需求已經開發完善，很少會有大的變動了。但是現在實施的項目卻很多，而項目當中也有許多個性需求需要開發。可以移植到主線版本的東西可能不是太多。但是如果減緩大版本的步伐。那麼分支版本何時收口呢？何時纔到主線版本呢？分支版本怎樣很好的控制質量呢？這些都是凸顯的問題。
分析問題：
如果儘量採取1對1的方式，1個分支版本對應1個項目。那麼用戶的滿意度應該是最高的，但是同時，成本也是最高的。
如果採取1對n的方式，就有可能有一個問題，當某個項目要的需求可能其他項目不要，這個需求又可能會引發一些列缺陷，而這些缺陷本不應該發生在其他項目中。這樣勢必就會影響到用戶的滿意度了。但是這樣做的開發成本會降低。
解決方案大膽設想：
那麼最佳方案應該是，讓儘量類似的項目歸爲一個支線版本，完全不一樣的項目做1對1。這樣的話對產品經理的能力要求就比較高了。
同時，對於1對n的項目一定需要有一個策劃文檔說明各個項目的名稱以及歸併到一個支線版本中的理由。最好這個策劃的變更要走變更流程評審。而且當多個項目中的某一個項目結項時，需要對支線版本做結項操作，並行以此支線版做基線再產生新的支線版本做剩下的項目的繼續開發。
對於主線版本的策略：
因爲主線版本已經趨近穩定，已無大的變動。可以考慮這麼幾個策略：
1、以時間點來控制，比如1年時間發佈一個大版本。時間點嚴格控制不能延誤，但是範圍可以靈活調節。但是必須要保證足夠的測試時間，保證大版本發行的質量。這樣做的好處是，需求或者缺陷可以隨時加入，不受項目邊界的約束（項目邊界變更不需要變更申請）。缺點是項目週期長，項目邊界未知（完全由項目經理控制）。
2、用正規的項目管理來走，收集需求，確定邊界。當邊界滿足一定條件是（比如開發工作量達到6個人月）就進行版本開發。這樣做的好處是，項目邊界固定，項目完成時間可控，壞處是項目變更困難。
以目前產品特點來看，我建議用策略1。
自己瞎寫了一大堆。感覺就像在自言自語。呵呵，還望大家有更好的意見和建議。互相交流學習。
