專案管理工具可以自己做嗎？4 種做法與各自的限制
關於本連載
「專案管理工具可以自己做嗎？」是寫給打算用試算表、無程式碼工具或 AI 自己做工具的讀者的連載，共 6 篇。可以從任何一篇開始閱讀。
- 專案管理工具可以自己做嗎？本文
- 讓 AI 做一個議題管理 App 試試看即將推出
- 從「能運作」到「能使用」的距離即將推出
- 做出來之後才是真正的開始即將推出
- 自己做的真正成本即將推出
- 該自己做的人，該買現成的人即將推出
按月付費的工具，人數每多一次，帳單就漲一次。功能很多，真正用到的卻只有一小部分。而且總覺得和自己團隊的工作方式不太合。
於是試著請 AI「做一個議題管理 App」，幾分鐘後就收到一段看起來有模有樣的畫面程式碼。
「這樣的話，是不是我們自己做反而比較快？」
隨著 AI 出現，自己做專案管理工具這個選項變得近在眼前。
本文比較自己做的 4 種方法，整理各自的工作量與限制。先說結論：專案管理工具是做得出來的。問題在於「幾個人用、用到什麼時候、由誰來修」。
註：本文由 GeckoFlag 的開發者撰寫。GeckoFlag 是開發者把自己做來用的議題管理工具做成了產品。在本連載中，我們站在自己做過的立場，把自己做的好處與難處都寫出來。
為什麼會想自己做
想自己做的契機因人而異。先依理由逐一來看，自己做是否真的能解決問題。
| 想自己做的理由 | 自己做能解決嗎 |
|---|---|
| 月費太貴 | 把做的時間和修的時間換算成費用，未必比較便宜（第5篇會試算） |
| 功能太多，用不來 | 也有設定項目很少的現成工具。不自己做也可能解決 |
| 不符合我們的工作流程 | 這是自己做最有效的理由。流程越特殊，自己做的價值越高 |
| 想把資料放在自己這邊 | 也有安裝在自己伺服器上的現成工具 |
| 做東西本身很有趣，想學習 | 這就是自己做的充分理由 |
如果理由是「太貴」「太多」，換一款現成工具或許就能解決。反過來，如果是「流程特殊，怎麼都不合」或「做東西本身就是目的」，就適合自己做。
理由清楚了，在接下來介紹的方法中做選擇時也比較不會猶豫。
做法有 4 種
專案管理工具的做法，大致可以分成以下 4 種。
| 做法 | 需要什麼 | 適合的規模 | 主要限制 |
|---|---|---|---|
| 試算表 | 試算表的基本操作 | 1 人到幾個人，短期 | 人數和議題一多就會亂 |
| 無程式碼工具 | 了解服務的用法 | 幾個人到小團隊 | 費用容易隨人數增加。受服務規格變更影響 |
| 自己寫程式 | 程式設計的知識與時間 | 取決於怎麼做 | 做和修都要花時間 |
| 讓 AI 來做 | 懂得怎麼對 AI 下指示 | 取決於怎麼做 | 手上會多出一堆自己看不懂的程式碼 |
無論哪種方法，都能做出「登錄議題、設定負責人和截止日、變更狀態」這個基本形態。差別出現在使用的人變多的時候，以及做完之後需要修改的時候。下面依序來看。
用試算表來做
最簡單的是用 Excel 或 Google 試算表來做。最小的配置，有下面 4 欄就夠了。
- 議題：每列寫一件要做的事
- 負責人：由誰來做
- 截止日：什麼時候之前做完
- 狀態：用下拉選單選擇未開始、進行中、已完成等
再設定條件式格式設定，讓超過截止日的列變色，延誤也就一目了然。1 人到幾個人、幾個月就能結束的案子，這樣往往就足以運作。
不過，人數和議題一多，表格就會一點一點亂掉。像是沒有地方記錄來龍去脈，寫上負責人也不會通知到本人。
相關用試算表管理時的極限，在入門連載「第一次用專案管理工具」第2篇「Excel 管理表在哪裡會碰到極限？」中有詳細說明
用無程式碼工具來做
用 Notion、Airtable 這類無程式碼工具，可以建立資料庫，並以清單、看板、行事曆等形式顯示。不用寫程式，也能組出一套議題管理的機制。
它的優勢是可以自由新增欄位，外觀也容易調整得整齊好看。可以一邊嘗試，一邊做出符合自己工作的形態。
另一方面，下面幾點需要注意。
- 費用容易隨人數增加：很多服務依使用人數計費，最後的花費可能和現成工具差不多。
- 只有做的人懂結構：容易變成只有做的人才知道哪個欄位和哪裡相連的狀態。
- 受服務方的情況左右：服務方一旦變更規格或調整價格，影響會直接落到自己身上。
自己寫程式來做
如果會寫程式，也可以從零開始做。自由度最高，可以和自己的工作完全貼合，也是很好的學習題材。
不過，花時間的往往不是議題清單、登錄畫面這些看得見的部分，而是畫面上看不見的部分。
- 登入與密碼管理
- 誰能看到哪些內容、能操作到什麼程度的權限
- 資料的儲存，以及資料遺失時的因應準備
此外，做完之後的程式錯誤修正、伺服器和程式語言的版本更新因應，也都要自己來。做完之後持續修改的時間比做的時間還長，這種情況並不少見。
讓 AI 來做
現在最受關注的，是請 AI 寫程式碼的方法。只要說一句「做一個能登錄議題、能設定負責人、截止日和狀態的 App」，有時幾個小時就能做出在畫面上動得起來的東西。
不會寫程式也能做出成形的東西，這是很大的變化。不過，有一點需要注意。
那就是：如果自己看不懂做出來的程式碼，出了錯誤就修不了。再請 AI 修一次也許能修好，但也可能弄壞別的地方。要判斷到底哪裡壞了，終究還是需要讀程式碼的能力。
另外，AI 寫出的程式碼在安全性與權利方面如何處理，取決於所用服務的條款，以及做出來的東西怎麼使用。如果用於工作，請事先確認所用 AI 服務的條款。
連載實際用 AI 能做到什麼程度，將在第2篇「讓 AI 做一個議題管理 App 試試看」中實驗（即將推出）
開發者的情況
GeckoFlag 最初也是在客戶專案的工作現場，想要一個符合自己工作方式的工具，於是開始動手做的。做它的是身兼網頁設計師與工程師的開發者本人，使用的是 PHP 框架 CakePHP。
製作過程中大量運用了 AI（Claude），從提出實作方法的建議到測試都有。即使如此，從最初做出「能運作的東西」，到變成好幾個人每天都能使用的狀態，花的時間比預想的長得多。這段期間發生了什麼，會在本連載中一點一點寫出來。
選哪種，取決於「幾個人、用多久、誰來修」
4 種做法選哪種，與其說取決於工具的功能，不如說取決於使用的情況。用「幾個人」「用多久」「誰來修」這 3 點來整理，大致如下。
| 幾個人 | 用多久 | 誰來修 | 適合的選擇 |
|---|---|---|---|
| 1 人到幾個人 | 幾個月 | 使用者本人 | 用試算表也能應付 |
| 小團隊 | 1 年以上 | 做的人會一直都在 | 無程式碼，或用 AI 自己做 |
| 外部人員也會用 | 好幾年 | 做的人可能會離開 | 很值得考慮現成工具 |
另外，如果工作流程很特殊，現成工具怎麼都不合，那麼不論人數和時間長短，都值得考慮自己做（自己寫程式，或讓 AI 來做）。
這張表只是參考。即使是 1 個人或小團隊，用工具也會有輕鬆很多的時候。
特別希望留意的是最後一列。外部人員會用、要用好幾年、做的人可能因調職或離職而離開。只要符合其中任何一項，開始動手之前，請讀一讀第3篇之後的內容。
「能運作」與「能使用」之間隔著什麼
一旦開始自己做，很多人都會在中途發現一件事：「能運作」和「好幾個人能長期使用」之間，隔著很大的距離。
例如下面這些，都是在做最初幾個畫面時不容易想到的項目。
- 每位成員能看到的範圍：只想讓外部人員看到這一個案子
- 忘記密碼時的重設：希望本人能透過電子郵件自行重設
- 通知信：被指派為負責人、有人留言時，希望能收到通知
- 資料備份：即使伺服器壞了，也不想失去議題的紀錄
這些都會在使用的人一多時立刻變得必要。而且每做一項，要確認的和要修改的就會增加一些。
在開始動手之前了解這些項目，對所需時間的估算會大不相同。
連載自己做之後才會發現的項目，將在第3篇「從『能運作』到『能使用』的距離」中整理成檢查清單（即將推出）
總結
- 專案管理工具，用試算表、無程式碼、自己寫程式、讓 AI 來做這 4 種方法中的任何一種都做得出來
- 自己做最有效的情況，是工作流程特殊、現成工具不合時，以及做東西本身就是目的時
- 選哪種，取決於「幾個人用、用到什麼時候、由誰來修」
- 「能運作」和「好幾個人能長期使用」之間，隔著很大的距離
自己做絕不是魯莽的選擇。只是在動手之前，把做完之後的事也考慮進去，就能少走冤枉路。
下一篇，我們會實際讓 AI 做一個議題管理 App，看看能做到什麼程度。在連載的最後，我們將以自己做過工具的開發者身分，寫出自己做和現成工具該怎麼選的結論。
在工作中用上 AI 之後，任務管理本身會有什麼樣的變化，在連載「與 AI 協作的團隊任務管理」第1篇「開始用 AI 之後，還需要任務管理工具嗎？」中有介紹。