如何讓軟體被看見？

《溫伯格的軟體管理學》共有四冊，本書為第二冊，談的是專案經理如何具備觀察以及正確解讀專案各種資訊的能力。就像開車需要看儀表板一樣，管理專案要看哪些指標？這些指標怎麼用？所代表的意義是什麼？透過正確的觀察才可能有效地提早發現，甚至預防專案問題的發生，降低開發成本。

克勞斯比（Philip Crosby）把文化模式的觀念引用到工業生產過程的研究上，他發現組成一門技術的各種生產過程並不是一種隨機的組合，而是由一套有先後關係的模式所組成：半信半疑（Uncertainty）、覺醒（Awakening）、啟蒙（Enlightenment）、明智（Wisdom）和確信（Certainty），此模式是根據管理階層的態度來分類。
能夠分辨穩定系統與不穩定系統間的差異，這對於管理階層極其重要。對穩定系統加以改善完全是管理階層的責任。一個系統穩定與否，取決於系統的表現是否可以預測。系統達到穩定的方法是將所遇到問題的特殊成因一一排除，而偵測問題最好的方法則是利用統計信號（statistical signal）。──戴明（W. Edwards Deming）

戴明和克勞斯比兩人對於品質所持的觀念都是來自製造業的經驗。然而，軟體開發的工作根本上不屬於製造性質的作業，因為完全相同的軟體我們（在正常情況下）絕對不會開發兩次。

為了更深入了解如何改善軟體品質，我們需要利用來自其他領域的經驗來擴充他們兩人的觀念。這是為什麼我們需要研究如何管理工程性的專案。
然而，從更底層來看，製造業的管理和專案管理兩者都用到控制論模型。我們將此模型重複放在圖3-1，但加了一樣東西：從「軟體」和「其他輸出」多出來兩條回饋線路，蓋上「看不見的」印章，其中一個原因是因為軟體天生就是看不見的，除非我們設法讓它看得見。

在一個建築專案的進行期間，我們可以看見建築物不斷增高；但是在一個軟體專案的進行期間，我們唯一能看見的就是一個程式設計師在那兒盯著螢幕看。為了能夠將其他領域的品質觀念應用到軟體工程上，我們首先必須克服「看不見」這個問題。

利用感覺的各種主形式
在扮演觀察者的角色時，人們通常可利用以下的感覺主形式（modality）：視覺、聽覺、動覺、嗅覺以及味覺。

我們都有自己最喜好的感覺主形式，不過，若是不能使用最喜好的方式，我們仍能很快適應，改用其他的方式。

在觀察特殊的狀況時可能會偏好利用某些感覺主形式。以軟體管理的情況為例，氣味和味道通常沒有什麼用處。某些人也會偏好利用某些感覺主形式。在美國，視覺是最慣用的方式，但聽覺和動覺也不少見。

若是不准人們利用他們所慣用的感覺主形式，他們會改用其他的感覺主形式。例如，我偏好用我的眼睛來獲得資訊，但我也能用電話與人交談。不過，我在電話上不如與人面對面那麼自在。同樣的，我也能在一個不熟悉的汽車旅館中漆黑的房間裡摸索找到電燈開關的位置。

雖然人們少了某些感覺主形式仍能適應，但他們比較喜歡改變環境，省得自己還要去適應。雖然我能在黑暗中摸索前進，但我寧願不這麼做，因此我旅行時都會帶個手電筒，以避免遇到這種情況。

如何讓軟體成為可見的
不幸的是，當我形容軟體是「不可見的」時，我指的是所有的感覺主形式，因此若想用其他的感覺主形式來補償那是不可能的。不可見的意思是無法進行觀察。對於軟體，我們既不能看、聽、感覺、嚐到它，也聞不到它。如果我們能夠感覺到磁碟表面的小磁區，或是晶片上的電子，我們就可以直接讀取軟體的內容，但我們無法做到。我們無法感覺到軟體，但我們可以感覺到它在人們身上所造成的影響。

我們只能透過某種轉換的過程，利用間接的方式來體驗軟體，雖然程式設計師通常說話的方式就好像他們可以直接接觸到軟體似的（「我把這個指令搬到別的模組去」），甚至好像他們自己就是軟體（「我從這個資料結構裡取得它的數值，然後把它搬到記錄器上」）。

除了這些速記式的說話方式外，一定還有一套轉換的過程。的確，轉換過程若是失敗，我們想控制軟體的努力就會遇到非常嚴重的麻煩。例如，我們利用dump格式化程式的方法使儲存於當機的應用程式中的軟體可以被我們看見。如果有誰曾經試圖利用一個不可靠的dump程式來幫忙找出程式的缺陷，他將永遠不會忘記這個經驗的挫折感有多麼強烈。

顯示邏輯
有為數相當龐大的軟體工具都是為了讓軟體成為可見的，這件事絲毫不足為奇。我們會利用格式化dump、交互參照表、各式流程圖、Nassi-Shneiderman圖、資料流圖、複雜性圖、Wiggle圖、實體-關係圖、螢幕畫面、資料鍵入格式、輸出格式、單一線索圖、HIPO圖以及許多各式的圖表。甚至有工具讓軟體變成可聽見或可觸摸，以便視障的程式設計師可以使用。

這些供觀察用的工具之於軟體，猶如雷達之於戰爭：它們讓「在黑暗中」掌舵成為可能。

顯示品質
圖3-2是一個相當典型的方法來顯示一組模組已呈報的功能失常，它也就是軟體的一張圖片。圖3-2並不顯示系統的邏輯，反之，其中的棒狀圖形讓我們看見軟體品質的一個面向：軟體各組件之功能失常的模式。對想要管理軟體開發過程的人來說，看像這樣的品質資訊要比看邏輯圖有趣多了，尤其是如果這個人不了解該程式的邏輯的話。

利用次形式以促進溝通
一般而言，每個人對資訊的呈現和接受都有其獨特的偏好。這樣的獨特性有些是植根於感覺主形式的偏好，有些則植根於個人經驗或目的上的差異。例如，程式設計師可能看邏輯性的圖（諸如流程圖）比較順，而經理人員可能偏好含有評量值的圖表。圖3-2中有關功能失常率的資訊如果能以圖3-3的形式來呈現，可能比較容易為程式設計師所接受，圖3-3是這個系統的流程圖，陰影的深度與每個模組的功能失常率成正比。這樣的圖表比單單使用流程圖或直方圖可提供程式設計師與經理人員間更好的溝通媒介。

結合多種感覺次形式以傳達更多訊息
圖3-4除了陰影的深淺外，還利用形狀的大小來強化傳達的資訊。大小和深淺都是視覺形式中的次形式（submodalities）。利用愈多的次形式來承載相同的資訊，所傳達的訊息就愈強烈。圖3-4的訊息會讓經理人看到之後難以忽視。

更重要的是，結合多種的次形式可以傳達更多的訊息，因為對形狀的大小、陰影的深淺、或其他的次形式並不是每個人都同樣的重視。如果只以形狀的大小來呈現，某些人會抓不到重點。如果只利用陰影的深淺，某些人則會接收不到訊息。

選擇扭曲或重複呈現
從另一個角度來看，對一個非常重視形狀大小和陰影深淺的觀察者來說，圖3-4就將資訊稍微扭曲了。理論上，要傳達資訊只需用到一種感覺的次形式即可，因此圖3-4的資訊有重複呈現的現象。如果資料本身尚不足以讓結論顯得理所當然，可利用類似這樣視覺重複呈現的方法來凸顯自己的結論。

將資料像這樣的扭曲法在科學上是禁止使用的，但是在管理上就有充分的理由可以使用。專案經理在研究功能失常的資料時不會有那麼多的時間去完全符合科學的要求。他們為了能控制軟體開發過程，他們的反應必須隨著資料的意義做調整，如此方能獲致專案的成功。為達此目的，即使更加扭曲的資訊也是合理的，正如圖3-5所示，圖中所說的意思其實是，「此刻，除了C101和B102之外，其他的模組都不用管。把你擅長偵錯的高手用來對付C101，第二高手對付B102，以找出它們為什麼會成為易於出錯的模組，並重新設計這兩個模組，愈快愈好。」

實際上圖3-5的重點還可用重複呈現法做更進一步的強調（或扭曲）。加上「易出錯的模組」和「合理的模組」的標題可增加語言的感覺次形式。由語言所組成的資訊可能是由聽覺所蒐集的資訊中最重要的一種感覺次形式。在技術上，這些字雖然是印在紙上，但閱讀這些字通常需要用到聽覺系統。再加上這第二種感覺主形式可以大大地強化（或扭曲）訊息。

扭曲的有多嚴重？
「扭曲」聽起來是負面的東西。一個未被扭曲的軟體的圖片不是比較好嗎？那可能會長成這個樣子：
......1101101010010100100100101010101000100101010101111110 1001010101000010101010000101001011101010100000101001010001
0101001001010010000101001001010010101010010010000000010100
101001110101000100111101011011010101001101001......

對專案的管理階層來說這樣的資料有用嗎？好像沒有什麼用處。雖然一個有一億個位元所組成的字串或許忠實地承載了一個程式的所有資訊，但人類的大腦並無法有效處理這種形式如此大量的資料。
因為我們大腦的容量有限，因此我們需要有另一種的圖片。那些圖片受到扭曲的部分正是我們為了克服我們先天心智上的限制而不得不付出的代價。

每一張軟體的圖片就是開發過程的地圖，而這個地圖並不是地形圖。除了位元的字串之外，每張地圖會強調某些面向，但也弱化其他的面向。這是我們使用地圖的原因，因此若是不說明我們使用地圖的目的何在，就無法判定某張特定的地圖的「好壞」，如同下面這個例子所闡述的：假設在圖3-3的系統中，主要的執行路徑（可處理99%的資料）是：A101－A102－A103－B103－B104－B105
再假設圖3-3中模組A101的某個缺陷是有阻擋功能的缺陷（blocking fault，此缺陷會阻擋控制流進入該程式的某些部分），或是阻止某些資料項目的取得，或是阻止某些測試的執行。

假設此阻擋性的缺陷會阻止大部分的測試都無法觸及A102，導致所執行的測試有90%都因此跑到B101去，即使B101在實際執行測試時只能代表1%的測試案例。

在此例中，圖3-5所建議的A101是「合理的模組」就是一種嚴重的扭曲。相同的，圖中建議A102、A103、B103、B104和B105是「合理的」就無法從測試資料來證明，因為此阻擋性的缺陷保證這些模組在測試時從來不會被執行到。

在軟體工程領域，統計式的觀察（例如每一模組的功能失常次數）僅只是「將所遇到問題的特殊成因一一排除」的過程中的第一步。
在此例中，管理階層若是得不到了解程式碼結構的人的指點，是無從了解這些統計數字的含意的，正如同程式設計師若是沒有自己在設計上的功能失常所造成之後果的統計資料，就無從了解程式碼缺陷的重要性：
利用評量數字之前，要先去了解評量數字背後的故事。

這個故事的寓意是，如果軟體的工程師和經理人不想受到錯誤推斷的誤導，以為會走向康莊大道，結果卻步入危機，那麼，我們想要走過相同地形的話，就需要有那麼多種地圖（許多種可用視覺辨識的方式，以及其他感覺主形式可感知的表達法）。每張地圖讓我們從某一特別角度來看系統，類似於一個房屋的各種設計圖，談結構有結構圖，談配線有配線圖，談景觀有景觀圖等等。這是為什麼不論何種工程領域，了解其歷史最好的方法就是去看它資訊表達方式的演變。這也是為什麼對於某些人我們要心存感謝，因為有他們的發明讓我們能夠用新方法來接收資訊，或將所接收到的資訊傳遞給他人。（摘錄整理自第一、三章）

用「嗅覺」判斷專案的「氣味」是否有問題

以軟體管理的情況為例，氣味和味道通常沒有什麼用處，不過一個好的經理人從來不會事先即排除某些事物。
實例1在美國文化裡，氣味這個東西我們在評論時會特別小心，除非那是令人愉悅的，或我們確信那產生氣味的人不會聽到我們的評論。雖然氣味不是軟體經理觀察時最重要的感覺主形式，氣味在許多場合還是能提供部分有用的資訊。不止一次，我利用工作團隊所發出的臭味，即可推論他們的閒暇時間都被工作占據，因此人們連洗澡或洗衣服的時間都沒有。讓這個問題浮出檯面可以使大家看清楚專案小組所依循的時程完全不切實際。

實例2緊張的情緒會改變氣味，尤其是在一個封閉的空間裡，而氣味的本身又會助長壓力。如同狄馬克和李斯特所指出的，每個程式設計師可使用的辦公室坪數，與生產力有著高度的相關性。在較擁擠的辦公環境，緊張所散發出來的氣味會造成生產力降低，還是它只是一個徵兆？或許兩者皆是，而且它們是在同一個互相強化的回饋循環裡。

實例3對軟體經理來說，味覺可能是觀察時最沒有用的一種感覺主形式。但是為了再次強調「我們不可排除任何一個資訊來源」，我有一個朋友，他號稱能夠從每個工作團隊所煮的咖啡來評鑑該機構的文化水平。我自己是不喝咖啡的，對於他所宣稱的事我無從判斷真偽。我懷疑他是利用咖啡來多跟一些人聊天，因而有機會可以觀察其他的東西。（摘錄整理自第三章）

溫伯格的軟體管理學 ：
　第一級評量（第2卷）
　傑拉爾德‧溫伯格（Gerald M. Weinberg）／著
　經濟新潮社出版
　售價：800元 

作者簡介─傑拉爾德‧溫伯格（Gerald M. Weinberg）

是美國軟體工程界大師級的人物。在40多年的軟體業生涯中，他曾任職於IBM、Ethnotech、水星計畫（美國第一個載人太空計畫），並曾任教於多所大學。1997年，溫伯格因其在軟體領域的傑出貢獻，入選為美國計算機博物館的「計算機名人堂」成員。他也榮獲J . - D .Warnier獎項中的「資訊科學類卓越獎」。

溫伯格共寫了30幾本書，包括《顧問成功的祕密》、《你想通了嗎？》、《領導的《程式設計的心理學》、《溫伯格的軟體管理學》等。他現在是Weinberg andWeinberg顧問公司負責人，他的網站是w w w . g e r -aldmweinberg.com。