It Depends 是我最討厭的一句話
# 雜談前言
「It depends。」
不知道從什麼時候開始，這句話成了工程師的萬用解答。架構怎麼設計？It depends。要不要上微服務？It depends。該用哪個框架？It depends。
說得沒錯，在軟體開發裡面沒有銀彈，任何技術決策都要看情況。但這句話無法對推進專案產生任何幫助。
在日本，工程師很喜歡用這句話「技術的に可能です」，來表示某件事做得到，但可能他不想做，所以用這句話代表委婉拒絕。
正確到沒有意義
你說一個觀點，對方回你 it depends。你再追問，對方再給你一個 it depends。最後大家達成了一個什麼共識都沒有的共識，然後散會。
It depends 幾乎在所有情境下都是正確。因此這句話有講跟沒講是一樣的。就像有人在炒菜的時候問你火候怎麼控制，你回他「重點是火候」。
反過來說，如果對方說出 It Depends，也有可能代表你的目標不夠清晰，導致對方不知道現在應該如何做決定，才給出了一個籠統的答覆。
因此在我進行討論的時候，我會盡可能把目的、背景事前分享給大家，確保彼此的認知是一樣的，才有辦法找到解方。可以看看我之前寫過的文章——菜籃與長矛，你們現在看到的風景是相同的嗎？還是一邊看著果園、一邊看著叢林呢？
無法做決定的原因
沒有想法這件事本身沒有錯。在完美決定之魂這本書裡提到，通常可以把事情放到這三個分類：
- 立刻決定
- 資訊不足
- 決定時限
我認為無法做出決定或提出想法的原因，通常是因為資訊不足。這也是最好解決的，只要雙方能補齊資訊落差即可。沒有想法這件事，其實也可以當作一個意見表達。可以說「我資訊不夠，沒辦法判斷」。對這個領域不熟，可以說「這塊我不太懂，先聽你們的」。
以後遇到「It Depends」，可以反問他：
- 那麼，你的意見是什麼？
- 需要哪些資訊才能幫助你判斷？
- 你說這句話的目的是什麼？
怎麼做才能推進專案？
It Depends 曾經是我用來判斷是否為 Senior 的標準。因為他代表的是做權衡，釐清需求，不再只停留在把功能做出來而已。
然而這份成熟也有可能變成不表態的傲慢。因為要考慮的事情太多了，你害怕出錯，所以把該做的事情都變成一句 It Depends 帶過。
這是一種自我欺騙。最後的結果是，什麼都沒說的人反而佔據了道德高地，而真正在討論的人看起來像是不成熟。
真正推進專案的方法是——負責任地承擔 It Depends 的重量。整理論點、釐清關係利益人的需求、排優先序、補齊不足的資訊、主動溝通。
- 這次要先顧哪邊？
- 什麼條件下優先順序會反過來？
- 誰來承擔這個取捨的成本？
- 如果判斷錯了，哪個方向比較容易補救？
- 這是原則問題還是這次的例外？
把討論推進到這個粒度，「平衡」才會變成可以執行的東西。然後他們會做決定、承擔後果。錯了就回頭檢討，調整之後再往前推。
同樣的道理，說「重結果不重流程」很容易，但不能拿這句話當藉口，逃避流程的改善。短期靠衝刺可以交出成績，但你不可能永遠只靠衝刺。不去改善流程，就是在透支未來。
讓我舉幾個例子。在我接案的過程中，曾經遇到幾個討論：
- 我們要用 MySQL 還是用 Postgres？
- 要用 Monorepo 還是分離 Repo？
- 前後端分別要用什麼程式語言？
這些討論都是沒有正確答案的。這時候如果讓團隊討論，就會變成毫無結論的會議。
「用 MySQL 跟 Postgres 都可以」
「用 Monorepo 看似比較好管理，但分離 Repo 也有道理」
在專案進行當中，我最忌諱就是這種無法推進專案的討論。因此我在事前就準備好資料來說服團隊，表面上是要開會決定 Tech Stack，實則是將我的結論傳達給團隊。至於要用什麼方法來評估，可以看看我之前的文章：
我盡可能做到 It Depends 的重量，與團隊說明為什麼我會這樣決策，包含最近的趨勢、客戶的環境都使用哪些技術線。（當然，也可以把自己的喜好包裝起來，好讓團隊往你想要的方向走）
儘管那代表我要承擔決策錯誤的風險，但比起只會講「It Depends」跟「看吧 I told you」的人強太多了。
我在以前曾經吃過幾次虧，儘管我知道團隊的討論不佳，但我並沒有提出自己的想法。因為我下意識認為講出來也沒用，然後在 SNS 上抱怨取暖就這樣過去了。
結語
不要把看情況掛在嘴邊，明確表達「情況」是什麼？現在的情況為何？應該要注重哪些事情？怎麼下決定才能幫助專案前進。當一個站在高點冷笑嘲諷的人很簡單，把手弄髒、說服別人你的方案可行，一步一腳印推進專案，承擔著「It Depends」的重量前進酷多了。