iT邦幫忙

2021 iThome 鐵人賽

DAY 22
2
IT管理

邁向Tech Leader的成長之路系列 第 22

21. 當一切未知時,該如何做決策?

前言

當你是junior時,每次交給你一個任務你大概可以想像要怎麼樣達成目標,對於丟給你的問題,即使不知道要怎麼解,但你也大概有方向知道怎麼樣做是對的。然而世界沒有想像中的美好,隨著seniority的增加,你處理問題scope越來越大,問題越來越複雜,大部分狀況其實是沒有清楚的答案的,更多是也沒有所謂「正確的答案」存在,在這種情況下你要如何做決策?

這篇文章蠻適合給Senior或者Leader來看,特別是當你發現你的工作充滿著未知與不知道怎麼做決策的問題時,可以看看這個演講提供的建議是否對你有幫助。

演講總結

這篇演講的主題是告訴我們如何做困難的決定以達到遠大的目標,特別是那些你沒經驗也毫無概念的任務。

做決定的困難點

為何隨著年齡增長,你處理的問題會越來越趨困難?

  • 因為問題本身越來越模糊,並不像junior的任務這麼清楚定義好。
  • 要花的時間越來越長,你要完成任務的時間可能從一兩週變成,一兩個月一兩季甚至變成一兩年。
  • 下決定的成本越來越高,一旦走錯路可能要改正回來非常的困難。

在這樣複雜模糊與困難的狀況下,我要怎麼知道我做的決策是對的?
講者表示基本上沒救,當下你擁有的資訊不可能讓你知道最後決策是否是正確的。

因此,與其思考怎麼樣做「對的決定」,不如思考怎麼「修正錯誤」。

如何做決定?

講者建議我們可以使用「精益方法(lean approach)」去達成長期與高不確定性的目標。接下來就是要細講這三個部分。

https://ithelp.ithome.com.tw/upload/images/20211006/20141895iGBw4wvE4U.png
(圖片來源:原演講投影片)

Step 1. 擬定計畫(Form a plan)

  1. 寫下問題的描述、限制、與動機

    不同於那些你已知或熟悉的任務,這種計畫很難擬定就是因為你根本也沒有經驗,所以首要之事就是先釐清問題本身與記錄下來,因為它已經超過你腦袋的記憶體容量了。

  2. 指定負責人(DRI,Directly Responsible Individuals)

    通常在做困難決定時都會一群人一起討論,大家會彼此爭論觀點,也因此很容易就會形成爭論半天但毫無結果的狀況,所以這時候這位DRI的目標就是確認整個決策過程是有在向前進邁進的。

  3. 打擊分析癱瘓(analysis paralysis)

    跟上一點雷同,基本上就是要防止無進度的討論。在做決策時人常常過度分析事情本身而苦於做出決定。所以嘗試跳脫這個循環,確認每次meeting都是有在向前進的。

而我們希望在擬定計畫的部份能獲得以下成果:

  • 以文件記錄下來問題的所有相關資訊
  • 確認負責人是誰
  • 達成共識選擇一個方向向前邁進

這裡的方向不用是確定的解法(其實你也無法得知確定解法),只要是一個可以嘗試的小賭注就可以,下面來解釋這點。

Step 2. 做小賭注(Place small bets

小賭注的特徵:

  1. 盡量簡單與越小越好
  2. 一個月內可以獲得feedback
  3. Bonus: 可以平行操作的話更好

做小賭注的目的很明顯,我們希望多樣性的嘗試不同的方向(diversification),利用類似MVP(Minimum viable product)的方式去理解哪個方向比較適合。如此一來我們便可以

  1. 獲得更多資訊幫我們做決策
  2. 幫助我們思考風險
  3. 降低處理問題的複雜度。

這邊有幾個常見的方式是這種小賭注的實現方式

  • 可行走的骨架(walking skeletons):其實就是MVP或者說可以動的prototyping XD。
  • 部分上線(Partial releases):釋出一小部分的功能,利用feature toggle或whitelist控制會受到影響的用戶。

Step 3. 吸取教訓(Get feedback)

最後吸取教訓的部份就是從一次又一次的小賭注中,嘗試做到

  • 獲得feedback確認方向是否正確
  • 嘗試早點修正與解決問題

總結

當初美國在擬定「登月計畫(Project Moonshot)」的時候,沒有人知道到底該怎麼做,更不知道怎麼做才對。但為了快速達到這個目標,前人做的嘗試就是不斷的利用MVP去嘗試:嘗試發射火箭到太空,嘗試回收火箭,嘗試在太空生存...。不斷的利用快速的feedback loop去逼近目標。

如果大家有興趣可以看看google的X company,他們把各項登月計畫變成一次又一次的登屋頂計畫(roofshots),也才能不斷的達成各種不可能。

最後總結整個演講的點

  • 建立一套迭代進步的流程
  • 審慎思考,但偏向著重目標(bias toward action
  • 建立護欄,早日發現問題與修正它
  • 從小賭注中重新調整與協調
  • 不需要等到你真的知道怎麼做之後再開始

個人心得

這篇的主題真的意外的蠻有趣的。

雖然他在講的是做決策,但其實跟解決問題是同樣的道理。一般人可能都會想說解決問題的方法是:先列出你想達成的目標,然後想辦法分成小階段去完成這個目標。但現實狀況是你可能根本對於問題本身都不夠清楚,也沒有前人的經驗,那在這種資訊不完全的狀況下你要怎麼達成你的終極目標。

超越工作本身的哲學

我自己覺得這個approach其實不只是套用在工程上,也是一種很好的生活哲學。

工作的目的其實就是在教導你如何面對世界。

你怎麼處理工作上的未知,其實就跟你怎麼處理生活上的未知是很一樣的道理。工作模式的抽象,其實完全是可以套用在生活上的。

例如你工作覺得無趣而想嘗試轉領域當工程師看看,但你知道這個成本很高,不確定該如何做決定好?那你或許可以套用上述的方法,加入個bootcamp認真花個一兩個月學個coding感受一下,或許可以有更多資訊幫助你做最終決定。

再例如我自己也曾經嘗試改進我的時間管理,而時間管理有各種framework可以套用那我應該選擇哪個呢?我也不知道,所以我就先亂選了Get Things Done(GTD)試試看。在密集的嘗試一個月之後,我發現幾件事:

  1. 我不適合GTD。主要是因為中間的review process花的時間有點多,我有點難建立這個習慣。
  2. 我內心或許也沒把時間管理當成first priority,動機不夠高,所以我願意投下去的時間精力沒有想像中的高,我想這也是某個會失敗的原因。

就像這個鐵人賽也是一個對自己的嘗試,看看寫文章是不是個適合我的路線XD,目前已經寫了2/3,流程上的收穫蠻多,希望我最後一天有時間好好整理這些東西。

關於如何做決策

當Leader常常發生的事情是,當大家遇到兩難、難以下決定的狀況時,常常會請Leader來決定到底要怎麼做比較好,但其實很多問題Leader本身也不太知道答案。例如說兩個性質相近的API到底要合成一隻還是分成不同的?例如這個DB要使用Mysql還是用HBase?例如我們到底該不該把commit code gen出來的code還是只在deploy的時候dynamic的gen出來?

其實這些大方向決策的問題,我也都沒答案,其實也無法得知哪個比較好。因為**「系統設計本來就是一項預測未來的過程」**。好的設計只是這個設計對於預測的未來剛好比較match,而不好的設計或設計錯誤,往往只是當初的預測跟未來走向不同而已。

所以很多時候與其花時間討論哪個決策是最好的,不如就選擇一個方向做下去,因為計畫總是趕不上變化的。我們自己到最後決策的重點,往往考慮的是當這個決策是錯誤時,有沒有辦法修正?或者這個決策的風險有多高?只要這些小賭注的後果是自己可以承擔的,那我們就可以先往這些方向前進。

所有決策都是最好的決策

不要追求最好的決策,將你的決策變成最好。

雖然與上文寫的沒有什麼關係,但我覺得人生其實就是一連串的決策過程。很多時候你不見得需要像上面那樣做各種小的嘗試,更多時候是快速做決策後,嘗試把下定決心的結果變成最好。

心思細膩的人往往會多想到底哪個決策是最好的?花了很多時間分析優劣,但是卻遲遲不願意下決定。我自己其實也是這樣的人:在考慮要不要換手機前就會思考各種換手機的優劣,在出去玩就會各種比較哪個地方會玩的比較盡興,租房子的時候有兩個各有優劣的選項苦苦無法選擇,究竟要待在現在公司還是換去其他地方,到底應該要跟喜歡的人告白還是不要(?)。花了很多的時間分析優劣卻還是不知道怎麼下決定。

我覺得分析是必要的,但是過度分析只會導致更加難以抉擇,因為其實大部分選擇的優劣,都是無法比較的。所以與其繼續苦惱無法做決定,還不如選定一個方向做下去,然後慢慢的把你的決策調整成最好。但要記住的是這裡的最好不是指如預期結果的最好,而是你自己能接受的最好。因為我們無法控制外界事務,但是我們可以控制自己面對事物的心態。


上一篇
20. 在公司響起革新號角
下一篇
22. 一些關於leadership的事
系列文
邁向Tech Leader的成長之路30

尚未有邦友留言

立即登入留言