我們策略的關鍵之一，是讓技術人員專注於技術問題、業務人員專注於業務問題。專案必須由業務決策驅動，但業務決策必須由關於成本與風險的技術決策提供資訊。

兩種失敗模式#

業務端（Business）與開發端（Development）的關係有兩種常見的失敗模式。無論哪一方取得過大的權力，專案都會受害。

業務端當家#

如果業務端握有權力，他們會覺得自己有資格向開發端指定全部四個變數：「這是你要做的事。這是完成的時間。不行，你不能有新工作站。而且品質最好是最高等級，否則你就麻煩了，老兄。」

在這個劇本裡，業務端總是指定太多東西。需求清單上有些項目絕對必要，但有些不是。而如果開發端沒有任何權力，他們就無法反對、無法迫使業務端去分辨哪些是哪些。於是開發端盡忠職守地低頭去做那份被交付的、不可能的任務。

「業務端當家」劇本的結果是：專案背上太多工作量、以及太多太多的風險，換來太少的回報。

開發端當家#

那麼輪到開發端當家時，你會以為日子好過些了吧？並沒有。淨效果一模一樣。

當開發端當家，他們會把所有「以前被那些西裝推來推去時沒時間做」的流程與技術通通裝上去：新工具、新語言、新技術。而這些工具、語言、技術之所以被選中，是因為它們有趣且尖端。

「開發端當家」劇本的淨結果是：太多工作量、太多太多的風險，換來太少的回報。

那該怎麼辦#

解法是設法在業務端與開發端之間切分責任與權力：

業務人員做他們適合做的決定，程式設計師做他們適合做的決定。每一方的決定都應為另一方提供資訊。任何一方都不能單方面決定任何事。

維持這種政治平衡看似近乎不可能——連聯合國都辦不到，你有什麼機會？

嗯，如果你手上只有「平衡政治權力」這個模糊目標，那你確實毫無機會——第一個出現的強勢人格就會打破平衡。所幸，這個目標可以具體得多。

各自該決定什麼#

依循這個模型，業務人員應該選擇：

• 發布的範圍或時機
• 提議功能的相對優先序
• 提議功能的確切範圍

開發組織必須為這些決策貢獻：

• 實作各項功能所需時間的估算
• 各種技術替代方案之後果的估算
• 一套適合他們的個性、業務環境與公司文化的開發流程。沒有任何一份「軟體該這樣寫」的清單能適用於所有情境；事實上，沒有任何單一清單能適用於任何情境，因為情境永遠在流動。
• 他們一開始要採用哪組實踐，以及用什麼流程來檢視這些實踐的效果並實驗變更。

最後這一點頗像美國憲法：它訂出一套基本哲學、一組基本規則（權利法案，也就是前十條修正案），以及改變規則的規則（增訂新修正案）。

由於業務決策發生在專案的整個生命週期中，把業務決策的責任交給業務人員，就意味著——客戶和程式設計師一樣，是 XP 團隊的一員。特別是，為了最好的成果，他們與團隊其他人同坐，全職待命回答問題。

技術選型是業務決策#

技術選型乍看像是純技術決策，但它其實是一個業務決策——只是必須有開發端提供輸入。客戶得與某個資料庫或語言供應商共處許多年，因此在業務層面上也必須對這段關係感到自在，而不只是技術層面。

如果客戶對作者說：「我們要這套系統，而且你必須用這個關聯式資料庫和那個 Java IDE」，那作者的工作就是指出這個決定的後果。如果他認為物件資料庫加 C++ 更合適，他會把專案用兩種方式各估一次，然後讓業務人員做出業務決策。

但技術決策還有另一面，這一面穩穩落在開發端的陣營裡：一項技術一旦被引進公司，只要它還在使用，就得有人讓它活著。

最新最棒技術的成本，不只在初期的正式開發，甚至根本不完全落在開發上。成本必須涵蓋「建立並維持讓這項技術存活的能力」的代價。

萬一它真的很難#

大多數時候，這個流程產出的決策實作起來簡單得令人驚訝。程式設計師擅長看見每個故事底下潛伏的怪獸；於是業務人員說：「我不知道那麼貴。那就只做其中三分之一吧，現在這樣就夠好了。」

但有時候事情不是這樣。有時候，最小、最有價值的那塊開發，從程式設計師的角度看仍然又大又危險。

當這種情況發生時，你不能眨眼。你必須小心，你負擔得起的錯誤很少，你可能得拉進更多外部資源。但當該翻出戰壕衝鋒的時刻到了，那才是你真正賺到薪水的時候。你會盡一切可能鼓勵縮小範圍，你會想盡辦法降低風險——然後你就上。

換句話說：業務端與開發端之間的權力切分，不是逃避硬活的藉口，恰恰相反。 它是一種方法，用來分辨出哪些工作是真正困難的，哪些工作只是你還沒想出怎麼讓它變簡單。

大多數時候，工作會比你一開始想像的更簡單。當它不是時，你還是照做——因為那正是你領薪水的理由。