客戶親和力

原文： customeraffinity

敏捷 2023年7月28日 bliki

索引當人們一談起「具備哪些技能方可成就一名頂級的企業軟體開發者」，話題常會轉入「要掌握框架和語言」，或者「要能理解複雜的演算法和資料結構」。依我之見，不論是對一名程式設計師還是乙個開發團隊，最重要的品質卻是另外一樣東西——我稱之為「客戶親和力」——就是看開發者有沒有興趣密切地關注軟體所要面向的業務問題以及那個業務領域裡的人。

客戶親和力體現在多個方面，第一就是對業務本身的興趣，包括各種業務流程和業務規則。我做過不少領域的工作：衛生保健、金融衍生業務、薪資管理、租賃業務等等——我被深深吸引住了，它們都充滿了十分有趣的領域問題，需要理出條理，真正理解之後才能解決。在我看來，諸如o-r對映、遠端程序互動這些方面對於乙個企業應用系統就好比是供熱供水的管道工程對於一棟大廈一樣，它們對我的吸引力與前者是不同的。

乙個團隊能把管道工程幹得漂漂亮亮固然重要，但我認為，在業務問題上投入的精力越多，這個團隊就會越有效地彰顯自身價值——這正好解釋了為什麼乙個問題只要屬管道工程之列就宜借框架之力來簡化、解決。

客戶親和力的另一方面是與領域專家協作的能力。在我看來，程式設計師們並不需要像那些專家們那樣精通領域知識，詳盡的領域知識對程式設計師有幫助，但並非最重要的——更關鍵的是與具備那些知識的專家們良好協作的能力。

我對客戶親和力如此的重視，正是我那麼愛好極限程式設計和其他敏捷方法的乙個主要原因。在「敏捷」這個「新詞」誕生的snowbird討論會上

（譯註1），kent beck向其他同好總結xp的時候，他選擇描述的並非xp的技術方面，而是他對轉變客戶與開發者之間互動的原本特性的期望。

對於客戶與開發者之間關係，我常聽到種種不恰當的描述，尤其有一種錯誤觀念認為：那無非是客戶們想出一些需求，再把它們丟給開發者；與之相反相成的，還有一種觀念認為：需求都攤在那裡，得由開發者們自己去收集。這兩種方式都沒什麼互動協作，取代它們的應該是：開發者要與領域內人士協同工作，在這個過程中了解業務問題學習業務知識，同時產生設計思路。

kent為「敏捷」這一概念提供的名字之一叫做「交談式軟體開發」——其著眼點即軟體開發是一種雙向交流的過程。這與電信協議之類的東西不同，後者你可以定義出來，而前者強調的是：雙方就「軟體如何促進業務」這一問題有來有往的討論體現了真正有價值的東西。這種討論得出的想法常是半成熟的，其中有一部分可以演化成頗有意義的特性——而這一部分往往並非客戶最初所考慮的東西。

一件讓我失望的事是：客戶親和力的發展常受到來自組織機構的壓制——儘管有些人不承認那麼做了，但那常是其他一些決策的直接後果。例如，機構之間的界線常起到壓制客戶親和力的作用——我見過不少地方，你要想與業務方面的某某人交談，就先得告訴你的經理，讓他再與對方經理溝通好，這次交談才可能實現 ——這種溝通障礙怎麼會不打擊你**業務問題的積極性呢？

我經常聽到人們說做企業軟體枯燥乏味，無非是把資料傳來傳去，真正有本事的人得做真正地道的軟體——需要很炫的演算法，還得死磕硬體，沒準還有滿篇的數學。我覺得發生這種情況通常就是由於缺失了客戶親和力。企業軟體開發對智力水平的真正挑戰來自：對某一業務領域，如何弄清軟體在哪些地方能產生什麼樣的實際貢獻。要做好這件事，紮實的技術功底不能少，齊備的業務知識也不可或缺——與業務人員密切合作以積累業務知識，在此過程中

取悅你的客戶，企業軟體開發的樂趣就在於此——另外，激勵機制是使工作做得漂亮、團隊富有生產力的關鍵所在。

許多聰明且有能力的人都希望了解他們編寫的軟體要服務的行業，但無奈各個組織機構頻頻為此設定障礙，只有這種狀況改變了，我們的職業才能持續地體現出我們的潛質。

譯註1：詳情參見http://agilemanifesto.org/history.htm

客戶親和力

親和力與生產力

具有親和力的文字隱藏方法

具有親和力的文字隱藏方法

客戶親和力

親和力與生產力

具有親和力的文字隱藏方法

具有親和力的文字隱藏方法

相關推薦