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

23則回應

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

委外分包商管理

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

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

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

所以，主包業者提供者即使情感上相信分包廠商者可以「受人之託，忠人之事」，但卻不可以把分包商管理的成功與否置於這個假設當中，而要認清它是風險的來源並加以管理，這樣才能展現出專案管理者的積極態度與專業。

分析或猜測？

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

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

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

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

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

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

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

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

省略測試

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

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

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

  繼續閱讀： 開發過程的管理>>