2002/03/30

程式設計師的工作慣性


這次要討論的主體可能跟創新的關係很小,請容許我離題。一般來講年後換工作的風潮在各個行業都會發生,我們來分析一下程式設計師工作的型態,這些分析可能在各行業都可以適用。

首先,我面對到程式設計師換工作的主要原因大部分是認為原來的工作創新度不足,使用的開發工具比較舊,原系統已經不做大幅度開發,只作例行性的維護,缺乏新鮮感,種種的跡象顯示很難獲得成就感,或者是無法獲得大家的一致的認同有價值。

但是,這時候程式設計師的確是一樣的忙碌,每有忙著救火,卻得不到掌聲,如果你正式處於這種狀況,你第一個想到解決的辦法就是換工作吧!然後原公司可能會在找一個人頂替你的位置,而你接觸新的工作,同樣的狀況兩年後又發生一次,這是一個無法解決的惡性循環。

問體出現在哪裡呢?我想並不是技術能力的不足,而是錯估了處理問體所花的成本,接專案的人總認為有一個洞,把他補起來就好了,哪知道有很多洞要補,而且補了洞還不一定知道是不是會產生另一個洞,所以需要從系統架構上的問題去了解,然後再來解決。

第二,可能是在系統整合上的問題,現在的系統大部分是採用開放式的架構,大家協同把所有的子系統放上去,第一次整合測試沒問題,第二次也沒問題,測試過後就上線了,但是系統運作的時間久了之後,有的子系統因為檔案讀取失敗,資料庫沒有正常運作,或者是當初沒有考量道的錯誤,造成平常操作人員的困擾,因為程式設計人員也換過了好幾代,文件不齊全,原始程式碼沒有說明,導致無法找出問題點。

這一類的程式設計師總覺得自己在接爛攤子,接愈多包袱愈大,最後只好選擇丟掉,其實,要解決整合的問題,別無他法,就是程式設計師或者操作人員下去做分析,詳細的一步一步的把錯誤訊息找出原因,然後把問題發生的狀況紀錄分析,然後看是要改程式來解決,或者是從作業流程去改變,這個以目前用 Excel 來做應該都綽綽有餘了,這個過程可能隨時都在做,但必須密集的去分析解決。

最後,可能跟資源的整合或是分開有關,公司會資源整合一定是有某些產品的收入不合經濟效應,所以一個人本來負責一個產品或專案,但是可能一個人變成負責兩樣產品,如果程式設計師還認為事情是Double 的話就錯了,可能剛開始的時候是這樣,既然負責了兩件事情,就要把程式碼變成一份,這樣慢慢地就變成一件事情了,不然比較差的方法就是安排事情的重要程度來處理。

另外最重要的想要換工作除了是被挖角跳槽之外,其實也有景氣循環這一回事,景氣不好的時候,開發新功能新產品的事情是比較少,維護程式系統的事情比較多,認清楚你的專長是在開發新系統還是在維護系統,在搭配業界的景氣循環,才不會永遠在景氣循環或是過年的時候換工作。

總共有3個迴響

  1. Liu 1/09/2008 11:36 上午
    作者已經移除這則留言。
  2. zeelot 1/09/2008 11:38 上午

    我沒有讀過水瓶子之前的文章,可是看到這篇文章我身有同感,過去帶領軟體團隊的時候往往遇到無法跳出迷思的設計師,往往到最後都只能看著他離開的背影。然後過幾個月後接到這些過去團對成員的電話,繼續抱怨著現在的公司出現類似的狀況,接著開始認為整個產業都有問題。諸如此類的問題我認為無論國內外應該都有出現,軟體專案在我所知的專案管理裡面算是複雜性最高的,但是心態這種事情,在我合作過的國外團隊裡就相對的有成熟的認知。雖然我現在轉換到其他的部門擔任主管,但看著下一個接任的PM面對同樣的問題出現,大家都為了如何建立工程師正確的心態而需要花非常多的時間,這種事情對生產力來說在我看來是有相當程度的影響。

    不知道你在這方面有什麼見解嗎?

  3. 水瓶子 1/10/2008 7:11 下午

    我很想停下來思考最近幾年有甚麼樣的轉變,重新讀了我以前寫的文章,基本想法沒有甚麼改變,可是會有不同的體認,例如目前軟體程式工程師的分工模式因為網路的發達,似乎這幾年已經不同,以往可以單打獨鬥,或是小組就可以搞定的事情,現在雖然也可以,可是要搭配的先決條件已經不同。

    真的想靜下來思考,但是最近實在沒時間,對 zeelot 很抱歉,也對我自己很抱歉,我應該是多花點時間思考的。