AI 在商業決策層面給我帶來的三層改變

AI 在商業決策層面給我帶來的三層改變

從二月開始,台灣就陷入一陣 AI 瘋,一堆人都開始投入龍蝦、Claude Code、Codex 等超級生產力的任務中。不寫程式的人開始寫程式,包含老闆、設計師、行銷、創作者。而其中最瘋狂的,莫過於身邊的一堆老闆們。

有人批評說:「這些老闆們放錯重點,應該好好回到自己的位置上去做出好的決策,讓專業的人來處理專業的工作,不要瞎搞。」

關於這個批評我個人極端不認同

我的看法是老闆不多花點時間深入理解 AI,他在未來就很難做出好決策

今天看到 Coinbase 的 CEO 在 X 上發布了裁員的消息。

而我也在 FB 寫下了我對這件事情的想法。

今年不知道第幾家公司了,幾乎都不是因為經濟不景氣,而是各家公司都在為變化儲糧。很多軟體公司之所以裁員,都是為了有更多的資本支出可以投入在 AI 的團隊、產品或基礎建設上。

扁平化只是一種不再需要「管理代理人」的訊息。現代的管理概念還是很崇尚那個一人最多管七人的科層組織管理概念。

為了「有效管理」,一個人管七個人是個看似科學,實則不思考管理方法該如何進步的落伍觀念。這種觀念導致組織內會有許許多多不具備生產力的行政管理者,他們唯一的作用就是分派工作,就是幫忙審核單據,或者跟催進度。

在公司財務上還過得去時,這類主管的存在問題不大,可隨著公司面臨挑戰時,這類無法創造價值的人就變得特別醒目。

今年 AI 變成這個樣子,連老闆都開始動手在處理問題時,過去那套,老闆應該放手讓團隊學習的氛圍已經淡化了

現在老闆們看到的機會是,如果他不進這個局,他不下來親自體驗,很多決策都會做錯。接下來幾年,founder mode 應該會再次變成顯學。連帶的,老闆也會要求主管要變成這種樣子。

Pure manager 要退場了,更多的管理者都會被要求再次成為 individual contributor,你不只要帶團隊,你還要有能力自己把事情搞定。

最近看一堆老闆朋友像瘋了一樣開始 All in AI,每天都在 build 自己的服務,都在用過往無法使用的方法來解決問題,都在用 AI 提升自己的能力邊界。

當老闆變成這個樣子時,他哪裡還能接受主管們告訴他「這做不到」、「那有困難」。他們心裡肯定覺得「你連自己動手做得能力都沒有,那你這主管形同虛設」。

過往的組織中這類老闆代理人(boss agent)的角色,接下來應該會被更接近老闆想法的 AI Agent 給取代了。


這段時間深度使用 AI,我復盤了自己有幾個很巨大的變化,這也是我對上述想法會如此深信不疑的原因。AI 對我的改變可以分成以下幾個層面。

第一層:工作方式改變

這是大家最常提到的,也就是我們可以透過 AI 將許多工作自動化,也可以靠自己做到那些原先需要依賴特定專業工作者才能完成的任務。例如設計、程式、數據分析、寫文章等等。

但這僅僅只是最表層的變化。

第二層:重新理解工作設計與分工方式

我忘了自己已經有多久沒認真動手寫程式了,即便在去年,我也停留在淺嘗即止的狀態。但今年二月之後,我花了許多時間跟 Claude Code 為伍,到了三月底,我甚至每天都會用 Claude Code 寫程式,四月份開始更是直接弄出了好幾個可運行的系統。

在 38 歲後,我本以為我這輩子除了叫別人寫程式外,不會再親自動手建構一個系統。可現在,我竟然對 AI Coding 這件事樂此不疲。

這個改變,讓我看見許多的可能性。

這包含了,因為大家能做的事比以前多很多,代表我們很難用從前的職能來定義每個崗位。而這會進一步影響分工,影響職業定位,影響組織設計,一家公司的組成,接下來會有非常大的變化。

如果我不去理解這些變化,那我很快就會跟不上這個時代,就像進入資訊時代時,那些仍再堅持用紙本作業,要員工用土法煉鋼方法工作的企業。又或者進入移動網路時代,所有的思維仍停留在定點的 PC 時代。

意識到這件事,我開始讓公司調整了分工方式,也開始強制要求大家要開始使用 AI,並讓 AI 直接取代掉部分工作。

第三層:決策邏輯的改變

我前兩週發現,我在與團隊或客戶討論問題時,我對一件事的回應方式有了很大的改變。

像是要建構一個自動化的銷售系統,過去我會說「我可能花半年左右的時間,把問題釐清,把資料整理清楚,然後動手開發第一個版本。而且前提是,你得丟兩個工程師跟我協作」。但現在我會說「下禮拜我給你一個版本。

或者要彙整一大堆資料,從中分析出洞察,並建立好一個自動化的報表。以前我會說「給我兩週整理資料,然後我可能先給你一個 excel 模板看看」。但現在我可能說「我今天用 AI 跑跑看,順利的話明天應該能給你一個可互動的報表」。

我對於完成一件事情所需的時間大幅縮短了。表層的意義是,我的工作效率提升了,我交付的速度提升了很多倍。

但更深層的意義是,我做決策的邏輯,以及處理事情的優先順序會因此有巨大變化

一個本來要半年才能搞定的業務系統,我現在只需要一個禮拜就能出一版。前者,我會需要花時間從長計議,要溝通,要準備計畫,要等待工程師的人力,所以我快不起來。有時甚至會因為過程中的不順暢,會將整個計劃延後或取消。

這導致一件重要且緊急的事,因為資源因素而無法順利推進。

但 AI 讓我在一週的時間,靠我自己一個人就推出了一個版本。中間少了折衝、討論、等待,而是直衝交付,並在這個基礎上進行迭代。

身為一位創業者或專業經理人,我們都可以回想自己過往幾年,有多少次想做一件事,但卻因為資源問題,技術困難,或者專業不足的原因而打消念頭。

那些你曾打消的念頭,或許現在都值得拿出來再想一次。
那些你過往不做的決定,現在或許都可以被討論了。

當決策的阻礙減少了,你會發現選項變多了,很多過去想不出解法的問題也開始有了解答。

或許有些人會擔心這會不會導致老闆開始亂做決定,又或者做了太多不太重要的事情。

我可以很誠實地告訴你:「絕對會。」

可我認為這就是典範轉移過程的必然,大家通常都是想過頭、用過頭,然後才開始校正回歸。

但如果因為擔心衝過頭而選擇不衝,那我們會連發現新大陸的機會都沒有。永遠只能愈來愈有限的選項中做決定,很難找到新的可能性。

過頭/犯錯/修正,永遠比不敢嘗試更值得鼓勵。
如果你覺得我內容寫得還不錯,歡迎訂閱我的電子報,我每雙週會發送一封電子報到你的信箱。訂閱連結在這,過往的電子報也在這:Gipi電子報

也鼓勵你可以將我的電子報分享給你認為有需要的朋友們,也許你的舉手之勞,將會改變另一個人的思維與習慣。

Read more

[徵才]方圓國際誠徵兩個新職務

[徵才]方圓國際誠徵兩個新職務

今年四月份,我加入了方圓國際擔任策略長,方圓是一家茶飲連鎖公司,旗下有兩個主要品牌「吃茶三千」與「喫茶小舖」。吃茶三千在海外 30 多的城市有約 130 家門市,喫茶小舖在台灣則約有 60 家門市。 我從去年底開始擔任方圓的顧問,主要協助梳理公司的管理制度、流程與阻礙成長的問題。四月份我轉任策略長,過去這一個多月,我除了 AI 的引入與建置外,我也花了大量的時間重新構思公司的整體策略。 我們進行了「未來十年不變的事」的策略探討,最終設定了十年戰略方向,三年目標,以及 2026 年的關鍵任務。 透過這樣深度的策略思考,我們也藉這個機會盤點了公司目前的人才缺口。 以下有兩個很關鍵的角色是我迫切在找尋的。如果你覺得自己或身邊的人很適合加入方圓,請自薦或推薦給我,謝謝。 歡迎將履歷投遞到:gipi@teashop168.com.tw 門市體驗經理(Store Experience Manager) 門市是接觸終端消費者的最後一哩路,也是品牌傳遞價值的關鍵接觸點。我們在全球因應不同的市場有不同的店型設計,

By gipi
克服 AI 焦慮的方法,唯有實作

克服 AI 焦慮的方法,唯有實作

2018-2019 年左右,線上學習在台灣整個大爆發,線上課程一大堆,每個禮拜都有很多線下學習活動。每天都可以看到大量的學習心得與活動心得,每個人講的內容都很有道理。全台灣好像瞬間變成一個知識島,所有人都學識淵博,而自己似乎懂得有點少。 知識焦慮年代 在那個時候,很多人染上了「知識焦慮」的病症。 害怕別人知道自己不知道的,擔心自己沒跟上世界的節拍,所以哪邊有新知往哪兒去,哪邊學習氛圍濃厚就往哪兒鑽。看起來是因為熱愛學習,但內心的煩惱其實是「害怕失去」。 害怕失去話語權,害怕失去社交談資,害怕失去機會,害怕失去競爭力,害怕自己不再是別人眼中領先的族群。 而克服焦慮最有效的方法,不是知道更多,而是實踐,從時間中獲得成果,獲得進步。 那些仍在學而沒有做的人,焦慮是無法停止的,因為他並沒有真的改變現況。 這也是當年為何我們想舉辦 case study、學習營、打卡、案例練習,並且鼓勵大家多多輸出的原因了。因為輸出,其實就是最輕量的實踐,而動手做,則是讓自己學有所用的基本配備。 在那個知識焦慮的年代裡,因為我本來就熱愛學習,也經常輸出,

By gipi
我如何與 AI 協作開發,我的開發步驟分享

我如何與 AI 協作開發,我的開發步驟分享

昨天到工程師場子分享,想說跟大家對照一下,現在是否多數人都跟我一樣,寫程式完全不手打任何一行 code,全部都是 AI 做的。 結果發現,現場只要有在用 AI 開發的人,多數時候真的都是讓 AI 來完成程式撰寫工作。 目前我的開發組合是 Claude Code / Claude Design / Fly.io / Github / Cloudflare,其他還有根據程式功能需要而使用的第三方元件。 做一個新系統的習慣是: 1. 跟 Claude 討論我想解決的問題,以及我的核心需求,中間我可能會用 Claude Cowork 做本地資料的分析,然後請他廣泛收集一下資訊,做幾輪 prototype 的模擬。確認方向是否是我所期待的。 2. 對完需求後,請他產出系統定位、限制、邊界與 PRD。 3. 把 PRD 跟幾個

By gipi
加快了速度,少了回饋

加快了速度,少了回饋

2022 年時我曾推出了一堂課《打造高效軟體開發團隊》。 在這堂課程中我繪製了一張軟體開發過程管理的架構,這張圖我從公司策略->產品策略->需求管理,一路到開發過程管理、交付、市場回饋,最後再回到產品需求管理。 當年我曾說過,軟體開發最重要的其實不是程式開發本身,而是 align 公司策略與產品策略,同時兼顧好短期需求,將需求管理做好。 但我們也可以看到產品需求管理是上述架構中最主要的節點,上承策略,下接短期需求,右邊則是成為所以開發計畫的起頭,同時還要承接來自市場回饋,並能持續優化管理過程與技術債務管理。 簡單的說,決定做什麼,決定了產品定位,決定先做什麼,則決定了策略重心。但要做出決定,除了對目標有清晰的認知外,更重要的是「回饋」。包含市場回饋、使用者回饋、利害關係人回饋(研發/行銷/客服...)。 這陣子透入 AI 開發後我對這張架構圖有一些新的想法: 首先,是生產力過剩。 因為 AI 不用休息,生產力幾乎沒上限,

By gipi