📜 歷史腦洞
巴別塔的跨國專案經理：現代 Scrum PM 穿越到巴別塔工地，用敏捷開發協調幾萬名工人
清晨的兩河平原，陽光尚未完全驅散薄霧，空氣中混雜著泥土、瀝青與汗水的气味。這裡是西元前兩千年的示拿地，人類史上最野心勃勃的工程——巴別塔——正在如火如荼地興建。
然而，在工地中央的那座用巨石堆疊成的指揮台上，一個身著現代polo衫、手拿數位板的人，正眉頭深鎖地盯著螢幕上不斷跳動的紅字。他的名字是李天明，一個在矽谷身經百戰的Scrum Master（敏捷教練），不知何故，醒來時便身處這片古人類的建築奇觀之中。他手中的iPad居然還有電，但顯示的不是Jira看板，而是一個他從未見過的、名為「雅赫維任務控制台」的古老介面，上頭用楔形文字和英文雙語寫著：「距離上帝降臨視察尚有：180天。任務達標率：47%。混亂指數：爆表。」
李天明深吸一口氣，看著台下那些分屬不同部族、操著數十種語言的數萬名工人，有的在搬運巨石，有的在燒製磚塊，有的卻因為「我們迦勒底人的搬運法才是正統」而與「亞述幫」的工人大打出手。他知道，若不能將這群「跨國團隊」導入敏捷開發，別說塔頂通天，恐怕連地基都會被內鬥給掀翻。
「好吧，」他喃喃自語，點開了控制台上的「啟動Sprint 0」按鈕，「雖然這裡沒有咖啡機和便利貼，但我有的是橄欖油和石板。讓我來告訴你們，什麼叫做真正的『擁抱變更』！」
李天明花了整整三天走訪工地，他發現巴別塔的興建計畫，正是典型的巨型瀑布式開發（Waterfall）。根據「王室總工程司」的宏大藍圖，這座塔預計要蓋到「塔頂通天」，但整個專案只分成了四個階段：奠基、築牆、封頂、剪綵。而這份藍圖被刻在巨大的石板上，被當作神明指示般供奉著，不容更改。問題是，執行這份藍圖的，是來自七十個不同國家、使用七百種不同語言（根據聖經記載的說法）的勞工。
一名亞述工頭理直氣壯地說：「我們亞述人蓋廟用了五百年，這規格可是祖先傳下來的！」旁邊的迦勒底工人立刻吐了口唾沫：「呸！你們的磚太厚，根本是浪費材料，我們這裡才是標準！」
這就是典型的依賴關係混亂與需求溝通障礙。傳統的瀑布式管理試圖透過「權威」來壓制衝突，但幾萬人的力氣若用錯了方向，只會產生巨大的內耗。更糟的是，上層的「產品負責人」（也就是祭司團）每隔幾天就會因為「神諭」而修改塔的裝飾細節——今天要鑲金邊，明天說要換成藍寶石——導致工人們反覆拆掉重做，士氣低落。
李天明在這份巨大的「契約文書」（等同於專案章程）上，寫下了第一個診斷結論：「缺乏短週期交付、缺乏透明化溝通、缺乏對變更的適應性。簡而言之，這是個注定失敗的巨型『死亡行軍』專案。」
他知道，若要在此時此地推行Scrum，他不能只是告訴他們「要站著開會」，而要徹底改變這群古代人對於「工作」與「團隊」的認知。他必須先建立一個最小的可運行框架，讓大家嘗到「快速成功」的甜頭，才能贏得信任。
李天明知道，在幾萬人的大型工地中，不可能只有一個Scrum團隊。他必須設計一個能大規模擴展的敏捷框架。他站在指揮台上，用一種融合了亞蘭語、埃及語和手勢的「破爛跨國語言」，開始了他的第一次「Sprint規劃會議」。
「聽著！從今天起，你們不再是『搬石頭組』、『砌牆組』或『祭司溝通組』！」李天明大聲宣佈，他讓書記官在泥板上畫下新的組織圖，「我們要組成『細胞小隊』！每一隊由一名亞述工匠（擅長石工）、一名迦勒底泥瓦匠（擅長砌磚）、一名埃及繪圖師（擅長測量）和一名亞蘭翻譯（負責溝通）組成！」
這個概念在現代稱為跨功能團隊（Cross-functional Team）。在過去，石匠只管把石頭丟到定點就不管了，磚匠也不知道下一步要做什麼，全部仰賴上層的「排程官」像發號施令般逐一指揮，導致大量的等待時間與返工。
現在，每個小隊負責一段獨立的牆面，從底層的地基處理到磚石的堆疊與抹灰，全權負責。他們不再是被動接受指令的螺絲釘，而是對「完工定義」（Definition of Done）有共同認知的當責者。「你們這隊，只要負責把這個區域蓋到五肘高，而且通過垂直度測試，就算完成！至於怎麼分配內部工作，你們自己討論！」李天明將「怎麼做」的自主權交還給了現場的工人。
古代的官僚體系非常喜歡開會，但那只是為了讓祭司或工頭們展現權威。李天明禁止了這種浪費生命的會議。他規定每天早上在太陽升起時，每個「細胞小隊」必須在他們負責的牆面下集合，進行「每日站立會議」（Daily Stand-up）。他不准他們坐著，因為這樣會議才會簡短。會議上，每個隊員只需回答三個問題：
剛開始，工人們覺得莫名其妙，但很快他們就發現，透過這種簡短的同步，隔壁隊的埃及繪圖師會提醒他們：「你們牆角的垂直線偏了半寸！」這一句話，可能省去了隔天整面牆打掉重做的悲劇。這些「日常障礙」被李天明蒐集起來，登錄在「障礙移除待辦清單」（Impediment Backlog）上，由他這個「Scrum Master」專責去解決——比如協調更多的運水工、進口更好的瀝青，或是去跟祭司團交涉，請他們不要每一天都改變裝飾的顏色。
然而，改革總會遇到巨大的阻力。最大聲的反對者，是原本的「王室總工程司」——一位白髮蒼蒼、德高望重的老者，阿赫摩斯。他看著李天明把原本井然有序（至少看起來是）的萬人大軍拆成了幾百個「細胞小隊」，氣得鬍子都翹起來了。
「你這是在胡鬧！」阿赫摩斯在營帳中咆哮，「沒有中央調度，萬一東邊的牆建得比西邊快，導致地基不均勻，塔垮了誰負責？你們這套『野路子』，根本是兒戲！」
阿赫摩斯的擔憂並非沒有道理。在大型工程中，整體的建築藍圖與結構力學確實需要中央控管。但李天明提出了一個現代大型組織常見的解法——「保留整體架構的『鬆散耦合』，強化單元之間的『高內聚』」。他解釋，這不是放棄規劃，而是將規劃分層：
這套邏輯終於安撫了阿赫摩斯。李天明甚至引進了「在職訓練」（On-the-Job Training）的概念，讓經驗豐富的埃及石匠師傅到各小隊巡迴指導，取代過去只會站在高處罵人的「監工」。他告訴這些師傅：「你們的角色不是抓貪婪的狼犬，而是幫助團隊解決技術疑難的教練（Coach）。」
改革後的第一個月，進度雖然沒有暴漲，但「混亂指數」已經從爆表降到了百分之六十。更重要的是，因為「完工定義」被清晰地讓每個團隊知道，牆面的平整度大幅提升，祭司團派人驗收時，讚嘆不已：「這次的石牆，比我們的宮殿還要光滑！」
隨著塔身越蓋越高，新的挑戰出現了：物料補給與需求蔓延。祭司團看到城牆蓋得好，開始要求加蓋「空中花園」；尼尼微的商人則希望塔頂能設立一個獻祭平台，方便他們膜拜金星。這些突如其來的要求，打亂了原本的節奏。
「這不就是標準的『利害關係人』亂入嗎？」李天明苦笑。但他沒有拒絕需求，而是引入了「產品待辦清單」（Product Backlog）的概念。他在石板上畫了一張巨大的四象限圖，分別是「高價值/低成本」、「高價值/高成本」、「低價值/低成本（打雜）」、「低價值/高成本（拒絕）」。
他邀請祭司長、商人領袖和王室代表，一起為這些新需求打分數。這就是所謂的「敏捷契約」：我們不保證所有需求都會做，但我們保證「最有價值」的需求會被優先完成。李天明將「空中花園」與「獻祭平台」標記為「高價值」，但它們的成本極高，必須排在「強化地基」之後。
「各位，」李天明指著那塊巨大的規劃石板，「我們現在在衝刺『垂直高度』這個最關鍵的績效指標。如果你們現在硬要加蓋陽台，我們就得停下來重新計算承重，這會讓我們錯過『神明視察』的期限。不如我們把這些偉大的構想，放進下一個Sprint？」
這套滾動式規劃（Rolling-wave Planning）的思維，打破了古代工程「一動工就誓死不改」的僵化。工人們發現，他們不再需要為了迎合祭司突然的奇想而拆掉三天的工作成果，因為那些奇想會被記錄下來，經過「產品待辦清單」的排序，變成未來的正式任務，而當前的Sprint目標依然清晰可見。
巴別塔的興建，終於進入了一種「順流」的狀態。工人們士氣高昂，因為他們能親眼看到自己的小隊在每個月的「Sprint評審會議」（Sprint Review）上，展示一段如同藝術品般堅固的牆體。他們獲得了大量的「即時獎勵」——李天明用數位板向「雅赫維任務控制台」申請了大量的啤酒與肉品，作為達標的犒賞。這正是現代敏捷中的「激勵性薪資」與「成就感」的古代版實踐。
就在塔高聳入雲、即將觸及天堂門檻的那一刻，故事迎來了所有讀者熟知的轉折。李天明永遠記得那一天，天空並未烏雲密佈，反而萬里無雲。但控制台上瞬間亮起紅燈：「警報！非授權變更！變異性產生！」
他看見「雅赫維任務控制台」上出現了一行字：「需求變更：『混亂人類語言』方案已核准。專案指標：協作效率將因溝通誤解而呈現斷崖式下跌。」
上帝（或更高的存在）沒有採用李天明的敏捷方法論，而是選擇了最激進的「破壞性重構」——直接讓所有人說不同的語言。幾乎在一瞬間，細胞小隊內部的溝通崩潰了。亞述工匠聽不懂迦勒底人的安全警告，埃及繪圖師看不懂亞蘭翻譯寫的備註。原本能透過「每日站立會議」快速消除的誤解，現在因為語言隔閡被無限放大。整個工地的「資訊輻射器」（Information Radiator）——即那些原本貼滿圖形化看板的石牆——瞬間失去了意義。
這次，任憑李天明再怎麼調整「Sprint」的長度，或是改變「團隊組成」，都無法遏止混亂。因為敏捷的核心在於「以人為本的互動」，而當人類最基本的「互相理解」被剝奪時，所有的框架、儀式與工具，都成了裝飾品。工人們不再信任彼此，他們聚集在自己的語言族群中，無法合作，最終作鳥獸散。巴別塔的專案，以「不可抗力因素」被迫中止。
李天明站在那座未竟的高塔頂端，看著逐漸散去的人群，心中沒有挫敗，反而充滿了頓悟。他明白了：敏捷，不是為了控制不可控的未來，而是為了在一片混沌中，為人們找到一個可以暫時依偎的「節奏」。但當混沌的源頭並非來自市場或技術，而是來自「人性」與「神性」最深層的干預時，即便是最優秀的Scrum Master，也只能學會「擁抱結束」。
李明天笑了笑。他收起iPad，走下高塔，走進了一個不會有人聽得懂他語言的新時代。但他知道，那個關於「透明化」、「檢視」與「適應」的古老智慧，已經悄悄埋在那些四散的工人心中，總有一天，會在另一片大陸的某個軟體公司裡，以「立體便利貼」的形式，重新生根發芽。
這趟穿越之旅，雖然沒能讓巴別塔完工，但對於李天明（以及我們這些看故事的現代人）而言，絕對是一個成功的「經驗教訓」。巴別塔的失敗，向我們揭示了幾項超越時代的專案管理真理：
如今，我們在電腦前用著Jira、Trello或Asana，或許偶爾也會遇到如同巴別塔工地般的混亂。不妨想想那位穿越時空的Scrum Master，想想那句話：「擁抱變更，但永遠不要放棄讓彼此理解的努力。」 因為無論是在西元前兩千年，還是在二十一世紀的科技公司，專案成功的唯一配方，永遠是「一群彼此信任的人，為了共同的目標，攜手解決難題」。而這，正是「雅寶社區 · 頂客論壇」想送給每一位專案經理與歷史愛好者的最終祝福。
歡迎在下方留言，分享您的想法、心得或疑問。所有留言都會透過 GitHub 帳號 進行驗證。