一直以來，我都覺得服務業的員工訓練是一件很難的事。員工帶有的想法，往往與公司文化、價值觀有關系，並不是什麼可以輕易訓練的事。

* 比方說，如果我的員工做出了非凡的服務，而客戶對他說，「謝謝你，你做得真的很好，你在貴公司的工作是什麼？」我希望他會回答：「我的工作是服務你。」而不是，我的工作是「副理、副總、…」一堆了不起的頭銜，但是對客戶沒有任何意義。

* 比方說，如果我的員工搞砸了什麼事，而客戶接受他的道歉之後，對他說：「沒關系，看來也不盡然是你的問題，有一些不可控的因素。」我希望他會回答：「謝謝您的體諒，但我，代表本公司的品牌。」

當然，上述兩題都可以背答案。但是，背了答案之後，回答的就是硬生生的答案，而且不再反映真實的企業文化。

上週，我收到一筆國外的電匯，客戶從海外匯錢給我，但是受款人 (Beneficiary’s Name) 的名字寫錯了。銀行通知我時，告訴我，我需要去知會我的客戶做「修改電文」的動作。我想了想，在電話裡詢問銀行，「修改電文」這個專業的詞彙，你們知道英文要怎麼講、或是怎麼寫嗎？

銀行的服務專員回答我，「這…，這…，我們不知道呃。」我有委婉地請銀行協助，不過沒有得到回音。我上網做了功課之後，得到了可以用的說法，”to send an amendment onto the wire”，然後順利地解決了我的問題。

唉，該家銀行在我的心中留下的印象，依然是環境整潔、理專漂亮、網路介面不好用，跟其它很多家銀行差不多一樣，沒有差異。

某公司的設計部門主管，在該部門擁有了自己的網址之後，製作新名片時，順手將自己原本公司電子郵件地址的後綴 (公司的網址) 改成自己部門的網址，並且放在新名片上，還把新名片發給公司的合作夥伴。而公司的合作夥伴要寄電子郵件給這位主管時，才發現這個電子郵件地址不存在。最後，該公司的 IT 部門只好有點好氣又好笑地來設法解決這個問題。IT 部門的主管心道：「拜託，買了網址 (domain name) 不等於設定好電子郵件啊！」

針對上述的這個錯誤案例來分析的話，我認為，可以看成是兩種不同類型知識的同時缺乏，一起造就了這個錯誤：

1. 缺乏內容型知識 (content knowledge)：不知道「購買了網址 (domain name) 之後，不會自動得到電子郵件」，這是缺乏 IT 領域的內容型知識。每個行業、每個領域都有自己特有的內容型知識。由於該主管是設計部門的主管，缺乏 IT 領域的內容型知識，某種角度來講，也算是合理的。
2. 缺乏程序型知識 (process knowledge)：「決定好新的電子郵件地址之後，沒有先試著寄一封電子郵件來試驗看看，到底這個電子郵件地址能否正常工作，就直接把電子郵件地址印在名片上，還把名片發出去」這部分則是乏缺程序型知識。程序型知識某種程度來講，是跨各種行業、各種領域都可以應用的知識。以名片的這個例子來講，該主管顯然缺乏了一種做計畫的習慣：「對於計畫會去分析，計畫裡是否有什麼環節是過去沒有做過的、比較難的、又或是容易出錯的部分，可以視為是關鍵環節 (critical link)，並且對於關鍵環節去思考，如何在事前防錯 (preventive action)、又或是出錯之後該怎麼補救 (contingent action)」如果有上述的習慣的話，自然有機會察覺電子郵件地址可能是關鍵環節、可以先簡單地寄一封電子郵件給自己試試，就可以做到事前防錯。

主管的工作內容通常直接以企業的經營目標為依歸，意謂著常常要處理各式各樣的雜事，勢必要是一個有通才能力的人。而通才能力可以從哪裡來？我看過最成功例子是：各行各業的佼佼者，在既有的專業能力成熟後，往往可以從自己的專業中，將有用的做事方式：策略、除錯、決策、計畫等，加以抽象化，成為了程序型知識。

佼佼者往往是可以輕鬆晉昇的人，而一般人呢？我建議新手主管從這個程序型知識的角度去思考自己可能缺乏的能力、應補足的知識。畢竟，公司會交代主管這個角色的任務，往往多變又複雜，很有可能是從來沒有做過的事、超出既有知識範疇的事。覺得自己對主管的工作感到困難時，盲目地去補足內容型知識，很可能緩不濟急，應該先從程序型知識來加強起。

緣起

大約 2018 年底的時候，我換了一次工作，那一回，唯二投履歷的工作之一，是間技術棧 (technical stack) 選用 Erlang/Elixir 的軟體接案公司，我滿懷憧憬，覺得如果換一分新工作又順便學一些先進的科技真是不錯。

求職沒有被收下的時候，我又很快地轉了一個念頭：「既然有人可以在台灣開一間軟體接案 (software agency) 公司，技術棧選用 Elixir？那應該也可以有人在台灣開一間軟體接案公司，技術棧選用 Clojure 吧？」(註：Elixir 與 Clojure 都是相對小眾的程式語言。)

從 agency 轉型成為 consulting

做生意，不免都要思考最適規模、價值創造、收費模式等議題。總之，經營一年半之後，我就決定把自己的生意改一改，從接案代工 (agency) 改成諮詢顧問 (consulting) 。主要的差異在哪呢？其實對我而言，主要的差異就是：「不需要雇用員工」

轉型之前，我是獨力完成軟體專案。轉型之後，我是與客戶協力完成專案而非獨力完成專案。做專案的人力，主要是客戶的員工。我只動手解決最難、最關鍵的部分。專案裡多數的工作，我是傳授知識技術給客戶的員工，由他們協力完成。

Clojure 很難直接「賣」

Clojure 很難直接「賣」，在很多次的嘗試之後，我徹底地了解這個道理。所以，我通常都是拐一個彎、拐兩個彎來賣。我通常是跟客戶談：什麼可以讓你的軟體開發速度變快、軟體品質變好、還有應該如何量測成效與成功。

即使是這樣子談，效果還是不太好，我又再換了一個方法談。準備一分 20 小時的教材，然後講「20 小時無痛起步」之類的。

逆向工作、六個工作天導入

最近的一個專案，在一些條件的加持之下，我幫客戶非常順利地導入了 Clojure 。

加持條件：

• 我承接的軟體專案，其中有兩個部分， 第一部分是資料分析 (data analytics) ，主要是 SQL 。第二部分則是應用軟體開發 (application program)。而我在做資料分析時，進度大幅超前，建立了客戶的信心。

實務的作法：

1. 我和客戶談應用軟體開發時，先與客戶談成的協議是：我做架構設計，實作的部分原則上交給客戶的員工。我可以協助做品質管控之類的。在這個時候，技術棧 (technical stack) 依然是一個開放的選項。
2. 等到資料分析的進度大幅超前，我與客戶顯然有時間可以玩一些大膽的創新時，我就拿出我的 Clojure training tutorial ，並且解釋照這個教材來訓練，大約多少時間可以訓練完成。
3. 兩個工作天，先是密集地上課 ，把教材的課程教到第七課。
4. 三個工作天，我自己把客戶的專案拿來開發。先把需要的函式庫 (libraries) 都串好、相對難的部分我直接刻完，做到的程度是：「整個系統對於客戶來講，就是一個框架 (framework) ，他們只需要去把最後三個空缺 (todo) 填完即可。」
5. 最後一個工作天，我把我做到一半的專案連同文件交接給客戶。客戶表示：「比原先想象的，還簡單許多了。」

結論

新創公司的理論，有一派的人主張，要經營成功的公司，要先取得最小可行客戶 (minimum viable customers)。一旦有了，事業就成功一半了。對於軟體開發，我主張：「要把軟體做好，要先取得最小可行知識(minimum viable knowledge)。 」

對於我的客戶來講，導入 Clojure 這件事，他們需要學習的『知識』，基本上就是最小可行知識：

1. Clojure programming 的基礎
2. 勉強足夠把三個空缺 (todo) 填完的知識

快速取得最小可行知識，這就是要導入先進軟體技術棧 (advanced technical stack) 的成功要件。

有些工作本身的特性是適合分散式、多點地來做。然而，有時因為工具不普及、法規等限制，反而變成了中心化最有效率。一旦限制消失時，就會產生去中心化。比方說，一旦有了 youtube 與剪接影片軟體、後製影片軟體之類的工具，一般人也可以自行製作影片，接著會沿生 youtuber、網紅文化，電視一方獨大的現象也會開始勢微。

有一些工作則剛好相反，本身的特性是適合集中地來做，但是因為某些限制存在，人們為了突破這些既有的限制只好訴諸去中心化的權宜之計，一旦隨著工具的發展或是外界的變化導致限制消失時，就會自然回歸中心化。

晶片架構

主流的硬體設計是一個功能對應一個封裝好的晶片、以印刷電路板組合數個不同功能的晶片，電流的訊號必須在印刷電路板上傳送相當長的距離才能完成運算。

然而，由於晶圓製造技術地不斷提高，現在的一些超高效能晶片則是採用 SoC (system-on-a-chip) 架構，即系統所有的功能全部做在一張晶片裡。我寫這篇文章時，使用的Macbook ，裡頭的 M1 晶片就是如此。硬體的設計採用了 SoC 這樣子的中心化架構，一方面節省了封裝成本、一方面電流需要跑的距離也縮小到肉眼幾乎看不見，於是製造成本、耗電量都可以降低，運算速度又可以再提高。

軟體產品布署

1995 年之前，網路還相當的緩慢，那個時代的軟體，多半是以光碟的形式傳播。使用者要先把軟體安裝在個人電腦裡才能使用軟體。

然而，當網路的速度愈來愈快時，雲端軟體就開始流行，許多的軟體的設計，都逐步改成商業邏輯、運算、資料都放在雲端伺服器上，使用者用瀏覽器即可以使用軟體。改用雲端軟體這種中心化的方式來布署軟體的話，廠商每次更新軟體，不再需要去考慮用戶的個人電腦環境，因為軟體布署在廠商自家的伺服器裡，這讓軟體的快速改版得以實現。

軟體商業邏輯的布署

早期的 CPU 比現在慢非常多，為了讓系統可以正常運作，出現了應用軟體的 n-tier 架構。Perl, PHP, Python, Ruby 之類的程式語言寫的後端程式，要布署在獨立的 application server 上，如此才能讓資料庫伺服器的負擔變小，從而讓系統順利運作。

然而，當硬體的效能大幅改善，加上後來版本的 SQL 也比原先版本的更具有簡潔的表達能力，在這種條件之下，相對穩定、不快速變動的商業邏輯直接以 SQL 來實作，由於資料與程式可以位落在同一台機器裡，省去了 IO 的開銷，運算效能也可以大幅地提昇。

頁面生成的邏輯

有一段時間，網路說快不快、說慢也不太慢，為了的使用者體驗，使用者介面 (UI) 會採用 SPA (single page application)。頁面生成的邏輯，則大量地從後端移往前端 (去中心化)。

然而，隨著網路的速度變快許多，搭配前端應用 htmx 之類的函式庫，頁面全部在後端生成就可以達成類似的效果。於是，使用者介面的邏輯大量往後端移動、集中化，省去了前後端軟體開發溝通的成本，軟體開發的效率可以大幅提高。

資料工程

過去，為了應用海量的企業資料，但是 data warehouse 的成本太高，只好採用 data lake ，用各種較低成本的解決方案 (去中心化) 去儲存資料。

然而，當 data warehouse 的速度與容量都大幅進展後，就可以再一次地把大量的資料全部放進 data warehouse ，這樣子一來，在 data warehouse 上執行的 SQL 即可取代一個又一個手刻的 MapReduce ，如此，資料清理、資料建模更改版本的速度自然可以提高。

總結

每個人都在談論的事稱之為流行、每個人都在做的事叫趨勢。中心化的作法如果符合了工作本身的特性，可以帶來極大的效能提昇，這是一種工作流程上的創新。但是，如果決策者在思考工作流程時，對於去中心化的作法有執著又或是盲從於潮流，就會妨礙這種創新。

我曾經拜訪過幾位的 CEO ，有時候也會有機會談到各式各樣的「決策」，不管是技術選型、人才雇用、選擇外包廠商等等。我很喜歡詢問 CEO ，『請問貴公司是如何做出這樣子的決策的？』

從這些 CEO 告訴我的事，我認為關於「決策」有三個重點：

• 決策大致上也符合所謂的 80/20 法則。大多數的決策影響並不大，但是極少數的決策影響非常重大。
• 做好的決策、正確的決策，也許不會讓公司立刻勝出，但是，無數正確的決策累積下來之後，產生的競爭優勢非常可觀。
• 對於組織來講，要長期穩定地做出高品質的決策，應該要利用所謂的理性決策方式，即所謂的「決策模型」。透過決策模型來決策，是提昇一個組織長期決策品質的不二方式。

最近，有一位 CEO 請教了我一個很有趣的問題，「為什麼 Clojure 語言，如此小眾的語言，在台灣居然還有三家公司在使用？這些公司難道不擔心找不到人才嗎？這些公司是如何做出這樣子的決策的？」

老實說，我也不知道這些公司是如何決策的。而且，這些公司也很有可能『沒有使用任何決策模型、一切還是是交由 CTO 決定』。但是，另一方面，在絕大多數的情況之下，我也會選擇 Clojure，所以我給了那位 CEO 我本人的決策矩陣。

程式語言決策矩陣

應用「決策矩陣」有下列的步驟：

首先，第一步要想清楚「決策前提」

「如果我要讓公司取得長期的成功，用哪一種程式語言，最有優勢？」

第二步要列出各種可能的選項

簡化一點，這邊只列出 Java, Python, Javascript, Clojure 四個選項。前三個大概是目前台灣市場最主流的選項。

第三步則是要列出，會有助於達成決策前提的關鍵要素

1. Machine Efficiency (在機器上的執行效能)
2. Developer Productivity (軟體工程師的開發速度)
3. Library Ecosystem (語言函式庫的生態系完整度）
4. Extending to Frontend (該語言是否可以延伸應用到前端？)
5. Local Talent Pool (在地的人才庫)

上述的 5 點，滿分都是 10 分，最低分是 0 分。

第四步，將矩陣填完

填寫數值的部分，也沒有所謂絕對的客觀、必然還是有主觀的成分。然而，將本來只用一兩句話就解釋完的決策，改成使用決策矩陣決策，可以讓經驗、資訊、判斷被有效地加以整合。

最後一步，加總判斷，做出充分考慮多個面向、最平衡的選擇。

決策的關鍵

我解釋完決策矩陣之後，CEO 又問了我第二個更重要的問題，「做這樣子的決策，跟別人都不一樣，不會有一種怕怕的感覺嗎？」

我引用杜拉克的話回答他，要做好決策，最重要的關鍵，不在於卓越的分析能力。而是有沒有勇氣去「選擇未來而非過去、著眼於機會而非問題、堅持自己的方向而非隨波逐流」。

我做了一個夢，夢到了一家公司。我在想，也許大家也會覺得似曾相似、有點眼熟？

• 該公司疑似有現代的管理方式？比方說，使用 OKR 作為管理方式。
• 該公司疑似也有鼓勵創新？比方說，舉辦駭客松。
• 該公司也有非常多的會議。

夢裡的細節有點鮮明，讓我不由得記錄了下來：

• 雖然使用了 OKR ，但是，主管要求下屬設定 OKR 時，主管並沒有給予方向，因為主管也不太清楚公司的策略方向。反正，公司明年需要做的事，就是把去年或是前兩三年的業績，做個線性外插，就取得明年的目標了。至於說，資源如何分配呢？資源分配的邏輯，與政府也很相似，就是比賽誰比較會喊、誰比較會提案、誰與上司的關系最親近。資源分配主要由政治實力決定，與公司的策略沒有關系。仔細想想，既然公司的策略從來就不存在，當然該公司的員工必須想出使用「策略」以外的基準來分配資源嘛！這也是在困境中不得已而為之的辦法。
• 由於該公司也雇用了不少的軟體開發人才，所以自然一定要舉辦所謂的駭客松，這樣子才跟得上時代嘛！對於該公司來說，只要有寫軟體，就叫做創新。在管理學書上的定義，創新的重點與結果應該是要提昇公司的營運績效、顧客滿意度，未必是要使用「新知識」、「新科技」。然而，在『彼得原理』在該公司有效地運作的前提之下，「demo 軟體」這種可以讓主管上台，增加曝光度的東西，當然是創新的首選。正如彼得原理的預測，下屬一切的作為，最重要的事，就是討上級的歡心，「創新」自然會是為了讓上級風光而創新，而不是為了提昇客戶滿意度而創新。
• 該公司的會議，在簡單的事情上，通常開得相當久，在困難的事情上，通常開得特別快。討論簡單事務的會議，主講者是主管，而下屬是聽眾。這種會議有一種非常重要的功能，它可以強化主管們的 ego 。無論主管腦子裡的知識有多麼地過時，透過一場又一場與下屬召開的會議，都可以再一次地自我強化「主管就是比下屬們優秀得多」這種永遠經得起時間考驗的概念。討論困難事務的會議，這種會議就超有效率，因為主管們通常就是只討論工作的 input ，而不討論工作的 output 。主管們交代完下屬工作完成的 deadline 之後，會議就算是完成 80% 了。至於說要完成什麼、細節是如何，那些絕對是下屬的責任。之後如果主管看了結果覺得不滿意，這表示下屬需要再多加訓練，所以解決之道是：「主管主講的那種會議，時間要再加長一些。」

在那個夢裡，我想發表一點意見，但是，該公司的許多人跟我說，「我們公司無論是在管理制度、創新、人才，全都是一流的。」「這就是我們公司一貫的風格啊！大家都是這樣子做啊！」

上個月被客戶問了：「你如何做好銷售的工作？」由於我是做顧問業，銷售上遇到的問題也有顧問業的特性，不過，既然被問了，就來談看看。從開業以來，我遇過的 4 種常見的銷售問題。

1. 工作內容延展、或是殺價
2. 詢價、估價
3. 介紹費
4. 不可能的任務

工作內容延展或是殺價

這類的問題有兩種變型：

1. 合理的工作內容延展
2. 不合理的工作內容延展或殺價

第一種情況是：我協助客戶完成了合約所定義的工作之後，客戶發現當初他與我談好的需求，與他後來領悟的需求有落差，想請我「順便」再修改一下。舉個例子，有一回客戶請我開發軟體，設計了一個 UI 選項，是「過去 365 天的利潤總和」。等到功能完工之後，客戶跟我說，他認為我做的軟體有 bug ，請我修正，因為在 2020 年這個功能並不正確。我回應他，2020 年有 366 天，因為是閏年，也因此，他所需要的並不算是修正錯誤，而是進階版的功能，能一併處理閏年。像上述這種情況，就是常見的「合理的工作內容延展」。

在上述的這種情況，我採取的作法會是：如果我真的順手就可以解決的話，服務就直接贈送客戶。如果並不是順手的話，我會跟客戶說：「對於貴公司委託我的工作，超出合約的部分，無法保証其完工的品質，如果希望維持一貫的品質的話，由新的合約來界定的工作，會符合彼此的最佳利益。」

第二種情況是：客戶講了某個他覺得有說服力的理由，認為我提供的服務之一部分，並不符合他的需求，要求退掉服務中的一部分以換取其它服務，又或是直接殺價。遇到這種情況，我後來的心得是：『很多時候，客戶也許善於議價與殺價，但是，並不一定有想清楚其自身的最佳利益。』這種情況，我將其視為是「不合理的工作內容延展或殺價」。此處的不合理，是指，在客戶最佳利益的層次上不合理。

比方說，有些時候，客戶其實並沒有所謂的 BATNA (best alternative to a negotiated agreement)，只是因為喜歡殺價，就二話不說地要求議價。遇到這種情況，我會詢問客戶，「請問貴公司委任我某工作，最主要的目的為何？對現在的這個細節詳加討論，與主要的目的是否有關？在這件事上多花費時間討論，是否符合貴公司的最佳利益？」

詢價、估價

有的客戶喜歡問價錢。在談話剛開始時，就先詢問，「一般來講，做某某事，價格多少？」像這樣子的提問，我一開始的處理方式，是回答：「可以請您描述一些更多的細節嗎？」這樣子的回答，通常對話持續不下去。原因很簡單：很多時刻，潛在客戶詢問價錢，是要取得價格的參考資訊，並不一定真的有意願要做生意。

想通了言談背後運作的邏輯之後，解法就簡單多了，我會回答客戶：「如果您能考慮安排 1 個小時，與我談談您的需求的話，我可以在談話之後，迅速地給您一個參考的價格。」

介紹費

對幾乎大部分的生意來講，舊客戶介紹新客戶，都是生意成功的關鍵點。我也會請我的客戶幫我介紹，偶爾也會有遇到極少的客戶認為，我應該為其支付介紹費的情況。

對於客戶介紹客戶一事，去表示感謝，有許多不同的方式可以做到。直接給予金錢的方式，由於被負面解釋的可能性相對高，為了省事，我就不考慮這個選項了。如果口耳相傳是基於愉快的合作關系，這是相當正面的。然而，如果口耳相傳主要是由金錢所推動的，這樣子，顯然違反了一句做生意的古諺： Market share should be won, not bought.

不可能的任務

客戶會考慮委任顧問工作，很多時候，客戶對於顧問的專業領域所知是甚少的。也因此，也有許多成功的委任，在最初的時候，它的樣貌是一種「不可能的任務」。對於不可能的任務，我後來領悟的作法不是「硬接下來」、也不是直接說：「這是不可能的任務」，而是透過談話與提問，提供客戶關鍵的資訊，讓客戶可以優雅地修改他原先構思的委任方式。

銷售的重要性

在日本漫畫「結界師」裡有一句對白：「不漂亮的工作，只能得出不漂亮的成果。」我覺得這句話也可以應用在銷售上，『不漂亮的銷售，只能得出不漂亮的成果。」

許多的專業人士，比方說，軟體工程師、會計師、律師等等，都會需要跟客戶或是上級溝通，而在溝通時，就很容易遇到所謂「溝通不良」的問題。

先不論遇到奧客或是缺乏專業的管理階層，專業人士在與委託人溝通自己的專業時，本來就很容易遇到一種困境：「沒有合適的語彙可以使用，換言之，一旦使用專業術語，委託人就聽不懂。」

要改善這種情況，專業人士需要對溝通的情境 (context) 做一點分析。視溝通的對象與溝通的主題，溝通的情境可以分成三種不同的層次：

1. 溝通委託人的問題/困擾 (domain problem)
2. 溝通專業人士所提出的解決方案 (solution)
3. 溝通解決方案的執行細節 (implementation details)

我認識的專業人士，往往都最善長溝通「執行細節」的部分。原因很單純，執行細節就是專業人士的專業領域。要討論執行細節，專業人士覺得要講清楚相對容易，因為這部分要溝通清楚，就是要使用『專業術語』。

要溝通清楚「解決方案」，往往需要一種由「外部觀點」的視角所建構出來的「高階語彙」才能講清楚。而這種「高階語彙」很有可能並不在專業人士過去所學的專業知識領域之內，而是需要其它領域的知識，甚至下游產業/下游服務提供者的知識有時反而更容易說清楚。以軟體開發來舉例子：要詳細描述一個軟體系統的外部行為來讓一般人充分了解，有時候反而要使用軟體工程師並不特別熟悉的 Excel ，反而最容易溝通清楚。

而討論「委託人的問題」之溝通難點在於：「專業人士變成了所謂的聽話者，而說話者是委託人。」在這種情況下，專業人士必須要精於提問，要透過有系統的提問，才能取得重要的資訊。