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 幫你管理專案」。

而比較像：Evidence-based AI。

AI 可以提出建議，但必須告訴你：「我是根據什麼資料做這個判斷。」

我相信，企業真正敢使用的 AI，不只是模型有多聰明，還有它知不知道自己為什麼這樣回答？

也是我刻意把產品架構從單純的 Task Management 往更完整的 Project Operations 思考。

讓管理者看到 Portfolio 與專案健康度，

讓 PM 可以從 Roadmap 一路追到 Release、Task 與 Bug，

讓 RD / QA 的交棒、送測、驗收有完整脈絡，

讓 SOP、決策、缺陷與 Retro 不再散落，

甚至讓 Slack / LINE 中的重要討論，可以被整理成真正的工作紀錄。

所有專案的資訊都可以被累積成經驗知識庫，搭起AI回答的紮實基礎。

建立 Task，一點都不困難，但要如何把獨立事件變脈絡經驗，才是每個Task背後的價值所在。

資訊是不是連得起來。

責任是不是看得見。

決策是不是找得回來。

經驗是不是留得下來。

最後形成了三個我自己很喜歡的關鍵字：

Visibility.看得見全局。
Traceability.追得回脈絡。
Memory.留下組織記憶。

讓每一次執行，都不只是完成一次工作，而是成為下一次更好決策的基礎。

你現在公司裡的「專案記憶」，到底存在哪裡？

系統裡？

文件裡？

Slack 裡？

還是某幾個資深同事的腦袋裡？

https://pmory.com/