經營一個 AI-native 的工程組織（第 2/2 段） ☕ Buy me a coffee

🧑‍🏫 這是 Claude Code 團隊主管分享的下半段，講她怎麼帶一個「什麼事都先想 Claude 能不能做」的團隊：怎麼練出對產品的判斷力、怎麼讓 Claude 補上每個人不擅長的部分、怎麼調整組織，還有怎麼判斷有沒有效。就算你不是工程師，裡面「自己用、定期砍流程、驗證成果」這幾招，放到一般工作上也用得到。

• 13:19 團隊重視兩種人才：有 product sense 的創意型 builder，以及有深厚系統專業的人；同時仍要保持「trust but verify」
  ↳ 團隊最看重兩種人：有 product sense（判斷使用者要什麼的直覺）又愛動手做的人，和技術很深的專家。但不管信任誰，成果都要檢查，這叫 trust but verify（信任但要驗證）。
• 13:19 講者在舊金山演講後，很多工程師問她如何培養 product sense，她分享自己覺得有用的做法
  ↳ 她在舊金山演講完，最多工程師追問的就是：product sense 到底怎麼練？所以這段她分享的是自己實際覺得有效的做法，不是空泛理論。
• 13:49 Product sense 像肌肉，第一步是 dogfooding；特別是主管，要花時間親自使用自己和團隊在做的產品
  ↳ 她說 product sense 像肌肉，要靠練。第一步是 dogfooding（親自用自家團隊做的產品）。越是主管越該撥時間真的去用，而不是只聽別人報告。
• 13:49 講者每次加入新團隊，第一件事就是 dogfood 產品，藉此真正理解產品、「用骨子裡感受產品」
  ↳ 她每換一個團隊，第一件事就是自己當使用者把產品用一遍。看文件只知道產品「有什麼」，自己用才知道哪裡卡、哪裡順，這就是「用骨子裡感受」。
• 13:49 Dogfooding 時要不斷問自己：當初做這個產品是想解決什麼問題？想為使用者實現什麼體驗？
  ↳ 用的時候不是隨便點點，而是一直對照初衷：這東西本來要幫使用者解決什麼？現在用起來有做到嗎？中間的落差就是該改的地方。
• 14:19 在有 Claude 之前，主管可能已沒時間碰 codebase；主管親自用產品，團隊成員會覺得「你是真的在乎」
  ↳ 以前主管忙到沒空碰 codebase（產品的整份程式碼）。但主管如果願意親自用產品、講得出細節，團隊會感受到你是真的在乎，不只是在盯進度。
• 14:19 Product sense 來自大量 dogfooding，加上反覆迭代、出貨，以及實際出去和客戶聊
  ↳ product sense 沒有捷徑：大量自己用、一版一版改、真的推出給人用，再出去跟客戶面對面聊。這幾件事反覆做，直覺才會慢慢長出來。
• 14:50 講者熱愛小型企業，提到剛宣布 Claude for small business（字幕寫作 Cloud for small business）
  ↳ 她很喜歡小型企業這群使用者，也提到 Anthropic 剛宣布了 Claude for small business（字幕誤寫成 Cloud）。
• 14:50 她親自幫開餐廳的朋友 onboard 到 Cowork，觀察企業以外的小型企業使用者如何上手，發現 onboarding 流程有很多可改進之處
  ↳ 她親自帶開餐廳的朋友上手 Cowork（Anthropic 讓非工程師也能請 Claude 代辦工作的產品），在旁邊看才發現 onboarding（新用戶從開始到會用的過程）有很多可以改。
• 15:22 若不 dogfood，久了可能只根據 metrics、dashboard 或 PowerPoint 做產品決策；Anthropic 內部把 dogfood 稱為「ant food」
  ↳ 不自己用，久了就只看 metrics（數據指標）、dashboard（數據儀表板）或簡報做決定。數字看得到結果，卻看不到使用者卡在哪。Anthropic 內部把 dogfood 叫做 ant food。
• 15:22 用 Claude 填補跨職能缺口，這適用於所有角色
  ↳ 每個人都有不擅長的事，以前只能等別的職位的人來幫；現在可以請 Claude 先補上那一塊。工程師、設計師、PM 都適用。
• 15:52 例：以前設計師做 polish／UX 修正要畫 red line 交給工程，常要等工程有空；現在 Claude Code 團隊的設計師直接用 Claude 修，迭代迴圈更快
  ↳ 以前設計師想微調畫面，要畫 red line（標出哪裡要改、改多少的設計標註）交給工程師，再排隊等對方有空。現在設計師直接請 Claude 改，來回修正快很多。
• 15:52 也因為設計師等角色會自己改東西，所以驗證（verification）更加重要
  ↳ 但非工程師也能直接改程式之後，出錯的機會跟著變多，所以「改完確認沒弄壞東西」這一步比以前更重要。
• 16:23 反過來，講者身為工程師寫文案容易太冗長，修 bug 時請 Claude 當內容設計夥伴；Claude 會補強每個人較弱的領域
  ↳ 反過來也一樣：她是工程師，寫介面上的文字常常太長。修 bug 時她請 Claude 當文案夥伴幫忙精簡。Claude 補的是每個人各自的短板。
• 16:54 講者加入 Claude Code 後做的第一批改變之一：和招募團隊合作，讓每位主管都先從 IC（個人貢獻者）做起
  ↳ 她加入 Claude Code 團隊後，最早的改變之一是跟招募團隊講好：新進主管一律先當 IC（不帶人、自己動手做事的角色），之後才開始帶人。
• 16:54 原因是團隊用 Claude Code 打造 Claude Code；先當 IC 讓主管在承擔帶人責任前，有時間實際進 codebase、體驗當團隊工程師
  ↳ 因為這個團隊是用 Claude Code 在做 Claude Code。主管先當一陣子工程師，實際改過程式、用過工具，之後帶人才知道團隊每天面對的是什麼。
• 17:24 現在也是主管拿回 maker hours、回到 codebase 的好時機，因為 onboarding 比以前不嚇人多了
  ↳ 她認為現在正是主管拿回 maker hours（不被打斷、專心動手做東西的時間）的好時機，因為有 Claude 帶著，重新熟悉程式碼沒以前那麼嚇人。
• 17:24 講者過去多次在主管與 IC 間切換，每次當 IC 都幫她累積工程工具箱，但以前久沒碰會對 onboarding 有些猶豫
  ↳ 她自己在主管和 IC 之間換過好幾次，每次當 IC 都讓技術功力更扎實；但以前離開程式碼太久，要重新上手總會有點卻步。
• 17:54 知識分享：什麼是新的 source of truth？在 Claude Code 團隊，程式碼就是 source of truth
  ↳ 團隊的知識以什麼為準？這就是 source of truth（大家認定最正確、有疑問就回來查的依據）。在 Claude Code 團隊，答案是程式碼本身，而不是另外寫的文件。
• 17:54 講者仍會和團隊每位工程師見面，但現在更多是聊大家在意的事，而不是做技術 deep dive
  ↳ 她還是會跟每位工程師見面，但重點變成聊他們在意什麼、卡在哪，而不是請對方講解技術細節，因為技術細節可以直接問 Claude。
• 18:24 她的第一次技術 deep dive 是跟 Claude 做的；修第一個 bug 前，先請 Claude 教她該 bug 相關的 surface area 與周邊區域
  ↳ 她第一次深入研究技術是跟 Claude 一起做的：動手修第一個 bug 前，先請 Claude 解釋這個 bug 牽涉到哪些功能、周邊的程式怎麼運作。
• 18:54 建議：不論 source of truth 是什麼（例如 spec），可把它改成 skill 放進 codebase，才能持續保持最新
  ↳ 不管你們以什麼為準，例如 spec（規格文件），都建議做成 skill（Claude 隨時能讀、照著做的指引包）放進 codebase，跟程式碼一起更新，才不會過時。
• 18:54 寫程式的產能大增後，不在更新迴圈內的文件更容易過時
  ↳ 有了 AI，程式改得又快又多。文件如果不在「改程式時順手更新」的流程裡，很快就跟實際狀況對不上。
• 19:25 推動改變的方式：有些事全團隊要對齊（must do），也保留 bottoms up 空間，因為各團隊重點與工具鏈不同
  ↳ 推動改變分兩層：少數事情全團隊都得照做；其他的留給各小組自己決定（bottoms up，由下而上），因為每組的重點和用的工具都不一樣。
• 19:25 團隊原則（forcing function）之一：每位隊友（不只工程師）都要用 Claude Code，也要用 Cowork
  ↳ 第一條必守原則（forcing function，用硬規定逼大家真的改掉習慣）：每個人，不只工程師，都要用 Claude Code，也要用 Cowork。
• 19:56 原則二：能 Claudify 的都 Claudify，隨時問「Claude 能替我做嗎？」以釋出自己的頻寬去解其他問題
  ↳ 第二條：能 Claudify（交給 Claude 做）的就交給它。隨時問自己「這件事 Claude 能代勞嗎？」省下來的時間拿去處理更需要人的問題。
• 19:56 原則三：明確允許砍掉舊流程；即使是幾個月前定的原則或流程，也要檢討它是否仍達成原本目的
  ↳ 第三條：明確允許大家砍掉舊流程。就算是幾個月前才定的規則，也要問它還有沒有達到當初的目的，沒有就可以拿掉。
• 20:26 Bottoms up 部分交給各 team／pod 調整，例如 Claude 如何出現在 triage、規劃儀式或 stand-up，以及哪些工作流程先 Claudify
  ↳ 由下而上的部分交給各 team 或 pod（團隊裡的小組）自己調整，例如 Claude 怎麼參與問題分派（triage）、規劃會議、每日站立會議（stand-up），哪些工作先交給 Claude。
• 20:56 講者為 Claude Code 與 Cowork 優先做的三件事之一：讓組織盡量敏捷、扁平，主管也要進 codebase、直接負責部分產品
  ↳ 她為 Claude Code 和 Cowork 定的三個優先之一：組織要靈活、層級要少，主管也要進程式碼，直接負責一部分產品，而不是只管人。
• 20:56 第二件：Claude-ify——「如果 Claude 能做，就該讓 Claude 做」
  ↳ 第二個優先是 Claude-ify：只要 Claude 做得到，就讓它做，人把力氣留給 Claude 還做不到的事。
• 21:27 模型進步很快，兩三個月前 Claude 做不好的事，模型更新後可能就很擅長，所以要持續回頭檢視、保持成長心態
  ↳ 模型進步很快，兩三個月前 Claude 做不好的事，換新版之後可能已經很拿手。所以「Claude 做不到」的結論要定期重新測，不要一次就定案。
• 21:27 人們不會自己刪流程，流程只會越堆越多，因此要定期稽核
  ↳ 流程只會越加越多，很少有人主動刪。所以要定期盤點，主動找出哪些已經沒用了。
• 21:57 例：講者曾待過 SLA 太多的團隊（P0 bug SLA、incident response SLA 等），工程師問「一天只有 24 小時，該先顧哪個 SLA？」，於是她檢討是否都還必要
  ↳ 她待過一個團隊，SLA（承諾多久內處理完的標準，例如嚴重 bug、事故應變）多到工程師問：一天只有 24 小時，要先顧哪個？她就回頭檢討這些是否都還需要。
• 22:28 成效訊號一：onboarding ramp-up 時間下降，例如新工程師 land 第一個 PR 所需時間，以及對其他成員造成的成本都在下降
  ↳ 訊號一：新人上手變快。例如新工程師完成第一個 PR（送審並被合併的程式修改）花多久、帶新人佔用其他同事多少時間，都在下降。
• 22:58 新人問問題時，講者常回「好問題，我們問 Claude 吧」；主管學新領域也不再覺得占用工程師時間
  ↳ 新人發問時，她常說「好問題，我們一起問 Claude」。主管想學新領域，也不必再覺得是在佔用工程師的時間。
• 22:58 成效訊號二：PR cycle time 應該下降，但不要只看端到端，要拆成 PR 各階段來看
  ↳ 訊號二：PR cycle time（一個程式修改從開始到合併的總時間）應該變短。但不要只看總時間，要拆成撰寫、審核、測試等各階段來看。
• 23:28 PR cycle time 沒降不一定代表沒採用 AI，可能是吞吐量變大讓其他環節塞車，例如 build 與 CI 系統跟不上；應逐段找能改善或自動化之處
  ↳ 總時間沒降，不代表沒在用 AI。可能是程式寫太快，後面的 build（把程式組成可執行版本）和 CI（自動測試檢查）排隊塞住了。要逐段找瓶頸，看哪段能改善或自動化。
• 23:58 成效訊號三：Claude 輔助的 commit 增加；講者說最近幾個月沒看過不是 Claude 輔助的 commit
  ↳ 訊號三：有 Claude 協助的 commit（每一筆存進去的程式修改紀錄）變多。她說最近幾個月，已經沒看過沒有 Claude 參與的 commit。
• 23:58 比吞吐量更重要的是：找方法衡量你和團隊想解決的產品或問題，確認真的讓產品更好、品質提升
  ↳ 但產出多不等於做得好。更重要的是找方法衡量你們真正想解決的問題，確認產品真的變好用、品質真的提升。
• 24:31 仍在思考的問題一：還需要分開的 iOS 與 Android 組織嗎？Claude 讓工程師能跨行動平台工作
  ↳ 她還沒有答案的問題一：iOS 和 Android 還需要分成兩個團隊嗎？有了 Claude，同一個工程師可能兩個平台都做得來。
• 25:01 仍在思考的問題二：全自動 review 要推到多遠？要在速度與不遺漏重要事項之間取得平衡
  ↳ 問題二：程式審核（review）要交給 AI 自動化到什麼程度？越自動越快，但也可能漏掉重要問題，兩邊要抓平衡。
• 25:01 仍在思考的問題三：角色界線變模糊，如何讓每個人都有生產力；驗證是重點，要讓每個做修改的人對自己的修改有信心
  ↳ 問題三：職位界線變模糊之後，怎麼讓每個人都發揮得好？關鍵還是驗證：要讓每個動手改東西的人，都能確定自己改的沒問題。
• 25:31 也在改善所有職能的工作流程，例如和設計師合作；剛宣布了 Claude design
  ↳ 他們也在改善其他職能的工作方式，例如跟設計師怎麼合作，並提到剛宣布了 Claude design。
• 25:31 帶回家的練習：挑出最吵的工作流程，或大家不喜歡、對團隊負擔很重的流程或會議
  ↳ 帶回家的練習：挑出團隊裡最吵、最多人抱怨、最拖累大家的流程或會議。
• 25:31 例：講者曾見過一個昂貴的每週會議，大家都在看筆電，只有報告狀態時才抬頭；算一下與會人數就知道這個會很貴
  ↳ 她看過一個每週例會，大家都盯著自己的筆電，只有輪到報告進度才抬頭。把出席人數乘上開會時間，就知道這場會有多貴。
• 26:01 問自己：它還達成目的嗎？若成本很高，Claude 能幫忙嗎？並且一次改一步
  ↳ 接著問：這個會或流程還有達到目的嗎？成本這麼高，Claude 能不能接手一部分？改的時候不要一次全翻，一次動一步就好。

講者說，如果團隊的 PR cycle time 沒有下降，應該怎麼解讀？