# EP09 - 服務心態(Service Mentality)

## 本集介紹

討論主題：服務心態(Service Mentality)

短述：研三是技術服務單位，我們每個人都身懷絕技，帶著滿腔的熱血準備要支援前線。可有時專案需求千奇百怪，我們不懂需求後面的需求；有時我們深思熟慮，保持技術品質，專案也不懂我們的堅持。要把「服務」做好做滿，似乎也是一門技術？還是我們缺乏的是正確的心態？

## 訪談內容

### 乃宏

#### 節目介紹

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

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

#### 討論主題

2022年第一集，我們就從這個其實我們早就該講的主題開始吧。我們是「技術服務」單位，是「服務」單位對吧？可我們又不是「服務業」，不是「客人永遠是對的」那種服務業。我們常常需要在需求和實作規劃上，在投入人力和獲得效益的評估上，在協作和主導的比例上有所拉扯，常常需要求平衡。這一集我們要討論的就是，我們應該帶著什麼樣的心態，去思考該怎麼分配，該怎麼做，才不會搞得大家都不開心。

#### 來賓介紹

今天的來賓是技術組的扛霸子騰廣，設計組的實力新秀禹圳，以及第二次來參加節目，一直是應用整合組技術高手的瑋玲，我們請他們跟大家自我介紹。

> <font color=green>騰廣</font>：大家好，我是技術組的騰廣。我主要負責AWS與GCP這類的雲平台管理。
>
> 禹圳：打給賀，我是設計組的禹圳，主要負責框體設計以及使用者體驗相關領域的導入執行
>
> 瑋玲：大家好，我是應用整合組的瑋玲，很開心能再次來參加。

### 騰廣 / 「技術(或架構)」上正確，與「需求」上正確，有時是往不同的方向去的，以「服務心態」來思考的話，你認為怎麼做可以更好的讓大家比較好接受？

> <font color=green>騰廣</font>：如同前一個問題，我會先以理解需求為優先，有時候來討論的同事會帶著做法來溝通，我反而不是很了解真正的需求是什麼。如果能夠先真正的理解對方的需求，這樣再提出正確的技術與架構讓對方選擇，這樣在感覺上應該會比較好一些。有時候需求只是解決當下的問題，但是在問題的根源其實沒有被解決。如果能夠多理解背後的問題，讓需要幫助的團隊少一個痛點，這樣對大家應該都好。
>
> <font color=red>乃宏</font>：禹圳，你們應該遇過很多次這樣的問題吧？你們的設計可能會有比較全面的考量，除了美觀，還有營運或組裝的考量，那你們會從什麼角度切入說明，讓大家比較好接受？
>
>> 禹圳：其實也是理解需求，還有理解執行者的需求，討論再討論這樣。像是成本或是組裝運送考量這些需求，跟專案或是業務合作久了，也都會有一定的溝通基礎，反而不是問題。那如果是設計上的提案，比較菜鳥時期的作法有過抗爭只畫自己的，也有過全盤接受。現在的話，主要是看時程還有多少時間，能做多少事，最好的情況是專案的想法提出一案，自己的想法提出一案，討論時可以截長補短，各取優點來執行。
>
>>> <font color=red>乃宏</font>：「各取一案」這一招聽起來不錯耶，雙方都不委屈。
>
>> 禹圳：然後理解執行者的需求，就是去認識專案團隊的人員，有些時候問題點的產生可能是執行人員發生問題傳達給專案，專案才轉達給我們去處理問題，大家應該都看過綜藝節目，比手畫腳傳到最後一個人答案都天差地遠了，有時候去認識專案團隊的執行者，了解問題的痛點，也會有幫助。
>
> <font color=red>乃宏</font>：騰廣，聽起來對你而言，一個好的「服務心態」，是建立在「滿足最深層需求，追根究底的思維」，對嗎？
>> <font color=green>騰廣</font>：應該是種幫對方找到真正的問題，連同他現在的需求一起解決。讓對方感受到我們是幫他著想的。也許是種讓對方覺得窩心的感受。

### 禹圳 / 陳總在早會提到，建立「服務心態」會有助於建立良好的溝通？你的想法是什麼？你覺得這個心態有助於解決什麼問題？

> 禹圳：其實乃宏哥也有提到，我們不是在北車看到的高鐵站務員、餐廳的服務生，那種社會上會看到待人親切、彎腰鞠躬的服務業。以我們公司來說，專案是顧客，然後顧客至上，而我們是服務員，這樣的關係我覺得對專案、遊戲發展或是自己的實力提升都是不好的，公司"應該"也不會希望我們這樣。

> 禹圳：服務心態的產生也跟專案合作有關，最終目的是為了雙方的溝通能夠很順暢有關。之前在奪寶奇航專案上，早期的專案非常求好心切，每天都要討論，每天修改產出新版本，根本都還沒有時間設計出昨天討論的成果，可能今天看到雛形就開始討論就要修改。一方面也有設計師的尊嚴跟自傲，不想當一個copymachine，按下列印把專案腦袋的東西直接一模一樣印出來，會護航自己的提案想法，對抗別人的建議。所以結果就是，那些討論就像進去死胡同一樣沒有太大進展，大型會議中被打槍，挫折感也越來越大，覺得為什麼花那麼多心力，結果進度卻很緩慢。
>
>> 乃宏：你們的溝通問題，比較像是設計師難以接受「被改掉」的理由，甚至覺得那是一種「被否定」，對嗎？
>>
>>> 禹圳：對,我覺得這有時候是設計師常見的心理的偏執，某種程度來說，設計師很需要自信，要相信自己做出的東西很厲害，所以當然會有不想被改的心情。
>
> 禹圳：後來找主管、同事深談，也有一些方式去改善，先建立一個緩和的機制，接收到需求指令的時候，可以先試著收下，不要馬上就去反駁或直接說不可能。可能過個一天再去找專案或是找更多人去討論，一方面也仔細思考別人的建議的可行性。如果是我們有做到的而對方沒有了解，也要用比較緩和、舒服的方式讓對方了解。畢竟我們是服務單位，降低彼此的摩擦力是很重要的課題。
>
>> 乃宏：所以在這裡表現出來的「服務心態」，比較像是"把自己先放下，認真傾聽"這樣的表現，對嗎？
>
>>> 禹圳：對，這算是一種方式，抽離情緒，先放下立即反駁的心態。一方面多一點時間思考，也一方面尋求更多專業的意見，像是如果有牽涉到開模或結構的問題可以找機構協助
>
> 禹圳：另外就是降低自己的語速，我的電腦螢幕有一張便條紙上面寫語速，應該貼超過一年了吧。自己比較急性子，要讓口條更圓融，更緩和，就是要逼自己放慢語速，隨時提醒自己要注意說話速度，不要常常因為講話很急，讓溝通有反效果。
>
>> 乃宏：你有沒有什麼過去的例子可以分享，語速過快的反效果會怎麼樣？
>>
>>> 禹圳：過去曾經有一次框體提報，自己那次準備做很足，所以講得很順，很快，結果到QA的時候，很多人提出的問題都是我在簡報內有呈現的，口頭上也有說明的，結果反而簡報五分鐘，QA一小時。後來自己反省，放慢語速，讓話跟話之前能夠思考，也同時能觀察其它人的反應。反而會讓溝通或是討論更清楚。
>>
>> 乃宏：QA一小時也太慘了…😅
>
> 禹圳：久而久之服務心態就建立起來了，為了讓溝通更順暢，讓對方知道我們的難處還有理解對方。最後專案執行也越來越順利，像是之前ＨＰ的VR眼鏡有定位還有會翹的問題，兩邊的溝通上順暢很多，也確實改善問題點，那種的合作，才像是真的在【討論】。這樣的心態其實也不一定是應用在專案上，部門間團隊合作，尋求其他主管專業上的建議，不過學海無涯，我也還在學習中。

### 禹圳 / 你覺得「藏拙」是怎麼影響該有的「服務心態」？

> 禹圳：首先，我先定義藏拙的意思，並不是藏私或是怕多提想法而會更多事的狀況，跟專案合作的過程中，很少有因為怕事或是覺得很麻煩就不去處理的狀況。這邊指的藏拙的意思是，並沒有讓對方知道自己的顧慮或是背後的原因，亦或是專案提出的需求，背後的意義也沒有讓你知道，這是我定義的藏拙。
>
>> 乃宏：聽起來比較像是「懶得跟你解釋」？😅
>
> 乃宏：不過「怕麻煩」這件事在騰廣的週報也說過。你們的狀況又是什麼？
>
>>> 禹圳：我記得是有一次好像跟人因尺寸相關的問題，因為專案提出的需求會影響到非常多地方的人因尺寸。當下就立即跟專案反應需求不太合理，甚至也有一點比較情緒的討論，不過事情還是要做。花費非常多時間跟心力去做測試，只是為了去引導專案理解這個需求是不可行的。但其實這個過程中自己先有先入為主的觀念，知道這樣做是不可行的，反而都只是為了證明而證明，結果只有這樣，花費心力又浪費很多做白工，曠＂力＂費時。
>
> 乃宏：瑋玲，以前妳們寫MCU，寫FPGA，應該也被要求過一些聽起來就很不合理的要求對吧？妳們也會花時間去「證明」專案的需求不合理嗎？
>
>> 瑋玲：一開始也會想要去證明，但有時花了很多時後證明後才發現重點不是並不是在證明的部分，所以了解需求背後的目的才是關鍵，服務要針對目的來執行才能得到最好的效益，確認目標再來討論可行方式雙方才能合作愉快。
>
> 禹圳：其實在專案提出需求當下，還有更多可以做的事，像是剛剛有提到的先收下需求，避免當下立即反對，可能過一小段時間再去了解專案提出需求背後的原因，也讓自己緩衝思考一下，或許會有不同的解決方案出現。所以藏拙當然會影響服務心態，服務心態的產出結果就是溝通能夠順暢，你都沒讓對方知道你在想什麼了，當然就沒辦法溝通阿，更不用說互信關係了。

### 瑋玲 / 向不滿意的他人請益，妳會期待有什麼「火花」產生？

> 瑋玲：會有不滿意，代表他看的角度與重視的部分與自己是不同的，而且目前方向與他的期望不符，所以向他請益，更能看到自我目前的盲點與缺失，也更能了解他所需求的目標為何。才能正確的調整後續的方向提升整體的工作率。
>
> 乃宏：騰廣，你曾經有什麼經驗，是向不滿意的人請益，最終真的得到自己也沒預期到的火花的故事可以分享嗎？
>> <font color=green>騰廣</font>：在我們技術組的雲端管家開發上有遇到，當時使用的專案不多，而研五在某次的搬遷下，使用了雲端管家的服務，但是當時的雲端管家還是有些地方沒有考慮到使用專案的感受，因此在事件事故管理的某次會議中，我們主動提出了請大家說一下使用上的問題，反應相當熱烈。
>> 在那一次中發現大家其實會有自己覺得方便的地方，也因為大家願意談，我們也有了方向進行修改，並做出些自動化的改進，雖然現在還是有些地方還需要改進，但也因為這樣，大家的使用意願有比較高了。這個結果是我沒有想到的。

### 瑋玲 / 為了達到更好的服務品質，妳今年有什麼「跳出舒適圈」的目標？

> 瑋玲：我目前的工作著重在自動化測試的部分，雖然測試的流程與架構大致上都已經固定，但還是想再嘗試是否有其它的方式能達成，例如目前自動化主要是使用圖像比對的方式，未來想再加入機器學習的部分，因為不同的方式雖然都可以達到目的，但對於不同的環境條件下，有越多工具與方式才能越容易找到最佳解。

> 乃宏：禹圳，我想你的「放慢語速」應該還是今年的重要目標之一對吧？你有沒有安排什麼方式，來刻意練習這件事？
>> 禹圳：那張語速便條紙貼在螢幕應該超過一年了，可能快兩年，前後換了好幾次便條紙，但上面寫都是語速，這已經不算是一個年度目標了，已經算是時刻提醒自己要做到這件事。我記得最一開始是練習在閱讀或是看社群的時候，心裡跟著默念對方的文字，試著把他的話一字一句都準確慢慢念完。一直到現在的話，會讓自己練習呼吸，減少那種講完話會大口吸氣的情況，但是當然有時候還是會破功，不過我覺得這個練習是一輩子的修練，但是只有持續去做，才能看到成果。
>>
>>> 乃宏：有試過寫作嗎？我自己透過寫作，很大幅度的增進了口條清晰的程度。因為要能寫出東西來，必須要透過思考來重組腦中的訊息，使其變得淺顯易懂，因此往往能讓接收訊息的人，更容易理解我想表達的意義，可以試試。
>>>> 禹圳：學生時期有寫作(日記、心得、小影評）跟發社群的習慣，出社會工作之後就沒有了，或許之後會再試看看。

## 節目結尾(主持人)

「服務心態」其實不是什麼新東西，而是許多軟實力提到的思維的組合。感謝這些來賓在不同的面向，都給了我們一些啟發，能讓我們去反思，在自己的工作上，應該怎麼「服務」會更好。

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

我們下次再見，拜拜～

> All：拜拜～

---

(以下是未上架保留部分)

### 騰廣 / 你覺得跟非同溫層同仁的溝通，最讓你感到吃力的是什麼？今年你會帶著什麼樣的心態去看待這件事？

> <font color=green>騰廣</font>：我覺得比較吃力的是，容易因為立場與共識不同時，產生溝通上的誤會。在以往的溝通上，我的立場會比較著重於與我有關的事物，並且單方面的思考我的難處與痛點，也因此沒有與對方達到共識。這部分會讓跟我溝通的同事覺得我否決了他的需求，也因此讓對方有壓力，因為他也有他的難處與痛點需要解決。
>
>> <font color=red>乃宏</font>：你有嘗試把你的難處表達出來嗎？像是你要花多少時間調整服務的參數，要架設環境，架了就要測試什麼的…如果有試過，對方能理解你的難處嗎？
>
>>> <font color=green>騰廣</font>：其實都有直接或間接的表達，例如蠻常遇到專案在最後一刻才提出申請單，這時候或多或少會希望專案能夠再提前一點，這樣比較好處理。只是以前的我一直沒有意識到，會來找我討論就是因為有需要我幫忙解決的地方，但是我當下只著重在我的管理好不好處理，後續會不會有更大的問題會產生。忽略掉這時候來找我幫忙的同事，反而讓他更受挫，進而有了我不好溝通，或是脾氣不好的印象產生。
>
> <font color=green>騰廣</font>：今年在溝通上，我會以先理解需求，再想辦法處理的心態來試試看。看看是否能夠讓溝通上，大家的共識與認同多一些，彼此的溝通誤會少一些。
>
> <font color=red>乃宏</font>：你剛剛提到一個重點是「後續會不會有更大的問題」。就算我們是技術單位，也不能保證會有100%沒有異常的系統或服務。可需求單位很難避免會對這件事敏感，在往後的服務中，你會怎麼跟需求方在這件事取得共識？讓雙方合作不致於陷入一種「誰會負責」的僵局？
>
>> <font color=green>騰廣</font>：因為我這邊提供的是基礎建設，如果後續會有持續性的變動，那其實會很困擾，想像一下，你住的大樓以後可能會隨時更換地基，這樣你會不會安心?
>> 不過未來我會先把這個問題提出來，看看對方對於這件事的看法，尋找雙方能接受的方式解決這類的問題。
>
> <font color=red>乃宏</font>：瑋玲，專案會質疑妳們的自動測試程式的正確性嗎？妳們又是怎麼和需求方達到一定程度的共識的？
>> 瑋玲：基本上在做自動測試時都會使用錄影輔助，當對數據有疑問時可以查閱影片核對正確性，這樣對於雙方都容易釐清問題。在共識的部分會先與專案討論需求與想看的數據面向，還有報表格式如何呈現，對於有些技術上無法直接記錄的數據，就會討論是否有其它的解決方案，通常也是經過多次討論，慢慢建立雙方的共識才有現在的模式。
###### tags: `roc_newsletters`