小員工也能做大事

作者:周思博 (Joel Spolsky)
譯:Paul May 梅普華
Tuesday, December 25, 2001
屬於Joel on Software, http://www.joelonsoftware.com

這個站應該是關於軟體管理的,不過有時候你並沒有那個權力去改變組織的行政命令。很顯然的,如果你只是圖騰柱底層的一個普通程式師,絕對不可能命令大家開始建立時程或問題追蹤資料庫。事實上當你成為經理之後,可能會發現管理開發人員很像養貓,不過沒那麼有趣。光會說「照這樣做」並不真的能照這樣做。

在[約耳測試](/wiki/The_Joel_on_Software_Translation_Project:%E7%B4%84%E8%80%B3%E6%B8%AC%E8%A9%A6 “The Joel on Software Translation Project:約耳測試”)分數低的組織裡工作可能會讓人沮喪。不管你程式寫得多好,同事還是會寫出讓你羞與為伍的爛程式。另外管理階層在決定產品時也會作出爛決策,所以你只好被逼浪費自己的才能,去為針對兒童的AS/400版退休計劃遊戲除錯(譯註:誰家小孩會玩退休計劃遊戲,更別提能用到AS/400了)。

我建議你大可離開。不過萬一你基於某些原因必須繼續待著,比如股票選擇權還沒有到手,或是住的地方太小沒有 更好 的工作,又或許老闆抓了某個你愛的人作為人質。不管如何,在一個爛團隊裡討生活實在叫人抓狂。不過還是有些策略能從底層改善你的團隊,而我要與你分享其中幾項。

策略一 :去做就是了

有很多事一個人就可以改善專案。沒有每日編譯伺服器嗎?架一個。在你自己的機器上設一個定時的工作,在每天晚上編譯並把用電郵發送結果。編譯的步驟太多嗎?寫個makefile吧。沒有人做可使用度測試嗎?用幾張紙或VB原型自己去找收發室的人來做吧。

策略二 :利用病毒性行銷的威力

[約耳測試](/wiki/The_Joel_on_Software_Translation_Project:%E7%B4%84%E8%80%B3%E6%B8%AC%E8%A9%A6 “The Joel on Software Translation Project:約耳測試”)中很多策略都可以在不合作的團隊中一個人施行,其中有幾項做得好的話還能推廣到整個團隊。

舉例來說,假設團隊中沒人願意用[錯誤追蹤資料庫](/wiki/The_Joel_on_Software_Translation_Project:%E7%84%A1%E7%97%9B%E9%8C%AF%E8%AA%A4%E8%BF%BD%E8%B9%A4 “The Joel on Software Translation Project:無痛錯誤追蹤”)。別因此覺得困擾,自己去用就是了。把你自己程式裡找到的問題輸進資料庫。如果你找到確實是其他人該修的問題,就用錯誤資料庫把問題指派給他。如果你用了好的問題追蹤軟體,這時候就會用電子郵件通知他。沒有也不打緊,如果他們沒有修正問題,你還是可以 一直 寄電子郵件提醒。最後他們總會發現問題追蹤的價值,然後像自願般地開始使用這個系統。如果QA團隊拒絕把問題輸入問題追蹤資料庫,你只要拒絕其他方式的錯誤回報就好了。等你重複告訴大家約三千次:「請聽我說,我很想修好這個問題,不過我會忘記,能不能請你把問題輸到系統裡?」他們就會開始使用資料庫。

團隊裡沒有人要用源碼版本管理嗎?建立你自己的CVS儲存庫,必要時可以放在你自己的硬碟上。即使沒有人合作,你還是可以把其他人的程式自己放進系統。然後當他們發生某些可以用版本管理解決的問題(通常是誤把rm *~打成rm * ~)時,就會來找你幫助。最後大家都會知道他們自己也可以由版本管理取出程式碼。

策略三 :建立一個卓越圈(Pocket of Excellence)

團隊不排[時程](/wiki/The_Joel_on_Software_Translation_Project:%E7%84%A1%E7%97%9B%E8%BB%9F%E9%AB%94%E6%99%82%E7%A8%8B “The Joel on Software Translation Project:無痛軟體時程”)?不寫[規格](/wiki/The_Joel_on_Software_Translation_Project:%E7%84%A1%E7%97%9B%E5%8A%9F%E8%83%BD%E8%A6%8F%E6%A0%BC(%E4%B8%80) “The Joel on Software Translation Project:無痛功能規格(一)")?自己來寫吧。花一兩天針對你的工作寫份小規格和時程,不會有人因而抱怨的。

找些更好的人進團隊。想辦法參與雇用面試過程並招募好的人選來加入團隊。

找出那些願意又有能力改善的人,想辦法讓他們支持你。即使是再爛的團隊還是很可能有聰明人在,只是缺乏寫出好程式的經驗。幫助他們脫離困境,安排他們學習。看他們登入的程式,如果他們做了什麼蠢事,不要寫電郵高傲地指出他們的程式哪裡不對。這樣只會激怒並讓他們更加護短。應該故作無知地回報該錯誤會導致的問題,讓他們去找出原因。等他們自己找到問題,印象就會深刻多了。

策略四 :讓笨蛋無害

即使最好的團隊都會有一兩個笨蛋。團隊裡有爛程式師讓人頭痛的地方,就是他們的爛程式會攪亂你的好程式,另外就是好程式師得花時間幫壞程式師擦屁股。

身為底層工作人員,你的目標是損害最小化,也就是所謂的牽制策略。有時候這些天才會花兩星期寫出一點點程式,而且寫出來的東西爛到不可思議,完全不可能用。這時候你會很想花15分鐘把這段程式從頭再寫過。請忍住這種誘惑,因為這是個把這些白痴拖住幾個月的大好機會。只要一直報告那個程式的問題,他們就只好一直在這段程式卡 好幾個月 ,直到你找不到其他問題為止。而這幾個月他們就不會在其他地方造成傷害了。

策略五 :遠離干擾中斷

所有好的工作環境都一樣(個人辦公室,安靜的工作狀況,優越的工具,很少干擾和更少的大型會議)。而所有不好的工作環境都各有不好的原因。

不幸的是,幾乎在任何公司裡都不太可能改變工作環境。長期租賃表示可能連執行長都無計可施。這也說明了為何只有少數的軟體開發人員擁有自己的辦公室。對公司來說這會造成兩種傷害。首先是更難以請到頂尖的開發人員,這些人偏好能提供更佳環境(當其他條件相等時)的公司。其次是干擾的程度會讓開發人員的生產力急速下降,開發人員會發現自己根本無法進入狀況並專心工作。

想辦法離開那個環境。拿台筆記型電腦到公司的餐廳去,裡面有很多大多時候都空著的桌子(而且沒人找得到你)。可以把某間會議室預約一整天然後在裡面寫程式,然後用工作成果來證明,獨自在一個房間作業能完成的工作會多上許多。等下次出現緊急狀況,經理要求在明天之前完成工作時,你就知道要說什麼了。他們會找間辦公室給你在那天用,然後不久他們就會開始覺得應該整年都保有這種生產力。

上下班都晚一點。其他人下班之後的時間生產力最高。如果所在的開發團隊習慣晚到,你可以早上九點就來,在其他人上班干擾之後專心做事,這段時間的成果會比後面的時間加起來都多。

不要開著你的電郵和即時通訊。需要的話可以每小時去收一次信,不過 不要一直開著

策略六 :提升自己的價值

如果你並不是真的很有貢獻,這些策略通通都沒用。如果你寫不出好的程式,那麼你「應該」正在寫程式的時候,其實只是在問題資料庫裡浪費時間還惹人厭。如果你被掛上做不出東西卻只關心流程的惡名,大概就沒什麼職業生涯可言了。

曾經一度當我在某家新公司開始當個底層程式師時,發現公司[約耳測試](/wiki/The_Joel_on_Software_Translation_Project:%E7%B4%84%E8%80%B3%E6%B8%AC%E8%A9%A6 “The Joel on Software Translation Project:約耳測試”)大概只有兩分,於是我決定要改善這種狀況。不過我也知道良好的第一印象非常重要,所以安排自己在每天前七個小時都照大家的期望單純只寫程式。頻繁地把程式登入版本管理,是讓開發團隊認為你很好的最佳方法。不過我會在每天下午回家前保留一小時改善流程,利用那段時間修正讓產品難以除錯的問題。我架了一台每日編譯伺服器和一台問題追蹤資料庫,還把所有長久阻擾開發的煩惱都解決掉。我針對當天要做的事撰寫規格,也寫了文件逐步解釋如何從頭建立一台開發用的環境。內部有個重要的程式語言沒有任何文件,我也把它完整的文件做出來了。整個流程慢慢地變得愈來愈好。雖然除了我(還我帶的小組)之外沒有寫規格或時程,不過除此之外約耳測試已經提高到十分左右。

即使你沒有當家作主,還是 可以 讓事情變得更好,不過你必須像凱撒的妻子一樣無可質疑之處,否則就會一邊進行一邊樹敵。

有其他想法嗎?

這些網頁的內容為表達個人意見。
All contents Copyright © 1999-2006 by Joel Spolsky. All Rights Reserved.