程式過客

這是一件很多年前的往事,不知為什麼印象很深,最近又突然想起。

那年,我在一間不算大的公司裡寫程式,用的工具是 Borland Delphi,偶爾也寫點 C++。記得全公司好像就兩個人用 Delphi,一個是我,另一個就是老闆(我一直很佩服他)。有一次,幾個同事在辦公室閒聊,說到自己在對軟體開發這條路的想法,頗有「盍各言爾志」的 味道。某位仁兄的計畫是「打算先寫兩年程式,然後轉作 SA,磨練個兩三年的經驗,再升 PM。」我從小胸無大志,不知何謂長遠規劃,初次聽到這樣的「生涯發展路徑」,頓時覺得自己是否也該想想將來的路該怎麼走。

可是,當時我對未來的能見度大概就幾公尺遠(現在恐怕也差不多),只覺得自己可能會一直矇著頭寫程式,暗無天日,直到隧道盡頭冒出一點光,再循著光線摸索前進。

後來,我離開了那家公司,到別的地方繼續寫程式,除了參與一些新的軟體開發案,當然也少不了要維護前人留下來的 legacy code--寫程式很有趣,但修改別人的程式 bug 則是另一回事。我沒有再見到當初那位同事,也不知道他後來怎麼樣了,但是,這些年來,我似乎偶爾會在別人身上看到他的影子。我開始擔心,我參與的專案,PM 和 SA 是不是也都循著那樣的生涯路徑一路「升」上來的,我會不會碰到「說得一口好程式」的傢伙、會不會要維護他們寫的程式碼?(註:這裡的「說得一口好程式」,意思是程式撰寫經驗很有限、技術背景或 sense 不夠,卻常指點別人程式應怎麼寫;這樣的人總是認為「那些功能應該都很容易做到」,因而經常低估需求變動的成本、任意承諾需求,導致專案範圍不斷擴大、成本不斷增加,甚至懷疑開發人員的可行性評估老是在誆他。)

無論 PM、SA、SD、還是 PG(programmer),都各有其專業,團隊不應把工作流程的順序理所當然地視為職務的高低(否則測試人員不就更等而下之了?絕非如此!),然後想當然耳地任意指揮「下層」的團隊成員工作--這樣恐怕只會創造弱勢族群,令位於「下層」的人無心做好手邊的工作,老是想著「往上爬」。我懷疑「寫兩年程式就要轉做 SA」的念頭多少因此而起。而且,如此循環下去,推而廣之,恐怕很難造就專業的程式設計師,而是產生一堆「程式過客」。

都說軟體開發團隊裡不需要救火英雄了,但為什麼軟體專案老是有一堆爛攤子需要有人挺身而出力挽狂瀾?

時勢造英雄,我想多半是這樣的。

5 則留言:

  1. 非常贊同您的見解 ."不應把工作流程的順序理所當然地視為職務的高低"..但放眼看台灣現今的工作現象, 幾乎都是這樣的模式在進行著. 所謂的 "專業分工". 在這裡似乎沒有辦法執行, 因為老闆們總希望找到的員工, 是 "多元多工" 一人可以做完全部的事情的. 但是現實面卻是犧牲了品質, 當然..也幫我們這種一天到晚在收爛攤子的人創造了很多工作機會吧. = =..

    回覆刪除
  2. 小莎,
    「幫我們這種一天到晚在收爛攤子的人創造很多工作機會」,確實如此。但就怕造就了英雄之後,「獸鳥盡,良弓藏」。點到為止,相信你應該瞭解我的意思。
    碰到這種狀況時,又得提醒自己「用之則行,舍之則藏」。這可有點累人....

    回覆刪除
  3. 大推 "無論 PM、SA、SD、還是 PG(programmer),都各有其專業,團隊不應把工作流程的順序理所當然地視為職務的高低"
    這句話說的太好了, 沒錯, 每個角色都各有專業, 並不是職務高低!

    回覆刪除
  4. 本來就是各有專業,學了外國的分工原則,卻不懂得分工原則的要義,反而拿來當程職務高低來區別

    回覆刪除

技術提供:Blogger.
回頂端⬆️