專案管理軟體救不了你

當我在一家寵物玩具兼科技公司擔任文案時，我們使用 Airtable 和 Basecamp 來組織工作流程。到了下一份工作，行銷人員要求我們學習 Asana（「跟 Airtable 一樣但好用得多」），但產品團隊則透過 Jira 推動他們的工作和衝刺（sprints）。我在還沒學會 Jira 之前就被裁員了，而下一份工作他們對 Airtable 推崇備至——呼，這我早就懂了。但顯然效率仍在流失，而 Airtable 成了替罪羔羊。就在我離開那份工作時，我聽見有人提到一個新程式 Trello 將取代 Airtable，並為我們「改變一切」。幾年後我以約聘人員的身分回到那裡，發現一切都沒有改變。公司已經拋棄了 Trello，現在正迷戀一個叫 Monday.com 的東西。它同樣承諾會帶來巨大的變革。

如果你在現代白領職場中擔任「個人貢獻者」（individual contributor）——工程師、文案、設計師、數據分析師、行銷人員——你可能都遇過這些專案管理軟體（PM 軟體）企業。你的入職培訓會包含來自 Smartsheet、Notion、Udemy、ClickUp、Projectworks、Wrike 或 Height 等平台的協作邀請。名單似乎永無止境，而且還在增加。目前有超過一百種專有應用程式和規劃工具正在爭奪企業訂單，全都承諾能提高生產力、實現無縫工作流以及無與倫比的敏捷性。如果你像我一樣，在幾年內於不同工作和專案團隊之間跳槽，你不得不接受一個事實：在任何大型勞動力群體中，誤解和混亂都是必然的。但在這個數位化程度日益提高、遠距辦公日益普及的時代，你可能仍會幻想真的會出現一個「殺手級應用程式」獲得最終勝利。然而，這些 PM 軟體服務沒有一個能讓工作真正運轉起來。這些缺陷的關鍵在於職場效率本身的歷史——要從最初的商業顧問說起。

在第二次工業革命之前，基本上不存在所謂的生產力（Productivity 這個詞在 1900 年之前基本不存在）。隨著工廠變得更加複雜，工資勞動者激增，資本的目標變成了確保勞動效率。如果將你對 Trello 通知過多的職場煩惱，與 1900 年代製造車床的機械師的處境聯繫起來會讓你感到暈眩，你並不孤單。但「確保工作效率」的概念，與「被僱用」的概念一樣古老。

於是，1900 年代開啟了我們所熟知的專案管理。根據弗雷德里克·泰勒（Frederic Taylor）的《科學管理原理》，管理工人的目標「應該是為雇主爭取最大的繁榮，同時也為每位員工爭取最大的繁榮」。就在機械工程師泰勒從工廠基層晉升為美國首批職場「抓耙子」（或稱顧問）的同時，另一位工程師亨利·甘特（Henry Gantt）推廣並規範了甘特圖的基礎。這是一種簡單的條形圖，將專案進度轉化為 X 軸和 Y 軸上的一組線條，時間從左向右移動。甘特圖也被稱為「瀑布式」方法，它為任務及其依賴關係和偶發事件創造了一種視覺隱喻，讓你能夠根據任務相對於整體專案及前置任務的開始與完成時間，來審視每個獨立任務。

你是一位正在等待照片和文案到位才能設計橫幅廣告的平面設計師嗎？在許多現代 PM 軟體中，你可以看到這些先決條件，就像 Monday.com、Wrike、Microsoft Project 和 ClickUp 提供的現代甘特圖一樣。Asana 也有甘特圖模板。

泰勒和甘特當時正在研究如何管理工廠機械師的工作，這些人的工作就像露西在巧克力工廠裡一樣，通常涉及單一的可重複任務。但資訊工作者的增長意味著出現了更多的通才、顧問、分析師和經理——以及更多的層級。例如，在建築工程中，只要鋼筋安裝好了，混凝土團隊就可以澆築地基。同樣地，工廠工人不需要看甘特圖就能製造出零件，他們只需要知道該做什麼。他們不需要參與圖表的創建，也不需要與圖表互動。在宏偉的胡佛水壩工程中（其施工是透過甘特圖組織的），澆築混凝土的工人不需要在自我管理任務的同時還去查看甘特圖。在資訊工作時代之前，執行任務的工人（個人貢獻者）不需要自我管理；他們是被管理者。

另一方面，資訊工作更容易使用甘特開發的方法來管理。在資訊勞動力中，存在著無數的反饋向量、辯論、利益相關者審批和修訂，更不用說無窮無盡的接觸點。（如果你覺得你的公司充斥著經理，你並不孤單。）模仿過去那種設置專案骨牌方式的軟體，正是我們職場挫折的根源，也是那些最終只會製造更多工作的「全能解決方案」的開端。

你知道曼哈頓計劃也是專案管理輝煌歷史的一部分嗎？日益複雜的問題需要日益優雅的解決方案，如果沒有高效組織的平行工作路徑，你不可能在幾年內將一個想法變成原子彈。曼哈頓計劃中一些工程師的觀察導致了 1950 年代後期「關鍵路徑法」（Critical Path Method）的誕生，這是一種算法模型，可以為開發過程或專案的所有部分創建一個微型地圖（有點像決策樹）。每個節點和路徑都被賦予時間值，由電腦計算出在完成所有必要任務的情況下，到達終點的最快（或最便宜）路徑。將關鍵路徑法與美國海軍同時開發的類似系統 PERT 法相結合，專案管理便進入了電腦時代。大約在同一時間，豐田汽車開發了看板（Kanban）系統，以從精實生產中榨取更多效率。作為一種手動的卡片和信號系統，看板也獲得了普及。

到了軟體開發成為一個更正式的管理領域時（1980 年代），我們有了弗雷德·布魯克斯（Fred Brooks）的「法則」，該法則指出，向延誤的程式開發專案增加人力只會使其進一步減慢。這個想法背後的真相——即「導入」複雜任務所耗費的時間比節省的時間更多——是導致軟體開發人員轉向「Scrum」工作的幾個因素之一。Scrum 是一種在程式編寫等開放式工作專案中更靈活的溝通方式。Scrum 可能比關鍵路徑、看板或任何前輩都更具革命性，因為它提供了一種符合具有短期目標的小型團隊功能的格式。Scrum 幫助程式員快速完成工作，然後在下一個專案中如法炮製。

你可能會看著關鍵路徑圖並心想：嘿，這聽起來很像產品路線圖（Product Road Map，一種看起來頗具用途的組合，結合了甘特圖的瀑布部分和關鍵路徑的依賴路徑佈局）。或者你可能會考慮看板，並心想：好吧，我可以習慣這個。但請注意，Asana 正在廣告中宣傳它精通看板、關鍵路徑和 Scrum，以及一個較新的術語：敏捷（Agile）。PM 軟體把自己包裝得像 1800 年代末的弗雷德里克·泰勒，穿梭於各地向工廠主保證他的系統同樣適用於木工和工業洗衣。不同之處在於，泰勒提供的是一種一體適用的解決方案；而 PM 軟體則推銷自己是所有系統的通才，且樣樣精通。

除了過度承諾之外，PM 軟體的商業模式還要求程式像泰勒那樣運作，但要有持續的回報。現代科技商業模式建立在預期的經常性收入之上，因此這些程式必須利用科技銷售團隊和軟體即服務（SaaS）模式來鎖定長期客戶，並保持可預測的資金流入。公司可能承諾解決工作流問題，但他們賣的是服務。

Wrike 成立於 2006 年，Asana 成立於 2008 年，Trello 成立於 2011 年，Monday.com 和 Airtable 則成立於 2012 年。在行銷軍備競賽中，每家公司都在網路上充斥著自己的內容網站（Asana 甚至有自己的假報紙）、付費的虛假評論、推廣的 Quora 答案，並聲稱只有他們擁有正確的軟體來組織你的整個團隊。為了哪怕只是稍微實現這個承諾，軟體必須對各種規模、風格和類型的工作團隊都有用。

Wrike 可以做甘特圖或類似試算表的小東西。Asana 可以做路線圖、瀑布圖和看板。但在底層，這些程式究竟在做什麼？在遊戲引擎中，世界是被建模的——重力將物體拉向地面，投射物有特定的行為模式，你的角色在必須丟棄物品前只能攜帶一定數量。PM 軟體承諾提供強大的系統來解決複雜問題，但其解決方案通常只是在關聯式（連結）資料庫之上套了一個淺薄的使用者介面（UI）。這些程式通常對團隊「不起作用」，因為它們不是對簡單任務來說太複雜，就是對複雜任務來說不夠強大，而且關聯式資料庫並不是解決職場挫折這個「狼人」的銀彈。

由於軟體即服務供應商的目標是銷售和維持訂閱，這些公司必須不斷增加個別功能，以應對任何可能出現的使用案例。但當你的軟體建立在資料庫思維之上時，新功能往往只是增加了複雜性。將關聯式資料庫思維應用於「我需要修一張寵物玩具的照片」這樣的任務，會造成不必要的複雜，除非該軟體真正易於使用，並模仿使用者熟悉的軟體。

在很長一段時間裡，許多這類程式（以 Asana 為例）都沒有撤銷（undo）按鈕。一個稱職但不太懂技術的修圖師可能會進入 Asana 的「卡片」，不小心刪除了任務或其歷史記錄，在無意中搞砸了一切。

當一般使用者擁有新增、刪除和移除任務的普遍權限時，這就是個問題，而這是 Asana 的某人所做的（或未做的）選擇。當然，你不應該在工作中刪除檔案，但建立在資料庫條目上的軟體，讓那些大腦習慣於現代使用者體驗（UX）的人很難調整。

像 PM 軟體這種圍繞程式員思維構建的程式，揭示了電腦運作方式與外行人對其運作理解之間的巨大鴻溝。在 90 年代中期，你可能會合理地期望擁有電腦的人理解檔案樹或資料庫，因為當時的 UX 尚未發展到如今手機和應用程式那種無縫的水平。Gmail 現在做得太好了，以至於進入職場的 Z 世代可能根本無法以檔案樹或關聯式資料庫的方式思考，他們可能也無法排除 PM 軟體中那個奇怪的小故障。如果我們觀察在核心仍是資料庫的系統中加入資源回收筒或撤銷按鈕，就會發現使用者專業知識與開發者專業知識之間的差距正在擴大，因為像 Gmail 的 UX 持續巧妙地掩蓋了電腦上實際發生的電腦運作。

撤銷按鈕最終出現了，但它帶有一個 20 秒的窗口，就像 Gmail 一樣。不夠快？太遺憾了。這項功能很可能只是將你的操作存儲在本地內存中，並將其覆蓋在界面上，因此你的操作與程式伺服器接收操作之間的時間，就是你撤銷的時間。從伺服器的角度來看，你並不是在撤銷，而只是「沒做」。

之所以有這麼多這類公司卻沒有一個殺手級應用程式，是因為籌集資金並在資料庫之上構建新軟體並不困難。Jira 在你（使用者）和資料庫之間放置了一個基於 Java 的網頁應用程式。你訪問和操作資料庫的方式被佈置成一個實際、可靠的工作流管理系統，即前述的流程圖和看板。但我們大多數人不知道如何操作資料庫。如果出了問題，我們不會突然開始像程式員一樣思考。

我們也不全是經理，也不全是用決策樹思考。那種認為管理是一項超越個人學科的技能的「MBA 式思維」，是 PM 軟體推銷的一部分——銷售這些服務的人聲稱，如果他們的軟體對他們的開發人員有效，那對每個人都一定有好處。堅持使用自己開發的產品（也稱為「吃自家狗食」）是 Asana 等公司的驕傲，但對這位評論者來說，這並不像他們想像中那樣具有說服力。

資訊工作越來越要求員工處理更多的複雜性——但我們不應該為了僅僅完成工作，而在套用程式員思維的不完美系統中自我管理生產力。

因為組織專案和工作量沒有唯一的方法，沒有任何軟體能成為現代工人的全部。你可能會發現自己真的很喜歡其中一個程式——那很好！但像 Jira 這樣的軟體，其效用在於真正的程式員。較小的、針對特定職業的軟體（如律師使用的 Clio）更有可能解決特定類型工作的問題，而不是強迫工人在經過 SEO 優化的清單文章中苦苦搜尋，試圖找到一組可以勉強適用於其團隊的功能。

今天你工作的一大部分可能僅僅是解決和重新配置辦公室中自然的熵增，但溝通不良的截止日期無論是寫在索引卡上、發送在電子郵件中，還是附加在 Asana 的「任務」中，都依然是溝通不良。如果你在數位看板上放了資訊不足的東西，它並不會比你創建任務之前更有用。職場軟體正在將管理專案的工作轉嫁給無數個微型專案，每個專案的效用僅取決於個別使用者的技能和效用。我們不能指望每個使用者既是執行者又是自我管理者，尤其是在市場上工具並不完美的情況下。當我們把 Trello、Asana、Wrike、Airtable 以及無數個本質上相同的專案管理失敗複製品排在一起時，它們之間的差異遠不如最終結果重要——套用安娜·卡列尼娜關於家庭的名言：每個專案管理 App 都承諾同樣的幸福，但每個 App 都以自己的方式創造了不快樂的使用者。