阿偉頂著一對熊貓眼推門進來，整個人看起來像剛打完一場敗仗。

他一屁股坐下來就開始抱怨：「老楊批准了我的重構提案！本來應該很開心的對吧？結果我昨天晚上失眠到三點半。」

「怎麼了？」我點了兩杯咖啡，看他這樣子顯然需要雙份咖啡因。

「老楊決定在下個迭代給我們三週時間處理那個爛到爆的核心會員服務。」阿偉揉著太陽穴，「聽起來很棒對吧？問題是...他把我跟老黃分到一組。」

我想起上次他跟老黃的事情，立刻明白了。他們是團隊裡技術最強的兩人，理應是黃金組合才對，但現在看起來更像是要互相折磨三週。

「所以現在你們要一起合作三個禮拜啊？」

「對！」阿偉拿出手機，「我昨天很認真地做了重構設計，想說這次要用你教我的方法，先求一個最小可行重構，確保三週內能交付一個穩定的版本。但老楊給我們的三週，是商業的極限啊！」

他滑了滑手機，找到老黃的回覆：「結果老黃看了我的設計後說...」

阿偉學著老黃的語氣，壓低聲音：「『你這個設計依然是耦合度過高，與架構設計初衷不符。建議重新考慮整個服務的DDD劃分。』」

「就這樣？」

「就這樣！」阿偉差點把手機摔到桌上，「我知道他技術上是對的，但老楊給我們的時程就是三週啊！你知道嗎，本來老楊只打算給兩週而已，要拜託他才勉強擠出三週的耶。現在如果真的按照老黃他那種完美主義來做，別說三週了，三個月都做不完！」

當技術潔癖撞上時程壓力

咖啡送上來了，阿偉狠狠喝了一大口，被燙到舌頭還是不停。

「你覺得老黃為什麼要這樣啊？」我問。

「因為他是技術潔癖魔人啊。」阿偉翻了個白眼，「他只看到code要優雅，看不到時間的壓力耶。」

「嗯...不過你想想看，如果你是老黃，看到一個『暫時性』的解決方案，你會怎麼想？」

阿偉愣了一下。

「你會不會擔心，這個『暫時』的解決方案最後會變成永久的？然後未來每次要修改，都要在這個爛架構上面打補丁？」

「...會。」阿偉小聲承認，「我自己也遇過這種事。本來說是暫時的workaround，結果用了兩年。」

「所以老黃的問題，本質上是他不信任你的妥協程度。他擔心你的最小可行重構，以後會變成另一個無法重構的技術債。」

阿偉沉默了一會，「那我要怎麼辦？說服他放棄完美主義嗎？」

「不，不必說服他放棄任何東西，」我眨眨眼，「我們可以反過來，邀請他來一起定義界線。」

從「請重寫」到「共同制定規則」

我拿出筆記本，在上面畫了一條直線。

「現在你們的問題是什麼？是老黃覺得你要犧牲品質，你覺得老黃不顧時程。但其實你們的目標是一樣的：做出一個不會爆炸、且未來好維護的系統。」

我在直線的兩端分別寫上：

快速交付 <——————————————————> 架構完美

「所以我們現在要做的，不是去說服老黃妥協，而是把他拉進來一起參與定義：在這條線上，我們可以接受的底線在哪個位置上。」

「怎麼做？」

我開始在紙上寫…

第一步：先確立共同的成功標準

「首先我們不能只跟老黃討論 code 要怎麼寫。我們得先告訴他的是…」

 - 必須在三週內交付，這是老楊能給的最大時間極限
 - 如果我們無法在期限內交付，老楊會收回這次重構的機會，下一季我們就得在原有的爛架構上寫code了
 - 在這三週內，要做到以下兩點
    - 能顯著降低崩潰風險
    - 不會再拖延即時推播功能

我說，「像這樣，讓老楊知道這次重構的機會，其實是伴隨條件限制的。讓他意識到，如果我們沒辦法在時間內交出一版的話，那做得再漂亮也沒辦法用。」

阿偉很疑惑：「可是這樣不就是在說服老黃，得要閹割他心目中的藍圖嗎？」

「你想啊，老楊現在頂住上面的壓力，好不容易爭取來三週的時間給你們，他期望能夠看到什麼？」

「嗯… 應該是希望可以馬上就能看到一些效果吧？」

「是啊。」我喝了口咖啡，「如果我們讓老楊在下次跟高層報告時，可以拿得出成果來證明初步重構有效的話，那規劃下季時程的時候，我們是不是就又有機會能完善這一版的重構了？」

我拿出筆，又補上一點：

 - 如果在時間內順利交付重構，並達成以上效果，老楊則可藉此爭取下次重構的機會

「原來是這樣啊！」阿偉恍然大悟，「這樣的話，老黃心中的理想就還是有機會實現了！」

「沒錯~ 還有，萬一老楊之後不幸沒能爭取到下次的重構，那至少你們也已經在這次，把最嚴重的問題給修補好了，對之後的開發工作還是幫助很大，對吧？」

阿偉用力點頭。

「所以如果我們能讓老黃也理解到這一點，那他應該就能明白，這次的重構是階段性的、而不是一次到位的完美解決方案了。」我補充道，「而且我們也需要他的專業視角，來確保我們在有限的資源下，可以盡量一起做出最好的成果。」

第二步：提出階段性重構

「接著，我們可以請老黃幫我們一起規劃實現路徑。我們可以問他…」

老黃，既然這次時間有限，你覺得這個完整的設計我們可以怎麼拆分，讓我們在這三個禮拜可以實現我們想要的初步效果、又能方便我們之後迭代呢？

阿偉思考著，「你是說… 找他來一起來思考這個拆分的決策嗎？」

「對！我們還可以跟他請教…」

以你的專業判斷，哪些部分是這個階段就必須處理的核心問題？哪些是可以留到下階段再做完善的呢？

「這樣的話，老黃就會覺得整個規劃是他參與制定的囉？」

「沒錯，而且當他自己劃分了優先級，就會對這次的範圍有了更貼近現實的認知。他會更加明白我們不是在閹割他心中理想的設計，只是在把技術邏輯分步實現而已。」我喝了口咖啡，「而且第一階段的成功，也會為下階段爭取到更多資源和時間，何樂而不為呢。」

第三步：邀請他劃定底線

「最後一步是最關鍵的。」我在紙上畫了一條線，「我們要請老黃幫忙定義這次版本的品質底線。我們可以跟他討論…」

既然我們要在三週內完成，你覺得我們有哪些核心原則是絕對不能違反的？哪些部分雖然看起來很髒，但因為時間因素，這次可以暫時留著，下次再完善也OK的？

我指著這段文字，「像這樣，在開發工作開始前，就先跟他說好妥協的邊界在哪裡，這樣才不會花太多時間在討論coding style、怎樣才算完美… 之類的細節。」

阿偉高興地說，「對耶，這樣應該可以減少很多跟老黃來回討論細節的時間了！」

把評審變成隊友

「沒錯啦。而且當老黃參與制定規則時，他的角色也同時從一個『評審』，變成了跟你在一艘船上的『隊友』了。這樣一來，他就不會想要再一直去評論問題、而是會跟你一起想辦法解決問題啦。」

阿偉聽完後，原本疲憊的神情逐漸被決心取代。

「我懂了。以前我總是想證明我的做法才是對的，但現在我要邀請他一起來守護這個專案。」

他拿出手機，開始打字：「我要發個會議邀請給老黃，主題就叫『關於核心服務重構的協作規劃』吧。」

「這次，我要讓他知道我們是站在同一邊的。我們都想做出好的系統，只是需要在現實條件下找到最佳路徑而已。」

咖啡廳裡的音樂換成了一首比較輕快的歌，阿偉臉上的熊貓眼看起來好像也沒那麼嚴重了。

「會議我約在明天下午兩點。」他邊打字邊說，「希望這次我們能真正成為並肩作戰的夥伴，而不是互相拖累的負擔。」

他放下手機，喝了一口已經涼掉的咖啡，「我突然覺得，跟老黃合作可能真的會是件好事耶。如果我們能建立起這種合作模式，以後遇到類似的困境就不會這麼痛苦了。」

「而且說不定，老黃也一直在等一個，能夠理解他技術理念的合作夥伴呢。」