在企業組織裡設計的挑戰

本文翻譯 Contextual Design 一書 (Amazon 記錄) 第 10 頁到第 16 頁 (Google Books 預覽)： The Challenge For Design in Organizations 。

在書中，「設計」一詞幾乎都是指「開發資訊系統」。

標色文字是我的註解。

---

在企業組織裡設計的挑戰

誰能說一套系統將能做什麼？真是行銷部門或系統分析師說：「搞出這個」，就能教開發團隊只跟隨規格做事嗎？或者，行銷人員或分析師真的只要說：「弄出『這一類的』東西」，開發團隊其實決定做他們想要做的以及決定系統該是哪個樣子？事實上，兩方人馬都要擔任說明新系統是什麼長相的角色──在企業組織裡，建立一套系統是他們這些人合作的結果？

下層的問題無可逃避。今日的系統太大，很難教一個人做完。所以企業組織把規定和建立系統的流程分為幾個部份，把每個部份指派給一小群人。每群人又特定他們負責的部份，與其他處理其餘部份的人失去聯係。在開發系統的事情上，有四個問題該答，這些問題傾向於將開發流程自然分割。所以很容易指定一群人回答一個問題。問題有這些：「工作中有哪些事項」──該認定工作的哪幾個方面；「該如何應對」──團隊該用什麼系統做應對；「系統該如何架構」──到底有什麼功能、功能的規劃、以及系統架構，能適合工作的需要；以及「我們做得怎麼樣」──所設計的系統真的能為客戶服務嗎？

(「工作中有哪些事項」──該認定工作的哪幾個方面 )

頭一個問題 (「有哪些？」) 是問，有哪些客戶的工作活動是新系統該認定的，有哪些提議或問題該克服、有哪些角色和工作項目有必要支援。指定回答這個問題的那群人是行銷人員或商務分析人員。在管理工作會改變企業組織的時候，他們常下指令定義企業資訊系統有哪些是要項。他們說：「採購的費用太多了。給每個部門一張信用卡，只有授權才准使用」、或說「咱們的化學資料庫是咱們的命脈。把所有資料庫跟公司綁在一起。」或者，行銷部們可能會告誡工程團隊說：「設計一項產品支援公司的計劃。」或「讓產品放到網路上。」這些指令說了好多高層次的工作方面的事項，要系統能夠幫忙，卻沒有實際定義系統。把產品放到網路上，影響工作的哪方面呢？把資料庫都綁在一起，意思是一個資料庫呢、重複的資料庫呢、還是一種搜索許多資料庫的方法？在那些設定方向的觀點上，上述問題則是細節，他們不必回答這些小問題。

(「該如何應對」──團隊該用什麼系統做應對 )

回答這些小問題，意味要說要應付些什麼：公司將要如何回應這些有關系統設計、流程、服務、以及發行策略的議題。行銷人員可能是定義回應方式的參與者，但除了公司都是技術導向之外。需求分析人員可能也是參與者，但除了這些人真的太不懂技術了，就要是開發人員來做了之外。客戶自己應該要涉入內部系統，因為系統定義了他們要怎麼工作。行銷人員和分析人員可能要得到正式許可「發展系統規格」，但是依照經驗，他們不在必須寫程式的層面中定義系統的行為。「他們丟了一份規格給我，」開發人員都這樣對我們說。接著，「但是老是有太多我們要決定的事情，而他們通常只問我們那些不夠實際的事情。所以這個叫做交換意見。」

(「系統該如何架構」──到底有什麼功能、功能的規劃、以及系統架構，能適合工作的需要 )

決定要怎麼架構系統，意味要具體決定要納入什麼功能，具體上系統怎麼動，還有系統會怎麼顯現視窗、選單或畫面。這幾乎都是開發人員做的事，也表示他們要了解使用系統的工作環境。要不然他們不能做什麼對客戶好的決定。開發團隊無法從行銷人員或分析師手中拿到客戶資料。做出詳細的系統架構仰賴於額外一層的客戶資料，開發人員要自己拿到──或者是，自己做出感覺對的系統。有些公司又走得很遠，把開發團隊擺在與他們客戶和分析師有差別的地位，創造了一群專精在他們設計工作中的人力。但那只是弄得需要更多溝通，而且如果缺少車馬費，就造成更嚴重的孤立。

(「我們做得怎麼樣」──所設計的系統真的能為客戶服務嗎 )

最後一個設計的問題，說，「我們做得怎麼樣？」這個問題是和客戶核對系統的進度，確認它還是個對的系統，而且在細節層次改動程式不會讓系統變得不能用。這個問題經常分割出去給一組可用度研究團隊或品質保障團隊做測試。回答這個問題，是檢查系統本身 (看看 bug 和是否符合規格) 以及跟使用者一起測試系統。但無論哪方面，處理檢查結果都是開發者的工作。所以，他們必須接收回報訊息，還要了解它並相信它──那表示他們要買進取得回報訊息的程序，並且信任收集回報訊息的人。並且經常是，到目前為止都沒有真的取得實際資料做設計，在這個時候發現的缺陷都是很基本，他們在開發階段很難確實找到的。

這些定義系統該如何的不同部份，若系統設計程序要啟動，就要一起做。界定應對方案的人要能答覆真實的問題；建立系統的人要建構他們認同的應對方案。但是，要保持每個問題都分別由指定的人來處理，會造就組織之間的溝通難題。開發的正式文件掌握擬定的設計方案，也要盡力控制各群人馬之間的溝通和歧見。「你們簽了協議。表示你們承諾了。」「是，不過我們已經了解並且真的不需要。」或「是的，但是我們與這位重要客戶談過，若我們沒有碰上需要，就沒有必要出貨。」或「是，但是依現有的技術我們真的沒能力實作。」

組織裡的設計，與在各群人之間發展同一凝聚的方向有關：符合他們打算交付的公司應對方式。並不是永不改變，而是在改變時，整個企業組織在各種功能上可以適當地回應，而不是將改變轉換為兩方人馬的叫囂。反過來說，同一凝聚的願景仰賴於在公司應對方向的發展之間多加考慮不同的觀點。行銷和分析人員需要科技方面的展望，看見新系統種類的契機。開發人員需要行銷觀點來看清為什麼有些走向造就好產品，有些卻不能。又需要分析師的看法，看到他們要處理的工作要點。資訊科技團隊需要客戶的看法，確定自己提議的工作流程變更很合理而且可採用。在他們發展出公司的應對方式之後，他們可以同時有效地做事，並且不會迷失方向。但是，在突出的設計上，跨功能團隊做得最好。

實際環境中的工作團隊

建立跨功能團隊來做一同的設計會執行出真實企業組織裡某些意外的問題。想想一個基本問題：這樣的團隊要符合什麼期待？快速檢視大部份組織的實際結構，就發現他們都做到讓人們分開。最常見的開發工作環境是小方塊，是一塊夠大的一人空間，可以舒服地做事，有電腦和桌子。但是那個區域沒有大到可以讓幾個人一起舒服地工作，也沒有一塊大的隔牆空間讓一支團隊工作。當然另外有會議室，但會議室的特色就是只能預約並共用幾個小時。因為預約時間有限，能提供的工作只是短時間完成的事情，不超過半天。以超過標準的方式預約這個房間，同事的樣子會讓你擺臭臉。畢竟是在浪費一塊公用空間。不但如此，因為房間是共用的，你不能擺太多東西。每次對談要從頭開始，每次會議要重新攤開設計圖。

所以會議室支援的工作是在能短時間做好，而不需要實體支援的類型──不要硬體、不要圖表，沒有你不能捲起來帶著走的東西。也許有網路線，但要接上哪個區域網路呢？網路品質還不錯吧？接上筆記型電腦怎麼樣呢？有這些限制，會不會有開發人員和工程師覺得開會浪費時間呢？有標準規模的公司的實體架構明白地說，真正的工程都在小方塊裡做成的，而人都來到會議室則是他們沒有真在做事。企業的普通結構，沒有可以支援面對面溝通而能啟動系統設計的。

管理面對面的設計

一同有效地工作，意思是擁有在其中能真正工作的場所，讓許多人面對面地完成工作。也意味了賦與人們人際能力和流程，使他們的聚集比較有效。有一位部門主管指出一件棘手的問題，是在當地旅店訂房間讓五位資深架構師待著，並告訴他們，如果不在一週內提出解決方案，就要辭退他們。他得到結果，而我們發現如果人們有合理的工作過程，通常會比較快樂、有創造力，並且更快產生結果。對程序的典型回應是「感謝你，我現在終於知道該做什麼。」即使痛恨程序的人也會這麼說。

一起工作是一種新技能。是學校沒教的事，也是工作很少教的事。一起有效地工作，意味要懂得怎麼時常維持設計方面的對話，要怎麼用心到工作要項而不是其他事情上，要怎麼掌控每個人的特質，還有要怎麼發現並指出歧見的根本原因。如果團隊不這樣做，他們的工作就會因為人們處理歧見的模式與保持他們愉快的工作凝聚力之間的取決，而遭受損失。

人們處理歧見的一種主要的模式是政治交易：「我覺得你弄錯了。但是，如果你給我一些對我來說比較重要的東西，我就容得了你。」政治交易帶出一套以拼湊為主的系統，缺少具備向心力的主題。而且政治交易讓團隊的每個人都減少對設計工作投注心力，因為每一位都至少要認同一個人的決定，而他認為那個決定是錯的。

也有其他處理歧見的方法，但是大都不夠好。有一種方法是妥協，說：「你說我們要把什麼都做成對話方塊，但我覺得應該要做成按鈕才對。所以，兩種都做，我們誰都高興了。」誰都高興了，不過使用者不高興。他們有一打達到功能的辦法，但是沒有好的理由說明哪個辦法比較好。或者，會有教師式的歧見處理方式，說：「大師最聰明，而且什麼都懂。我們要跟著做大師所說的。」這很好，但除了在科技環境、圖形使用者介面設計、使用者實際工作、行銷、專案規劃、以及其他能力方面，這些絕對不錯的大師們所佔的人口數少到幾乎沒有。

情境設計 (Contextual Design) 規定一種發展系統的過程，可以帶出人際技能的價值。規定了根據資料來取捨各種開發選項，所參考的資料不包括爭議和政治交易。情境設計規定了人該扮演的角色，能在設計的過程中一直保持討論。不但要讓設計的過程比較有效率，還要因為人們爭議並沒有進展而將系統暫時擱到一邊。

前端系統設計讓我們著眼於人際的課題，因為設計程序的這一部份會帶來由面對面影響得很深的不一樣的功能。傳統的設計較不帶出著重在一起工作的技能。致力於保持客戶工作的凝聚力，而排除團隊中不同的看法和不同的能力，會使認知到如何一起工作變得很重要。我們發現，在人們該進行明確的流程、扮演明確的角色時，那時他們會對個人風格很敏感，使他們在房間裡起衝突。而當他們有具體的資料可以根據以設定決策，就會跨過隔籬，一起有效地工作。

這就是以客戶為中心的意義：不只做到客戶導向的設計，還要讓設計流程將系統帶往能讓客戶的工作──從開始到實作──能凝聚在系統中。對情境設計的挑戰是內建在方法中，要瞭解一同工作的要點，還要提供有效工作的辦法。