黑先生

星期一早上，電腦才剛打開，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個小時真的不要想太多。重點是先讓團隊建立共同概念，開始有機會一起討論：「為什麼是我...

 最近從獨立企劃到開發完成了一套 PMO 專案管理系統，我一直在思考也一直想解決的問題： 為什麼公司做了這麼多專案，下一個專案開始時，卻常常還是像第一次做？ Roadmap 有了。 Task 有了。 Bug tracker 有了。 文件也有了。 甚至每個專案結束後，大家還會開 Retro、寫 Lessons Learned。 但幾個月後遇到類似問題時，團隊還是會問： 「上次我們怎麼處理的？」 「當初為什麼做這個決定？」 「這個 Bug 以前是不是發生過？」 「那次 Release 出問題的真正原因是什麼？」 然後開始翻 Slack、LINE、Email、Notion、Jira、Google Drive、Excel…… 最後問那個「還記得的人」。 我們真的缺的是另一套 Project Management Tool 嗎？ 還是我們真正缺少的，是一套能讓組織「記得自己做過什麼」的系統？ 這也是在設計 PMORY 時，最核心的產品主軸。 PMORY = PMO + Memory 。 我想做的，不只是管理專案。而是讓一個專案從： Roadmap → Release → Task → Bug → Decision → SOP → Retro 一路留下可以被追溯的脈絡。 因為我認為：專案真正有價值的，不只是最後有沒有上線。 更重要的是： 我們做過什麼判斷？ 什麼地方曾經卡住？ 哪些事情造成重作？ 哪一個決策後來證明是對的？ 哪一個問題，下次其實可以提前避免？ 這些東西，才是組織真正的 Memory。 這個想法讓我重新定義 AI 在專案管理產品裡的角色。 現在很多產品的 AI 功能，很容易變成： 「幫我摘要。」 「幫我寫報告。」 「幫我產生 Task。」 這些都有價值。但我更感興趣的是另一件事： AI 能不能不是替 PM 猜答案，而是幫 PM 找回組織曾經累積過的答案？ 例如， 今天一個 Release 又開始延期。AI 不只是說：建議重新安排資源。 而是可以告訴你： 三個月前另一個專案曾經發生相似情況。當時卡在 QA handoff。後來團隊調整了驗收流程。 這裡是當時的事件紀錄、Retro 與處理結果。 然後再讓人決定： 這次的情境是可以直接沿用？ 需要調整？ 還是其實完全不同？ 所以我在產品裡對 AI 的定位，不是「AI 幫你管理專案」。 而比較像： Eviden...

引導不只出現在外部工作坊教學討論，更能夠在公司內部專案落地運用! 當你剛進入新環境，對於公司內的所有文化、文件、流程還不熟悉， 這時身為專案負責人的你，必須將專案的每個上線合作、時程、細節敲定時， 你可以嘗試以下兩種不同樣貌的引導： ◎ 你有經驗有想法也清楚知道流程，但對於其他單位要如何開始界接合作，需要雙方更進一步的資訊，你可以這樣做。 ▲情境一：不太需要團體對話的引導 引導者主持，負責先把專案全貌視覺化後，再透過提問、摘要並寫下貼回資訊牆， 讓參與者共同參與一目瞭然整體專案狀況。 例如， 你負責的專案開始要對接進測試流程，但才剛到公司，完全不了解測試需要的流程與文件。 這時先將你腦中的上線計畫與QA環節放在一起，不要用簡報投影討論， 而是盡可能將所有資訊視覺化，每個關鍵點流程都是一張便利貼， 依照時間軸邊互動邊貼上資訊牆。 這樣的視覺引導過程，自然會將雙方的疑慮一一釐清。 ◎你雖然可以直接敲定上線計畫的所有時程，但你更希望開發團隊能夠自己討論自行承諾每個上線的關鍵點。 ▲情境二：需要團體對話的引導 引導者負責對話的架構和目的，讓參與者能夠在有結構的場域中有效對話。 給出會議討論需要的四種角色、資源卡、任務卡、風險卡、利害關係人， 參與者沉浸在討論的同時，很自然地用運手邊的工具將目的產出。 例如， 你負責專案最終的上線日控管，現在要將上線前的技術準備時程都敲定， 但剛到公司有很多細節還沒掌握的情況下，將最後需要的產出結論轉乘討論框架， 讓團隊自己討論、自行承諾會是更好的方式。 以上，視覺化加結構對話的好處是， 以往要花4-5個小時複雜且空泛的討論，現在可在1.5個小時內產生共識， 並且同時完成印象深刻的手作會議紀錄!!!

圖片是我管理專案用的流程，像這種詳細的介紹圖片如何產生? 一個字一個字打上讓AI產生? 讓AI產生是對了，但不是自己敲上所有細節。 使用AI大多時候，逆著會比順著更有效率， 像這張圖就是逆向生成圖，而不是寫詳細功能順著產生。 我的小專案控管是在google sheet上， 裡面的頁籤有每個專案流程需要資料頁內容。 每個分頁內容雖然看起來各自獨立但其實是有關連，而AI 擅長將大量的資料摘要、分類，進一步資料彼此關聯起來。 我們要做的就是在google sheet右上角"向Gemini提問"，讓AI幫我們快速有效梳理整理所有分頁的關聯性。 方式不複雜，只要在Google sheet中對著Gemini提問： """請提取這份文件的重點 以系統流程圖的方式描述。""" 這樣就會獲得AI梳理後描述： """「這份「上線進度表」電子表格是一份詳盡的專案管理與維運手冊，主要用於追蹤 2025 年的開發進度、任務分配、異常通報機制及產品維護流程。""" 以下是該文件的重點摘要，並以系統流程圖的邏輯進行描述： """核心內容摘要 進度管理：透過「2025上線進度」、「甘特圖」與「年度排程」追蹤從需求提出到正式上線的完整週期.... .....」""" 接下來就是把這段系統作業流程的文字描述變成圖。選對對的模型很重要，目前試起來，ChatGPT對於文字理解和生成圖片還是比較高些，效果也會很好。 向ChatGPT提問： """將以下系統流程圖的描述，生成一張圖片 # 系統流程描述圖 [貼上Gemini AI產生的描述...]""" 等個60秒，就會獲得像這樣的流程圖囉。 ⭐️大致流程： 1. 用原本的專案計畫google sheet 2. 打開google sheet的google gemini，請它理解與所有分頁的內容 """提取這份文件的重點 以系統流程圖的方式描述""" 3. 將google sheet gemini產生的promt 丟給ChatGPT產圖 ...

  今天有位專案管理師PM丟了一些職場上常見的問題來請教， 這些問題真的是經典，很適合拿來做交流分享~ 1. 工程師「知情不報」 「有些工程師在現場測試時明明感覺會出包，卻當下不講等事後才爆出來。我很想糾正這種行為，但又怕動作太大直接去跟老闆講，會導致內部爭吵。這種時候會建議怎麼跟工程師談，讓他們願意及時吐真言，而不是把風險藏起來？ 2. 成員「頻繁斷線、講了就忘」 成員進度很慢，而且狀態很不穩定。不管是寫在群組、釘在進度表，甚至我親自叮嚀他還是會忘記。對這種『記性不太好』或是『不在頻率上』的同事想請問你之前都會怎麼處理？ 3. 關於「資訊不明確、工程師很焦慮」 最近有兩案時間一直變，也還在等上面的確定消息。結果工程師不知道為甚麼比我還焦慮，一直追著我問何時進場何時出差如何前往..問題，雖然當下有請他們一樣先把這兩案要出的軟硬體優先處理掉以防萬一，但還是搞得我壓力也很大，甚至也有點被他們的情緒影響了。在這種我也沒辦法給答案的情況下，我該怎麼跟他們溝通，才能讓大家先冷靜下來工作？ 4. 工程師用『你不懂技術』擋掉需求 「最後是溝通落差的問題，我要求系統錯誤訊息要讓客戶看得懂，結果工程師直接彈出一大串程式碼（Debug Message），說這樣才方便。我反映這件事，他們卻說是我不懂程式，然後就放著不處理。遇到這種拿技術當擋箭牌的情況，會怎麼拿回主導權，讓他們願意配合優化呢？」 如果你就是這團隊的PM，你打算怎麼做來解決問題呢? 以下是過往的經驗： 1. 工程師「知情不報」 這篇文章可以先參考 https://www.managertoday.com.tw/articles/view/66569 這種缺乏安全感的環境，不是一兩天或有立即解藥能解決的問題 如果團隊平常就沒有對話，都是交辦，自然容易養成這種環境! 雖然不能馬上獲得改善，但可以慢慢培養。 ◎ 立解症狀解法： "現場測試"完回到公司後，固定開個１０－１５分鐘的小會議， 說說還有哪些風險沒考慮到？有哪些之後要多加注意的地方？ ◎長期根本解法： 利用固定周期(兩週一次)的"回顧會議"，輕鬆自在且自然的氛圍 檢視這兩周發生了哪些事情，下次遇到可以怎麼解決 然後偶爾帶點生活上的閒聊建立信任感，再慢慢累積建立可以講真話的文化 2. 成員「頻繁斷線、講了就忘」 設定容錯的邊界值。 大家...