敏捷開發一千零一問系列之十七：長期受制於強勢客戶怎麼辦？（上）

文章目錄

• 方案1：從技術上把項目產品化
• 方案2：提煉半成品

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

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

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

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

問題

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

方案

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

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

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

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

如果一個項目只會在一個客戶那賣出一次……說實話，公司正面臨險境，不是任何方法能輕易解救的。
複用分為多個層次，為了更生動一點，這裡大致說一下《火星人》中的複用層次，基本上由淺入深。

1.1純技術層次，大約1000行代碼
1.1.1MFCUI（Martian Foundation Class UI），處理Web上常見的圖片、連結、圖片連結、Ajax調用、快顯功能表等內容。
1.1.2MFCRepository/MFCCaches，增加任何錶後，只需1行代碼，就能處理資料庫表的增、刪、改、查和表層級的緩衝；緩衝會自動和資料庫同步。
1.1.3……
1.2准業務模型層面，大約3000行代碼
1.2.1Items庫，用於處理任何以父子關聯層次存在的資料（產品線-產品-版本-發布，公司-部門-團隊-小組，子系統-模組-業務資料-業務操作-增強，任何目錄……的底層都是它，大約有10種樹狀資料）
1.2.2UDC庫（User Defined Column），不用編寫任何代碼，就能為任何Item增加自訂欄位（大約有10種資料類型，各自的顯示和編輯介面也都是預置好的）。
1.2.3……
1.3通用業務層面，大約3000行代碼（方案2中詳解）
1.3.1MFC範圍內的，用於處理使用者，角色，許可權，分配任務、工作量，日曆，團隊，個人中心，通知……這些任何產品都需要的功能。
1.3.2DLC範圍（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.1MFC範圍內的，用於處理使用者，角色，許可權，分配任務、工作量，日曆，團隊，個人中心，通知……這些任何產品都需要的功能。
1.3.2DLC範圍（Downloadrable Content可下載內容）的，處理外掛程式類內容。
1.3.3……

如果把火星人中敏捷開發的那1000行代碼刪除，一個使用者仍然可以登入、加入部門或團隊、查看自己的工作空間、分配任務（雖然無任務可分）等，儼然是一個通用的原型。
其實，在遊戲界這已經不是新技術了，多數大型的遊戲公司都發現遊戲裡邊的登入、人物、商店、買賣、幫會、服裝……之類的系統都大同小異，因此早就開始搭建自己的半成品了。其中有一家公司做得“太好了”，以至於有些玩家批評他們幾個遊戲“看上去差不多”。
另外一家公司也在搭建他們的半成品遊戲，目的以便縮短新遊戲的開發週期，讓他們一上來就能開發核心玩法，而不是從頭開始。

分析：再談共振（一）

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

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