如何做出重大技術路線決策?

banq發表於2021-04-10

Uber核心平臺技術最初押寶Thrift和Mesos,這種兩種技術後來分別被gRPC和Kubernetes主流技術替代。
當初您做出技術路線決策的上下文已經時非今日可比,問題:技術決策的上下文半衰期是多少?多長時間你需要重新檢查你當初決策的上下文是否已經失效?Will Demaine提出一些建議。

“大多數設計活動都需要不斷做出選擇。這些選擇中的許多可能不僅僅是設計決定;而是其他選擇。這也可能是設計師對自己的未來做出的個人決定。”
— 引用“康韋定律”論文

在Monzo公司,我們團隊進行的許多專案都涉及對服務平臺的根本性更改,有時這意味著消除了“ Monzo特定的怪異現象”。我們通常的目標是使事物儘可能地標準化流行化,通常程式設計技術採取社群集中度很高的熱門技術。
當你創業建立公司時,您必須押注技術,有時您會選擇錯誤的人。有時,沒有合適的東西可用,您必須自己構建它。這沒關係。但是,當技術領域的環境或上下文發生變化時,重新評估當初這些決定就很重要。沉沒成本謬誤在這裡應該是您的首要考慮因素。
當變換技術路線時,“當我們已有Y技術並且易於學習時,是否值得采用X?”。這是一個公平的問題,很難回答。
選擇幾種平等競爭技術中的一種不是問題,但是當整個社群開始圍繞其中一種技術開始集中而您卻沒有使用它這種技術時,就成問題了。
如果您從自己的定特定解決方案中得不到任何好處,且又不想換掉它,那麼你會持續承擔債務。您等待的時間越長,您的路徑分歧就越大,遷移就變得越困難。
如果您今天理論上就可以進行明確的選擇,那麼這表明您至少應該考慮遷移到該技術,這是一個很好的指示。需要明確的是,過去支援錯誤的技術路徑沒有任何恥辱,沒有人能預測事情會如何發展。
那麼,您到底是否應該遷移嗎?在大多數情況下,似乎人們是基於*當前*狀態而不是*將來*狀態做出決定。如果我們有些怪異,可以很容易地說“但是我們都已經習慣了,新人們可以很快地學習它”。但是,如果您是一個成長中的組織,那麼擁有這種怪異上下文的人們很快就可以成為少數派。我稱其為工程組織的“上下文半衰期”。
可以這樣想:在您公司的整個生命週期中,最終需要了解此係統的“所有人”中,大多數人是否還在公司工作?
一些快速模型資料可以向您展示如何消除公司特有的怪異現象:擁有250名員工,年增長率為30%,人員流失率為10%,組織中50%的工程師只需花2年多的時間就可以使原始決策的上下文背景零化。擁有不到100名工程師,20%的增長和10%的損耗,這僅用了3年多的時間。
當我加入Uber時,我們有100名工程師,並且在2年的時間內以驚人的速度增長了驚人的400%。這意味著兩年後,最初的團隊僅佔工程團隊的3%。
有了這些數字,很明顯可以看出,投資於消除“怪異”將是一個不錯的選擇。Uber更換了平臺的核心部分,這使成千上萬的新工程師可以加入,而無需熟悉那些衰落的技術。
相關:
用於押寶的方法論:Kent Beck的3X模型是什麼?

相關文章