止步問題的決策 — 大學的機率課堂上，有個招募問題：「要招募一名秘書，有 n 個應聘者。每次面試一人，面試後就要及時決定是否聘他，如果當時決定不聘他，他便不會回來。面試後一定可以清楚了解應聘者的合適程度，並能和之前的每個人做比較。請問怎樣的招募策略，才使最佳人選被選中的概率最大。」 理性的招募策略是設定一個停止規則：「面試官會一律拒絕頭 r — 1 個應徵者，並假設在頭 …

營運指標與企業策略的緊密關系 — 友人是位主管，也管理公司內部的資料，跟我聊天時，聊到在工作上遭遇的困難：「老闆常詢問我，『你來告訴我有什麼數字？可以怎麼看？怎麼做可以影響這些數字？怎麼做可以成長？』 但，指先指標 (leading metric) 並不是那麼容易尋找，也因此友人自覺工作上的成效沒有特別突出。 我想了一想，分享了一下我個人的經營 IT Consulting 公司，所使用的指標 (metric)。營運指標與公司的策略、還有策略的執行密不可分，首先是公司的策略： 1. 要在 1~3 個利基市場取得領先地位 (領先才能獲利) 2. 利基市場： a. 協助客戶建立資料管線 (data pipeline) b. 協助客戶除錯 (debug) 3. 銷售通路： a. 寫書 b. 寫 blog c. 友人、客戶介紹 (referrals) d. 演講、參加活動等其它方式，設法主動去認識潛在客戶

如何在資訊殘缺的條件下，順利展開工作 — 最近遇到了兩個題目，都算是需要利用假設才能有效進行的工作。 題目一：效能改進 客戶的軟體在報表產生的部分相當地慢，跑一個報表在資料量大的時候居然會需要一分鐘以上，客戶認為，這應該要考慮做程式碼的效能改進。客戶的軟體工程師認為，生成報表的程式碼最大的不同之處，就是有大量的資料轉換 (transformation)，由於開發的程式語言是 Clojure ，會有比較多的資料拷貝，他們認為也許改成用一種節省資料拷貝的寫法 (Transducer) 會有幫助？ 而我在第一時間就在心裡否定了這個假設。我的假設是：「十之八九會是資料庫的查詢問題。」有了假設還不夠，要驗証才行。我拿了 profiler 量測之後，得到了兩個結果： 報表產生的這段程式碼，它是 IO bound 而非 CPU bound 。換言之，它的時間主要消耗在 IO 而非 CPU 上。 某兩個查詢加起來，佔用了 95% 以上的時間。

寫書的路上大概有哪些困難，可以如何克服？ — 很多人都說要寫書不是件容易的事，親手完成了第一本書的初稿之後，我覺得確實不容易，但如果有提早掌握一些寫作要訣，整個寫作過程會容易地多。為何要寫？每個人的理由可能不同，對我來講，最能刺激寫作動力的理由有三點： 可以讓我大幅減少在進行顧問事業中，最大的銷售成本：「創造信任」。 可以創造一個相對低價的解決方案，提供給想要接受我的專業知識但是一時之間卻沒有足夠餘裕來支付顧問費用的潛在客戶。 可以讓我重新檢視、整理自己過去的所學。 找到了寫書的理由之後到完成初稿的一路上，還遇到了其它五個難題，由易到難排序如下： 寫作工具 章節與書的結構 寫作速度 如何寫得清楚明白 書的主題 寫作工具 我一度研究了兩三個專業的寫作工具，但試用了一陣子之後，還是覺得不特別順手，最後，改成先求有再求好，還是回歸自己最熟悉的 markdown editor, git, wc (計算字數的指令)。

只埋首於工作、專注於產能利用率往往無法帶來高產出 — 前些日子，我拜訪了幾位朋友。聊天之中，大家困擾的事情表面上不同，骨子裡又有點相同。 經營者的困擾 友人 A 是位二代的經營者，經營塑膠壓模廠，近年來，工廠最大的投資就是新進了一台新型的機器，友人 A 談到經營的難點時，陸陸續續談到了幾個他擔心的事： 人事管理的難點、員工流動率的麻煩 機器的產能利用率 我聽了聽之後，詢問了一下友人 A 是否有思考公司經營策略？比方說，未來打算要找怎樣子的客戶？提供怎樣子的產品與服務？透過什麼方式去開發？有打算在哪一個 niche 裡取得領先嗎？他如何得知自己在定價上有定下夠高的價格？ 主管的困擾 友人 B 是某科技公司的主管，他問我：「你對於現在剛畢業的學生，因為軟體業薪水的吸引力，不是本科系也 leetcode 刷了4年，有什麼看法？我的同事們覺得要與新鮮人比賽 leetcode ，心理壓力好大。」 對此議題，我表示：「leetcode 之類的比賽，在比拼效能時，重視的是演算法的 big O ，然而多數應用軟體開發的效能改進，其實講究減少 IO 而非 big O。對公司來講，工程師最重要的成效衡量，應該是能否把應用軟體做好，而這很可能與 leetcode 的能力沒有多大的關系。」「不幸的事情是，公司內部的政治制度，有時會出現一種情況：資源與權力的分配，並不是基於真正的成效，而是基於某種階級制度且這種階級制度既不反映個體的實力、也不反映策略上的需求，而是反映了某種尚未除魅的集體迷思。」

好的服務往往來自紮實的員工訓練 — 一直以來，我都覺得服務業的員工訓練是一件很難的事。員工帶有的想法，往往與公司文化、價值觀有關系，並不是什麼可以輕易訓練的事。 * 比方說，如果我的員工做出了非凡的服務，而客戶對他說，「謝謝你，你做得真的很好，你在貴公司的工作是什麼？」我希望他會回答：「我的工作是服務你。」而不是，我的工作是「副理、副總、…」一堆了不起的頭銜，但是對客戶沒有任何意義。 * 比方說，如果我的員工搞砸了什麼事，而客戶接受他的道歉之後，對他說：「沒關系，看來也不盡然是你的問題，有一些不可控的因素。」我希望他會回答：「謝謝您的體諒，但我，代表本公司的品牌。」 當然，上述兩題都可以背答案。但是，背了答案之後，回答的就是硬生生的答案，而且不再反映真實的企業文化。 上週，我收到一筆國外的電匯，客戶從海外匯錢給我，但是受款人 (Beneficiary’s Name) 的名字寫錯了。銀行通知我時，告訴我，我需要去知會我的客戶做「修改電文」的動作。我想了想，在電話裡詢問銀行，「修改電文」這個專業的詞彙，你們知道英文要怎麼講、或是怎麼寫嗎？

新手主管該怎麼為自己的工作內容大轉換做出調整 — 某公司的設計部門主管，在該部門擁有了自己的網址之後，製作新名片時，順手將自己原本公司電子郵件地址的後綴 (公司的網址) 改成自己部門的網址，並且放在新名片上，還把新名片發給公司的合作夥伴。而公司的合作夥伴要寄電子郵件給這位主管時，才發現這個電子郵件地址不存在。最後，該公司的 IT 部門只好有點好氣又好笑地來設法解決這個問題。IT 部門的主管心道：「拜託，買了網址 (domain name) 不等於設定好電子郵件啊！」 針對上述的這個錯誤案例來分析的話，我認為，可以看成是兩種不同類型知識的同時缺乏，一起造就了這個錯誤： 缺乏內容型知識 (content knowledge)：不知道「購買了網址 (domain name) 之後，不會自動得到電子郵件」，這是缺乏 IT 領域的內容型知識。每個行業、每個領域都有自己特有的內容型知識。由於該主管是設計部門的主管，缺乏 IT 領域的內容型知識，某種角度來講，也算是合理的。

什麼是成功導入先進軟體技術棧的要件？ — 緣起 大約 2018 年底的時候，我換了一次工作，那一回，唯二投履歷的工作之一，是間技術棧 (technical stack) 選用 Erlang/Elixir 的軟體接案公司，我滿懷憧憬，覺得如果換一分新工作又順便學一些先進的科技真是不錯。 求職沒有被收下的時候，我又很快地轉了一個念頭：「既然有人可以在台灣開一間軟體接案 (software agency) 公司，技術棧選用 Elixir？那應該也可以有人在台灣開一間軟體接案公司，技術棧選用 Clojure 吧？」(註：Elixir 與 Clojure 都是相對小眾的程式語言。) 從 agency 轉型成為 consulting 做生意，不免都要思考最適規模、價值創造、收費模式等議題。總之，經營一年半之後，我就決定把自己的生意改一改，從接案代工 (agency) 改成諮詢顧問 (consulting) 。主要的差異在哪呢？其實對我而言，主要的差異就是：「不需要雇用員工」

善用科技與中心化來創新工作流程 — 有些工作本身的特性是適合分散式、多點地來做。然而，有時因為工具不普及、法規等限制，反而變成了中心化最有效率。一旦限制消失時，就會產生去中心化。比方說，一旦有了 youtube 與剪接影片軟體、後製影片軟體之類的工具，一般人也可以自行製作影片，接著會沿生 youtuber、網紅文化，電視一方獨大的現象也會開始勢微。 有一些工作則剛好相反，本身的特性是適合集中地來做，但是因為某些限制存在，人們為了突破這些既有的限制只好訴諸去中心化的權宜之計，一旦隨著工具的發展或是外界的變化導致限制消失時，就會自然回歸中心化。 晶片架構 主流的硬體設計是一個功能對應一個封裝好的晶片、以印刷電路板組合數個不同功能的晶片，電流的訊號必須在印刷電路板上傳送相當長的距離才能完成運算。 然而，由於晶圓製造技術地不斷提高，現在的一些超高效能晶片則是採用 SoC (system-on-a-chip) 架構，即系統所有的功能全部做在一張晶片裡。我寫這篇文章時，使用的Macbook ，裡頭的 M1 晶片就是如此。硬體的設計採用了 SoC 這樣子的中心化架構，一方面節省了封裝成本、一方面電流需要跑的距離也縮小到肉眼幾乎看不見，於是製造成本、耗電量都可以降低，運算速度又可以再提高。