發表文章

[PMORY - 3] 同一個產品有三個 PM，為什麼反而更容易漏事情？

-
圖片
照道理來說，一個產品如果有三個 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 看到的...
張貼留言
閱讀完整內容

[PMORY - 2] 每天事情很多，但到底有哪些事真的需要做？

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

[PMORY - 1]專案管理最累的，其實是那些根本還不能叫「任務」的事

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

PMORY = PMO + Memory

-
圖片
 最近從獨立企劃到開發完成了一套 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產圖 ...
張貼留言
閱讀完整內容