李先生在一家上市軟件企業擔任需求分析師，該公司在電信信息化已經有多年積累，為了縮短軟件的交付周期，降低研發和維護成本，公司從一年前開始逐步從定制化開發向產品化方向轉型。李先生負責的產品參加軟件產品化運營的第一批試點，經過1年的努力，產品已經在5個現場上線并開始正式運營，年底成本核算，比同類定制化項目效益提升了近40%，李先生還被評為優秀員工。
隨著產品的深入使用，現場反饋的新需求越來越多，而且需求之間的沖突越來越多。以前做定制化開發遇到需求沖突的情況，一般都是和用戶協商，由用戶方安排一接口人，負責溝通和解決有沖突或者不合理的需求。但現在不同的現場需求之間有沖突，這種辦法就行不通了。另外，軟件中為了實現不同需求，配置項和邏輯分支越來越多，程序的維護越來越困難，常常一周過去了現場報的問題解決還沒有眉目，用戶嘖有煩言。開發工程師的不滿也越積越多，認為需求分析工作不到位，需求頻繁變更，導致軟件質量下滑。如果再這樣下去，軟件的問題會越來越多，工作會越來越難做，點上一支煙，李先生陷入沉思。
一、軟件產品需求管理面臨的問題分析
軟件產品化運作的企業越來越多，大多企業的需求分析師或項目經理都遇到過和李先生類似的情景?？偨Y一下大概有下面三個問題：
1、需求來源多樣，差異過大難以兼容
產品化和定制化開發的主要區別之一就是產品化面向的是用戶群，而定制化開發面向的是一個或幾個同質化的用戶。所以產品化比定制化接收需求的多樣性要豐富的多。針對同一功能點的需求，需求之間或重疊，或交叉，或互斥。按照用戶甲想法實現，可能用戶乙會強烈不滿。
2、配置項過多，軟件使用過于復雜，用戶不滿增加
解決不同需求的一個最簡單的辦法，就是增加配置項。通過配置項交付有差異的功能給不同的用戶。隨著產品的維護時間，軟件中的配置項越來越多，產品的使用復雜度越來越大。每次產品升級時，一不小心覆蓋了本地化配置，就會造成原有功能丟失，軟件無法使用等異常情況，嚴重時還可能被用戶投訴。
3、程序中充斥大量的分支邏輯，越來越難以維護，產品質量越來越差
研發工程師的人員流動率在諸多行業中，公認比較高。一茬一茬的新陳代謝，再加上很多企業的過程管理不嚴謹，文檔不全，原來為解決不同需求引入的配置和邏輯分支成了新的世紀之謎。為了快速完成任務，避免影響現有功能，工程師們采取另外增加一個分支的方式解決問題和實現需求。
日積月累，程序中像謎一樣的分支越來越多，程序質量開始變的很糟糕。往往解決了一個問題，引發了一系列的bug。開發工程師們越來越沒有成就感，對軟件的前景越來越沒有信心。
二、多層次需求管理的對策
在上述的問題仔細分析，可以發現一個產品的需求其實是分層次的，有些需求是某個用戶群特有的需求，比如電信領域中中移動和中聯通的規范在方向上有非常大的差異；有些需求是某些用戶的通用需求，比如網管中心監控人員對于網元的呈現方式；有些需求是用戶的個性化或者臨時性需求，比如重大活動保障時期的特定需求。如果要解決產品化引致的這一系列需求問題，就不能把視角局限在需求-開發的層面上，而是要在站在業務領域分析，產品定位的高度，合理地把需求落實到不同層次上解決。
圖1：需求和需求交付的對照關系
1、用戶群的需求處理策略
一個規模推廣的產品可能會橫跨多個用戶群，比如在電信BOSS領域的計費軟件，移動，聯通，電信都有自己的技術規范，中間的規范方向，計費的模式以及算法各不相同。
如果把這些都放到相同的產品上實現，會造成產品非常臃腫和復雜。
我們的經驗是首先創建產品平臺，平臺的設計采用微內核的方案，內核包括系統的技術框架，組件的集成引擎和一些公共的工具組件，平臺外圍功能采用組件化的方案，包括不同的批價算法組件，適配組件，配置組件等。按照用戶群的需求以及商務策略把內核和相關組件打包成不同的業務產品，如移動版，電信版和聯通版等。
運營商的規范升級以后，同時也要對產品平臺上的相關組件進行升級，并發布新版本的業務產品。所有的業務產品就組成了一個計費的產品族。
這種策略在一些大型的軟件企業里應用非常廣泛，比如微軟的window產品系列：window Server，window profession，window home，分別覆蓋企業用戶，商務用戶和家庭用戶這三個有著明顯需求差別的用戶群。國內騰訊公司的QQ和TM也是一個成功的案例，用兩個不同風格的軟件覆蓋娛樂人群和商務人群的社交需求。
2、用戶的典型性需求
所謂典型性需求是此類需求具有普遍性的特征，比如在報表要提供10秒鐘自動刷新數據功能。這類需求往往可以引導產品規劃方向，因為使用最深入的用戶提出的需求最多，而且需求的價值越大。
對待這一類的需求，一般對應有兩種配置方式，一種是粗粒度，一種是細粒度。跟據用戶的偏好和使用的環境，在系統安裝階段配置，配置影響的粒度一般是組件級，最小到對象級，比如office安裝過程中，引導用戶選擇需要在本地安裝的程序模塊，比如word，excel，dbaccess等。另一種是系統中的各種配置項，影響的主要是對象級以及程序的邏輯，比如firefox中的系統配置項，以及window的注冊表。
利用這兩級的配置管理，基本上能解決用戶需求的差異化，但采用這種辦法的前提是已知用戶的可能需求并預先做了定義和開發。對于不可預知的需求，就需要通過二次開發接口來解決了。
3、用戶的本地化需求
用戶本地化需求的滿足程度，響應時間和用戶的滿意度關系非常密切，要提升用戶滿意度就必須關注本地化需求的實現。而軟件產品的大規模推廣帶來的本地化需求的工作量非常大，不僅會影響企業的利潤率，而且提高了產品自身維護的風險。所以大型的軟件產品都會提供一些本地化需求開發，比較典型的是sap，sibel，把產品實施和本地化開發的工作全部外包出去。
在產品定義階段，需要重新評估產品的范圍，以及在產品范圍內可能的用戶本地化需求，對其中非核心的，可以通過外掛接口實現的功能規劃出二次開發接口。比如運維平臺短信派單模塊，安排短信派發的二次接口，產品實施的時候，通過開發相應的短信接口類，適配不同的短信網關，短信協議，然后把該實現類掛接到系統上實現短信工單排飯的功能。
二次開發接口的優點是增強了系統功能的擴展性以及縮短了需求的響應時長，缺點也是比較明顯的，當二次開發接口過多，過于復雜超出了產品管理的能力時，會在產品升級的時候帶來很多問題，比如開發程序被覆蓋，接口變更導致功能無法使用等。
三、總結
相比定制化開發，產品化的模式提高了復用水平，降低了研發和維護成本，但是提高了管理水平的要求，特別是規劃，需求以及交付管理。筆者見過很多中小公司，產品化運營以后不經沒有提高經營效益，反而因為產品前期投入過大，后期維護成本過高而陷入泥潭。所以產品化運營是否成功的關鍵在于業務積累和管理水平。前者是規劃產品方向，能否取得市場競爭優勢的核心；后者是產品化目標的保證，是能否切實降低研發維護成本的關鍵。采用定制化還是產品化，取決于企業的發展水平以及企業的競爭優勢，沒有最好，只有最適合。
對于產品的需求管理，不應該套用定制化的那套解決辦法，應該把需求分析放在合適的產品層次上考慮需求的實現方案，如果原有的解決方法需要平面思維，那么在產品化的需求分析需要的是多層次的立體思維模式。