文章目錄
一、一個讓我越想越不對勁的現象
我做了十五年的軟體專案經理。在電商這一行,除了管整家公司的總經理職位以外，這個角色管過工程師、管過時程、管過大促前夜的作戰室,也管過那條把流量變成營收的生產線上,每一次延誤與每一場救火。
AI 崛起之後,這個工作正在被重新定義。邏輯不難理解:當寫程式這件事變得前所未有地快,大家第一個檢討的,往往不是工程師,而是「管理工程師的方法」——過去那套排時程、盯進度的手藝,還適用嗎?
而有一個現象,讓我越想越不對勁。這一兩年,各家公司搶著導入 AI 開發工具,程式碼的產出速度前所未有;但放眼整個產業,產品並沒有因此快三倍上線——有的團隊確實快得驚人,有的卻跟一年前沒有兩樣。產出量的曲線陡峭地往上走,交付價值的曲線卻只是微微抬頭。中間消失的那一段,去了哪裡?
我把這個問題,從頭到尾想了一遍。答案在一本將近四十年前出版的書裡,而它指向的不是工程師,而是管理——那件我做了十五年、如今正被 AI 重新定義的事。這篇文章,是我想寫給坐在決策位子上的人的。
二、先承認一件事:我們其實是軟體公司
外界看電商,看到的是倉庫、物流車、購物節的成交金額。但在裡面待過的人都知道,這一行的損益表底下埋著另一張報表:轉換率每一個百分點的變化、購物車流程少一個欄位、結帳頁面快 0.5 秒、大促當晚系統撐不撐得住——這些全部是程式碼。
零售的毛利結構大家都差不多,真正拉開差距的,是把「流量」變成「營收」的那一層軟體,以及背後那群工程師。說得更直白一點:一家上市櫃電商的市值,有相當比例是軟體人才生產力的資本化結果。我們是掛著零售外衣的軟體公司,只是很多經營者不願意這樣看自己。
而如果公司的核心產能是「人的腦力」,那管理學大師彼得・杜拉克(Peter Drucker)早在 1959 年就替這種員工取好了名字——知識工作者(knowledge worker)。杜拉克的核心提醒是:知識工作者的生產力,不能用管理體力勞動的方式去榨取,因為生產工具長在他們的腦袋裡,他們下班會把工具一起帶走。
這句話我年輕時當作教科書上的漂亮話。直到 AI 出現,我才意識到它是一個預言。
三、天下大勢:我看了二十年的分工史
《三國演義》開篇說,天下大勢,分久必合,合久必分。我這二十年看著資訊人才市場,走的正是這條路。
我剛入行的年代,公司裡管電腦的就是「那個很厲害的人」:他組電腦、拉網路線、架郵件伺服器、順便把官網也寫了。後來產業長大,開始分工——先分出 MIS 和開發工程師,再分出前端與後端,接著 UI/UX 從前端獨立出來,DevOps 從開發獨立出來,資安從 MIS 獨立出來。每一次徵才,職缺名稱都比上一次更長、更細。
然後 AI 來了。我們現在看到的是反向運動:一個會用 AI 的人,重新變回「什麼都做」的那個人。他寫前端也寫後端,自己部署、自己接金流、自己下 SEO。分了二十年的工,正在合回去。
職能的邊界一直在變,這不奇怪。奇怪的是——當我回頭去讀那些關於「如何管理開發人才」的經典,發現底層的道理幾乎一個字都不用改。因為職能會分合,但被管理的對象始終是同一種東西:人的腦力,以及讓腦力得以運轉的環境。
這就要說到那本書,和那場比賽了。
四、1984 年,一場持續三年的競賽
《Peopleware》(中譯《腦力密集產業的人才管理之道》)的兩位作者狄馬克(Tom DeMarco)與李斯特(Timothy Lister),從 1977 年起每年對軟體生產力進行公開調查;1984 年起,他們把調查變成一場公開競賽,稱為「編程競賽」(Coding War Games):各公司派出開發人員,依同一份規格,在自己平常的辦公環境、用自己平常的工具,設計、撰寫並測試一個中型程式,全程記錄時間,最後接受標準驗收測試。
1984 到 1986 年間,共有 92 家公司、超過 600 位開發人員參賽。結果整理出三條經驗法則:
- 表現最佳與最差者的差距,達 10:1;
- 表現最佳與中等者的差距,為 2.5:1;
- 表現較佳的一半與另一半的差距,為 2:1。
頂尖的人比普通的人強十倍——這個數字很聳動,但坦白說,每一位帶過工程團隊的經營者都心裡有數,這不是新聞。
真正該讓經營者坐立難安的,是接下來這一段。
五、與生產力「無關」的因素:四記打在管理直覺上的耳光
兩位作者分析競賽數據後,列出了幾項與工作表現沒有關聯的因素。每一項,都對應著一條我們深信不疑的管理直覺。
第一記:程式語言無關。 用 COBOL、Fortran 這類老語言的人,表現與用當時新潮的 Pascal 和 C 的人沒有差別。翻譯成今天的語言:你的團隊用不用最新的技術棧、有沒有導入最紅的框架,可能根本不是重點。
第二記:年資無關。 十年經驗的人,表現並未優於兩年經驗的人。只要對所用語言的經驗超過六個月,年資與表現之間就沒有任何關聯。而我們的人資制度,從職等、敘薪到專案配置,幾乎全部建立在「資深等於高產出」這條假設上。
第三記:薪資僅有微弱關聯。 表現較好的那一半參賽者,薪資只比另一半多不到一成,表現卻好了將近兩倍。加薪當然有留才的意義,但如果你以為調薪能直接買到生產力,數據不站在你這邊。
第四記:品質與速度不必取捨。 將近三分之一的參賽者交出零瑕疵的作品,而這些人完成競賽的時間,平均反而比出現瑕疵的人略短。「要快就得犧牲品質」這句我們在會議室說了二十年的話,在數據面前站不住腳。
那——到底什麼有關?
六、真正的答案:不是你的人,是你的公司
競賽裡藏著一個絕妙的設計:每家公司派出的是兩人一組,兩人不合作、各做各的。照理說,兩個獨立作業的人,表現應該像抽籤一樣分散。
結果不是。同組兩人的表現差異,平均只有 21%。你的夥伴做得好,你也做得好;你的夥伴做不完,你大概也做不完。這兩個不合作的人,唯一的共同點是:同一家公司、同一個辦公環境、同一套企業文化。
把鏡頭拉遠看更清楚:表現最佳的人,總是集中出自某幾家公司;表現最差的人,也總是集中出自另外幾家。92 家參賽公司中,最好的公司比最差的公司快了 11.1 倍——而且最好那家公司交出的程式,全數通過驗收測試。這印證了軟體工程先驅哈蘭・米爾斯(Harlan Mills)1981 年的預測:程式設計師之間存在 10 比 1 的生產力差異,軟體公司之間,同樣存在。
多年來,管理者對「頂尖工程師強十倍」抱持一種宿命論:天分是天生的,我改變不了什麼。但「強者總是成群出現在同幾家公司」這件事,宿命論解釋不了。天分不會挑公司投胎——是環境和文化,決定了一家公司留不留得住人才,以及留下來的人才,發揮得出幾成功力。
書中這一章的標題,毒辣地說穿了一切:「從上午九點到下午五點根本做不了任何事」。開放式座位裡此起彼落的電話、一場接一場的會議、每十五分鐘一次的訊息打斷——你以為你在管理,其實你在系統性地摧毀你最貴的資產的產能。同一位工程師,在 A 公司能撐起大促晚上每秒數千筆的交易,到了 B 公司連排程都追不上,差別往往不在他,在你給他的九點到五點。
七、AI 之後:當你的行銷長也開始寫程式
如果《Peopleware》只是講工程師的書,它不值得一位經營者在 2026 年重讀。值得重讀的原因是:它描述的那群「腦力密集工作者」,正在從工程部門溢出,淹沒整張組織圖。
這一兩年,我在不同的公司、不同的圈子裡,反覆看到同一種畫面:行銷的人用 AI 自己做了活動頁,沒有開需求單;財務的人寫了腳本,自動對帳;一位媒體業出身的朋友,靠著 AI 工具,一個月做了一百個網站。過去我們對工程師的想像——不擅言辭、坐在螢幕後面的技術宅——正在失效,因為「會開發的人」的邊界,已經炸開了。
這帶來一個全新的管理問題:這些介於一般職能與開發者之間的混種人才,績效怎麼評估?他們的產出既不是行銷 KPI 能涵蓋,也不是工程師的指標能衡量。
而布魯克斯(Fred Brooks)在《人月神話》裡的老警告,此刻也值得重讀:對進度落後的專案增加人力,只會讓它更落後。AI 相當於一夜之間,替每家公司空投了成千上萬名不知疲倦的初階工程師——如果人月神話的詛咒對「人」成立,我們憑什麼假設它對「人加 AI」自動失效?產出量翻了幾倍、交付卻沒有等比例變快——產出與交付之間消失的那一段,答案就在這裡:瓶頸從來不在打字的速度,在協作、在整合、在環境,在管理。
Coding War Games 給了我們方法論上的提示:**個人表現量不準,但環境的好壞量得出來,也改得動。**與其發明一套考核混種人才的新 KPI,不如先回答幾個老問題——他們有沒有一段不被打斷的完整時間?他們的好作品,公司看得見嗎?他們待的環境,配得上他們的產出嗎?
八、給經營者的三個功課
重讀《Peopleware》之後,我整理出三個功課,送給坐在決策位子上的你。
**第一,把「專注環境」當資本支出,不是行政費用。**對腦力密集的公司而言,一段不被中斷的安靜時間,就是產能設備。這個產業願意為倉儲自動化投資數億,卻捨不得讓工程師關掉即時訊息兩小時——這在資源配置上是荒謬的。
**第二,停止用年資和薪級推估產出,改用「團隊×環境」作為績效的分析單位。**數據說了,個人層次的預測變數幾乎全是假的;但同一組人差 21%、公司之間差 11 倍,是真的。要改善的槓桿在哪裡,一目瞭然。
**第三,把軟體人才管理之道,列為全體主管的通識。**當每個部門都有人在用 AI 開發,每一位部門主管,實質上都成了軟體經理——不管他自己知不知道。過去只有技術主管要讀的書,現在應該進入所有主管的讀書會。腦力密集產業的管理之道,正在從一門專業,變成一門通識。
最後,回到開頭那個問題:產出與交付之間,消失的那一段去了哪裡?AI 確實讓寫程式變便宜了,而且會越來越便宜。但它同時讓另一件事變得前所未有地貴:打造一個讓會寫程式的人——不管他掛什麼職稱——真正做得了事的環境。
前者,你的競爭對手明天就能用同樣的價格買到。後者,買不到,只能經營。這就是我認為未來十年,經營者之間真正的分水嶺。
而這份答案,四十年前就已經寫好了。我能做的,是把它重新遞到你的桌上。
附註(數據出處)
- 編程競賽(Coding War Games)規則、參賽規模(1984–1986 年,92 家公司、600 餘位開發人員)、10:1／2.5:1／2:1 經驗法則、與生產力無關的因素(語言、年資、薪資、瑕疵數量)、同組差異 21%、公司間差距 11.1 倍、Harlan Mills 1981 年之預測,均出自 Tom DeMarco & Timothy Lister,《Peopleware》(中譯《腦力密集產業的人才管理之道》)第八章。
- 「知識工作者」概念出自 Peter Drucker,最早見於 1959 年《明日的地標》(Landmarks of Tomorrow)。
- 「對進度落後的專案增加人力,只會讓它更落後」為布魯克斯定律(Brooks’s Law)之通行表述,出自 Fred Brooks,《人月神話》(The Mythical Man-Month, 1975)。
