「做得完嗎？」這個問題從來不是在問時間。它是一場談判的開局——只是通常，只有一方知道自己在談判。

一句「可以」，跟一句「可以，但是」

昨天說，找到誰說了算之後，下一課不是排程，是談判。今天就講一場排程會議。案例照舊經過去識別化與合併改寫。

某次版本規劃會議，投影幕上一張清單，十幾項功能。主管掃視會議室，問了那句每個工程師都聽過的話：

「這些，下個月底前做得完嗎？」

全場沉默三秒。

最年輕的工程師先撐不住，點了頭：「應該可以。」主管正要把「可以」寫進紀錄。

這時，資深工程師開口了：

「可以。但要嘛砍掉這兩項，要嘛加一個人，要嘛品質的風險你們收。」

會議室的空氣變了。

有趣的是接下來發生的事。主管沒有翻臉，也沒有講團隊精神。他盯著清單看了一會，問：「砍哪兩項，影響最小？」

然後，那間會議室出現了接下來二十分鐘的「談」：哪兩項可以移到下一版、那個月底其實是誰訂的、如果不砍，測試要讓掉多少。散會時，清單少了兩項，日期沒動，沒有人需要「回去想辦法」。

年輕工程師走出會議室，說了一句話：

「原來可以這樣回答。」

這句話才是今天的重點。不是資深工程師多會估時程——是在那之前，整個團隊都以為「可以，但是」這種回答不被允許。

當時團隊怎麼理解「做得完嗎」

當時多數人的理解是這樣的：主管都開口了，要的就是一個答案，不是一堂課；說「做不完」會被解讀成能力不足，或態度有問題；先答應下來，之後再想辦法，反正大家都是這樣活下來的；排程是 PM 的事，工程師只要回答可以或不行。

每一句單獨看都有幾分道理。合在一起，它們把一個有六個變數的問題，壓縮成一題是非題。

而這題是非題只有一種答錯的方式：答「不行」。

所以大家都答「可以」。

「做得完嗎」到底在問什麼

那句話字面上在問 Time，實際上同時押上了六個變數：

Value     這些東西為什麼值得做？哪幾項不做會真的痛？
Scope     要全部，還是先要最痛的那塊？
Time      哪個日期是真的死線，哪個只是喊價？
Cost      加人、加預算，是選項還是禁語？
Quality   哪些部分不能打折，哪些可以先欠？
Risk      這次在賭什麼？賭輸了誰收拾？

回答「可以」，等於替這六項一次簽名，而且不附任何條款。回答「不行」，等於把談判在開局就結束，連條款都懶得開。

這兩種回答有個共同點：都沒有談。

而瀑布跟敏捷，其實都替這場談判內建了位置。Day 02 說過，瀑布的承諾是計算的結果——先有 Baseline，才有估算，才有答應；有人要改，走 Change 重新報價，Day 05 那張變更報價單就是談判的書面版。敏捷那邊，每一輪的 Planning 本身就是一場公開談判：容量有限，要塞新的東西進來，就得當場拿舊的東西出去。

換句話說，兩套方法吵的只是「怎麼談、多久談一次」。沒有任何一派主張「不用談」。

把談判桌拆掉、只留下點頭的，不是瀑布也不是敏捷，是我們自己。

今天缺席的 Artifact，名字可以叫 Trade-off Record，也可以叫談判紀錄，形式不重要。重要的是那個動作：在答應之前，把「拿什麼換」攤開來，讓有權決定的人自己選。

排程當然還是要排。但排程是談判結束之後的會議紀錄——先談完要什麼、給什麼、換什麼，剩下的才輪到日曆。順序反過來，你排的不是計畫，是別人的願望。

那句話，為什麼只有他說得出口

回到會議室。年輕工程師不是不知道做不完——他後來私下承認，點頭的那一秒，心裡想的是「大概要賠上三個週末」。

他缺的不是估算能力，是把估算說出口的籌碼。

資深工程師憑什麼敢講？他有多年累積的信用，講「做不完」不會被當成偷懶；他知道主管真正在意的是哪一個里程碑，所以砍哪兩項他心裡有數；說得再直白一點——他知道這個團隊離不開他。

於是「談判」在這個團隊不是流程的內建步驟，而是一種資深特權。他在場，代價會被攤開來選；他不在場，會議就回到點頭，代價回到默默由人吸收。

注意，這次大神補的洞跟之前不太一樣：不是知識，是位置。他用自己的地位，暫時充當了那張本來就該存在的談判桌。

這件事，先記著。

這次到底誰在吸收代價？

老規矩。先看沉默的版本——如果那天資深工程師沒開口，「應該可以」就是結論：

Scope       □   一項都沒少
Time        □   日期照舊
Cost        □   沒加人
Quality     □   暫時沒人承認會打折
Risk        □   沒被討論，所以不存在（嗎）
人          ■   「應該可以」的下半句是三個週末   ← 又是這格

再看實際發生的版本——他開口之後：

Scope       ■   砍掉兩項，而且是主管自己選的
Time        □
Cost        □
Quality     □
Risk        □
人          □   這次沒有人需要默默吸收

兩張表放在一起，今天的重點就出來了：談判沒有消滅代價，也不可能消滅。它做的事情只有一件——讓代價在答應之前被看見、被選擇。

■ 從「人」這格搬到「Scope」那格。專案管理第一課，就是這一格的搬動。

第一部收工：任何方法的地基

今天是第一部的最後一天。這七天談的，其實是同一件事的不同切面：

瀑布賣的是承諾——答應之前，先知道自己答應了什麼
敏捷賣的是回饋——承認還不知道，就把承諾切小、把答案問出來
固定 Scope 還是固定 Time，是選擇的結果，不是口訣
沒有免費的 Change，代價一定有人付，差別在有沒有人選
需求要跟說了算的人談，而不是跟離你最近的人談
而以上每一件事，最後都發生在同一個地方：談判桌上

這些不是瀑布的專利，也不是敏捷的儀式。它們是地基——不管你之後選哪套方法，這些問題都得有人回答。

第一部想說的就這一件事：在爭論該跑瀑布還是敏捷之前，先確認你的團隊答得出「答應了什麼、拿什麼換、誰點的頭」。答不出來，換哪套方法都一樣。

今日 Artifact｜承諾前談判記錄

把今天那場會議收成四行。任何人向你要承諾時，答應之前先填：

□ 對方要什麼：＿＿＿＿（哪些項目、什麼時候、為什麼是這個日期）
□ 我們給什麼：＿＿＿＿（答應交付的具體範圍）
□ 拿什麼交換：＿＿＿＿（砍哪些 Scope／延多少 Time／加什麼 Cost／收什麼 Risk）
□ 誰點了頭：＿＿＿＿（有權選擇代價的那個人，同意了哪一項交換）

第三格空白卻照樣答應的承諾，交換條件不會消失——它只是自動填上「人」。

今日一句

「可以」和「不行」都是談判的放棄；成熟的工程回覆只有一種——可以，但代價是什麼。

不過，在替第一部關燈之前，回頭再看一眼那間會議室。

那句改變空氣的「可以，但是」，是最資深的人才說得出口的；那格從「人」搬到「Scope」的 ■，是因為他剛好在場才搬得動的。地基長什麼樣，我們現在知道了——問題是，很多團隊根本沒有這些地基，專案卻照樣一個一個結案。

靠的是什麼？

接下來七天，第二部：大神在的時候，所有流程看起來都很好。