黑先生

做專案有一個很有趣的現象，大家明明都在同一個群組，也一起開過會、需求文件有寫、Task 也開了，甚至昨天才剛同步過一次，結果今天再問一句： 「所以這件事情現在到底做到哪？」 你可能會得到三個不同答案， PM 說：「差不多了，應該快可以送測。」 RD 說：「主要功能好了，但還有兩個例外流程沒處理。」 QA 說：「我還沒拿到可以驗的版本耶。」 營運則可能以為：「不是說這週要上嗎？」 大家都沒有說謊，也都沒有偷懶，只是每個人腦中的「做到哪」，其實不是同一件事。 專案最麻煩的地方，不一定是沒有資訊 很多時候反而是： 資訊太多，但彼此沒有對齊。 例如一個功能從需求到上線，中間可能經過： 需求確認 ↓ 技術評估 ↓ 開發 ↓ 整合 ↓ 送測 ↓ Bug 修正 ↓ 複驗 ↓ 允收 ↓ 上線 但每個角色關心的節點不一樣。 對 PM 來說：RD 做完，可能已經覺得「進度差不多」。 對 RD 來說：Code 寫完、自己測過，也許就算完成。 對 QA 來說：沒有正式送測，就代表還沒開始。 對營運來說：正式站還沒看到，就等於「還沒做完」。 所以同一句： 「完成了嗎？」 其實每個人的完成定義都不一樣。 最常見的問題，是大家都在講自己的進度 這件事在跨部門特別明顯。 RD 說：「我這邊好了。」 QA 說：「但還不能測。」 PM 說：「那現在到底算好了還是沒好？」 RD 覺得自己明明已經做完。 QA 也覺得自己說得沒錯，PM 最後只能開始翻聊天紀錄。 才發現： 原來 RD 所謂的「好了」，是開發完成，但還缺一個測試環境設定，設定要另外找系統部，系統部還不知道這週要處理。 所以問題根本不是「誰沒有做」，而是： 我們把不同階段的完成，全部用同一個字在描述。 「做到哪」如果只能靠人解釋，PM 就會一直當翻譯機 這也是 PM 很常做的一件事， RD 說：「已經 Merge。」 PM 要翻譯成：「開發完成，但目前還沒有送測。」 QA 說：「還有兩個 Case Fail。」 PM 又要翻譯成：「目前正在驗收，還有兩個問題要處理，所以暫時不能上線。」 營運問：「星期五能不能上？」 PM 再把所有人的資訊重新拼一次。 有時候我會覺得，PM 很像人肉 API，不同部門講自己的語言，PM 負責把這些資訊轉成另一個人聽得懂的版本。 偶爾做當然沒問題，但如果每一次進度查詢都要靠 PM 現場翻譯，久了就會非常累。 最危險...

在職場待久了，大概都看過幾種很熟悉的老闆。 昨天才說這個專案最重要，今天一早又突然改方向；會議上才拍板，下午又開始懷疑：「我們這樣做真的對嗎？」 嘴上說要授權，最後每個細節還是要親自確認；明明請了主管，卻什麼事情都繞回自己身上。 有些老闆甚至像公司的「情緒氣象站」。 今天心情好，大家講話大聲一點沒關係；今天臉色不對，整間辦公室自動進入低氣壓。 久而久之，員工每天進公司第一件事，不一定是確認今天最重要的工作，而是先觀察： 「老闆今天心情怎麼樣？」 「這個現在能不能講？」 「他今天是不是又很焦慮？」 「昨天說的方向，今天還算數嗎？」 於是，一個很奇怪的現象就出現了。 大家看起來都很忙，實際上卻把大量力氣花在「讀老闆」。 不是讀市場，不是讀客戶，也不是讀數據，而是讀表情、讀語氣、讀空氣。 這也是我在看《高位不亂》時，最有感的一個地方。 我們很常以為企業的問題出在策略、制度、人才、執行力，於是公司一有狀況，就開始開會、改流程、訂KPI、找顧問。 但這本書提醒了一個更根本的問題： 如果站在最上面的人自己就是亂的，再好的制度，也很可能只是把混亂包裝得更精緻。 ▌老闆為什麼會亂？很多時候不是能力不夠，而是扛太久了 大部分高位者的「亂」，其實不是突然發生的。 它通常是很多東西一層一層累積出來的。 其中最常見的一種，就是高責任感。 很多企業主、高階主管之所以能走到今天，本來就是因為他們比別人更能扛。 事情來了，他先處理。 別人退了，他往前。 團隊卡住，他補位。 危機發生，他告訴自己：「現在不能倒。」 久了之後，「我來處理」幾乎變成一種反射動作。 看起來很可靠，但它也很容易掉進一個心理陷阱： 「如果我不扛，誰來扛？」 這句話剛開始可能是一種責任感，後來卻慢慢變成一種身份。 你不只是「願意負責」，而是開始相信「所有事情最後都只能靠我」。 於是更難授權、更難信任，也更難真正休息。 因為只要一放手，心裡就會不安。 「他真的做得好嗎？」 「我不看會不會出事？」 「是不是我自己來比較快？」 最後就變成一個很常見的循環： 因為不放心，所以自己做；因為什麼都自己做，所以更忙；因為太忙，所以更焦慮；因為焦慮，所以更想控制。 然後整間公司都跟著一起緊繃。 ▌忙碌，有時候也是高位者不敢停下來的方式 書裡談到「績效會上癮」，我覺得這點非常有意思。 我們很容易把忙碌理解成努力，把撐住理解成能力。 尤其是高績效...

照道理來說，一個產品如果有三個 PM，應該會比只有一個 PM 更安全。 人變多了可以分工，有人顧版本、有人顧需求、有人顧營運、有人顧外部廠商，看起來事情應該比較不容易漏掉。 但實際上，很多團隊反而會遇到另一種狀況： 人變多了，資訊也跟著分散了。 然後最可怕的事情就開始出現，每個人都以為： 「這件事應該有人在處理吧？」 三個 PM，不代表有三倍的掌握度 假設一個產品目前有三位 PM。 PM A 主要負責版本上線。 PM B 比較常接營運和客戶需求。 PM C 負責日常 Bug、優化和一些跨部門協調。 表面上看，分工很清楚，但現實通常不是這麼整齊。 營運可能直接私訊 PM A、客戶在群組裡 @ PM B、RD 發現一個風險，順手跟 PM C 說了一句、主管臨時想到一個方向，又直接找其中一位 PM 討論。 最後就會變成： 每個人手上都有一部分資訊，但是沒有人真的知道全貌。 問題通常不是「沒有人負責」 而是： 大家都負責一點。 這種狀況其實比完全沒有人負責更麻煩，因為完全沒有人負責時，至少很快就會爆出來，但「大家都有碰到一點」時，事情很容易進入一個灰色狀態。 例如： PM A 以為 PM B 已經跟營運確認需求。 PM B 以為 PM C 正在問 RD 技術可行性。 PM C 則以為 PM A 會在排版本時一起處理。 三個人都沒有真的忽略它，但三個人也都沒有把它完整接住。 直到兩週後有人問：「那個需求現在怎樣？」 大家才開始互看。 這時候最常出現的一句話就是： 「我以為他有在處理。」 多人協作最容易漏的，不是大事，而是交界處 我覺得多人 PM 最難管理的地方，不是各自負責的事情。 反而是那些： 不知道算誰的事情。 例如： 這是一個客戶需求，但又可能影響版本。 這是一個 Bug，但又需要營運確認。 這是一個版本風險，但根本原因是外部廠商。 這是一個產品優化，但需要先確認是不是共用需求。 這些事情很容易卡在角色交界，因為它不是百分之百屬於任何一個人，而只要責任沒有明確到「下一步誰要做什麼」，事情就很容易停住。 資訊透明，不等於大家都在同一個群組 很多團隊會覺得：「我們都在同一個 Slack 群、LINE 群啊，資訊應該是透明的吧？」 但其實不一定， 群組只代表： 資訊有出現過 。 不代表： 每個人都看過 。 更不代表： 每個人理解的是同一件事。 同一段對話裡： PM A 看到的...

 做 PM 或企劃久了，應該都很熟悉一種感覺。每天都很忙，訊息很多、需求很多、問題很多、會議很多、待辦也很多。 早上才剛開始工作，手上可能就已經有： 昨天還沒追完的事情 今天臨時冒出來的需求 老闆突然想到的功能 客戶希望「順便」加上的東西 RD 說可能有風險的地方 QA 說還要再確認的問題 其他部門問你什麼時候可以做 每一件看起來都不能不管，但真正讓人累的不是「事情很多」，是那些 「到底哪些事情真的需要做」 ？ 忙，不代表所有事情都同樣重要 以前有一段時間，很容易把「有人來問」理解成「這件事我要處理」。 有人來問，就記下來。 有人催，就往前排。 老闆問，就標高優先。 客戶問第二次，就覺得是不是很急。 久了之後，待辦越來越長，事情明明一直有在做，但很奇怪，整體卻沒有比較輕鬆。 每做完一件，又會有兩三件補進來，甚至有些事情做到一半，才發現這個其實好像不用做。因ˋ為對方只是想先知道可不可行，又或者這件事情另一個團隊已經在做了。 最尷尬的是那種，你花了兩天整理、評估、找人確認，最後得到一句「喔，那先不用。」 如果你常有這種現象，下次事情進來前，你先好好確認你自己，是不是直接進入了「執行模式」?略過了應該先有的「判斷模式」? PM 很重要的一個工作，其實是幫事情排隊 如果所有需求都有無限的人力、時間和預算，那專案管理大概會簡單很多。 但現實通常剛好相反。 五件事情同時來，RD 只有兩個人，QA 也有別的版本要驗，這個月還已經排了兩個 Release。 已經一堆接了一大堆問題還沒消化，還要不要繼續收下任務? 這件事情要不要做？這件事情，現在要不要做？ 有些事情值得做，但不是現在。 有些事情現在很吵，但其實不重要。 有些需求聲音很大，只是因為提出的人剛好比較積極。 有些真正重要的問題，反而沒有人一直催。 所以我後來會覺得，PM 有點像交通警察，每一台車都想先過， 但如果你真的全部一起放行，最後就是全部塞住。 事情的「聲量」和「重要性」常常不是同一件事 這件事情我自己很有感。 工作上最容易被優先處理的，通常是： 最常被問的 最常被催的 聲音最大的人提出的 現在看起來最急的 今天剛好發生的 但這不代表它一定最重要。 例如有人突然來說「這個按鈕顏色可以今天改嗎？客戶覺得不好看。」 另外一邊，其實有一個月底要上線的功能，還有一個 API 規格沒有確認。 如果單純看誰催得比較急，按...

星期一早上，電腦才剛打開，LINE 群組先跳出一個訊息：「這個活動下週有辦法上嗎？」 Slack 另外一邊有人問：「昨天正式站那個問題是不是還沒完全好？」 坐在旁邊的同事順口補了一句：「對了，老闆上禮拜有提到那個功能，好像希望這個月可以先評估一下。」 然後信箱裡還躺著一封廠商寄來的新規格。 這時候如果你打開 Jira、Trello、Asana、ClickUp，甚至是自己公司的任務系統，常常會遇到一個很尷尬的問題。 我要開什麼單？ 因為這些事情，現在其實都還不能算是一個真正的「任務」。 任務出現以前，其實已經做了很多工作 我以前一直覺得，專案管理工具最重要的事情就是把任務整理好。 誰負責、什麼時候做、做到哪裡、什麼時候完成。 後來做久了才慢慢發現，真正讓人累的，很多時候根本不是那些已經被整理好的任務。 反而是任務「還沒成立以前」的那一大段。 例如營運突然丟來一句：「最近玩家一直在問能不能增加這個功能。」 這到底是正式需求嗎？不知道。 有多少人需要？不知道。 是不是現在最重要？不知道。 技術上能不能做？也還不知道。 可是你又不能直接把它忘掉。 於是 PM 腦袋裡就多了一條暫存資料。 過幾天商務又說客戶也問到類似的東西。 這時候你才開始覺得，好像值得認真看一下。 接著你去問 RD。RD 說可以做，但如果這個月要上，可能會影響另外一個版本。 你再回頭跟營運確認優先順序。營運說：「沒有一定這個月啦，但最好不要拖太久。」 看到這裡，事情依然還沒有變成正式 Task。 但 PM 已經處理它一個禮拜了。 這就是我後來很常想到的一件事： 很多專案管理系統，是從任務成立之後才開始工作；但 PM 的工作，往往早在任務成立之前就已經開始了。 那些「先放著」的事情，最後到底都放去哪裡？ 每個人其實都有自己的方法。 有人放在記事本。有人丟自己的 Slack。有人用 Google Sheet。有人在 Trello 開一個「待確認」。 有人直接靠腦袋。還有人最乾脆：傳訊息給自己。 我自己也做過差不多的事情。因為這些東西很難分類。它可能是一個需求。也可能只是一個想法。可能過幾天就不了了之。可能突然被老闆問一句：「上次那件事後來怎樣？」 然後你才發現，糟了，它已經在聊天訊息裡沉下去三個禮拜。 所以問題其實不完全是「有沒有記錄」。而是： 這些還沒有成形的事情，我們有沒有一個地方可以暫時管理它？ 不是一收...

 最近收到一個很大的大哉問。 「這個團隊的價值在哪？你們每個人的工作定位在哪？一個月給你們討論，再來跟我報告！」 心裡瞬間其實充滿各種不可思議：這題是不是有點大？不是應該要有一群資深主管關在會議室裡兩天兩夜，桌上擺滿便利貼、咖啡跟便當，最後才有機會整理出一個答案？ 團隊成員普遍很年輕，大多七年以下的工作經歷，也幾乎沒有真正的管理經驗。所以這次並不是一群「很懂策略的人」坐下來談策略，比較像是一群平常埋頭做事的人，第一次一起把頭抬起來看看：「欸，所以我們到底在做什麼？」 ★只有兩小時，但比起直接談 KPI，我更想先讓大家看見彼此 如果一開始就直接丟一句：「來，我們訂明年的 KPI。」 我猜大家應該會瞬間安靜。 不是不會訂 KPI，而是大家連「自己的工作跟別人的工作到底怎麼串在一起」都還沒有真的攤開來看過。 所以這次沒有從數字開始，而是先從人開始。 先認識團隊裡每個人的工作，再看看彼此之間有什麼關聯，接著把利害關係人、專案、需求一個個攤出來。 桌上的便利貼越貼越多，事情也越看越複雜。 誰跟誰有關？這個需求是從哪裡來的？這個專案到底服務誰？某一件每天都在做的事情，放到整個產品裡到底扮演什麼角色？ 很多平常「大家好像都知道」的事情，真的寫出來以後，才發現其實每個人腦中的版本都不太一樣。 ★從「我每天做什麼」，一路看到「我們可以一起完成什麼」 這次的結構討論，大致上的流程： 團隊認識 → 彼此的關聯 → 利害關係人 → 專案與需求 → 業務脈絡與工作流程 → 營運／產品指標 → 產品目標與 KPI → 個人 KPI 與任務。 AI替我定義的引導流程給了更深層的結構，背後的本質是這樣： 看見自己 → 看見團隊 → 看見產品 → 看見流程 → 看見成果 → 看見責任 → 看見價值。 「團隊的價值是什麼」這種問題如果直接問，真的很難回答。即使你知道上層要看的就是KPI，還是很難具體寫出來。很容易變成一些很漂亮的句子，例如「跨部門協作」、「提升營運效率」、「創造產品價值」……每一句都對，但講完還是不知道明天到底要做什麼。 只有當每個人開始知道自己的任務，跟誰有關、影響哪一個流程、支持哪一個產品目標、誰可以支援我加速，最後連到什麼成果，「價值」這件事情才慢慢有了形狀。 ★當然，2 小時根本做不完 2個小時真的不要想太多。重點是先讓團隊建立共同概念，開始有機會一起討論：「為什麼是我...