這是敏捷開發一千零一問系列的第十七篇。（在這裡提問，之一，之二，之三，問題總目錄）

這個是在一次面向電信行業供應商的公開課上提出的問題，被評為本場最佳問題。

對於這類“供應商”而言，一方面業務根深蒂固，一般固化在某些專有領域因此很有必要產品化；另一方面又受制於客戶總是來回改動，很難有自己的自主權。兩者的矛盾，可以通過逐步推廣敏捷開發而解開，也需要大量的周邊技術、管理、市場手段來輔助。

甚至應該反過來說，敏捷開發知識輔助這些技術、管理、市場手段的執行。

問題

長期受制於強勢客戶怎麼辦？

方案

多數情況下，受制於客戶會導致開發活動長期以“無法複用的專案”存在，而不是以“一本萬利的產品”存在。所以本文會更多地說說專案開發，而非產品研發，但會循著專案產品化的道路走，因為這個幾乎是專案型公司的“只此一條”的出路。

老規矩，前面的方案最簡單，幾乎立刻就可以開始執行；而後面的方案才是終極之道，雖然很難。

方案1：從技術上把專案產品化

產品化是個大話題，投入和風險都很大，沒有老闆拍板，不是誰想做誰就能做的。方案1說的“從技術上”，就是連技術人員都能做主，不用問老闆“我們要產品化嗎”。具體手段，就是把專案中可複用的部分，抽出來做成可複用元件使用。很多人認為“做產品可以談複用，但做專案很難，因為每個專案都不一樣”，其實不然。在產品開發中，由於所有功能都只會做一次，其實很難在高層次上做複用；反而是專案，倒有可能在多個客戶處做很多相似的乃至相同的功能，更應該複用一下。

如果一個專案只會在一個客戶那賣出一次……說實話，公司正面臨險境，不是任何方法能輕易解救的。複用分為多個層次，為了更生動一點，這裡大致說一下《火星人》中的複用層次，基本上由淺入深。1.1 純技術層次，大約1000行程式碼1.1.1 MFCUI（Martian Foundation Class UI），處理Web上常見的圖片、連結、圖片連結、Ajax呼叫、彈出選單等內容。1.1.2 MFCRepository/MFCCaches，增加任何表後，只需1行程式碼，就能處理資料庫表的增、刪、改、查和表級別的快取；快取會自動和資料庫同步。1.1.3 ……1.2 準業務模型層面，大約3000行程式碼1.2.1 Items庫，用於處理任何以父子關聯層次存在的資料（產品線-產品-版本-釋出，公司-部門-團隊-小組，子系統-模組-業務資料-業務操作-增強，任何目錄……的底層都是它，大約有10種樹狀資料）1.2.2 UDC庫（User Defined Column），不用編寫任何程式碼，就能為任何Item增加自定義欄位（大約有10種資料型別，各自的顯示和編輯介面也都是預置好的）。1.2.3 ……1.3 通用業務層面，大約3000行程式碼（方案2中詳解）1.3.1 MFC範圍內的，用於處理使用者，角色，許可權，分配任務、工作量，日曆，團隊，個人中心，通知……這些任何產品都需要的功能。1.3.2 DLC範圍（Downloadrable Content可下載內容）的，處理外掛類內容。1.3.3 ……1.4 專用業務層面，大約1000行1.4.1 處理使用者故事、迭代、意向表、產品這些只有敏捷開發才具備的業務。實際統計資料中，整個火星人有89%的程式碼處於可複用庫範圍內，剩下的才是只能用在我們看到的“敏捷開發管理工具”中的程式碼。這樣做的好處也是顯而易見的，儘管這麼多庫只在“1000”行業務程式碼中被“複用”過，但火星人的程式碼效率還是達到了業界的3倍左右（注：業界每功能點對應50～75行C#程式碼，火星人是20行不到），生產效率大約是業界的2～3倍（注：業界生產400功能點大約需要500人天，火星人是200不到）。隨著日後業務增加，複用次數增加，這一差距還會繼續擴大。所以如果是人年級別以上的專案，拋開是否“產品化”不談，僅僅是複用就能產生巨大的收益。複用庫可以很快搭建下一個專案，而無需一切從頭開始，可以認為是一個“非官方產品”。這個方案，在本質上是有風險要平衡的，因為“可複用”庫的成本很高，遠遠高於一次性使用的程式碼，所以我自己有個習慣：第一次使用的程式碼最多隻封裝到函式級別，能支撐第一次能“乾淨地”使用即可，絕不多考慮日後的引數是否會多樣化，是否會增加方法之類的；之後用到第二次再說。

方案2：提煉半成品

即使完全被客戶牽著鼻子走，也會發現儘管每個專案的主要業務不同，但某些功能仍然可以被大塊地、完整地封裝起來，比如前面提到的1.3通用業務層面，也就是：1.3 通用業務層面，包括模型和介面，大約3000行程式碼（方案2中詳解）1.3.1 MFC範圍內的，用於處理使用者，角色，許可權，分配任務、工作量，日曆，團隊，個人中心，通知……這些任何產品都需要的功能。1.3.2 DLC範圍（Downloadrable Content可下載內容）的，處理外掛類內容。1.3.3 ……如果把火星人中敏捷開發的那1000行程式碼刪除，一個使用者仍然可以登入、加入部門或團隊、檢視自己的工作空間、分配任務（雖然無任務可分）等，儼然是一個通用的原型。其實，在遊戲界這已經不是新技術了，多數大型的遊戲公司都發現遊戲裡邊的登入、人物、商店、買賣、幫會、服裝……之類的系統都大同小異，因此早就開始搭建自己的半成品了。其中有一家公司做得“太好了”，以至於有些玩家批評他們幾個遊戲“看上去差不多”。另外一家公司也在搭建他們的半成品遊戲，目的以便縮短新遊戲的開發週期，讓他們一上來就能開發核心玩法，而不是從頭開始。

分析：再談共振（一）

很多程式設計師都夢想有一天老闆一聲令下，大家2年不賣東西，埋頭開發一個自己心儀的產品，兩年之後石破天驚，一家所向披靡的產品公司出現了。可惜，老闆沒眼光，所以你看，我現在還在這裡接客戶的一個一個電話改程式碼呢……可複用庫和產品化是一個思路的兩個層面，如果一個人平時都不積累可複用的東西，卻天天嚷嚷產品化，就是做白日夢。因此，應該在自己能控制的範圍內，先做好產品化的準備，如果準備充足了，老闆發現用可複用庫3個月後而不是2年就能搭建一個他也夢想過的產品，他就能下決心了。

本文所說的技術方法在一定程度上可以緩解變化的問題了，但是於下一篇提到的業務方法相比，就差得遠了。