標籤

2012年12月13日 星期四

[emotion] 我們是如何培養想要的人力?

最近因為時常發生resource conflict或者是可用工時不足的問題,導致自己一直在思考這個過程,其實回想幾個月前我也曾經在一場內部會議中跟在座長官們陳述相同但較簡單的說明。想不到,現在我們還在原地踏地,而我也還未找到改善方法,該打!

腦子中的思路起點是以我自己的學習途徑當作template,試圖一站一站的分析人力養成過程(我也很懷疑我算不算人才?)。

一個新手(先不管之前的工作背景,或者是剛畢業的新生)進來後會有哪些方法來進入狀況:
  1. 閱讀文件。(有蠻大比例的文件其實是沒有up-to-date的)。
  2. 資深同仁培訓。
  3. 看Source Code。
  4. 動手解Bug。
  5. 開發Feature。
  6. Support客戶的工作。

應該沒有漏掉任何一項,但回頭細看上述的項目會覺得:我們應該是要找超人,什麼都會都能解決的工程師。

個人經驗這6點最理想的狀況是依序發生,但事實上卻有可能是同時發生的,比方說:前3點,甚至是第4點也會發生。其實最快速讓自己上手的方法是解Bug,因為如果你發現要看的Source Code的大小有上百MB的話,單單只是trace code很沒有目的,也沒有效率,更容易發生的是看不下去。

其實環顧一下,比方說我自己到國外客戶那觀察到的,會當FAE或者是QA的人很多之前都是RD轉任的,也代表著他們對產品的掌握度很高,知道發生問題時,可能問題點。但反觀台灣卻不是這麼一回事。

而我自己心中定義的培訓完成是指可以開始support客戶,因為這時代表同仁已經準備就緒,可以足以應付客戶端的攻防。

之前曾有同仁反應context switch太快,這我承認是事實,卻也是要面對的現況,目前這麼競爭的市場情狀況,身為軟體工程師必須要調適自己改變的,就像有人可以由底層driver,一路到上層application開發都可以做,坦白說這是個人能力的擴展。

當resource conflict發生時,第一個被問到的問題幾乎都是:有其他resource可以進來嗎?
這時,數一數人力分配如果有空的resource出現,但如果這位同仁不熟悉要緊急支援的技術,那試問你會舉手說:有人可以支援嗎?

我自己會舉手,但會加但書就是進來後加乘的效果不會立即發生,需要點時間才能解決目前的窘境。但長官或客戶買單嗎?

因為這個系統很huge,不瞭解的人其實永遠都想不通,為什麼客戶簡單的問題,你要花好久的時間,小到幾個小時,大到幾天才能找到solution解決,甚至只能找到答案回答他們。(如果要快速的可以回答問題,通常是找原作者問,但偏偏原作者通常不會正好可以讓你問!)

目前我就面臨到很類似的case,所以自己也在回想整個流程還有改善方法,也才寫了這一篇blog。


PS:這個道理其實跟我自己有些新的東西要學很像,常常想學,但沒去規劃如何執行,結果時間久了,還是在原地踏步一樣。