但有時設計是為了「解決問題」而誕生，因此這篇文章想透過業界的實際案例，從不同角度跟大家做個討論。

如何讓車子降速

無論如何宣導，路上一定有車子超速，而超速就可能導致事故發生。

既然事實證明宣導的用處不大，那麼交通事故率高的地方，就會看到下圖的降速坡。

因為車子在經過凸起物時會稍微顛起來一下，因此有自動降速的效果。

如果從視覺的角度來看，你不會覺得他是一個好設計，但他卻給我們帶來了幫助。

如何保護路上的行人

台灣有很多的巷弄並沒有專屬人行道，進而導致「人車爭道」，走在路上都有被撞的風險。

但近幾年，大家應該發現路上越來越多這種綠色的「標線型人行道」，他可以讓駕駛注意到這塊是給行人走的。

因為給了彼此明確的界線，所以許多過去常發生意外的路段在加上這個設計後，事故與傷亡的機率已大幅降低。

有質感的設計 VS 好賣的設計

下面舉一個課程中提到的商業案例，泰山的「大吸管」飲料。

原本設計時，飲料包裝上是沒有實體照片的，只有圓滾滾的吉祥物。

但業者看到後希望加上實體照片，因為這個產品是「食品」；從商業的角度來講，加上實體照片更能讓消費者看到時產生「食慾」。

如果從視覺設計的角度來看，只有吉祥物的版本很清爽；但如果想要賣得好，你就必須要放上照片。

對客戶來說，讓他們賺到錢，才是解決問題的設計。

「專業」也是會被市場淘汰的

在文章的最後一段，想跟大家聊聊「設計自己人生」的議題。

長期關注我部落格的朋友，應該會發現我文章的主題相當多元。

前兩年我的文章以「專業技術、團隊合作、工程師職涯」為主，而今年新增了「AI 應用、設計思維」等主題。

有朋友問我：「為什麼要接觸這麼多領域？主題不會太發散了嗎？」

我回答：「部落格對我來說，除了分享知識外，也是記錄自己學習的過程；我會根據市場趨勢動態調整文章的內容，因為我無法保證自己的專業在 10 年後還會被市場需要。」

謹記，現在很夯的產業，很可能在新技術推出後就逐漸沒落；不要把雞蛋放在同一個籃子裡，專業也是一樣。

目前工程師這個身份，是我的核心價值與主要收入來源。但除了持續提升專業能力外，我還會持續接觸新事物，並將其與原本的知識結合運用。

以上就是「設計思考全方位」第五單元的心得筆記，如果覺得我的分享對你有幫助，歡迎 Follow 我吸收更多知識。

如果處理過程情緒管理不當，或是方法錯誤，就可能衍生出更多問題，甚至讓類似的問題一再發生。

恢復理智，整理思緒

專案出包後，有些高層會先把主管找過去痛罵一頓。

只要是人都會有情緒，沒人在被罵完後還能保持好心情；但如果把情緒帶到接下來的緊急會議上，就可能把問題擴散的更廣。

試想，如果會議開場你直接把脾氣發洩到成員身上，他們會是怎樣的心情？搞不好罵完後，有些人直接辭職不幹了（這個狀況如今並不罕見）。

因此筆者建議：「無論多想罵人，先讓自己恢復理智，確保自己能心平氣和的處理問題後，再召開緊急會議。」

召集相關人員開緊急會議

主管，尤其是技術部門主管，他們在收到回報後，往往能很快判斷出問題是誰造成的；但很多時候：「出包的人，未必有解決問題的能力，抓戰犯，對解決問題也沒有幫助。」

筆者不建議在會議中把矛頭指向特定人士，比較好的做法應該是先讓與會人了解以下幾點：

1. 問題的嚴重性、影響範圍。
2. 問題有多緊急，需要在 XXX 時間內解決。
3. 我判斷問題可能源自於 XXX…
4. 我會跟你們一起面對問題！

待大家了解問題後，詢問是否有人熟悉這塊功能，並儘可能安排兩個人一起解決問題（Pair programming）。

在高壓的狀態下，一個人獨自面對問題容易鑽牛角尖，甚至情緒不穩崩潰；但多一個人在身邊，除了能給予不同的想法外，還能起到彼此鼓勵的效果（當然這也是看人）。

問題解決後

向高層回報問題已經解決後，如果還在上班時間，建議趁大家記憶猶新的時候，立刻開會討論：

1. 問題發生的原因？
2. 現有工作流程是否需要調整？
3. 這類問題是否有可能避免，如果有，我們該如何制訂標準？
4. 如果再次發生類似的問題，是否有更好的處理方式？

於會議結尾，記得再次感謝大家的辛勞；就算是出包的人解決問題，也不要吝嗇對他的感謝。

如果是加班解決問題，建議隔天再開會討論；要是硬在大家都很疲憊的狀態下開會，得出的結論通常沒有什麼參考價值。

等出包的人冷靜後

除非出包的人不想幹了，不然在出包當下，最緊張的應該是導致問題發生的人。

但如果第一時間找他問罪，他有很大的機率會把精力放在推諉卸責，而不是解決問題身上；所以建議等問題解決且出包的人冷靜後，再單獨找他約談。

談話過程中，除了讓對方認知到自己的錯誤，還要使他明白再犯可能要面臨的懲處。

有些主管在問題解決後就想說算了，但如果沒有適當的警告，可能讓出包的人認為犯錯也沒什麼大不了的。

想跟讀者聊聊

每個主管都有自己的領導風格，因此想詢問讀者，當專案出包的時候，你們的主管都是如何處理的呢？你認同主管的處理方式嗎？

又或者你本身就是主管，面對這種突發狀況，你是如何應對進退的呢？有沒有可以分享的小撇步？

歡迎大家分享自身經驗，或許你的留言可以幫助到有需要的人。

文章提及之專案、人物、事件純屬虛構，如有雷同，實屬巧合，請勿對號入座。

在前兩篇文章中（連結 1、連結 2），我們討論了團隊的聲音為何越來越少，以及主管權衡事情的角度。

而在這篇文章想跟大家分享，這些累積的問題是如何爆發的。

▋不患寡，而患不均

在一個團隊中，如果主管對每個人的標準都差不多，那至少可以維持基礎的平衡。

但如果出現了嚴重的偏差，比如：

1. 同樣是犯錯，有些人輕描淡寫帶過，而某些人則是被嚴懲。
2. 同樣是功勞，有些人藉此升官發財，而某些人卻被賦予更重的任務。

只要有人的地方，就一定會有「親疏遠近」，主管跟其中幾個人特別要好也是人之常情；但如果差別待遇的太明顯，那團隊內部肯定會出現問題。

就像這名工程師在爆炸前有提出最後一個問題：「如果有做不好的地方，我會持續改進。就算在會議上被點名檢討，只要是自己的問題，我就會虛心接受，並在下次做得更好；但為什麼我提出的問題，專案經理都沒有改進？」

結果沒想到主管回他：「不要總是在檢討別人，你要加強溝通技巧啊！」

在聽完主管的話後，工程師理智斷線，怒吼道：「好！我閉嘴！反正我說的話都沒人在聽！」並且在當天遞出辭呈。

如果主管對下屬過度雙重標準，那團隊的流動率會相當高。

▋專案經理的後續發展

也許讀者覺得專案經理這麼混，一但離開公司肯定四處碰壁，但實際上在不久後他也遞出了辭呈，並成功跳槽到另一間薪水更高的公司。

其實這位專案經理並不是沒有專業能力，而是因為受到主管的庇護而不需要認真發揮實力；如果一個人發現自己就算很混也能立足，那大多數的人就是能混就混。

▋主管最後怎麼樣了？

因為專案經理離職，所以他需要暫時代理這個職位；為了避免更多的工程師離職，他重新規範需求規格該有的元素；並且開始面試新的專案經理、工程師。

有沒有覺得這些事情很熟悉？

對！其實就是上一篇提到，主管想解決問題時所需要做的事。有時我們把時間拉長會發現，該做的事還是得做，如果當下不做，只會讓問題在引爆後更難收拾。

▋筆者的想法

發現問題 ➝ 承認問題 ➝ 解決問題

團隊中不乏能發現問題的成員，而解決問題的方法也很多，比如：「將大問題切割成小問題、定期回顧問題處理狀況、獎懲機制明確……」隨便 Google 都有一堆解答。

既然能發現問題，解答又不難找，為什麼團隊還是有這麼多問題？

從筆者的角度來看，應該是卡在「承認問題」的環節；換而言之，「人」才是造成問題無法解決的根本原因。就像在這個案例中，如果主管能適時地做出決策，也許故事的發展就不同了……

文章提及之專案、人物、事件純屬虛構，如有雷同，實屬巧合，請勿對號入座。

在上篇文章中，我們提到團隊改善的聲音越來越少，最後淪為一個形式的問題。

今天讓我們來了解，為何有些主管在收集到成員對團隊的建議後，選擇忽視成員心聲，甚至把問題放著不管。

對錯重要，還是穩定重要？

假使今天有工程師提出問題：「專案經理寫的需求規格太過模糊，裡面沒有交代前因後果，甚至連一些判斷的邏輯都沒有寫，這樣每次在實作前都要先跟他討論一次，我覺得非常浪費時間。」

上面問題的責任歸屬很清楚，根本的原因就是「專案經理缺乏撰寫需求規格的專業能力」，理論上我們只要請專案經理跟工程師溝通，協調出怎麼樣的需求規格是可以接受的，那問題就解決了。

但如果我們把上述的情境加上如下前提：

1. 專案經理已經在公司做了 5 年，過去的專案也都順利結案。
2. 工程師才進來 6 個月，有些東西還在摸索。

我想整個問題就會變複雜了，以這個案例來說，主管也在會議上要求專案經理寫出更詳細的規格；但一個月後，規格依舊模糊，完全沒有改善的徵兆。

這類問題常發生在老鳥身上，他們認為：「自己過去這樣做都很順利，今天來了一個小毛頭就要我配合他進行調整，憑什麼？」

不是沒有解決方案，只是很難推動，以及想不想推動

主管不傻，他當然也知道解決方案；但就像是上面的例子，如果你硬是要專案經理改，如果他不爽不幹了，許多他手上正在進行的專案都會受到影響。

離職預告期是給善良的人來遵守的，筆者曾遇過提離職後，直接請連續假到離職日的人。

很多人會想如果再找一個專案經理，慢慢取代他手上的工作不就好了；但實際上部門編列的預算，未必能夠再多聘請一個人。

上面講了這麼多，只是想透過實際案例讓讀者們了解；站在主管的角度，他要做的是權衡出一個對部門(自己)最有利的方案，而不僅僅只是從事情的對錯來決策。

如果主管只是想悠閒混日子，那他可以繼續放任專案經理；但假使想徹底把問題解決，他就需要做多手準備，比如：

1. 深入了解每個專案，萬一專案經理離職，他可以暫時代理這個位置。
2. 律定需求規格該有的元素，讓工程師可以順利作業。
3. 開始面試新的專案經理，確認專業能力符合需求。

假使你是主管，面對這個問題你會選擇哪一條路？

就像上篇文章提到的，很多問題都是綜合因素所造成；今天所舉出的這個例子，應該也在很多公司不斷上演。

站在旁觀者的角度，我們知道怎麼做才是「正確」的；但站在當事人的角度，因為問題還沒有大到讓團隊無法運作，在動力不足的狀態下很多人會放棄決策（因為做出決策後，自己接下來幾個月都會很累）。

人，容易因為需要太多努力，而拒絕改變。

在下一篇文章中，筆者會跟大家分析工程師真正的引爆點，以及主管後續的故事。

文章提及之專案、人物、事件純屬虛構，如有雷同，實屬巧合，請勿對號入座。

這個情緒話的標題，真的是筆者在現實職場中聽到的。

我打算以這個標題做一個系列文（目前預計有 3 篇），讓你了解是什麼樣的問題，才導致工程師情緒失控用這種方式表達自己的不滿。

主管在徵詢團隊成員意見時，是真的想改善？還是做個形式而已？

在部門會議時（ex：週會、月會），有些主管會詢問大家：「團隊還有哪些地方可以改善？」

相信大部分主管是想透過這個問題與成員討論，進而讓團隊的運作更加順暢；但通常只有一開始的 3~5 次會有人提出哪些地方需要改善，隨著時間推進，會越來越沒有人提出問題。

一但發生上述情境，這個問題就會淪為一個形式，象徵會議的結束。

沒有人提出要改善的地方，是真的沒有地方可以改善了嗎？

我相信一定有團隊在經過多次磨合後，已經摸索出最適合當下的運作模式，即使遇到新問題也可以快速應對。

但這種團隊真的是「極少數」，實際上大部分團隊的狀況是：「過去的問題尚未解決，新的問題不斷誕生。」

明明問題一直存在，甚至越來越多，為什麼反而沒有人提出來呢？

是什麼原因，導致後來沒有人提出問題？

以筆者過去的經驗來說，在發生以下的狀況後，即使對工作再有熱情，也會逐漸被澆熄：

1. 問題在被提出來後，並沒有明確地商討出彼此能接受的解決方案。
2. 往往只有階級高、資歷深的人提出的建議才會受到重視；而基層、資歷淺的人所提出的建議容易被當耳邊風。
3. 技術人員所提出的建議，有時會被以「你不懂專案管理、這不是你應該插手的事」為由否決。
4. 即使討論出解決方案，也不是每位團隊成員都會遵守執行。

冰凍三尺，非一日之寒。很多問題都是綜合因素所造成的。

大家可以想一想

我相信這個問題不只筆者碰到過，應該絕大多數的團隊都曾遇到，或正在面臨類似的狀況。

說一句實在話，團隊問題並不是光靠基層努力就能解決的，畢竟現實生活不是連續劇；如果管理層不覺醒，問題會一直存在，甚至變得更糟糕。

下一篇文章中，筆者會分析為什麼有些主管選擇忽視成員心聲，甚至把問題放著不管。

這些明眼人都知道會對團隊帶來負面影響的問題，為什麼他們還是做了？真的是因為昏庸無能嗎？

每個人都有自己的人生經驗，本篇文章是從筆者的角度出發，希望可以給讀者帶來不同的視角與觀點。

從第二份工作開始，幾乎每場面試你都會被問到：「過去在公司或是專案上扮演過什麼角色？遇到過什麼樣的困難、如何解決？」

只要出現在你履歷上的工作經驗都可能會被詢問，所以請務必準備。

大綱

1. 在工作中有遇過哪些挫折、衝突，以及你的解決方式
   • 1.1 同事刻意挑選你無法處理問題的時間捅你一刀
   • 1.2 常常快到下班時間臨時開會
   • 1.3 跨部門溝通時遇到合作意願低又甩鍋的同事
   • 1.4 跨部門開會時遇到用階級壓人的長官
   • 1.5 開會冗長且不斷偏離主題
2. 描述一下你在這份工作中擔任的角色、負責的任務
   • 2.1 敘述本職工作
   • 2.2 與產品經理溝通
   • 2.3 處理主管交代的事情
   • 2.4 分配任務給組員
   • 2.5 分享印象最深刻的專案
3. 常見問題
   • 3.1 如果把事情搞砸了，你會怎麼辦？
   • 3.2 如果跟主管意見衝突如何處置
   • 3.3 如果擔任專案經理，你會如何與多個部門溝通，制定共同遵守的流程
   • 3.4 公司有跑 Scrum 嗎？你們是如何運作的？
   • 3.5 [狀況題]公司高層突然在週五下班前要求提前部署，你會如何應對？

1. 在工作中有遇過哪些挫折、衝突，以及你的處理方式

下面的內容可能由求職者主動說出來，或是被面試官問到，無論如何謹記一個原則：「要說出你是如何面對、處理這些事情，千萬不要淪為單純的抱怨！」

大家為人處世的方法不同，筆者的做法僅供參考；主要是為了讓讀者在遇到問題前，可以先思考自己的處理方式，不至於手忙腳亂。

1.1 同事刻意挑選你無法處理問題的時間捅你一刀

• 事件描述
  過去上班時有碰過同事，遇到問題不在上班時間詢問，而是等你離開辦公室後才在有總經理的群組 tag 你，說你的專案有 bug。
• 處理方式
  • 先作反思
    我會先回憶過去有什麼地方惹到他了，或是部門間是否有利益衝突；因為一個正常人沒道理在對方無法處理問題的時候，故意在有高階長官的群組 tag 他。
  • 盡快回覆
    儘管是在下班時段，但因為對方是在有高階長官的群組發佈訊息；所以我會盡快回覆，但不管對自己的程式多有自信，我都不會強調專案沒 bug，因為你此時可能在吃飯、運動、逛街，根本無法確認這個問題是否存在；筆者的回覆範例：「專案每個版本在釋出前有撰寫完整的測試案例確保功能穩定性，且通過測試部門的嚴密測試，針對 XXX 所提出的問題，我會盡快確認，並於明早 10:00 做好彙整向大家報告。」這段回覆有幾個重點：

    • 專案是經過測試，確認穩定後才釋出的。

    • 你有即時看到這則訊息。

    • 給出明確的報告時間。

      這邊舉例的是不影響系統運行且無法確認是否為真的 bug，如果是系統當機這類重大問題，你還是得即時處理。

  • 彙整報告

    • 真的有 bug
      老實承認錯誤，並承諾bug 的修復時間。

    • 如果沒 bug
      筆者報告完後，會用這段話做結尾：「感謝 XXX 在下班時間努力工作，可能是因為他太累了才會有這個錯誤回報；這部分我會再跟 XXX 溝通，希望他之後可以先跟負責的工程師釐清問題，避免類似的烏龍再次發生，抱歉讓各位長官受驚了。」

      筆者不會趁這個機會打壓對方，將對方的問題點出來、釐清責任歸屬就好；如果你沒辦法讓對方離開公司，那請做人留一線。

1.2 常常快到下班時間臨時開會

• 事件描述
  有些人一整天上班時間都不找你討論，偏偏等到下班前 10 分鐘才傳訊息跟你說有問題需要討論。
• 處理方式

  • 如果對方是故意的
    偶爾發生就算了，但如果對方是刻意如此，請明確地告知對方，你希望在上班時間討論；筆者的訊息範例：「如果有問題請在下班前一小時找我討論，這樣不會耽誤到彼此的下班時間，也有比較好的討論品質。」

  • 如果勸告無效
    如果對方在你明確告知後依然故我，筆者建議直接請上級提醒對方；有些人加班不是因為工作做不完，只是想在長官面前刷存在感，自己想刷存在感沒關係，但如果影響到其他同事就真的不好了。

    不是所有事情都一定要靠自己解決，適時的請上級支援也是有必要的。

1.3 跨部門溝通時遇到合作意願低又甩鍋的同事

職場奇葩多，遇到問題先甩鍋。

• 事件描述
  有時專案需要多個部門一起合作才能完成，但有些部門成員就是努力地拖延進度；你可能已經在 2 個月前就把功能完成並交付到對方手上，可是對方拖到最近才開始實作，但當上級問他功能怎麼還沒做完時，他會第一時間把責任丟到你身上，說是因為你功能不夠完善導致他無法作業。
• 處理方式
  • 留存證據
    職場上難搞的人太多，明明是自己的問題，卻把責任都推到對方身上；如果原本公司就有使用專案管理軟體就是一個很好的證據；如果沒有的話，建議要截圖對話紀錄並且每封 Email 都要把上級加入 Loop，以此保護自己。
  • 尋找關鍵人物
    如果你是專案負責人，但對方總是有各種理由拖延；到最後專案無法如期交付時，上級會找你麻煩，而不是找那個沒做事情的人麻煩。
    如果對方是因為部門不同而不願意配合，筆者建議你直接找對方上級溝通；但請在問題發生初期就去溝通，如果等到時程緊繃才去溝通就晚了，對方也會想辦法推卸責任。

1.4 跨部門開會時遇到用階級壓人的長官

• 事件描述
  在組織結構龐大的公司，有時開會的結論不是看哪個部門的方案比較好；而是看出席會議的長官中，誰的階級比較大。
• 處理方式

  • 先了解會議出席人員
    會有高階長官出席的會議不可能沒有會議通知；筆者會先向上級詢問這些長官在開會時的習性，因為有些長官會用階級來判斷你是否有跟他說話的資格。

  • 獲得相同話語權
    如果不幸遇到只看階級說話的長官，我會請主管邀請能與之抗衡的長官在會議列席，這樣在溝通上才有平等的話語權。

    直接請一個擁有相同話語權的人，會遠比自己以下犯上好很多；這裡是現實社會，不要以為自己是故事的主角。

1.5 開會冗長且不斷偏離主題

• 事件描述
  相信大家都有這個經驗，我們為了 A 的議題開會，但常常會開到一半就冒出 B、C、D 的延伸議題；不但造成會議時間大幅延長，有時甚至在會議結束後連 A 的議題都沒有結論。
• 處理方式
  • 以會議大綱為討論主軸
    很多會議只有主題沒有大綱，這造成了很多參與人員根本沒搞清楚開會目的，所以偏移主題實屬正常。
    如果在會議前就有把大綱發給與會人員，並在會議開始時先說明要解決的議題；把情境限制住後，就能減少非常多的延伸議題。
  • 延伸議題在其他會議討論
    開會過程中產生延伸議題實屬正常，但不建議在同一場會議中討論新的議題；除了會議容易失焦外，會議的時間延長也會使人無法集中精神。

2. 描述一下你在這份工作中擔任的角色、負責的任務

這塊原則上都是依照個人經歷敘述，面試官會挑感興趣的部分做深入詢問；下面是筆者統整常見的問題以及個人的回答方式。

2.1 敘述本職工作

目前擔任 Backend lead 並兼任專案經理。

• Backend lead
  對程式 Code Review、思考專案優化方向、負責新人的教育訓練。
• 專案經理
  與產品經理溝通了解需求，規劃專案時程、分配工作以及追蹤進度。

對內，讓團隊工程師實力成長，提升部門價值；對外，讓產品符合客戶需求，提升公司價值。

備註：其實跟自我介紹很像，說出面試官可能會感興趣的關鍵字。

2.2 與產品經理溝通

• 如果多項任務要完成
  我會先詢問每項任務的 Priority、要完成的時間；並初估開發所需時間以及人力資源配置。
• 需要跨團隊合作的任務
  我會建議產品經理找相關的 key man 一起討論，避免雙方的認知差異，導致最終結果不符預期。
• 遇到不熟悉的需求與技術
  如果碰上不熟悉的領域，我會先研究完這方面的資訊後，再跟產品經理說我預估的時程，而不會在一開始就直接承諾。

2.3 處理主管交代的事情

大部分的主管只會交代方向，比如：「幫忙規劃下個階段的企劃書。」

如果在不了解方向、時程、人力的狀態下直接開工，有大機率最後的成果與主管心中的答案不符，所以在收到任務時，我會先確認自己的思路是否與主管一致，舉例來說：

• 方向
  之前跟產品經理開會時，他有提出幾項客戶期待優化的需求，您看是否以這個為改版的主軸；其次再規劃新的功能。

• 時程
  我預計在週四早上將相關規劃整理好交給您，請問這個時間點可以嗎？

  記得盡量避免在週五以及平日下班前交企劃，這個時間點交企劃是希望主管加班嗎？

• 人力
  這次規劃的功能在人力資源上，除了團隊內部成員外，還需要與 XXX 部門合作；我這邊會先向他們的主管詢問方便合作的 schedule。

有時主管在指派任務時也沒有太多想法，所以要多做溝通釐清需求；如果時間允許，筆者會在初期提供幾個方案讓主管評估，否則加班加點到最後弄出來的產品不是公司需要的就真的悲劇了。

2.4 分配任務給組員

如果你擔任專案經理，上面交代給你的任務可能很模糊，但你向下分配的時候可不能模糊。

千萬不要把組員當成你心中的蛔蟲，指派任務時都要有明確的需求規格，像是：

• 需求來源
• 需求描述
• 影響範圍
• 驗收標準
• 預估工作天數
• 負責組員

如果需求規格寫的不夠明確，除了組員會時常跑來問你問題外，還可能做出完全無法使用的成果；儘管這個階段很費力氣，但真的要寫仔細，並且確認組員都明白自己要做的事。

每個工程師的工作效率相差很大，但在分配工作時還是要盡量做到平衡；不要讓能者過勞的狀況頻繁發生。

2.5 分享印象最深刻的專案

在我入職 3 年後，很幸運擔任一個千萬級別專案的負責人；除了撰寫程式外，需求訪談、時程規劃、易用性測試、教育訓練等工作都需要由我來做安排。

當時這個專案主要的使用者年齡落在 40~60 歲，我需要設計一個系統取代過去他們用紙本及 Excel 的作業流程；但是在溝通以及開發的過程是非常挫折的，因為網頁系統對他們來說是一個很陌生的東西，他們並不清楚自己要的是什麼；而當時的我只有開發經驗，對需求與規劃一竅不通，因此處處碰壁；再向周圍的前輩請教後才知道在前期可以先透過 Mind-Map 了解客戶需求，並利用 Wireframe 向客戶說明規劃。

不過 Wireframe 跟真實系統畢竟還是兩個概念，在系統進入第一次易用性測試後就是噩夢的開始；因為當時的流程規劃是跟承辦人還有一些長官討論出來的，但他們並不是這個系統的主要使用人員；導致系統在易用性測試時發現並不符合真實使用者的需求。

因此在易用性測試後，專案需求大幅更動，但截止日期沒有改變，且時程只剩下 1/3；我在這個時機點做了一個冒險的決定：「導入 Scrum 機制。」以此充分了解每個團隊成員的進度、遇到的困難、需要什麼幫助。在完成每個 Sprint 後，會請客戶試用確保符合需求，最後順利在時程內完成系統驗收。

一開始在承接這個案子的時候，我覺得他們有很多行為是無理取鬧；但到後來我體悟到：「只有你真正在乎的工作才會去爭辯，如果你不在乎大可讓他隨便。」所以我把自己的角色重新定位，帶著更多的同理心，從對方的視角去看問題，最後討論出來的答案往往是藉由工程師的專業以及他們的經驗揉合出來的成果。

一開始承接這個案子的時候我整天被客戶罵，但是在最後結案時，客戶主動打電話到公司向老闆稱讚我：「做事認真負責、工作效率高、溝通技巧良好；多虧了他才做出我們想要的系統。」

從一開始的四處碰壁，到最後得到甲方的尊重與認同；我現在回想起這段經歷，雖然苦澀但還是非常驕傲。

• 故事需要包含的元素
  筆者選擇用說故事的方式來回答這個問題，這邊整理故事中包含的元素。
  • 發生時間
  • 你擔任的角色
  • 遇到了什麼困難
  • 解決困難的方式
  • 自己從這個專案中學到了什麼
  • 客戶對你的回饋
  • 自己對這份專案的感悟

3. 常見問題

3.1 如果把事情搞砸了，你會怎麼辦？

我會明確說明自己在什麼時間點能夠解決，並盡力在預估的時間點前解決任務。

備註 1：第一時間千萬不要找理由搪塞，這只會讓主管更火；他此時關注的只有什麼時候可以解決問題。

備註 2：如果你真的是因為有其他的重要的事耽擱了，請把任務完成後再去跟主管解釋，此時的主管才聽得進去。

3.2 如果跟主管意見衝突如何處置

不同職位看事情的角度也會不一樣，我會先做一個聆聽者了解主管的想法，畢竟主管的經驗通常比我豐富，他會選擇這個做法可能是有一些我沒有考慮到的問題。

在了解意見的全貌後，如果我認為自己的想法有更多好處，我會先用詢問的方式，問看看主管有沒有考慮到這一塊，畢竟一個人能想到的內容是有極限的，透過一些思維的碰撞可以彌補彼此欠缺的地方，我相信有效的溝通是建立在雙方願意聆聽彼此的想法上面。

3.3 如果擔任專案經理，你會如何與多個部門溝通，制定共同遵守的流程

• STEP 1：我會先找合作部門的負責人協調，確認流程可行性與需要調整的地方。
• STEP 2：各部門負責人都認可流程後，我們會各自向部門成員再次確認是否有不周之處。
• STEP 3：各部門成員都接受後，我會開一個正式會議來公佈，以取得「全員共識」。
• STEP 4：在會議後發佈「正式流程」。

3.4 公司有跑 Scrum 嗎？你們是如何運作的？

在我們公司每個人都需要當 Scrum Master；如果只專注在自己的任務上，有時會偏離專案的方向。

我認為這樣跑 Scrum 的好處有：

• 培養從團隊的角度來看專案
• 快速回顧每個人的工作
• 解決成員卡住的問題
• 在當下確認任務，並協商出一個完成時間
• 每個 Sprint 結束後去思考有什麼部分可以再改進

開 Scrum 時會要求每個人說明以下內容（盡量控制在 3 分鐘內）：

• 昨天完成了哪些任務
• 有卡在哪些問題
• 今天要完成的事情
• 有需要哪些部門、同事的協作

3.5 [狀況題]公司高層突然在週五下班前要求提前部署，你會如何應對？

並不是高層交代下來的事情都必須答應，如果情境特殊，應該要先思考幾個問題：

• 這個任務是不是你一個人就能解決的？
• 如果搞砸了，會不會需要其他人的協助？會不會影響到公司？
• 這個任務一定要在這個時間點處理嗎？有什麼特別的理由？
• 如果按造原定計畫執行，會造成什麼損失？

筆者認為所有問題都是可以討論的，不要一開始就給自己否定答案；像是這個狀況題，如果真的發生意外，後果可能非常很嚴重，讓我們看看不同選擇帶來的後續影響：

• 接受
  如果順利部署那當然是皆大歡喜，但萬一不順利呢？

  • 注意力不集中
    今天是禮拜五而且快要下班了，你敢說自己還有 100% 的注意力在部署上？
    如果中間漏掉某個步驟、少了一個指令都可能導致部署失敗。

    若沒有 IaC（Infrastructure-as-code），在這個時間點部署根本是賭運氣；就算有，筆者也不建議在這個時間點部署。

  • 影響到同事
    如果部署失敗，問題你無法一個人解決，但已經到下班時間了；你可能晚上沒事，但你的同事呢？他們會不會有約會？
    大家急迫想下班的心情，可能會使洞越補越大，最後甚至變成整個部門留下來加班。

  • 沒有太多好處
    你部署成功，高層只會認為這是應該的，對整體職涯沒有太大幫助。
    但萬一出錯，或是假日才察覺到錯誤，那這件事對你在這間公司的職涯可說是毀滅性打擊。

    完全沒必要承擔高風險低報酬的任務。

• 拒絕
  當然不能用快要下班了這種理由拒絕，我們可以換個說法。

  • 詢問提前部署原因
    是因為客戶在假日有急迫的使用需求嗎？如果在下週一早上部署會造成什麼損失嗎？

    有時提前部署這件事，只是因為高層想要炫一波，並沒有特別原因。

  • 說明按造原定計劃的好處
    如果在周一部署有這些好處：「系統穩定性高、可有效追蹤部署後的狀況、如果發生意外可以盡快處理。」

本篇文章匯集了筆者與朋友在面試、工作上的應對進退，希望文章的內容對大家有幫助，也歡迎讀者在留言區分享自己的經驗。

感謝大家的閱讀，如果喜歡我的文章可以訂閱接收通知；如果有幫助到你，按Like可以讓我更有寫文的動力，我們明天見～

在許多人的幫助下，本系列文章已成功出版，除了添加新的篇章，更完善了每個案例的應對進退；如果對現在的職涯感到迷茫，也許這本書能帶給你不一樣的觀點～

天瓏書局： https://www.tenlong.com.tw/products/9786263334571