Brian Sletten — Fairfax, Virginia, USA

失敗的責任不只在開發者#

當組織的軟體專案出問題時，我們習慣怪罪開發者：錯過截止日、Bug 滿天飛，人們開始懷疑團隊能力不足。然而，成功的軟體專案需要所有利害關係人的積極且充分參與——將失敗全歸咎於開發團隊，是不完整也不公平的。

為什麼人人參與至關重要#

要防範失敗，你需要清楚掌握：

• 誰在建置什麼、何時完成、為何這樣做
• 以有意、優先排序的方式加入業務功能
• 及早發現需求捕捉和表達上的問題
• 識別潛在阻礙：可能成為瓶頸的人、溝通失效、過於衝勁十足但已超載的開發團隊

核心觀念： 開發軟體需要有效的度量指標（Metrics）、清晰的溝通，以及投入其中的業務端和高層利害關係人。他們必須參與軟體交付過程，並對正面和負面結果共同承擔責任。

追蹤紀錄與問責#

專案經理需要衡量和追蹤團隊的成功與失敗記錄：

• 持續交付的團隊可以被信任繼續如此
• 鮮少交付的團隊需要更多監督、進一步培訓、重新校準，或許需要讓某些成員離開

技術債不能無限累積#

技術債（Technical Debt）概念： Wiki 先驅 Ward Cunningham 提出這個術語。如同真實的負債，若不持續且負責任地償還，技術債會變得難以控制，最終消耗過多資源。

給軟體團隊清理自己製造的混亂的時間，這不是縱容，而是現實。每次迭代（Iteration）的工作應包含：

• 新的業務功能開發
• 對程式碼中不可避免的「快速解法（hacks）」進行重構（Refactoring）

這既不是偷懶的藉口，也不是開發能力差的象徵——它是程式開發的現實，需要高層利害關係人的全力支持。

組織對開發者的投資義務#

組織必須承諾：

• 追蹤產業趨勢，引進工具，採用能提升生產力的開發實踐
• 鼓勵開發者拓展知識，包括下班後的自主學習——探索新工具、接受培訓、參加高品質研討會、閱讀書籍和部落格
• 舉辦團隊知識分享午餐，以低成本促進知識流通和新想法的萌生

組織回報： 感受到組織支持的軟體工程師，往往更忠誠、更願意多付出一分，也更有能力應對需求和技術環境的變化。

結語#

軟體產業還有大量工作要做，才能讓從業者更一致地交付高品質、如期的版本。在所有層面積極參與軟體建置過程的組織，才能提升自身持續、可重複成功的機率。

詞彙說明