星期六, 2月 25, 2006

交接與傳承

最近每天都在忙碌地修改程式、準備投影片,卻看不到系統有多大的改進。

怎麼會這樣?我想,是因為自己並不是真的了解體會,「收尾」的困難處。此外,因為我並不喜歡虎頭蛇尾的感覺,因此總想把「整件事情」做到比較能令自己滿意的地步。

很早以前,就已經打算把 prototype 在適當的時機傳承給其他人;半個月前,甚至已經找到相關的人力(就是實驗室的學弟妹啦)。然而,系統交接與傳承,如果只是把手頭的程式打個包,簡單地寫些文件,通常下場都是草草收尾,承接的人怨聲載道,恨不得重新開發一個系統。

系統的傳承中,我覺得應該包含了「溝通」。要傳交出去的人,應該讓承接的人,了解到他們想了解的系統背景、模型、架構、設計、與實作。以實驗室的例子來說,這些了解,甚至應該包含「當初為什麼要採取這樣的作法、從中間學到了什麼教訓」等等。

溝通可不是一件容易事 --- 至少,我一直都不擅長溝通。要充分溝通,除了彼此都需要投入許多時間與精力,他們之間更需要有相當的互信與尊重。不過,或許是因為現代人太追求快速,因此典型的交接,才會變成「打包」、「寫些文件交代程式各做些什麼」吧。

另一方面,在工作上「人員的流動頻繁」是項現實。我想,「流程標準化」之所以重要的原因之一,或許就是因為它有這樣的優點:傳與承、交與接的兩方,都對這項標準有者相當程度的共識,因而能夠有效降低交接傳承的成本。

7 則留言:

lcat 提到...

職場上技術傳承的實際困難點在於:「Job Security」。

一旦技術容易交接,大部分的技術人員會擔心老闆是不是隨時可以找人來替換你,所以大家都不太願意真心將自己的經驗傳承下去,反而「留一手」成為常態。

被掛掉的阿尼 提到...

這種人我倒不常遇到, 技術人員通常滿可愛的
只是通常老闆把交接跟教育新人搞錯, 而技術人員常常會覺得很多他會的是理所當然要會的.
什麼是基本能力的, 什麼是工作內容, 有時候也很難界定

tu 提到...

當飯碗可能不保時,「留一手」或許也是人之常態。阿尼很少遇到,那是因為他碰到的技術人員,真的都比較純真啊!

然而,即使是不想留一手,交接與傳承都依然困難重重,不似想像般容易。這或許也是「理論與實際」的差異吧。

lcat 提到...

最早會有這種想法,主要是六年前在 yahoo 上IBM員工的 Forum,有人提到 IBM 要做知識管理,於是有同事很不客氣的說,交出去了怎麼保障自己?也許老外比較重視 Job Security吧? :P

不過有些工作像藝術創作一樣,小技巧是可以傳授的,但是怎麼教人臨機一動呢? *_<

mph 提到...

看從什麼角度想,廖有些同事可算是「Job Security」的典型。我感覺主要是自信的問題,大部份會保留的都是自信不足的人,比較有自信的人很少留一手。當然也有人對手上的東西很有信心,緊抓著來個奇貨可居,不過比例上少啦,畢竟並沒有那麼多奇貨吧。

只是以整體就業市場來看,或許沒自信的人還是佔大多數吧。

匿名 提到...

簡單的心理分析,如果事情的難度大於作事情的意願,大概事情就不太會被作成功.
且不論人的私心,技術交接本來就不容易,容易也就不用花功夫去交接了...再加上人的個性習慣合不合?溝通順不順?時間配不配合...
嗯..技術交接作不好是正常的,作得好一定是有其成功的背景(有制度 or 至少一方有熱情 or 兩方很合...)
至於私心人皆有之,討論它會討論不完的....

被掛掉的阿尼 提到...

mmm...可能被我視為技術人員的, 要有一定的呆伯特度吧, 呆伯特體內的鈣質通常是稍微多了一點, 所以不會死巴著工作不放. 廖的說法, 以前在幫老闆包case時, 就遇到過一些這樣子的公務員, 好心幫忙找問題還會被找麻煩, 後來學會幫他們解決問題要留一些人工步驟(一定要點個確認之類的)