起源
對于電信行業而言，這是一個沸騰的歲月——VOIP、小靈通、寬帶上網、短消息、預付費等等業務，一股腦的推到百姓面前，讓“上帝”們頓時感覺眼花繚亂；而我們，作為電信運營支撐系統（主要功能是計費、營帳）的開發公司，也終于有了用武之地。
面對忽然出現的市場需求，我們迅速做出了本能的反應：盡我們所能滿足電信局用戶的要求，搶占運營支撐系統的市場份額。本來我們已經擁有了一個針對市級電信客戶的小型計費系統，經過不斷維護增強而相當成熟；面對一下子冒出來的不同運營商在長話、市話、IP電話計費營帳以及相互之間結算的系統需求，我們將開發人員分成不同的項目組，在原有基礎上分別為不同的客戶進行定制開發，并全權負責系統的集成和交付。隨著所交付應用的系統數量不斷增加，成功的喜悅被一種焦慮和疲憊所代替——客戶需求增加/變更和產品缺陷處理。項目團隊成員像救火隊一樣奔赴現場，解決客戶的問題。我們就像《人月神話》的描述一樣，表面上看起來好像沒有任何一個單獨的問題會導致困難，每個都能被解決，但是當它們相互糾纏和累積在一起的時候，我們的行動就會變得越來越慢。對問題的麻煩程度，每個人似乎都會感到驚訝，并且很難看清問題的本質，一個接一個淹沒在了焦油坑中。
盡管大家鮮有機會當面交流，但是仍然會通過郵件交流一下現場解決問題的進度和方式：我們發現很多用戶的需求是相同或是類似的，由于原有系統缺乏該功能，我們不得不針對不同用戶去重復開發相同的特性，我們甚至私下提供代碼以相互參考。我們有時隱隱覺得該作些什么使開發效率提高一些，但是這種念頭在現場用戶焦灼而嚴厲的目光下轉瞬間就消失了。
公司總部也發現了這個問題，為我們空投了一位技術總監。其實我們對他并不陌生，他曾經在硬件和嵌入式系統的項目中從事過管理工作，一個認為系統開發都是類似的、擁有莫名優越感的項目經理。從他參加了一系列昂貴的培訓經歷來看，總部仿佛期望將他培養成未來的管理明星，而我們這里就好比這位明星的起跳板和出場秀。
剛剛上任，他就為大家宣灌了“平臺化”開發的重要意義和方法，聲稱要將系統開發的像KFC配餐一樣方便快捷。他要求項目組把各個系統的特性列出清單，然后將這些特性匯總為一張總表，又加上了一些頗為時尚的定語：跨數據庫、跨操作系統、三層結構等等。當我們解釋跨數據庫在技術實現上是多么困難時，得到的答復是你們可以自行開發一個高效的數據庫來徹底解決這個麻煩。在飽受現場客戶的抱怨后，我們長久以來被壓抑的情緒終于在這種無知和傲慢面前得到了發泄：在一次重要的產品規劃會議上，我們將異常樂觀的里程碑計劃、“亂點鴛鴦譜”般的特性分配進行了徹底的否決，甚至將這個夢想中的“平臺產品”戲稱為“殺死你三千”（周星馳的一部電影中將各種炸藥放在一個籃子里，聲稱是精心研制出的超級武器，實際上卻是派不上用場的廢物）。那位曾經躊躇滿志的技術總監在“千夫所指”下黯然離去。
鬧劇收場了，盡管我們在心里上得到了暫時的宣泄，但是在業務上卻是一籌莫展。我們也認同這種平臺化開發是解決目前困境的有效手段，但是僅僅有理念是遠遠不夠的，我們缺乏一個真正能夠將理念付諸實踐的人物，否則仍然要在黑暗中不斷碰壁。更糟糕的，我們已經沒有時間來揮霍：來自用戶的壓力漸漸將我們逼到了墻角卻無力扭轉；公司總部在核算我們部門的財務狀況，如果無法盈利將來就會被拆分或是裁員。
我們將何去何從？
轉機
有時候你不得不承認一個人可以帶來轉機。
作為一家開發電信支撐系統的公司，Z公司是我們的競爭對手，其產品質量和研發效率強于我們，我們一直也不明白其中的奧秘。Z公司的一位資深項目經理被我們“挖”了過來，準確的說不是我們“挖”的，而是這位心直口快的業務牛人得罪了公司高層，居然越俎代庖的妄想染指Z公司的產品規劃活動，震怒的Z公司高層于是將他“推”到了我們面前。我們就將這位業務牛人稱為“小馬”吧。
在困境中的人們往往期望奇跡的發生，我們就將這個奇跡寄托在小馬身上了——小馬被任命為我們的技術總監。
由于曾經是競爭對手，小馬對我們的產品現狀一清二楚，甚至可以說得出各個產品的特點和缺陷。他對我們各自為戰的局面感到困惑，明確提出當務之急是必須采取平臺化開發方式，開發出能夠支撐未來整個產品系列的平臺框架，同時針對不同的電信客戶進行少量定制開發，在質量和進度方面獲得突破。他也指出平臺化開發會暫時影響我們對市場的響應，就是說會丟掉一些機會；我們在研發組織、工程師技能等方面也會有很大的調整。
大家對目前糟糕的狀況感到深深的厭惡，都希望能夠拿出有力的產品去整頓混亂的市場，當然前提是趕在市場機會窗關閉之前。我們已經沒有退路，所以也沒有猶豫就投入了這場日后看來頗具風險的“賭博”中了。
重整
小馬不像他的前任，沒有談論什么高深的理論，而是直接觸及了問題的核心——什么是我們的平臺產品，里面包括了什么。平臺對于我們的開發人員來講并不陌生——我們每天都在和各式各樣的平臺打交道：開發平臺、信息平臺、管理平臺。但看似簡單的問題著實難以回答，似乎每個人都知道一點，有無法達成共識。多數人心目中的理想平臺是無所不能的利器，可以定制成所有的產品：小到市縣級的簡單市話計費、大到省級漫游計費、也要包括營業帳務系統，還要支撐不斷出現的新業務，這樣我們就可以“一勞永逸”了。
從實際情況看，我們實在過于天真。基于原有系統不斷的修修補補已經將問題暴露出來了——原有的成熟的小型系統的架構根本無法支持全系列的產品，我們未來設計的平臺恐怕同樣無法包打天下。關鍵問題是，面對如此龐大的市場，我們到底如何規劃產品進而確定平臺的范圍。
這就是產品規劃的問題，對于我們這些技術出身的工程師來講，實在是“不專業”。都知道在“市場導向”與“技術導向”的PK中，無疑前者勝出，關鍵是如何操作。
小馬把我們公司負責計費產品的銷售人員、客戶經理請來共商大計。從這群平日巧舌如簧的人們口中，我們驚訝的發現了許多非常珍貴的信息：南北電信即將拆分，網間結算系統市場增大；移動公司準備出臺新的系統規范，其中會有很多新業務描述等等。當我們問他們為什么不將這些有價值的信息早點告訴我們時，他們說以前提供過很多信息后沒有反饋，所以現在也懶的說了；開發人員都挺忙，也沒有必要多此一舉。我們忽然感覺自己就像鐵路上玩耍的小孩，只注意了腳下的石子，卻沒有意識到即將呼嘯而來的列車。
好在現在還不算晚。經過幾次會議，我們對整個運營支撐系統的市場才算有了大致清晰的看法：
l? 小型系統屬于底端市場，用戶對系統的質量要求相對不高，盡管數量較大，但是進入門檻不高且價格戰激烈，后期維護成本相對較高；
l? CDMA、PHS網絡正在建設，支撐系統的市場需求旺盛，用戶對系統要求很高，并且重視系統的維護和增強，具有非常理想的業務利潤；
l? 針對國內終端用戶的現狀，預付費業務需求很大，關鍵是系統要提供實時處理的能力，這方面我們與很多競爭對手都是空白；
l? 運營商之間競爭加劇，互聯互通屢屢出現問題，因此網間結算系統的需求也很大，我公司在交換產品上強大的競爭力可以很? 好的支持這項業務；
l? ……
經過對各個細分市場的全面評估，我們終于決定將產品定位在中高端運營支撐系統和網間結算系統，放棄了苦苦支撐的底端市場——盡管有些留戀，但還是對未來充滿期望。
我們成立了包括銷售經理、客戶經理、開發工程師的聯合調查小組，幾個小組分別針對事先鎖定的目標客戶，專門了解客戶的需求。這樣一來，客戶反倒奇怪了——原來是遇到問題后叫你們過來，現在倒是不請自到了。由于之前維系得良好的客戶關系和現場表現出來的積極認真態度，用戶非常的配合——原來用戶很樂于將新業務的發展方向共享給我們，當然也樂于有機會傾訴一些對產品的抱怨，我們的調查小組都進行了詳細的記錄。為期半個月的調查活動確實收獲不小，我們甚至了解到很多競爭對手的產品信息。
在公司內部，我們也要求開發人員、技術支持人員將需求和建議都提交上來，我們甚至將公司熱線電話的記錄都進行了搜索以獲取有益的信息。我們從行業報告、電信業務規范等文檔中了解業務發展趨勢，邀請相關國際優秀公司進行交流（名義上是與人家探討合作意向，實際上是刺探情報，做法有點卑鄙）。
當無法確定某項特性是否必要時，我們就會考慮既然我們無法代表客戶，為什么不去直接問問客戶的感覺呢？所幸的是我們的問題幾乎都在用戶那里得到確認。
總而言之，我們從各種渠道收集系統的需求。
根據我們已經確定的目標市場及其關鍵業務特性，我們進行了整個產品線的開發規劃；相比原來的規劃，現在多出了一個“平臺產品”，這個并不向外正式出售的產品卻是我們全系列產品的基礎。下面就是產品開發路標的示意圖：
一般來講，我們對于產品進行版本劃分是考慮基礎版本用于快速推出并搶占市場份額，通過不斷推出后續版本來增加產品特性，鞏固、增加市場。平臺產品的規劃也采取了這一策略。我們根據預期的市場發展確定了市場目標，考慮不同產品的版本劃分和特性分配、平臺產品對應的配套版本，特性實現的優先次序、可用的研發資源等信息，初步規劃了整個平臺產品系列的開發里程碑計劃。
盡管我們已經耗費了很多時間進行產品規劃而沒有發布一款新的產品，但仍然對未來充滿信心，原因是我們努力的目標逐漸清晰了。不過我們卻低估了后續開發的難度。
痛并快樂著
我們把研發人員分成若干小組，其中最為重要的就是總體方案設計的小組和平臺產品研發的小組，還有針對不同產品進行定制研發的小組。
總體方案設計小組負責更為詳細的產品規劃、產品特性分配、平臺產品的技術方案和架構設計。最為關鍵和困難的就是確定平臺產品和最終產品的需求界限：如果定義得過于寬泛，平臺就會過于臃腫和低效，成了四不像的怪物；如果過于簡陋，最終產品的開發工作量增加，平臺的收益就會大打折扣。原有系統架構的局限性使我們要設計出更為健壯的產品平臺。這些在技術和業務方面都頗有造詣的工程師就像在實驗室里使用天平一樣進行著精心的設計，他們深知其結果對這個產品線意味著什么。
一旦確定了技術路線和總體架構，我們就能夠制定出更為準確的研發計劃。為了降低風險，在小馬的提議下，在一個可發布版本內部，我們進行了增量式開發——在平臺產品的一個“小版本”開發并驗證完成后，我們就可以進行集成，觀察“最終產品”的運行情況，將問題不斷反饋到下一個“小版本”的開發計劃中，而不是像以前那樣直到最后才進行確認。
平臺產品研發的小組和定制研發的小組主要是根據方案小組的設計進行實現并驗證。在系統實現過程中，我們才發現平臺式開發要比想象的困難得多。由于需要考慮模塊的重用、兼容、處理效率、容錯等問題，相比原來純粹項目式開發，現在的開發效率大為下降。經驗的不足使得總體方案的設計出現變更，引起了后續的連鎖不良反應，前面幾個“小版本”的驗證結果簡直是慘不忍睹。大家有些沮喪了。
由于我們把主要資源都投入了平臺產品的開發中，已經沒有什么精力估計新的市場機會了，現在競爭對手已經搶到了我們的前頭。公司高層有些坐不住了：要求我們的研發資源優先考慮市場機會，將平臺的開發工作推后。這時候，小馬忽然變得異常強硬，說服領導堅持優先進行平臺開發，暫時放棄面前誘人的市場機會。在其一番軟硬兼施下，公司高層決定讓我們放手一搏。
大家對現狀都很清楚，事實上我們已經沒有退路了。利用一個晚上，我們奢侈地享受了一次視覺盛宴：項目組成員集體觀看史詩巨片《TROY》。我們現在的處境好比阿基硫斯率領的勇士們剛剛登上特洛依城外的海灘，只能為了自己的未來和榮耀而孤注一擲。
在管理方面，我們采取了更加靈活的方式：平臺開發小組實施更為嚴格的過程管理制度，主要體現在輸出件的配置管理、變更控制、正規檢視；而對于定制開發的小組則允許相對寬松的管理方式。這種方法可以最大限度的保證核心系統的質量，加快開發速度。
吸取了以前版本混亂的教訓，從編碼階段開始，我們對于文檔和代碼進行了更加嚴格的配置管理，要求在每個小版本驗證之前必須提交各自完成的代碼，其后的變更遵循流程的控制。有一位屢教不改的資深工程師，被惱火的小馬直接“派去人力資源部報到”了。
原來我們有一個“潛規則”：升任項目經理后就擁有了不親自編程的特權。對此，小馬認為項目經理會逐漸失去對項目的“嗅覺”，他要求每個項目經理都要從事文檔設計、編碼和檢視工作，沒有例外。起初，幾個項目經理都是頗為不屑——哪有教授還參加考試的道理，但是發現小馬并非光說不練的“嘴把式”的時候，再也沒有人行使“特權”了。
如果說，我們的開發進程在開始階段是跌跌撞撞的話，在歷經了三次內部小版本的驗證后，就已經步入了順利的快車道：例行的小組溝通會變得不再勞神，項目進度偏差可控，沒有人懷疑會重現以前無法按時發布的情況，最為重要的是小版本驗證的通過樹立起了必勝的信心。
隨著項目完成過半，我們決定再多做些事情：我們提前為銷售人員介紹了產品的特性，將部分完成的系統展示給他們，使他們在用戶面前擁有更多的“炮彈”；我們要求資料撰寫人員提前介入，先期充分的產品規劃工作為用戶文檔撰寫帶來了極大方便；在進行內部驗證時，我們要求技術支持人員使用這個系統，以了解是否符合用戶的習慣；由于用戶對于系統運行的硬件環境有不同要求，我們搭建仿真環境以驗證系統的處理能力和硬件的兼容性；我們要求各個定制小組開發系統遷移計劃和實施方案，以應對未來系統部署時可能遇到的問題。
項目在有條不紊的進行著，市場上的競爭日趨白熱。為了驗證用戶對我們產品的看法，銷售人員選擇了典型客戶進行產品試用。從試用反饋情況來看，用戶比較認同新開發的產品，同時也對運行界面、部分特性提出了建議，我們都進行了記錄和分析。例如原來數據文件的采集都是采用FTP方式，現在有用戶提出在網絡質量不高情況下，FTP方式可能導致大文件重復傳遞或者傳遞失敗，建議增加對MQ傳輸方式的支持。我們將這個需求增加到平臺產品中，這意味著相關產品都具備了這個功能。
我們的努力終于得到了回報，同時發布了全系列產品。由于平臺產品具備系統健壯、便于擴展、接口靈活等優勢，使我們在不同的細分市場競爭中取得了領先。我們可以在合同中明確承諾產品交付延期的懲罰措施，而競爭對手在這方面幾乎都是遮遮掩掩——這源于我們對產品的信心。
尾聲
沒有什么系統能夠“一勞永逸”，平臺產品也是一樣，但是它的升級卻可以最大限度的延長產品的生命周期。我們現在正在開發下一代的運營支撐系統平臺，重點增強對軟交換、3G、內容服務的業務支持。從當初的一片空白到現在的駕輕就熟，確實走過了異常艱辛的歷程，所幸的是我們堅持下來并迎來了勝利。
有人想知道我們在困難的時候如何堅持下來，小馬只是淡淡的說：當時沒想什么，只是“我等這個機會等了半年，我不是要證明我比別人了不起，而是要證明我失去的東西我一定要親手拿回來。