大型公共建設軟體專案後續討論

同人先聲明，本篇文章不談高鐵，而是從我所寫的〈從高鐵談大型公共建設軟體開發專案〉的上下篇的讀者迴響中，發現有一些值得探討的議題，在此做個整理。

委外分包商管理

有讀者提到，大型公共建設軟體開發專案要讓大部分的人滿意，需要整體的合作與共識，所以他認為”分包委外服務提供者”既然受人之託，就要忠人之事，若能做到的話，相信”做好關係人管理，達到同時兼顧所有關係人的期待”將不會是一項挑戰。

對於這個看法，同人在情感上認同”受人之託，就要忠人之事，就可以做好關係人管理”，但在理智及經驗上，卻往往發現我們事情往往出乎我們意料之外。為什麼呢？人的問題實在複雜得超乎我們原先預期，除了資訊不對稱之外，利益的不相容所造成的代理問題外，還有對方是否值得信任的風險考量，背景與專業所造成的溝通困難等，都讓做好關係人管理這件事，充滿了變數，這對參與軟體開發實務管理者及開發者而言，是如人飲水，冷暖自知的呀。

當然，回到初心是最美的。讓專案關鍵關係人共同朝著目標前進，專案才會有成功的機會，這是大家都很清楚的，然而，壞就壞在我們常忽略了目標是有可能是不相容的，大家對目標的優先順序常常是不一樣的，分包委外提供者有時候並不是不願意忠人之事，而是一旦其公司遭逢更大的壓力時，這時他是很難再履行他原先的承諾的。同人就曾聽過有分包委外提供者向主包委外提供者兩手一攤，即使主包委外提供者可以向他們求償甚至讓他們倒閉，對專案也無濟於事，這時對主包委外提供者來說，真是苦不堪言。

所以，對於主包委外服務提供者而言，即使在情感上相信分包委外服務提供者可以＂受人之託，忠人之事＂，但卻不可以把委外分包商管理的成功與否依賴在這個假設當中，而是要識別出這是個風險的來源，並加以管理，這樣做才是展現出專案管理者的積極態度與專業。

分析或猜測？

許多讀者對於同人的「不要猜測問題」的觀點，表達了他們的看法。Luke 認為當系統出問題時，需要猜測問題的所在，而且應該假設有錯誤的地方不在表面上看到的那樣，並透過排除絕對不可能的部份，試圖讓問題縮小，然後找到最可能的原因，最後再靠一針見血的猜測把問題抓出來。

NOVAASKA 認為，資深的技術人員對於問題發生的第一時間，會根據過往的經驗來加以分析問題可能出現的癥結，在這之前只能稱做是『分析』，而不是『解決』。他疑惑同人的說法，以為這樣變成「用猜測的方式來解決」，並質疑：難道「資深的技術人員」習慣分析後不需要實做和驗證就宣稱「問題已解決」了嗎？

同人認為這些對於猜測問題的爭議點，是出在我們對文字上定義的不同。同人在文中提到許多技術人員習於以自己所熟知的技術經驗，來尋求問題解答，卻未先去深入探討問題本身。所強調的是開發者沒有先進行分析問題的步驟，就逕自動手處理問題的猜問題行為，而不是指在解決問題的過程中，試圖找出問題成因的歸納手法。

所以，如果我們對問題所做的猜測或假設都經過求證的步驟，就不是我文中所言的「猜測問題」。不過，在此同人還是要提醒一件事，那就是即使如 Luke 所說的，我們能一針見血的猜測把問題抓出來，還是需要經過求證的過程，問題不可能只用猜的就可以把它找出來。

分析或猜測問題的差異，表面上看起來做法差不多，但其實其關鍵在於態度。同人認為猜測與分析的差別所在，就是前者在猜測未證實以前就採取行動，動手修改程式，卻常常愈改愈慘，因為這種處理問題心態靠的是運氣。

後者會根據程式運作的記錄與數據來研判，必要時，會寫測試程式來驗證假設是否成立，確認無誤後才動手修改程式。

不幸的是，實務上，前者的情況非常常見，所以我才會特別強調”解決問題的心態”。同人依據實務工作經驗認為，解決問題一定會要先弄清楚問題的徵結在那裡，而不要先思考如何修改程式，因為這樣做就好像亂槍打鳥，要根本解決問題的機率是很低的。

很明顯地，同人文中提到的「猜問題」與許多讀者心中所認定的「猜測」定義並不相同。他們的猜測是動詞，是問題的歸納過程，但我所謂的猜問題是名詞，指的是”以懷疑當事實，推論當結論”的過程，未經驗證假設就貿然採取解決問題的行動。然而，很多時候，相同詞彙本來就會因人、因時、因地而有不同定義，其實只要說清楚就不會有認知上的誤解了。

省略測試

有讀者提到他的經驗，認為猜測在經驗老到的人而言是很精準的，問題在有經驗的人腦中事實上經過分析，挑出最可能的原因來看程式碼來測試。

同人認為這樣做當然沒問題，但我擔心的是有些自認經驗老到的人，會挑出他認為最有可能的原因來改程式碼，未詳加測試而交付修正。在實務上，據我的觀察，有些人都認為要一眼看出問題，才能顯露出他的神力，所以愈不做測試愈代表他很利害，於是乎就有那麼多的問題會該測到卻沒真正測到。

一旦期待用整合測試來取代功能或單元測試時，這是品質必出問題的先兆，而實務上，許多專案管理者甚至開發者卻常忽略這個重點，他們實在不能體會測試上的蝴蝶效應將足以將系統帶向混沌的失控局面，關鍵還是面對現實的態度，將問題延後其實是很笨的做法，因為在測試上相信人性無異於向惡魔打交道。

開發過程的管理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Please follow and like us: