客戶親和力

當有人在探討頂尖企業軟體開發人員的組成時，話題通常會轉向架構和語言的知識，或者可能是理解複雜演算法和資料結構的能力。對我來說，程式設計師，或更確切地說，開發團隊最重要的特質之一，是我稱之為「客戶親和力」的東西。這是開發人員對軟體所要解決的商業問題以及生活在該商業世界中的人們所抱持的興趣和親近感。

客戶親和力有許多面向。第一個面向只是對業務、其流程和規則感興趣。我對自己從事過的領域總是著迷：醫療保健、衍生性金融商品、薪資、租賃——這些都是真正有趣的領域問題，有許多必須組織和理解的複雜性。對我來說，專案的某些面向，例如物件關聯性對應、遠端程序通訊——我認為這是企業系統的管道工程，並沒有那麼有趣。

團隊讓管道工程運作並受到控制很重要，但我相信投入越多精力在業務問題上，團隊提供價值的效率就會越高。這是使用盡可能解決和簡化管道工程的架構的充分理由。

客戶親和力的另一個面向是與領域專家合作的能力。我不認為程式設計師擁有領域的詳細知識是一件重要的事；有用，但並不重要。比知識更重要的是與擁有知識的人合作的能力。

我對客戶親和力的重視是我如此推崇極限編程和其他敏捷方法的主要原因之一。我發現，當肯特·貝克在創造「敏捷」一詞的雪鳥工作坊中向敏捷同儕總結極限編程時，他選擇描述的不是極限編程的技術元素，而是他改變客戶/開發人員互動性質的渴望，這一點非常重要。

我經常聽說這種關係被錯誤描述。特別是，有些人相信客戶團隊只是提出故事，然後丟給開發人員。這種描述有點像需求只是在那裡等著被收集的概念。無論如何，這都不是什麼合作。相反地，開發人員需要與領域人員合作，在過程中產生想法，讓開發人員深入了解業務。

肯特建議的「敏捷」名稱之一是對話式軟體開發——重點在於這是一種雙向溝通。這不像電信協定那樣可以定義，但關於軟體如何增強業務的來回討論才是真正有價值的地方。大部分的對話都是半生不熟的想法，其中一些會發展成有價值的功能——通常不是客戶最初想到的東西。

讓我感到沮喪的事情之一，就是組織經常嘗試壓制客戶的親和力。這不是人們承認會做的事情，但這是其他決策的常見後果。組織障礙可能會導致壓制 - 我遇到過一些地方，你必須讓你的經理安排與另一位經理會面，這樣你才能與業務部門的某人交談。這很難鼓勵你了解業務的運作方式。

我經常聽說企業軟體很無聊，只是在整理資料，有才華的人會製作需要花俏演算法、硬體駭客或大量數學的「真實」軟體。我覺得這通常是缺乏客戶親和力所致。商業軟體真正的智力挑戰在於找出軟體對企業的真正貢獻是什麼。你必須具備良好的技術和商業知識才能找到它。與業務人員緊密合作以培養這種知識，並在這樣做的同時取悅客戶，這讓企業軟體開發變得有趣 - 而動機是良好且富有成效工作的關鍵。

有許多聰明且有能力的人想要了解他們為之撰寫軟體的業務。組織經常讓他們難以做到這一點。在這種情況改變之前，我們的職業將繼續無法發揮我們的潛力。

於 2012 年 4 月 26 日重新發布