---

在 Blue，我們花了很多時間思考項目管理。這對我們的工作以及我們交付給客戶的成功至關重要。如果沒有對項目管理的深入理解，我們怎麼可能建立 項目管理軟體？

每當我們開始一個新項目，無論是新功能、後端工程升級、行銷活動還是招聘推廣，我們都會先分析項目本身及其運行方式。因此，憑藉豐富的經驗和見解，我們決定開始正式化一些項目管理的基本原則。

雖然使用更非正式的個人直覺來導航項目是常見（且可接受）的做法，但這並不是一種可擴展的方法——而且並非沒有缺點。

項目

讓我們先定義什麼是項目。

項目是一個有明確開始和結束的臨時努力，旨在產出獨特的產品、服務或結果。這是大多數人對項目的看法。但還有一些其他更正式的項目特性值得考慮：

• 項目有有限的資源（時間、金錢、人員）；
• 項目是為了實現特定目標而進行的；
• 項目有明確的範圍（因此有明確的事情不會做）；
• 項目受到不確定性和風險的影響。

現在我們對項目有了更好的理解，我們可以進入基本原則——項目成功所需的核心構建塊。這些包括：

• 一位項目經理；
• 一個目標；
• 一個待完成事項清單——這通常稱為計劃；
• 指定某人負責每一項工作；
• 每項工作的時間表；
• 一個溝通策略，定期更新和會議的節奏，以及信息存儲計劃。

我們發現這些事項通常適用於所有項目，如果做得好，可以消除項目中99%的問題。

項目經理

項目所需的第一件事是有一個負責成功完成它的人。這可能看起來是一個顯而易見的陳述，但值得強調。

這個人 就是 項目經理。他們負責確保項目的目標得以實現，並且項目按時、在預算內、達到所需的質量標準完成。通常，我們中的許多人在沒有受過專業項目管理培訓的情況下，成為了事實上的項目經理。如果你也是這樣，那你運氣好，我們為此寫了一本指南！

值得考慮項目經理應該做什麼和不應該做什麼。畢竟，他們承擔著很大的責任，必須認真對待這份責任。

項目管理通常會佔用項目預算的一大部分——通常在2%到10%之間，具體取決於項目的風險程度。風險越高，項目管理的需求就越大，以確保事情保持在正軌上，項目不會失敗。

作為一名經理，項目經理應該專注於如何通過其他人來實現目標。他們需要確保項目團隊有效運作，並且和諧地朝著共同目標努力。項目經理是那個需要確保每個人都在做好自己的工作，並且做得好的那個人。

項目經理還負責與項目的利益相關者溝通，並保持他們對項目進展的更新。

就像我們在 領導者的優先級 中討論的那樣，項目經理應該不斷專注於約束點。如果讓利益相關者批准某件事花費的時間過長，那麼他們需要高度專注於獲得該承諾。他們需要不斷問自己：“什麼阻礙了我們完成項目目標，我該如何儘快解決這個問題？”

在某種程度上，項目管理與溝通同義。詳細記錄想法對於項目經理來說是一項寶貴的技能，因為這大大減少了所需的會議次數——團隊成員可以自助獲取所需的信息。

一個目標

項目的另一個核心構建塊是項目需要一個明確且可衡量的目標。項目完成後，查看結果應該是微不足道的，並知道項目是否達成了其目標或失敗。

目標應該公佈，以便每位團隊成員都能訪問。這很重要，因為這意味著決策可以分散和去中心化，因為每位團隊成員可以查看他們小部分的工作並將其與項目的整體目標聯繫起來。然後，如果出現不一致，他們可以提出問題，或者在他們小範圍內調整方法，以最好地服務於更大的目標。

項目的目標應該是SMART的：

• 具體。 項目通常有聽起來更像使命或願景聲明的高層次目標。一個糟糕的目標例子是“改善客戶支持”。這不夠具體。像“我們的目標是在第四季度結束前，90%的客戶在30分鐘內回覆電子郵件”這樣的說法要具體得多。
• 可衡量。 當你設定具體目標時，通常同時解決了衡量問題，因為這樣就容易評估目標是否已達成。
• 可實現。 目標只有在可以實現的情況下才有意義。但這不是創建簡單目標的藉口。一個好的目標應該有一定的挑戰性——足夠具挑戰性以便能夠達成，但又不至於不可能或極不可能。
• 相關。 這聽起來可能非常自明，但你會驚訝於這種情況發生的頻率。項目目標應該能夠通過執行項目來實現。你不能設定那些無法由執行具體項目工作的項目團隊控制的目標。例如，在一個公司的製造部門工作的團隊可能無法影響客戶的店內購物體驗。
• 有時間限制。 好的目標需要有某種時間限制。這可能很困難，尤其是在現代軟體項目中，待完成的工作並不總是明確的，因此時間表可能非常難以估算。有時你可能會偏差很多，而這並不是任何人的具體錯誤。儘管如此，擁有時間表確保項目的整體範圍保持在某些範圍內。如果你有一個月的時間來解決一個問題與一年的時間，你會提出非常不同的解決方案。

目標必須不斷重複告訴所有團隊成員：他們應該（比喻地）厭倦項目經理不斷討論目標。一些實時（或儘可能接近實時）的儀表板來跟蹤進展也可以對確保每個人朝著目標對齊並知道項目進展情況非常有價值。

待完成事項清單

我們強烈建議將計劃稱為“待完成事項清單”，因為這樣可以消除計劃過程的神秘感。

計劃通常是猜測，但仍然是有價值的。這是因為計劃過程本身有助於揭示我們知道什麼和尚未知道什麼。

不計劃就是計劃失敗。

計劃的本質是獲得從項目開始到成功完成的所有步驟的詳細清單。一些行動需要先前步驟完成，因此你可能會得到一系列相互關聯的任務，通常稱為依賴關係。其他行動可以並行進行，並不會互相阻礙。

項目經理應始終專注於阻礙其他行動的最重要行動，因為這定義了項目的關鍵路徑。也就是說，如果所有依賴關係端對端排列，項目可以完成的最短時間。

從項目的兩端著手計劃可以對建立有效的計劃有很大幫助。這意味著你從開始到結束，但然後你也從結束開始，向後工作以了解完成項目和達成目標所需的內容。

這個逆向計劃過程的最後一部分通常會發現遺漏的任務。

但是，計劃過程並不完整，直到我們了解每個任務的責任人以及每個任務完成所需的時間。

這些要點應同時涵蓋，因為它們緊密相連。你無法在不涉及了解該任務具體情況的專家的情況下創建工作估算，即使如此，你仍然需要注意資源分配。一個人很少能有效地同時處理多個任務，因此你需要了解項目計劃是否可能存在瓶頸。這是指一個人無法完成所有分配的任務，因為他們根本沒有足夠的時間。

指定某人負責每一項工作

項目中的每個任務都需要有一個具體的個人負責完成該任務。如果你發現需要多個人負責同一任務，通常是因為你沒有足夠細化任務以區分它們。

例如，在許多行業中，會有設計和建造階段；這可能是在製造、建設甚至軟體中。你應該將其細分，以便可以分配設計師的具體任務和建造者的具體任務。你會發現這兩個學科之間經常會有反覆的過程，你可以將其考慮進去。一個例子可能如下所示：

1. 設計階段1由設計師負責
2. 可行性檢查1由建造者負責
3. 設計階段2由設計師負責
4. 可行性檢查2由建造者負責
5. 高級利益相關者審查
6. 設計最終化由設計師負責
7. 最終檢查由建造者負責
8. 利益相關者批准

這顯示了不同參與方之間的現實上下波動，而不是將“設計階段”單獨分配給設計團隊，直到設計階段完成。

每項工作的時間表

這可能是創建計劃中最具挑戰性的部分——我們如何衡量每項工作需要多長時間？如前所述，時間表應該不是自上而下的，而是自下而上的。這意味著每個項目都由將要執行工作的人（或至少是一位知情的同事）進行估算，然後將所有這些估算加總並計算成整體時間表。

話雖如此，在進行詳細估算之前，擁有一個整體的高層次時間表是有幫助的，因為估算某件事情需要多長時間和決定解決任務的具體方法本質上是相同的。

因此，如果一個項目有寬鬆的高層次時間表，那麼個別專家可以將其納入他們的估算中，並嘗試優化長期解決方案，而不是為了確保時間表的達成而走捷徑。如果項目有緊迫的時間表，那麼每位專家都知道他們可能需要做出取捨。

在創建項目計劃的過程中，經常被忽視的一點是，利益相關者需要審查進展並確認需要考慮的決策。最好的方法是查看之前的項目，該項目包含相同的利益相關者，並了解他們提供反饋的典型周轉時間。

這裡的另一個危險是，如果與關鍵利益相關者的每月指導委員會會議，當項目交付物無法及時提交以參加其中一個會議時會發生什麼？項目會暫停到下個月，直到利益相關者再次會面，還是會在每月指導委員會之間處理並批准（或發回反饋）？

溝通策略

當出現這樣的問題時，它們證實了項目內部溝通方式的重要性。

通常，問題不是策略不好，而是根本沒有策略。因此，溝通渠道以非正式和臨時的方式開放，而“足夠好”成為標準。

這樣的問題在於事情並不總是按計劃進行。人們會改變，知識會丟失，隨著項目變得更大，越來越多的人加入，溝通的開銷會迅速增加。

因此，很明顯，工具本身並不是那麼重要；事實上，當你超過一個非微不足道的人數（例如10人）時，團隊合作變得越來越困難。

這是因為團隊溝通並不會隨著團隊人數的增加而線性擴展。

例如，如果你有一個2人的團隊，則有一個溝通線索（在兩個人之間）。再加入一個人；現在你有三個溝通線索。因此，雖然團隊規模增加了50%，但溝通線索卻增加了300%。

讓我們看看這是如何增長的：

• 2名團隊成員 = 1條溝通線索
• 3名團隊成員 = 3條溝通線索
• 5名團隊成員 = 10條溝通線索
• 8名團隊成員 = 28條溝通線索
• 10名團隊成員 = 45條溝通線索
• 15名團隊成員 = 105條溝通線索
• 20名團隊成員 = 190條溝通線索
• 30名團隊成員 = 435條溝通線索
• 50名團隊成員 = 1,225條溝通線索
• 100名團隊成員 = 4,950條溝通線索

這可以用以下公式表示：

n(n-1)/2

其中 n 是需要參與項目的人數。

如你所見，隨著團隊規模的增長，這個數字呈指數增長。如果你有一個10人的團隊，則需要管理45條潛在的溝通線索。但如果你有一個50人的團隊，則有1,225條潛在的溝通線索——這是27倍！如果你有一個100人的團隊，則有4,950條可能的溝通線索——這是110倍！

值得注意的是，這不僅僅是大團隊的問題，而是任何團隊中個體不在同一位置的問題。這是因為潛在的溝通線索數量不受團隊成員的物理接近性限制。

例如，你有一個10人的團隊，但他們都位於世界不同的地方。在這種情況下，仍然有45條潛在的溝通線索需要管理——即使團隊成員之間並不物理接近。

而且情況可能會更糟。上述計算假設只有一種溝通方式。如果我們想考慮不同的溝通方式，我們必須以以下方式重寫公式：

n(n-1)/2

其中 n 是溝通渠道的數量。

讓我們重新計算上述的溝通線索數量，但這次假設 n 包含：

• 電子郵件
• 群組聊天
• 個人聊天
• 項目管理系統中的評論
• 通話
• 文件中的筆記/評論

將數字代入，我們得到：

• 2名團隊成員 = 6條溝通線索
• 3名團隊成員 = 18條溝通線索
• 5名團隊成員 = 60條溝通線索
• 8名團隊成員 = 168條溝通線索
• 10名團隊成員 = 270條溝通線索
• 15名團隊成員 = 630條溝通線索
• 20名團隊成員 = 1,140條溝通線索
• 30名團隊成員 = 2,610條溝通線索
• 50名團隊成員 = 7,350條溝通線索
• 100名團隊成員 = 29,700條溝通線索

溝通線索的數量增長速度驚人——如果遠程工作更容易促成在現實生活中不切實際的大型會議，那麼這就是一把雙刃劍。

因此，簡而言之，制定策略對於避免即使是相對少數的團隊成員之間的溝通爆炸至關重要。

雖然“溝通策略”的概念聽起來可能複雜而宏大，但它不必如此。關鍵是設置幾個原則，說明主要的溝通渠道，並可能告訴人們不該做什麼。

幾個基本原則需要考慮：

• 保持信息公開。 假設所有信息在幾個月/幾年後都需要容易找到和共享。確保項目團隊中的每個人都能訪問所有所需的信息，並注意以此為考量命名文件和文檔。
• 偏向清晰。 想像一下，有新成員加入項目團隊。清晰簡潔地記錄信息，以確保他們能夠輕鬆理解關鍵決策。
• 保持會議記錄。 確保所有重要會議都有記錄，並且容易找到。

在溝通渠道方面，越少越好。我們建議將其減少到以下幾個：

• 項目管理軟體 用於特定任務的討論。
• 與會議記錄的會議（面對面或遠程）以及 在一個地方找到所有項目會議記錄的地方。
• 文檔：這可以是 Google Docs 中的評論和討論，或允許評論的特定工具（例如 Figma 用於 UX 設計）。

將 群組聊天 添加到此列表中也是可以接受的——但然後必須仔細管理，因為它可能變成一個沒有明確目標或議程的巨大全天（和每天！）會議。

項目經理需要明確設定這些規則，並成為如何協作的榜樣，同時偶爾使用一根棍子（比喻的，而不是字面的！）來讓項目團隊成員回到正確的溝通方式上。

最後的想法

無論一個人的專業水平如何，退後一步從基礎層面看待一個主題或過程總是有價值的。因此，在深入探討項目管理主題時，我們確定了成功執行項目所需的關鍵基本原則。

每個項目都應有一位項目經理：他們確保項目有明確的目標，這些目標被分解為完成任務以達到最終目標。然後，項目經理需要為每個任務分配一位團隊成員。團隊一起可以確定每個待辦事項和整個項目的時間表。

通常，似乎理所當然的事情可能會引發問題，而不是更高級的主題，這些主題往往受到更多關注——例如，溝通。這就是為什麼項目團隊內部和外部與利益相關者之間應該有明確的溝通策略。

項目管理是一個複雜的主題，因此這絕不是一個詳盡的指南。我們仍然需要考慮一些在這個初步概述中未涵蓋的因素，例如預算、解決選擇之間衝突的方法，以及在項目中委派的程度。