回顧時間

Polar bear Journal
Nov 9, 2017 · 3 min read

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

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

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

結果病人就死了。

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

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


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

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

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

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

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

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

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

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

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

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


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

Polar bear Journal

Written by

Agile lover. Chinese Calligraphy lover. Brain hacker. https://polarbearjournal.com

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade