大型公共建設軟體專案：讀者回響總結

| | | | | | 23則回應

    

讀者 NOVAASKA 提到，不管技術人資深與否，對於「更新系統」這件事本就該有一定的管理程序。他認為重點在「管理」，而不是「人」，「人」一定會有犯錯的機會，而「管理」可以減低犯錯的機率和風險。[問題發生]→[測試、修改、審核(loop)]→[發佈更新]已是最簡化的管理方式，如果說技術人的「猜測」可以讓[測試、修改、審核(loop)]的管理手段被省略，而直接對正式環境加以修改，無疑是這個系統的實務管理上出了大問題。

他同時提到了心態(或態度)的確是做任何事的基礎，因為太基礎，或許會直接去談論到建立在其上面的一切。德國汽車最被廣告宣傳的，是他們的工藝，而這種要求完善的工藝，建立在處理一切事物都需嚴謹的態度。這一點，是高鐵這個事件最容易被質疑的部分。

對 NOVAASKA 的這個看法，同人認同管理很重要，這也是我在該文章管理面著墨多於技術面的原因。然而，管理者卻不能忽略”人”的因素，不要以為流程與制度訂好就沒問題，把人只當成工具與機器，你的管理是不 work 的，因為對知識工作者而言，個人與團隊勝過流程與工具（〈敏捷軟體開發宣言〉）。

再多麼嚴謹的流程，對於沒有具備足夠紀律的團隊來說，還是沒有用的。很多人以為紀律就是按表操課就沒問題了，但這卻是最大的問題，沒有面對現實，流程只是手段而不是目標，造成目標與過程的混淆現象，同人常看到多數領導者有著管理上的迷思：對流程著迷，卻不知這是領導能力下降的徵兆（《專案管理之美學》）。

管理上的迷思，並不是缺少設備、資本及人力，而是缺少最重要以知識為核心的生產要素。知識不只是於技術而已，要做好專案管理，管理者需要”整合”使用者現場的領域知識、專案管理的專業知識及開發者的軟體開發經驗知識，缺一不可，這那是單純的技術知識單一角度可以詮釋的？

軟體是工藝或工程？同人認為都不是，而是問題解決的過程，這也就是我在技術面談的，重點在心態問題。什麼樣的心態？對問題採用合適的技術，並予以”調適”，然後熟練之，第一件事就是分析問題，問對的問題，而非許多技術人員習慣的用技術來主導問題方向，這才是我說的紀律，所我我才會說：”經由穩定及可見的觀察、假設後的求證、尋求問題的對策、最後再採取行動解決的過程，經驗往往是最不可靠的東西之一。態度才是決定技術得以成功的決定因素呀！”

至於誰要認錯，誰該負責，並不是我在該文中想要探討的，對於我而言，這種爭論一點意義都沒有。

讀者 NOVAASKA 對我的回應，提出了他的心得：

我比較有興趣的地方在於，很顯然的台鐵（同人按：應為高鐵之字誤）對於實務管理內的某些環節出了問題，以及你所謂的「猜測」行為對於管理層面上的衝擊。

誠如你所言，「人」的重要性超過「管理」，但「管理」不見的必須維持固定不變的模式，我們所討論的應該是「有效的」管理(以 “有效率且有效用的方式達成組織目標” 為目的)，如果因為人為因素或管理手段上的缺陷造成「無效的」管理，那也是管理上的必須加以修正的問題。

技術人若在良好的管理下，去「猜測」進而更動系統，這應該不是心態(或態度)的問題，而是觀念上的錯誤。如果管理上有制訂「系統異動」的程序，技術人員卻任意而為，他的立意並不是要破壞系統，心態上本意是良好的，但是觀念錯誤讓他誤以為可以不需遵循管理上的程序，或是認為不需先行建立測試環境來修改測試並加以評估，就算是心態良好但觀念錯誤，也很可能會為系統帶來災害。

有的人觀念和心態正確，按照管理上制訂好的規則按部就班的做，出了問題還有話可說。但若觀念正確卻心態不良，這就很可議了，管理上的確無法防範心態不良的技術人。

同人認為，讀者 NOVAASKA 的這段看法很有參考價值，同人也有一些看法想要補充。我認同團隊成員的行為立意上都是良善的，他們不會故意違反規定，所以很多情況是團隊成員觀念錯誤而導致錯行為的偏差，不過這通常發生在對技術能力較不熟的初學者而言，遇到這種情況，同人認為管理者負有訓練初學者的責任，讓他們儘快地知道自己不知道應該知道的事物。

不過，我在該文中要探討的不是這種狀況。我明知事情該這樣做，但卻不這樣做，我們不希望把問題歸因在個人故意不遵守規定上，那麼是什麼情況下讓我們不採取正規做法呢？不要忽略情境因素。在專案壓力大量湧現時，我不是要故意違反規定，而是人在江湖身不由己，於是開始捨本逐末以減輕壓力，但卻埋下了日後產生品質出問題乃至於專案管理失控的因子。

所以管理者必須及時洞悉這種問題，當壓力出現時，仍然堅持用正規的做法，讓專案的運作回歸常軌，否則專案出問題是必然的，只是時間早晚而已，而且愈晚出現所形成的災難愈難處理。當然，這不是三言兩語就可以說清楚的，在同人的網誌中也談了很多的有關軟體開發與專案管理的相關議題。

本文轉載自作者部落格。