# EP02 - 認知差距(Cognitive Gap)

## 節目介紹

節目名稱：[改變共和國(Republic Of Change)](https://rss.com/podcasts/republic-of-change/)

節目介紹：從管理週報中，我們可以看到身邊的人不斷的反思，觀察，進而做出改變。這個節目將帶領聽眾，更近距離，深度的去探索他們的這些過程，希望能給大家不一樣的啟發。

## 本集介紹

討論主題：認知落差

短述：有時開發者和用戶會把「地中海牡蠣風味義式紅醬蛋汁煎餅佐時蔬」和「蚵仔煎」搞混，會有自己的解釋和定義，而這似乎永遠是個無解的難題，歡迎大家參與我們的討論，一起想想有什麼可以改變的可能？

## 來賓和參考資料

### 鄞暉訓(技術組)

過去在跟專案合作上，有時會遇到組內提供的方案與專案的需求有落差，或是一些方案其實是由過去慘痛的經驗所優化而成，但是專案人員卻不了解這麼做的原因，亦或者因為雙方單位因人員變動而缺乏一些過去的”默契”，以上種種狀況都容易在會議討論上遇到一些問題，更甚者也會打亂雙方單位各自的時程掌握。

在最近協助sweepstakes專案導入AWS的WAF方案，過程中我們調整為在研究初期，即協同專案人員進來參與，並以例行會議做雙方資訊同步，我們將研究的過程同步給專案人員，讓他們了解需求的解決方法，即使無法做到的需求也會說明原因或，找原廠一起進來討論。透過一次次的會議討論，也能同時確認沒有偏離專案需要的應用需求。這樣做法的改變，比較不會像過去，單單由我們提出解決方案，但專案卻不了解後面的技術概念，容易衍生許多後續的問題。

期望一小處的改變能夠讓事情進行上更順利，如果後續覺得不夠好也沒關係，那就繼續改變！

### 蘇彥瑋(設計組)

這幾次參與專案，總樂觀認為有先前經驗累積，應能配合時程順利結案。然專案發展至今，延宕及修改不下數次，歸結自己有以下問題:急於開始，輕忽前期規劃，魔鬼藏在細節裡，若沒審視錯誤背後所暗藏之問題所在，便會起首錯，步步錯。

常自問為何常不停重複相同錯誤？又如何錯誤中汲取教訓？

切記不可因害怕麻煩而疏於了解及確認，通常這就是問題發生的最大原因。然當局者迷，而犯錯原因往往是自己沒正視問題本身的嚴重性，需審視自身明確了解問題，才能了解及執行正確解答。

產品設計首要於主客雙方認知，"溝通"與"確認"是避免錯誤的不敗法則。你腦袋想的，不一定是客人需要的。討論結束，需再次確認彼此認知是否同步，又更甚者再請第三人記錄確認無誤，如此決議才會正確有效。最後，當需身體力行，相信自己一定能突破及改變～

### 林聖倫(平台組)

作為共用技術的研發單位，經常會形容是個服務單位：以服務的態度來協助各團隊解決問題。有位成員跟我聊到於服務有個迷思，似乎服務就是要矮人一等，對於需求也是全盤接受。深度了解後，他本來就是個擔心討論時會有衝突的人，所以常會把工作攬在自己身上。久而久之，有時會習慣把需求過度的交付到他手上，時間越久他手上的工作量也越大。

面對成員這樣的遭遇，回想自己也在討論分工時意見分歧。重點是享受衝突與溝通後的共識，讓對方也能了解我這邊處裡的方式與進度。如果說要與服務全盤接受需求有甚麼差異，那就是我們是對等的合作關係。

其中的關鍵點還是在於願意花多少心思與時間進行溝通，而不是躲在工程師的舒適圈(程式與技術)中。溝通的過程與結果雖然比程式難預測與掌控，但與專案一起多溝通與合作找到雙贏的結論，才能讓彼此的團隊持續成長與開發出好的產品。

## 訪談內容

### 乃宏

#### 節目介紹

大家好，歡迎來到「改變共和國」Republic Of Change。

這是一個和商用研三的ROC電子報連動的一個Podcast作品，也是我們希望帶給大家更多正能量和啟發的新嘗試。這個節目會以ROC週報的內容挑一個主題，請投稿的作者一起來談談在反思，觀察及改變的過程，他們觀念改變的契機，遇到的困難和拉扯，以及改變後收獲了什麼。

#### 討論主題

今天要討論的主題很有趣，就是那些我們在平日工作中，所發生的那些認知誤差。研三部是技術服務單位，大家都有自己的技術專業領域。我們服務的對象是專案單位，他們所看到的則是產品及市場面向的專業領域。誤差是必然會有的，今天我們會和來賓聊聊，他們和專案合作的過程，曾經發生過怎麼樣的認知誤差？雙方在意的事情是什麼？要避免更多的誤差，我們可以怎麼樣改善這個狀況。

#### 來賓介紹

今天邀請到的來賓也是三位，也是來自不同領域。分別是技術組的鄞暉訓，設計組的蘇彥瑋和平台組的林聖倫。那麼就先請他們三位跟大家打個招呼，簡單介紹一下自己在職務上提供專案的是哪個部分的服務。

### 暉訓

#### 在週報上講到你們提供了解法，跟專案的需求有落差。可簡單幫我們帶一下故事背景嗎？需求是什麼，解法是什麼，落差來自哪兒呢？

舉個過去蠻常發生而且也比較簡單易懂的例子，例如專案會來反應目前主機效能不足，因此有要升級規格的需求。

在基於服務的角度我們會先確認主機目前的負載狀況，透過主機過去的監控資料可以了解到是不是真的效能不足或是哪裡的效能不足，但有時一查發現效能上其實是足夠的，這時會為了幫助專案減少不必要的成本，因此會跟專案說明可以考慮將需求的規格調降一些，結果偶爾會讓專案的人員覺得怎麼不依照他們開的需求規格來處理就好？

後面我們再進一步了解才知道原來是專案有新的活動或是有一些程式功能即將要上線，但也不確定需要多少的規格才能扛的住，因此乾脆把規格開大點。

後來我們才意識到，以前往往是收到需求後就按照要執行的技術面做討論，就會發生因為各自資訊不同與專業領域不同而有見解上的分歧。

因此我們開始調整為收到需求時先跟專案了解需求的起因是什麼，試著讓雙方資訊比較同步，之後才進到技術面與執行細節做討論，這樣才能有效避免見解上的分歧。

#### 在提供解法的過程，你會先想幾個版本，會找誰討論，簡報說明前怎麼定案呢？

這部分比較會看影響到的層面包含哪些，例如與系統、網路架構、資安稽核、後續維運問題或者成本考量等等，如果我初步覺得有疑慮的話可能會先想兩三個方案，或者整理目前手上的資訊，然後先跟組長騰廣討論一下，或是協同維運組一起進來討論，算是先內部討論過沒問題後再把相關方案拋出來，之後再跟專案或是相關窗口做會議討論。

#### 你有提到因為人員更動，造成「默契」的流失。原因單純是因為這個keyman懂你們專業領域的知識，還是因為他特別懂溝通？還是別的關係？

專業知識與溝通應該都算有吧!

算是每個人員配合久了就會比較了解互相需要處理哪個部分，溝通時也會比較知道彼此說的東西是什麼，當然久了也對彼此的個性比較熟悉，說起話來也比較順利，對於攜手邁向美好的未來一定有幫助...

#### 後來你們這邊採取的策略是，找原廠來說明技術障礙，也加大和專案的同步頻率，這有改善認知上的落差嗎？你覺得為什麼有效？

不管是會議同步雙方的資訊，或是協同原廠來做討論，以我自己感覺是有覺得比較好。

因為有些狀況可能當下我們是做不到的，我們可能會與原廠窗口先做簡單諮詢來確認想法。

以這次來說，剛好我們近期獲得AWS原廠比較大的支援，利用定期的例會找專案一併討論這類問題，透過原廠的說明能夠更佐證我們提給專案的資訊，這樣一來也讓專案更能接受相關的說法，當然有時我們也會把專案的需求拿來跟原廠做許願，看能不能推出我們想要的功能！

#### 轉場(主持人)

認知落差雖然有很多個不同的可能及層面，但大體上可簡單就分為「領域知識」和「主觀感受」兩個分類。以技術組的人員來看，「領域知識」是一個造成認知落差的關鍵，這部分不管是嘗試瞭解需求背後的需求，或是中間有人能”翻譯”各自的需求給對方聽，就能比較有效的減少認知落差。接下來我們就來看看光譜的另一面，也就是「主觀感受」的那一頭，我們要怎麼樣做出改變，讓減少認知落差？這部分就要聽聽彥瑋給我們的一些經驗。

### 彥瑋

#### 週報中你提到「不可因害怕麻煩而疏於了解及確認」。你害怕的”麻煩”是被否定？還是浪費時間？還是自己要準備溝通的資料？還是別的？

前次分享中，我反思的問題是＂因為害怕麻煩而疏於確認＂。。

其實也正呼應此次探討的認知落差主題。。

仔細想想。。認知落差無時無刻的在你我身邊發生，似乎只要需要互動之處就會發生。。

為何會認知落差，我探究其因竟是嫌麻煩造成？？因成效低，做白工都有可能。。

舉個例子，沒人會否認運動為健康帶來的好處。。但肯定很多人也第一時間飄過＂好麻煩＂這個念頭。。不能吃喜歡的，動了會流汗又臭又黏，又要洗衣服幹麼。

為了解決認知誤差，你需要做很多準備資料，也省不了花時間心力去學習研究，雖然這些努力到最後都有可能派不上用場

而再回歸工作層面上。。

情境.1

X，要改哦～看一次改一次。。設定也照當初規定，啊說改就改，是不知道為了達到所提需求，要花多少心力想方設法才能完成哦。(心中無義語助詞AGAIN)。

情境.2

阿，就做了再說。。就算沒見過，總有照片可先看吧；先有東西出來後續才能討論，先做再說。。反正不要走到死胡同，就有機會挽回。。

對，以上這些似乎都是我日常遇到的認知誤差情境之一

但。。靜下心深入思考，為何會發生這些問題，是因當時怕麻煩？又或不想麻煩。。而省略

（講白點，就是怕做白工，花時間卻做不正確的事。。雖然當中也能學習許多經驗）

#### 你算是相當資深的設計師了，明明累積了那麼多經驗，但好像永遠都會有認知落差，你覺得究竟是怎麼回事？

迄今為止都是專注商用框體的領域,其中個人覺得最棘手的莫過於競速類框體，因為使用者的操作條件，要求；話雖如此，隨著每次新專案，設定條件不同,就需依當下設定，環境，可用資源去做相對應的組合..經驗的累積就如同資料庫有助於快速切入及避免錯誤

對於目標達成的認知等易受各種因素所影響..專案要求的時程，成本，我要求的是好看的外觀..

也別想說已經配合那麼多次的經驗,我知道你要什麼的念想，不斷溝通討論,確認再確認才能逐步修正,達成彼此共識

以上,是我對認知誤差產生原因的看法..

過往所累積的許多經驗是適用在框體產品規範上,當下參數是適合當下的,而非絕對與現今匹配~

經驗法則1：過往經驗是安全無慮的，直接沿用過往經驗絕對安全，就也沒再次做確認..

經驗法則2：用過去的很好..但,現在環境及條件都變了,這個不是我要的..

#### 「設計」它困難的其中一點，就是主觀判定。用戶往往很難把他”覺得”不好的理由講得清楚，能否跟聽眾分享一下，你們有什麼方法去找到問題？

現階段做法以收集類似風格的,圖片,現有的機台照,使用情境之類相關資料;雖如此,但相信還是會有一定程度的認知差異..所以,最後還是需畫出實際3d,發包打樣實際模型來做最終觸覺及視覺空間的確認..

#### 對於難以避免的認知誤差，我們是有一套解法了。你覺得在這個過程，執行上的困難點是什麼？若你身邊有個新人，你會怎麼協助他克服？

個人看法：

１。如條件允許，就是一起進行專案，協同設計。

２。會議全程切實記錄（錄音，影），多次或多方口述反覆確認，如有疑慮就再準備資料或圖面提供參考。

#### 轉場(主持人)

設計這個領域，真的是最多認知誤差的地方。而且聽彥瑋分享他所面臨的困難才知道，除了要知道認知有多少誤差，最困難的可能是經驗上的重複使用率並沒有預期那麼高，因為每個專案的需求和環境都是不同的，差一點往往就差很多，而且設計都是環環相扣的。我想這是設計這個領域很大的挑戰，也是很有趣的地方（也是最難的）吧。

有時，認知落差不只是在設計面還是技術面，在「角色」的認知上也常常會有落差。我”以為”你會做什麼？你”以為”我應該要幫忙什麼？誰應該會產品的規格負責？誰又應該要對品質把關？這些問題，這些落差，對產品的開發來說，有時會比單純在技術或設計面上的落差還來得致命。這部分我們就要來問問平台組的聖倫，請他分享一下他的看法。

### 聖倫

#### 人家常說服務業就是「顧客永遠是對的」。做為技術服務提供者，這個觀念還適用嗎？差別在哪裡？

實際上我們都是公司的研發部門，如果硬要把專案當顧客，那我們就變成了專案的服務員。不應該是專案說的永遠是對的，我想這樣的關係也不是公司希望的。

認真的說，我們其實都是在為公司服務，只是我們協助專案一起研發、解決問題，我們真正的目標：透過協助專案的過程，幫公司統整各專案的技術、問題，減少重工與重複發生相同問題。

#### 在週報上你提到「是對等的合作關係」。但合作的過程彼此在做的事情就是不同，要談「對等」的話，你想表達的是什麼？工作量對等？還是一起談產品定位？還是品質責任各半？還是別的？

當我們協助專案需求時，專案有可能分析過市場與規格需求，但沒有相對的技術或人力資源，才會來找我們協助。但在經過市場的打磨，專案團隊可能甚至在某些技術或經驗更勝於我們。

我是站在公司與團隊永續經營想法，才會覺得不應該是服務員與顧客的關係，而是轉換彼此的角色，這時就換專案協助我們整理這些經驗，轉化為共用的資源

想要達成這樣的方式，專案必須要有相當程度的參與研發過程才有可能，而不會是把事情全都交給我們後，等我們做完再交接回去(我的經驗是通常這樣的交接，很容易因為一兩個人離職就流失掉技術，然後又回頭找當初開發的人臨時支援，會這樣就是代表這個技術沒有真正回到專案繼續成長。應該是一起規劃與持續參與這個服務的開發過程，最重要的是一起確保這個東西最後能回到專案內長期維運，就是對等的合作關係

#### 賈伯斯曾狂妄的說過：「用戶不會知道自己需要什麼，直到我們提供了他們想要的」。我們也蠻頭痛的是我們不知道用戶不知道什麼(好繞口)，我想這也是其他服務單位會有的問題，你有沒有什麼建議給我們大家？

我一直都覺得自己經常在切換角色，站在專案的角色，站在部門的角色，站在公司的角色，站在用戶的角色。

只有你夠懂用戶，夠了解他遇到的問題，花夠多的時間溝通找出核心，才能真正做到讓人滿意的成果。

這些就是要靠足夠的經驗與溝通才能做得到的，雖然這個沒有辦法一蹴可及，但是如果用戶願意轉變成測試員甚至研發員，跟你一起經歷嘗試的過程，彼此扶持，我相信做出的產品甚至會超越用戶當初的期待。

#### 「弄魚給他們吃」跟「教他們釣魚」現在似乎都是我們服務單位要做的事，你會怎麼決定底下的工程師要怎麼分配比重？依據是什麼？以前跟現在有差異嗎？

其實商用以前會做網路App的團隊很少，就連我們也都到現在還有很多面向經驗不足。所以一直以來，我們都是透過與專案團隊合作來一起成長，我們比較像三人行必有我師。

現在有許多團隊裡有不少缺乏實戰經驗的工程師，所以我們有時候甚至會送經驗不夠的工程師去團隊實戰學習請教這些前輩。

分配比重是與對方的管理者討論出來的，依據通常是時程與雙方人力、技術力的拉扯與平衡。但我想強調的是，彼此要多思考系統的永續維運與人才技術的培養，不是做出功能然後就結案。以前大家沒經驗，我們邊研究釣竿邊釣魚，現在大家有經驗，我們一起研究釣竿魚餌，一起教人釣魚。

#### 轉場

認知誤差真的是很有趣，但也很困難的一個主題。感謝今天有來自設計領域的，技術領域的，甚至是平台領域的專家來跟我們聊聊他們的想法和經驗，也感謝一路聽到這裡的聽眾們一起參與討論。

## 節目結尾

> 每個人都會因為改變而成長，再因為成長而看到更多改變的可能。在共和國內，還有許多人有不同的改變故事，希望能持續帶給大家改變的可能。

我們下次再見，拜拜～

###### tags: `roc_newsletters`