{
  "version": "https://jsonfeed.org/version/1.1",
  "title": "Michael Chang",
  "home_page_url": "https://printers-notes.zeabur.app/",
  "feed_url": "https://printers-notes.zeabur.app/feed.json",
  "description": "關於商業、決策與技術的個人洞見。長文為主，不追熱點。",
  "language": "zh-Hant-TW",
  "authors": [
    {
      "name": "Michael Chang",
      "url": "https://printers-notes.zeabur.app/about/"
    }
  ],
  "items": [
    {
      "id": "https://printers-notes.zeabur.app/posts/ai-project-second-month/",
      "url": "https://printers-notes.zeabur.app/posts/ai-project-second-month/",
      "title": "為什麼多數 AI 專案死在第二個月",
      "summary": "第一個月的成功是假的。真正的問題在 Demo 結束、有人必須改變工作方式的那一刻才開始浮現。",
      "content_html": "<p>第一個月大家都很興奮。Demo 跑起來了，老闆點頭了，會議室裡有掌聲。有人開始討論要不要擴大到其他部門。</p>\n<p>第二個月開始有人問：那我原本的工作流程要怎麼改？</p>\n<p>真正的問題從這裡才開始。</p>\n<h2>第一個月的成功是一種錯覺</h2>\n<p>Demo 之所以順利，是因為它跑在一組被挑選過的資料上，由一個高度投入的人操作，而且<strong>沒有任何既有流程需要為它讓路</strong>。這三個條件在第二個月會同時消失。</p>\n<p>我看過一個倉儲的揀貨排程專案。Demo 階段的模型把揀貨路徑縮短了 23%，數字漂亮到不需要解釋。導入四週後，實際節省是 4%。</p>\n<p>差距不在模型。差距在於現場的組長有一套自己累積十年的排法，他知道哪個貨架的棧板容易卡、哪個時段的堆高機會塞車。模型不知道這些，而沒有人被指派去把這些知識餵進去，也沒有人被指派去說服組長改變。</p>\n<h2>失敗的不是技術，是沒有人負責承擔改變的成本</h2>\n<p>任何流程改變都有成本，而這個成本一定會落在某個具體的人身上。導入 AI 的專案書裡通常會寫「預期效益」，很少寫「誰的工作會在前三個月變難」。</p>\n<p>但後者才是決定成敗的變數。</p>\n<ul>\n<li>如果沒有人被指派承擔這個成本，成本會被默默地丟給最沒有話語權的人，然後那個人會用各種方式讓新流程失效。</li>\n<li>如果有人被指派，但他沒有拒絕舊流程的權力，結果是一樣的。</li>\n<li>只有當「承擔成本的人」與「有權改變流程的人」是同一個人，導入才會真的發生。</li>\n</ul>\n<p>這聽起來像組織問題而不是 AI 問題。確實如此。<em>絕大多數 AI 專案的失敗都是組織問題</em>，只是它剛好穿著技術的外衣。</p>\n<h2>一個更好的第一個問題</h2>\n<p>多數人導入前問的第一個問題是：這個模型準不準？</p>\n<p>更能預測成敗的問題是：<strong>這件事做成之後，誰的工作會變難？</strong></p>\n<p>如果答案是「沒有人」，那多半代表這個專案沒有真正改變任何流程，效益也會等於零。如果答案是某個具體的人，那接下來的問題就清楚了——他知道嗎？他同意嗎？他有沒有拒絕的權力？</p>\n<blockquote>\n<p>我從來沒看過一個死掉的 AI 專案，是死在模型不夠好。它們都死在沒有人願意為了它改變自己的工作方式。</p>\n</blockquote>\n<h2>所以第二個月該做什麼</h2>\n<p>不要在第二個月擴大範圍。第二個月應該縮小範圍，找出那個「工作會變難的人」，然後把整個月花在他身上。</p>\n<p>具體來說：把他知道而模型不知道的事情列出來，一條一條問為什麼。這份清單通常會比模型本身更有價值，因為它是這家公司真正的營運知識，而它從來沒有被寫下來過。</p>\n<p>如果第二個月結束時你手上有這份清單，這個專案大概不會死。如果沒有，準確率再高也撐不到第四個月。</p>\n",
      "date_published": "2026-06-12T00:00:00.000Z",
      "tags": [
        "AI",
        "組織",
        "導入"
      ]
    },
    {
      "id": "https://printers-notes.zeabur.app/posts/weight-of-decisions/",
      "url": "https://printers-notes.zeabur.app/posts/weight-of-decisions/",
      "title": "決策的重量不在難度，在可逆性",
      "summary": "我們習慣把決策依「困難程度」排序，但真正該用來排序的是「錯了以後回得來嗎」。這兩者經常剛好相反。",
      "content_html": "<p>多數人排序決策的方式是看它有多難：要花多久想、資料齊不齊、會不會被檢討。</p>\n<p>這個排序方式會系統性地把注意力放錯地方。</p>\n<h2>兩種決策</h2>\n<p>有些決策錯了可以走回來，成本是浪費掉的時間。有些錯了走不回來，成本是接下來三年都要繞路。</p>\n<p>換一個供應商、改一次定價、上一個新功能——這些多半可逆。做錯了，兩個月內可以復原，而且過程中會學到只有做了才學得到的東西。</p>\n<p>找一個共同創辦人、簽一份三年的租約、決定公司要做哪一個市場——這些不可逆。不是完全不能改，而是改的成本高到會吃掉你本來想爭取的所有好處。</p>\n<p>麻煩的是，<strong>這兩類決策的「困難程度」經常與「可逆性」相反</strong>。</p>\n<p>換供應商很麻煩：要比價、要驗廠、要重談合約，開會開好幾輪。找共同創辦人卻常常在一頓飯之間就決定了，因為聊得來。</p>\n<p>於是我們把最多的分析力氣花在可逆的事情上，把最少的花在不可逆的事情上。</p>\n<h2>可逆的決策：拖延本身就是成本</h2>\n<p>如果一個決策錯了兩個月內可以復原，那麼再多開三場會議取得的資訊，通常少於直接做下去兩週學到的資訊。</p>\n<p>這類決策的正確作法是<strong>快，並且明確記下自己憑什麼這樣決定</strong>。後面那半句才是關鍵——如果不記下當時的判斷依據，錯了之後你只會知道「這條路不通」，不會知道「我的哪一個假設是錯的」。前者不能累積，後者可以。</p>\n<p>實務上我會寫三行：我賭的是什麼、我預期兩個月後看到什麼、如果看到什麼就代表我錯了。</p>\n<h2>不可逆的決策：要慢的是承諾，不是思考</h2>\n<p>不可逆的決策值得放慢，但很多人放慢的方式是錯的——他們花更長的時間思考，卻在思考的同時已經默默承諾了。</p>\n<p>真正該做的是把「承諾的時點」往後推，同時盡量把不可逆的部分切成可逆的。</p>\n<ul>\n<li>三年租約可以先談六個月加續約權。</li>\n<li>共同創辦人可以先一起做完一個真的有壓力的專案。</li>\n<li>進入一個新市場可以先用最小的形式賣三個月。</li>\n</ul>\n<p>這些做法都會讓你付出一點溢價。那個溢價買的是資訊，而且通常很便宜。</p>\n<blockquote>\n<p>值得付錢的不是「更好的決定」，是「更晚才需要決定」。</p>\n</blockquote>\n<h2>一個實際的檢查</h2>\n<p>在按下去之前問一句：如果六個月後發現這是錯的，我要花多少錢、多少時間走回來？</p>\n<p>答案如果是「兩個月內、花不了什麼錢」，那就不要再開會了，直接做。</p>\n<p>答案如果是「回不來了」，那今天要做的不是決定，而是想辦法讓這件事變得可以回來。</p>\n",
      "date_published": "2026-05-20T00:00:00.000Z",
      "tags": [
        "決策",
        "管理"
      ]
    },
    {
      "id": "https://printers-notes.zeabur.app/posts/silent-leverage/",
      "url": "https://printers-notes.zeabur.app/posts/silent-leverage/",
      "title": "沉默的槓桿",
      "summary": "公司裡真正決定事情速度的，往往不是決策者，而是那些沒有頭銜、卻掌握了某個關鍵環節的人。",
      "content_html": "<p>每家公司都有一份組織圖，上面畫著誰管誰。每家公司也都有一份沒有畫出來的圖，上面是誰能讓事情真的動起來。</p>\n<p>這兩份圖重疊的部分，比多數人以為的少。</p>\n<h2>權力與槓桿不是同一件事</h2>\n<p>權力是「我可以要求你做」。槓桿是「沒有我這件事做不成」。</p>\n<p>一個部門主管有權力。但如果所有客戶資料的匯出都要經過某位工程師手上那支沒人看得懂的腳本，那位工程師就有槓桿。主管可以命令他，但命令的執行速度取決於他的心情，而沒有人能證明他是不是在拖。</p>\n<p>槓桿最常出現在這幾種位置：唯一懂舊系統的人、掌握對外窗口的人、實際排生產順序的人、以及所有「這件事一直都是他在弄」的人。</p>\n<h2>槓桿的行使方式是「不動」</h2>\n<p>這是最容易被忽略的一點。掌握槓桿的人不需要反對任何事情，他們只要維持現狀就好。</p>\n<p>沒有人會在會議上說「我不同意」。他們會說「好啊，不過這個月比較滿，下個月開始可以嗎」。然後下個月有新的優先事項。</p>\n<p>於是專案不是被否決的，是被稀釋的。而從決策者的角度看，一切都通過了，只是不知道為什麼沒有發生。</p>\n<h2>所以要做的不是說服上面</h2>\n<p>多數人推動改變的方式是往上說服——把簡報做好，讓有權力的人點頭。點完頭之後專案卡住，就再回去要更多的權力背書。</p>\n<p>這條路的問題在於，權力能解決「不准做」，不能解決「做不動」。</p>\n<p>比較有效的順序是反過來：先畫出這件事實際會經過哪幾雙手，找出其中哪一雙手是不可繞過的，然後直接去問那個人——這件事做成之後，你的工作會變好還是變壞？</p>\n<p>如果答案是變壞，那不管上面點多少次頭都不會發生。這時要處理的是那個具體的損失，而不是再多開一場會。</p>\n<blockquote>\n<p>讓一件事發生最快的方法，通常不是取得更高的授權，而是讓不可繞過的那個人成為受益者。</p>\n</blockquote>\n<h2>一個副作用</h2>\n<p>用這個角度看組織一段時間之後，會發現一件有點不舒服的事：這些掌握槓桿的人，通常不是因為想要權力才走到那個位置的。他們只是長期把一件沒人想碰的事做好了，久而久之變成唯一會做的人。</p>\n<p>他們的槓桿是責任的副產品，不是政治操作的結果。</p>\n<p>所以更好的作法不是削弱他們，而是讓那件事不再只有一個人會做——同時，確定他因為交出這個槓桿而得到的，多過他失去的。</p>\n",
      "date_published": "2026-04-08T00:00:00.000Z",
      "tags": [
        "組織",
        "管理"
      ]
    }
  ]
}