回顧時間

看了第一集 Monday Morning,內容主要關於一班醫生做術後檢討。第一集共兩次的檢討會中,都是一大班院內醫生,加上一位主持人負責。主持人會選中某一事故,然後叫主診醫生上台,接受主持人一步步的質問。

這一集中,讓我最深刻的,莫過於第二論的檢討會。沒有血肉模糊的鏡頭,卻彷彿讓人窒息。主要是一個小孩位於腦中的惡性腫瘤,因為主診醫生忘記了做兩件事:

  1. 重大手術應該詢問第二意見
  2. 未做好背景調查,了解因為單親家庭而未能即時聯絡上的,病人的父親的病歷史

結果病人就死了。

最後主持人單刀直入,指出主診醫生的傲慢、自負,忘記了這些基本步驟

我想,這種回顧對醫生進步很有幫助,但做法實在讓人抖不過氣,很大壓力。(當然,不能忽略,電影節目為了增加吸引力,而設定這種回顧的方法哈哈。)


最近公司每天的工作也是抖不過氣。

隨著死線接近,越近就越挑戰著半年以來,堅持之下的固定模式:每天Refactoring,不論大小。每次都作一點兒嘗試,去做好每一個功能,不論大小。

很高興在兩次的 Milestone中,都發揮著平日Clean Code的優勢:臨時在Demo前要求加上的新功能,都能夠加,並以一種快靚正的方式,嚇到了不少同事。(本來不需要OT啊不過團隊都加班我不用又好像說不過去…?)

可惜的是,如果沒有同事們的通力合作,隨著編程時間越久,就越覺得阻止不了爛Code的出現。或許事情未變太壞,「針唔拮到肉,都係唔知痛」。我覺得編程與醫生有兩種相同之處:

  1. 基本步驟
  2. 沒有醫生未犯過錯

正常情況下,沒有外科醫生不洗手就動手術的。

正如沒有經過時間去思考如何擴充系統,沒有了解清楚就設計了一個過度設計結構,沒有嘗試了解清楚問題就亂去訂解決辦法,只會為未來帶來很多不必要的問題,在時間和人手緊拙的情況下,就更能放大這些,本身看起來很小的「小」問題。

我想,基本步驟就是需要每一個位置多一份「小心翼翼」。技術上可以引入Unit Testing, Integration Testing, TDD, BDD, 慢慢做小心做;Code Review,每次Sprint收窄範圍,釐清問題與收貨條件,團隊隊員清楚要實作的功能後,即使在死線之前,也不用太著急;問題與方法分開思考,越懂思考別人提出的想法,背後想解決的問題,總會有一些更容易解決的辦法;遏止不斷渴望增加功能的衝動,反思每個功能背後的重要性;越多你不需要做的事,就越能將時間,放在最重要的事情上。

團隊看來太少時間回顧一直發生的問題,又很少投放時間於「重要但不急」上,所以往往到死線前,總是心急如焚吧。

犯錯是不能避免,但降低犯錯後帶來的後果,其實一樣重要。


我想,我也要學會謙卑,忽略了學習的機會。就正如那位,犯了一次錯的醫生一樣。