程式過客

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

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

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

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

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

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

時勢造英雄,我想多半是這樣的。
Copyright © 2012. Huan-Lin 學習筆記 - All Rights Reserved
Powered by Blogger
Template Design by Cool Blogger Tutorials
Published by Templates Doctor