但這時會遇到一個問題：「每個人對專案的認知有差異，且文字表達能力不同。」

這會導致 Code Review 的人需要花更多的時間來理解程式，甚至浪費寶貴的時間在溝通上；有些交代不清楚的 Merge Request 如果被合併了，也容易在未來發現 Bug 時難以釐清問題。

而解決上面問題的方式也很簡單：「建立 Template（模板）」

如果大家都按照模板撰寫，就能保證每個 MR 都有一定的品質。

Merge Request 要有哪些資訊？

筆者個人建議一個好的 Merge Request 要包含以下元素：

1. 概要 & 背景：簡短描述這次 Merge Request 的目的，讓 Code Review 的人可以快速理解前因後果。
2. 相關資訊：放上專案需求規格連結、關聯的 Project/branch、會議紀錄等資訊。
3. 變更內容：說明新增/修改/移除了什麼內容，如果邏輯複雜可以簡述演算法。
4. 測試步驟：描述如何驗證這次的變更，包括需要運行的測試和預期結果。

大家可以參考我的 Merge Request Template 格式（Markdown 語法）：

# 概要 & 背景

# 相關資訊

- 需求規格: 
- 關聯的 Project/branch: 
- 任務 Ticket/會議紀錄: 

# 變更內容

- [新增] xxx
- [修改] yyy
- [移除] zzz

# 測試步驟

### 測試項目 1

- STEP 1: 
- STEP 2: 
- STEP 3: 

預期結果:

英文版：

# Summary & Background

# Relevant Information

- Requirement Specifications: 
- Associated Project/Branch: 
- Task Ticket/Meeting Notes: 

# Changes

- [Added] xxx
- [Modified] yyy
- [Removed] zzz

# Testing Steps

### Test Case 1

- STEP 1: 
- STEP 2: 
- STEP 3: 

Expected Result:

在 Gitlab 建立 Merge Request Templates 的步驟

STEP 1: 選擇 Project default branch，建立存放 Templates 的資料夾

我們要先在根目錄下建立 .gitlab/merge_request_templates/ 的資料夾。

小提醒：一定要在「default branch（ex: main、develop）」下建立，否則是沒有效的。

STEP 2: 在資料夾下建立「.md」的 Templates

你可以直接複製筆者在前面提供的 Markdown Template，這邊我將檔案命名為「merge.md」。

這邊我開一個測試的 branch 來做 Merge request，大家可以看到在 Description 旁邊有一個下拉選單，裡面的 merge 就是我們剛剛新增的模板。

選擇後就能看到剛剛建立的 Merge request Template：

相信一個好的 Merge request Template 能提高專案的品質，並加速團隊的協作流程，減少不必要的溝通成本。

軟體工程 Edit description dean-lin.medium.com

如果你已經淪落到這單不接就會餓死，那我建議你老實回去上班；因為接到爛案子，只會把你拖入更深的泥潭。

這篇文章會從 3 個面向給大家建議，畢竟有判斷、努力的方向才能持續成長。

文章大綱

ㄧ、什麼是好專案？
二、如何接到好專案？
三、如何判斷對方是否為好客戶？

ㄧ、什麼是好專案？

人的時間、精力有限，把注意力投入在「好專案」上，才有辦法持續成長。

1. 客戶尊重你：如果客戶是在了解你後才選擇你，而不是因為價格而選擇你。那他通常會比較尊重你的時間與流程，並讓你有一定的發揮空間。
2. 能賺錢：如果你是在工作之餘接案，那建議用 1.5~2 倍的時薪來計算報價；如果 [報價] 大於 [時薪 * 預估工時]，那才算是有利潤空間。更詳細的報價計算請參考這篇文章。
3. 對未來發展有幫助：有些專案在結束後根本無法成為你的「作品」，甚至讓人想直接把他丟到資源回收桶；因此在專案中能學到新技術、拓展視野，甚至獲得曝光帶來新客戶，也是一個重要的考量點。

不過在現實生活中，專案有符合上面其中一兩個就該偷笑了。

以筆者過去的經驗來說，「好客戶」往往是好專案最重要的基礎條件。

當人對了，一切都會往好的地方發展；如果彼此理念差異太大，就算你賺到了錢，也會有種人被抽乾的感覺，真的得不償失。

二、如何接到好專案？

如果你只是個 nobody，那是很難接到好專案的。

因為你要靠自己主動去找案源，但會釋出的案源通常都是一些難搞的 Case，不然早就有認識的人接單了。

所以如果想獲得好專案，讓更多人認識你是很重要的；但這塊需要花比較多的時間長久經營，下面分享幾個筆者持續在做的事情：

1. 分享自己的專業知識、作品：從 2020 年開始，我將自己的專業知識、作品分享到 FB、Medium、iT邦幫忙等平台，這些積累讓我獲得超過 200 萬次的曝光，讓更多潛在客戶認識我。
2. 分享到特定的社團：因為在個人版面發技術文根本沒人鳥我，所以我會將專業文章分享到技術社團，這樣才可能吸引到同好交流（擁有相似背景的人溝通起來會更有 Sense）。在合適的場合才會遇到對的人，減少浪費時間的可能性。
3. 強化個人特質：如果客戶是慕名而來，那專案會順利很多；但在資訊爆炸的時代想做到這點，你除了要有個人特質外，還要高頻率的曝光，畢竟被看見才會有機會。
4. 準備履歷＆作品集：要定期更新自己的履歷＆作品集，這樣遇到機會時，你才有辦法有脈絡的分享自己的觀點（前提是你有好的作品）。

提醒一下大家：「好的作品才會帶來好的專案。」

三、如何判斷對方是否為好客戶？

好客戶不常見，如果遇到請盡量培養成長期合作關係。

我們可以參考下面 3 點來做判斷：

1. 知道自己要什麼：有些客戶會在發想的階段找設計師、廠商討論，他們知道自己要做這個專案，但還沒有方向。但如果客戶不知道專案目的、目標族群、後續規劃… 那你要有後續討論難以對焦的心理準備，因為這些問題都可能導致時程延宕。如果走一步算一步，那設計規格肯定會一直調整，事情不斷重工，甚至無法結案。
2. 願意簽約：如果不簽合約，那代表客戶並不在意自己的權益。近一步思考，他可能不在意這個專案，這代表你們所做的討論、決策都可能隨時變卦。
3. 願意描述現狀：有些客戶希望你當個通靈師，不說需求要你猜；但這並不合理，就像我們看醫生會說自己不舒服的地方，這樣才能對症下藥。設計也是一樣，客戶可能不知道自己的問題，但描述現況與期待是必要的。

四、結語

雖然前面講了很多，但在沒作品的菜鳥時期；為了累積作品，部分有疑慮的專案還是得接。

我們能做的，就是當問題浮現時，把他優化到流程與文件中。

這樣你之後就知道在面對有疑慮的專案時，要在合約加上哪些備註，或是於交付內容上加限制，並在報價時把發生問題的時間成本考量進去。

以上是「職涯必修設計管理學」的 Part 5心得筆記 ，如果覺得我的分享對你有幫助，歡迎 Follow 我吸收更多知識。

但實際上，在累積一定的接案經驗後，繼續提高專業能力，並不會增加你的議價空間。

因為大部分的客戶並沒有那麼高的要求，你也許有 90 分的實力，但客戶只要 70 分的結果。

那麼在遇到瓶頸後，我們可以用哪些方法提高報價呢？

這篇文章會分享 6 個技巧，最後 3 個能立即見效！

ㄧ、經營個人品牌

既然有接案的本事，那肯定有自己的專業。

你可以嘗試將自己行業中的技術、心得、經驗，透過文章、影片的方式分享出去。

在特定領域持續分享自己的專業，會讓看到這些資訊的人對你產生信任感；如果他們未來找你談合作，就會對你有更多的尊重。

這道理就像如果只為了填飽肚子，你可以直接購買超商的微波食品。

但如果特地預定了某間餐廳，一定是對他有不同的期待，就算價格略高也可以接受。

二、在專業領域有自己的見解

有些人可能會覺得市場上已經有很多大神在分享經驗，根本不缺我這個小咖吧？

但其實並不是這個樣子的，因為每個人都有自己的背景、興趣、專長，從而產生出不同的視角。

就像大家在做同一個專案，每個人負責的任務、在意的細節、理解的程度往往有很大的差異。

不同的人生經驗會塑造出專屬自己的哲學觀，這是他人難以複製與取代的。

不管你的專業水平如何，都會有自己的受眾。

三、將成果分享到社團

在完成文章、影片後，除了發表到自己的頁面外；不要害羞，直接分享到相關的社團吧。

如果只發表在自己的頁面，那會注意到你的人就只有認識的朋友。

但分享到社團，會直接打破原有的舒適圈，讓更多的人認識你（批評你）。

分享我們為客戶製作的產品，其實也算是變向在幫客戶做宣傳、曝光，擁有很棒的廣告效果（這部分請先經過客戶同意）。

不過上面提到的都需要花時間經營，接下來分享幾個能夠立即見效的。

四、提供更多選擇

當客戶提出需求時，你可以基於這些內容提供更完整的解決方案。

這不但可以增加客戶對你的專業能力的信任，還可以提高報價。

因為客戶提出的需求，往往只在自己的認知範圍內，但其實還有很多細節是專業人士才會注意到的。

就像是我們訂外送，你可能一開始只是想買個雞腿便當，但在結帳前跳出加購飲料的優惠時，可能就順手加入購物車一起結帳。

五、建立接案的 SOP

時間就是金錢，但很多時候我們會把時間浪費在重複的事情上。

像下面這些資料，我建議要先準備好，並持續優化：

• 個人履歷、作品集（與客戶初步接洽時提供）
• 介紹服務的項目（初步認識＆討論）
• 報價單
• 合約

上面的文件做好模板後，建議製作一份檢查清單（範例如下），避免資訊錯誤顯得不專業：

• 公司名稱
• 報價日期
• 報價金額
• 規格內容
• 檢查錯字

六、提供內容詳盡的報價單

如果報價單的內容只有一行字，那客戶根本搞不清楚自己買了什麼東西。

就像我們購買高單價的商品時，一定會仔細看上面的說明，內容越清楚，我們會越信任他（哪怕我們看不懂）。

總結

經營個人品牌可以提高客戶的信任度，因為很少有人會為了追求短期利益而損害自己的聲譽。

如果我們有能力提供客戶更多選擇，就有機會提高客單價。

制定明確的接案 SOP 可以減少重工的時間，而一份詳盡的報價單能提高成交的機率。

希望這篇文章能幫大家爭取到更高的報價，也歡迎留言分享你的接案經驗。

以上是「職涯必修設計管理學」的 Part 4心得筆記 ，如果覺得我的分享對你有幫助，歡迎 Follow 我吸收更多知識。

如果打算長期接案，你一定要建立一套自己的報價邏輯體系；避免客戶詢問時，你愣在那邊支支吾吾不知如何回應。

接案僅適用於在某個領域擁有「專業」的人

請不要把接案當成自己練功的玩具，那是對自己與客戶的不負責。

建議對專業的掌握度到達「得心應手」後，再考慮去接案。

否則…你可能連評估專案工時的能力都不具備。

報價是「專業 + 客戶信任度 + 產品利潤」的總體考量

這就是為什麼老牌的接案公司、個人工作室往往案源不斷，甚至要排隊的原因。

因為除了專業很重要外，過去的作品、成果能夠增加客戶的信任度。

就像我們在買東西時，往往會挑大品牌，甚至去比哪個品牌得獎比較多，而不會冒險購買沒聽過的雜牌（除非是為了省錢）。

而剛出來接案的新手、沒什麼作品的工作室，就像是貨架上的雜牌；甲方會選擇你，通常是因為你有價格上的優勢。

所以接案初期通常是虧的，你賺到的錢甚至可能低於本職工作的時薪。

另外，不同產業的報價存在著巨大的差距。

像賺錢的產業往往有高額預算，而夕陽產業就算給出行業內最有誠意的價格，可能預算還不到前者的一半。

報價不是憑感覺，他是有邏輯的！

下面提供一個基礎的報價公式給大家:

報價 = 勞動成本 + 材料成本 + 其他成本 + 風險預期 + 利潤

• 勞動成本: 時薪 X 工時（如果是接外包，筆者會用本職工作的時薪 X 1.5~2 倍來計算）。
• 材料成本: 是否需要用到付費軟體、硬體設備、場地租借。
• 其他成本: 多久開一次會、每次開會幾個小時、在哪裡開會（實體會議需考慮通勤成本）。
• 風險預期: 完全順利的專案幾乎不存在於現實，所以在工時的預估上，建議多抓 1.2~1.3 倍的時間（如果你已經預感到這個客戶會雷，就報一個你接了不會後悔的價格）。
• 利潤: 這個就當成 Bonus 吧，可以抓總報價的 10~30% 之間。

上面的公式只是讓大家有一個初步的概念，如果你是新手，建議先用「勞動成本」作為報價基礎。

報價並沒有標準答案

有時報的價格太低，客戶反而會懷疑你做事的品質。

報價的數字需要合理且具競爭力，因為客戶往往會請多個人（單位）出報價單，然後從中選出最合適的（所以會寫報價單很重要）。

報價的平衡點，就是讓客戶買單的同時，也讓自己賺到合理的利潤。

以上是「職涯必修設計管理學」的 Part 3心得筆記 ，如果覺得我的分享對你有幫助，歡迎 Follow 我吸收更多知識。

對不了解系統上線流程的人來說，他們會覺得這不過就是個小調整，為什麼每次都要我三催四請的？

對開發的工程師來說，他們會覺得這些人有完沒完啊？這些文字不是都已經討論過了，為什麼每隔幾天，甚至幾小時就要改一次？

實際上，改動文字對工程師來說可能花不到 1 分鐘的時間。

但對有上版流程的公司來說，每次更新可能都要花 1 小時以上（就算只有改一個字）。

今天這篇文章不是要談誰對誰錯，或是如何用技巧來迴避問題；而是要分享面對問題時，可以如何一步步「解決」他。

文章寫完後，感覺自己在寫技術發展史；另外，這是朋友向我分享的經驗，絕對不是我自己的。

石器時代：寫死在程式碼

在最遠古的時期，網頁上的文字是寫死在程式碼的。

雖然直觀，但維護性極低。

因為面對「修改文字」的需求變更，開發人員可能改了 A 頁面，卻忘了還有 B、C、D 等頁面也用到一樣的詞彙。

大航海時代：建立語言包維護

如果系統只用同一種語言，那寫死在程式還勉強能維護。

但如果接下來要進軍國際市場，有中、日、英、法等多國語系的需求時，我想工程師就會崩潰了。

因為寫死在程式碼是完全行不通的，雖然很痛苦，但開發人員會需要把系統中所有的文字抽出來，建立「語言包」來維護才能解決這個需求。

這樣未來在面對「修改文字」的需求變更時，開發人員只要在單一檔案處理，透過模組化的管理，可以大幅降低遺漏的可能性。

工業時代：提供 Google Sheet 讓產品方填寫

把文字集中到語言包維護後，其實面對修改文字的需求就很容易處理了。

但…接下來要討論的是「人」的問題。

因為產品方會一直看系統的文字，看著看著可能就覺得哪裡不順眼，不順眼就要改！

所以在新版本上線後，可能一週內會收到多次文字變更的需求。

在這樣的狀況下，現實生活中最容易遇到的就是「漏訊息」；當訊息有前後因果關係、重複資訊的時候，失誤在所難免。

為了減少產品方打擾 PM 與工程師的頻率，以及減少訊息遺漏的問題。

提供一份格式律定好的 Google Sheet，讓產品方在線上「修改文字」是一個不錯的方案。

這樣雙方約定一個時間一次性更新即可（會跑一個將 Google Sheet 轉成語言包的腳本）。

科技時代：直接透過管理介面修改文字

改成 Google Sheet 後，雙方和平了好一段時間。

但還有一個問題，那就是這種修改沒有「即時性」。

因為程式每次上版都需要 Build Docker Image、跑回歸測試、上多個環境確認…

你可以理解為這些步驟至少要花費一小時以上的時間，而且會涉及到不同團隊的人（開發、QA、PM…）。

如果今天只是要修改文字，這樣的操作完全不符合成本效益。

所以目前的最新方案，就是在後台管理介面中，新增修改文字的功能，讓產品方可以依照自己的需求即時進行調整（搭配預覽頁）。

總結

修改文字是一個常見的需求變更，而且很多時候是在系統上線後才發生。

對工程師來說，修改文字這件事的確很簡單，但背後所需花費的時間與人力成本其實很高。

相信看完這篇文章後，大家可以理解為什麼有些小變更需要等一段時間才能更新。

儘管這篇不是純粹的技術文，但還是提醒一下讀者，每個時代的演進都需要不少時間成本。

這些改進所用到的技術並不困難，但問題在於：

• 有足夠多的時間來做優化嗎？
• 這個問題真的有優化的必要性嗎？
• 優化帶來的效益符合成本嗎？

因此千萬不要看完這篇文章後，就拿他去跟工程師吵架，我可不背這個黑鍋。

也許最後的方案在不久後會遇到其他挑戰，但這不就是「有問題我才有工作嗎？」

筆者過去接過的案子涵蓋網頁設計、APP 製作、網路爬蟲、專欄文章、線上課程、企業內訓…

不管是好的、壞的，還是奇怪的甲方全都遇過，所以在上設計管理的課程時很有「共鳴感」。

如果你有接案的打算，那這篇文章一定要讀到最後，別人踩過的坑，我們沒必要親自體會。

PS. 這篇文章沒有要批評任何一方的意思，其實無論甲方還是乙方都需要後天學習，沒有人天生就會。

文章大綱

ㄧ、與客戶初步接洽
二、初步認識＆討論
三、深入釐清需求
四、提供報價單
五、提供時程
六、提供合約＆簽約
七、結語

文章大綱所列出的，是接案常見的流程，可能會根據實際狀況增減。

ㄧ、與客戶初步接洽

建議先跟客戶確認以下 3 點，避免浪費彼此的時間：

• 時程: 了解客戶對專案時程的期待，確認彼此的時程能對上；當遇到急件時，你一定要考慮自己是否能夠如期完成。
• 類型: 判斷自己是否做過類似的專案，以及是否擅長這類型的專案。
• 預算: 你要初步提供自己可以接受的報價區間，避免談到後面才發現客戶無法負擔。

很多人會因為害怕或缺乏經驗，不敢在一開始跟客戶確認以上事宜，導致專案在一個很模糊的狀態下進行；但殊不知，這些模糊地帶往往會導致合作到後期彼此撕破臉。

另外你不要想著每次接洽都會成功，因為客戶可能一次聯繫很多人，避免出狀況時沒有備案。

這次沒有選你，未必是你不好，只是他們心目中的第一名接下了這個專案。

二、初步認識＆討論

客戶選擇你，不代表他了解你。

所以在跟客戶第一次見面時，建議你要先介紹自己過去的作品、做事的流程，讓客戶判斷自己是否能配合。

同時你也要了解客戶對這個專案的期待，像是專案的目標與背景資訊。

這邊也建議你了解一下客戶過往的做事流程，在資訊透明的狀態下才有可能合作愉快。

三、深入釐清需求

在初步確定合作意向後，建議約一個較大型的會議。

在這階段要讓專案相關利害人一同加入討論，以確認對方的需求。

四、提供報價單

如果沒有白紙黑字，那報價就只是憑感覺；以下是撰寫報價單要注意的事項：

• 不要有模糊空間: 規格要講清楚，能修改幾次要列出來，要明訂具體的流程。
• 附上但書: 具體寫上你不做的部分；並寫上如果真的要做，你會如何報價。

而這份報價單可以：

• 讓客戶思考預算: 有時客戶天馬行空，我們需要透過報價單把他拉回現實；如果有預算考量，可以在這個階段幫客戶收斂專案範圍，讓他對內容進行取捨。
• 幫我們初步篩選客戶: 在報價後，有些客戶會開始殺價或是提出不合理的需求；如果覺得對方的行為讓你覺得不舒服，那建議不要繼續合作下去，因為通常會越來越痛苦。

Tips: 與其消耗能量克服痛苦，不如一開始就選擇合適的客戶？

五、提供時程

有些專案的時程會長達幾個月，甚至以年為單位。

為了確保雙方的認知相同，我們要與客戶討論：

• 重要檢核點（里程碑）: 除了規畫專案時程外，還要列出每個階段可以驗收的項目；並在進行驗收前，確保相關利害關係人皆可參與這些重大會議（不然可能在後續被有決策權的人推翻重來）。
• 專案交付時間: 定下時間後，後續合約就會按照這個時間走。

六、提供合約

前面細節都確認完後，就可以準備簽約了，但簽約有很多細節需要注意，筆者有空時會再寫另一篇文章分享。

不過這邊也要提醒大家，簽約不代表有保障，就算對象是大公司也一樣。

因為法律流程跑起來曠日費時，我就聽說過有的公司的樓梯間堆滿法院傳票。

七、結語

你沒看錯，這篇文章談的只是「接案前要注意的事項」。

還有很多細節沒有寫進文章，比如: 如何報價、如何提高報價、如何接到好專案、如何判斷是否為好客戶…

接案其實很累，因為前期的溝通也是專案的成本。

如果在這個階段發現客戶不合適，建議及時停損，勉強的結果通常不好。

同時提醒大家，如果你在有正職的狀態下接案，請謹慎評估自己的身心狀況；因為接案而搞砸本業，那就真的本末倒置了。

以上是「職涯必修設計管理學」的 Part 2心得筆記 ，如果覺得我的分享對你有幫助，歡迎 Follow 我吸收更多知識。

但其實不管團隊、專案還是作品，都是需要被管理的。

如果一切都靠本能去做，那麼專案延遲交付、團隊缺乏方向、作品四散各地…這些可說是必然發生的悲劇。

就算為了減少自己的加班頻率，我們都該對「管理」有更深一層的認知。

管理是為了降低「意外」發生的可能性

每個人都是獨立的個體，所以有各自的想法、做事的習慣；如果沒有講好合作模式，那專案做到一半撕破臉基本上是家常便飯。

下面先列出幾個減少「意外」的方法：

• 簽訂合約: 不管專案大小，合作對象的親疏遠近，筆者強烈建議有合作就要簽約；簽約是專業的展現，也是對雙方的保障。
• 需求規格: 客戶的需求通常很模糊，不過我們可以透過需求規格，將這些發散的想法收斂成具體、可執行、可驗收的白紙黑字。
• 設計流程: 我們需要設計一套可以重複使用，並不斷優化的工作流程。明確的工作流程可以減少揣測彼此想法造成的誤會，並讓我們在面對不同專案、合作對象時有穩定的表現。
• 會議記錄: 任何會議、談話都需要有明確的文字紀錄，而且記錄要包含「是誰說的、前因後果、最終決議」等，這樣日後遇到爭議時才能釐清狀況。

將複雜的事務結構化，我們才有辦法有效管理，並持續執行。

將模糊的資訊明確化，我們做事才有效率，減少重工的可能性。

搞清楚誰有「決策」的權利

有時專案執行到一半，突然一通電話打來要你砍掉重練，因為公司高層覺得專案執行的方向錯了。

收到通知的你可能覺得很靠北，但這個在業界其實很常見，即便有需求規格、會議記錄佐證，但權力夠大的人就是可以推翻一切。

如果想減少這種狀況發生，就要在一開始搞清楚誰才是最後的「決策者」，並建議每次會議的結論需要由他畫押才算數。

很多時候專案的窗口、PM 甚至是主管，都只是在揣摩「決策者」的想法。

建立文件減少資訊「斷層」

有些專案為了求快，許多細節都是靠口耳相傳；這導致相關人員請假時，你需要重新說明一遍。

最差的狀況是關鍵人物相繼離職，而公司根本沒人知道過去發生了什麼事，然後專案就直接爛掉了。

為了避免資訊斷層，或是全公司只有一個人了解專案脈絡，最好將文件清晰的整合到一個大家都能閱讀的地方。

報價與工時都要有「邏輯」

接案時你要對客戶報價，工作時你要向公司預估時程。

但有時類似的專案、功能，我們會給出不同的報價、估時；此時對方可能會問你：「為什麼跟上次不一樣？」

如果你說不出報價、估時背後的邏輯，就會導致客戶、主管對你的印象大打折扣，甚至質疑你的專業能力。

為了避免這種事發生，建議準備一套報價、估時的邏輯＆公式，當對方有疑慮時，就可以有系統地進行說明。

失敗的經驗很珍貴，但不用親身體驗

寫這篇文章的時候有點感慨，想著自己為什麼在經過社會的毒打後才上到這堂課。

課程中所提到的案例都是在現實生活中會遇到的，相信在社會走跳一段時間的朋友們會很有共鳴。

人的生命有限，透過了解他人經歷來豐富自己閱歷，是更有效的成長方式。

以上是「職涯必修設計管理學」的 Part 1 心得筆記 ，如果覺得我的分享對你有幫助，歡迎 Follow 我吸收更多知識。

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

如何讓車子降速

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

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

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

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

如何保護路上的行人

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

因為 AI 跟人類一樣，如果你沒辦法清晰、具體的描述問題，你只會得到模稜兩可、不符預期的結果。

如果你覺得 AI、人類無法給你期待的答案，其實很多時候是因為根本沒把問題表達清楚，因此造成垃圾進，垃圾出 (Garbage in, garbage out) 的結果。

PS. 儘管這篇文章談的是「設計思考」，但與 AI 溝通時，設計思考也是相當重要的一環。

問題背後的問題

過去帶新人時，常常工作到一半就會收到私訊：「不好意思，可以問你一個問題嗎？」

收到訊息時，我通常會眉頭一皺，因為我根本不知道他要問什麼問題，所以先詢問他：「哪裡遇到問題了呢？」

新人：「我 xxx 功能做到一半卡住了。」

我：「為什麼會卡住？」

新人：「我使用 yyy 套件，但不知道 xxx 功能怎麼用。」

我：「你有看過套件的官方文件嗎？」

新人：「我看不懂官方文件。」

從表面來看，是新人功能做不出來；但真正的問題是「看不懂官方文件」，所以就算這次你幫了他，他下次遇到問題時還是會跑來找你。

不是每個人都很有耐心

在上面的案例中，我問了「3」次才抵達問題核心。

但在職場上，每個人都很忙，即使筆者也不能保證自己每次都很有耐心。

如果想請對方幫忙，盡可能一開始就完善的描述問題，而不要用開放式的詢問，建議的基本架構：

• 具體說明自己遇到的問題：可以搭配圖片、文件，讓對方在最短的時間掌握問題。
• 表達自己曾經做過的嘗試：即使是失敗的嘗試也列上去，否則就像是個伸手牌。
• 詢問對方可以討論的時間：因為對方可能手上有事情在忙，如果沒有約時間，可能已讀後就忘記了。

所以上面新人的問題就可以改成：「我想透過 yyy 套件達成 xxx 功能。但按照官方文件的範例（https://github.com/）實作後，還是做不出 xxx 功能，一直跑出 zzz 的錯誤訊息，不太確定是不是自己方向弄錯了。請問哪個時間點方便向您請教呢？感謝。」

表達越完善，對方越能在短時間了解問題，以增加回覆意願，或跟你說這個問題可以跟誰詢問。

把申論題改成選擇題

前幾篇設計思考的文章，都有談到「同理心」的重要性。

其實在發問前，我們可以先思考一下如果自己收到這個問題，會不會想回答，或者有什麼資訊不完整的地方。

當你站在對方的角度來思考，問出的問題就會不太一樣。

讓我們回想一下學生時期，相信大家在寫考卷的時候，比起申論題，應該更多人喜歡選擇題吧？

我們可以將「你覺得這個配色溫暖嗎？」這種開放式的問題，改成「你覺得 A 配色跟 B 配色哪個比較溫暖？」這類選擇題，這樣就會大幅降低對方回答的壓力。

把模糊的答案變精準

這是一個資本主義的社會，如果目標不夠具體，就容易花了很多錢但得不到成效。

就拿廣告來舉例好了，任何產品都有他的受眾。

如果你只問客戶他們的受眾是誰，客戶可能回答：「上班族。」

但上班族的市場很大，從 22~65 歲都是上班族；所以你需要更近一步的詢問，比如：

• 愛好（ex：戶外活動、逛展覽、運動、宅家裡…）
• 產業（ex：金融、科技、醫療、服務…）
• 薪資水平

透過細分市場你才有辦法聚焦，如果什麼都想要，下場往往是什麼都得不到。

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

面對不同意見時，許多人並不是用「引導」，而是要對方「按照自己」的想法做事。

若涉及自己的專業領域，我們更容易選擇後者，但話說出口前，我們不妨思考幾個問題：

• 他為什麼要聽你的話？
• 憑什麼覺得別人應該聽你的話？
• 你過去做了什麼事，值得讓別人要照著你說的去做？

你真的知道對方的需求嗎？

鄭司維老師在課程中提出的一個有趣問題：「你知道客戶買電鑽，是為了做什麼嗎？」

通常買電鑽是為了在牆壁上鑽洞（表層目標），但鑽洞會導致牆面結構破壞（負面影響）；如果客戶的目標只是為了掛畫（真實的目標），推薦他購買自黏畫框就好了（更好的解決方案）。

透過這個例子，是先讓大家認知到「客戶的選擇未必是對的」；以及更好的解決方案，是建立在有「背景知識」與「同理心」之上。

為什麼無障礙廁所的鏡子是傾斜的？

下次大家經過無障礙廁所時，可以探頭看一下裡面的鏡子，你會發現有些鏡子是往下斜的。

因為對於一些坐輪椅的人來說，這才是他們的視角。

如果你想同理別人，你就需要站在對方視角來看事情，這樣才能體會他遇到的困難與不便。

同理能加深彼此的羈絆

但同理時你可能會遇到一些問題：

1. 我們以為的同理，在對方看來可能是同情。
2. 你同理了對方，但對方根本不知道自己要的是什麼。

我們要承認自己不可能完全同理，因為我們就不是他；但我們嘗試同理的過程，對方是可以感受到的。

就像女生月經來，如果男生問要不要喝熱水、吃巧克力，女生通常都會生悶氣；因為男生沒有同理，而是直接說出解決方案。

同理就是要減少這種 SOP 的感受，去理解一句話背後的意義；但同時你也要了解一個人的個性，否則會導致誤判。

不用跟每個人都建立長久關係

通常溝通幾次後，你就能判斷對方是否值得深交；了解彼此的能力、達成共識，這樣合作的關係才容易長久。

以工作來說，有些東西可以明文規定；但不能規定的部分，我們可以用長期經營的方式，去做共創，彼此成長。

反過來，如果你認為對方只值得短期的合作，那就不要想太多；讓我們在規定的範圍內做好彼此的事情，這樣我們都不會受傷。

讓客戶接納你的建議

很多客戶認為自己比你更懂，所以你需要展現出自己的專業，讓客戶知道你也是懂行、做過功課的。

比如客戶在跟你討論設計風格的時候，我們應該先去了解產品目前的行銷策略、目標 TA、推廣方式等等；等這些資訊都明確後，我們才在這些資訊的基礎上給出對應的設計風格。

如果客戶對你的專業有信任度（Sense 有到位），推動專案才會順利，也埋下日後合作的種子。

補充：如果該做的都有到位，但老闆、主管、客戶還是無法溝通，那要思考一下這個環境是否要繼續待下去，否則永遠不會進步。

認知造就了你的世界

我們吃慣了台灣的義大利麵、法式餐點、泰式料理，但到了當地後，你可能會感到不適應，因為很多料理到台灣都經過「文化適應」。

當地著名的餐廳未必符合你的口味，但這份經驗能讓你理解當地人的口味；道地的未必好吃，好吃的未必道地。

透過餐飲文化的不同，我們就能了解，同樣的決策換一個時空背景可能就不合適了，我們不要總覺得自己是對的。

在文章的最後，建議大家可以透過旅行、讀書、看電影、聽講座…等方式拓展自己的視野與想像力。

你對世界的認識越深，就能理解不同的文化、背景，去同理對方在想什麼。

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

舉凡演講簡報的字太小、展覽動線堪比迷宮、看不懂主題的海報、操作到一半就卡住的網站…愚蠢的設計在各行各業都能看到。

但在批評這些設計前，也許我們可以先思考一下他們誕生的原因。

你在乎自己的作品嗎？

出社會後，我們無法隨心所欲地讓作品往自己期待的方向發展。

很多時候老闆、主管、客戶，會把自己的想法強壓到作品上面；一開始你會反抗，但時間久了，大多數的人為了生活還是選擇了「妥協」。

這樣的想法一但成為了習慣，你就會失去身為創作者最重要的靈魂，變成一個聽命行事的木偶。

如果創作只是為了「完成任務」，那我們就不太會去思考。少了思考、少了全盤的考量，那最終設計出來的成果很可能根本不能用。

就像是學生交作業，很多時候只是為做而做。

你紀錄過自己的想法嗎？

做事前，你會把自己為什麼這樣做的想法記錄下來嗎？還是想到什麼就去做什麼？

如果想到什麼就做什麼，那最後的成果可能毫無邏輯；甚至很多人做完後也忘記了當初為什麼要這麼做，所以做了很多的白工。

更可怕的是，有些人在解決 A 問題後，還製造了 B、C、D 的問題；不要懷疑，筆者在業界已經聽過非常多這類的鬼故事。

就算是為了減少加班的可能性，建議大家在做任何事情前，先把想法記錄下來，當想法轉為文字時，很多荒謬的設計就會消失了；如果可以，最好跟相關人員開個會，可以大幅減少考量不周導致的意外。

你認同自己現在做的事嗎？

當做的事情跟想的事情不同時，我們容易越走越偏，因為你無法說服自己那些是合理的。

比如讓工程師學 10 年前的技術、設計師當老闆的聲控繪圖板，相信我，在這種環境中沒幾個人能獲得成就感。

但請不要把自己現在的職場環境當成全部，這個世界很大，不是每間公司都是這個樣子。

但有能力的人，才有選擇的權利。

搞清楚你要完成的是功能還是藝術

藝術是為了自我實現，而功能則是為了符合商業價值。

沒有人會在作品被批評的一文不值、被改得面目全非後還會很快樂。

大家都渴望獲得認同、掌聲與肯定；因為受到認可後，我們才會對自己的設計感到自信。

獲得自信後，我們才有辦法不執著於那些掌聲與認同。

在社會生存，我們要識時務者為俊傑；但請不要捨棄自己的風格，也許在未來的某一天會有人發現他的價值，只是我們不能期待現在做的這件事就立刻有價值。

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

我學設計的初衷並不是為了成為一名設計師，而是在培養自己對美的觀察力，以及與設計師溝通的能力。

今天就來繼續分享「設計思考全方位」的心得筆記。

房東如何吸引到合適的租客

在第二單元中，方序中老師提出了一個很棒的題目，大家不妨想想看：「如果你是一個房東，你會如何設計空間內的視覺、聽覺、味覺、觸覺？然後吸引到適合的房客。」

很多人會抱怨遇不到好房東，但如果讓你扮演房東角色，你就會去思考怎樣的空間才能吸引到對的人。

以這個題目來說，設計只是其中的一環，他是一個複合性的訓練；即便沒有受過設計的專業訓練，你還是有能力去思考空間呈現的方式。

掌握流行趨勢很重要，但你要有自己的風格

我覺得這個概念可以套用在任何產業。

像今年 AI 很流行，你只要分享 AI 相關應用就可以有流量；但分享的人這麼多，等熱潮過後，有多少人會記得你？

跟著流行趨勢走，你有更高機率做出被大家鼓掌、歡迎的作品；但請定期反問自己，這些作品跟你是有連結的嗎？還是你只是做出一個跟大家都很像的作品。

設計之所以有趣，是因為每個人的生活模式、價值觀都不一樣，所以不太可能會有一模一樣的設計產生。

想讓作品有風格，先從認識自己開始。

不要追求「正確解答」，但也不要忽略「提示」

每個人都是獨立的個體，天賦、性格、背景、知識都有很大的差異。

因此對 A 來說的「正確解答」，從 B 的角度來看很有可能是個累贅。

所以當別人給你優化建議的時候，不要把它當成「解答」，而是當成「提示」；但如果發現有重複的「提示」反覆出現，也許就真的有調整的必要性。

所謂的「正確解答」，往往要靠自己不斷去練習、學習、失敗，才會摸索出適合自己的線索。

培養自己的「興趣與嗜好」

當熱愛的事物變成工作時，你很難感受到真正的快樂。

因為工作往往存在各種限制、阻礙，你無法完全按造自己的想法執行；有時甚至會做出不想承認那是自己成果的「作品」。

如果你的生活只有工作，那工作不順時就會陷入低潮。

但「興趣與嗜好」能讓你維持生活的熱情，讓你在工作之餘釋放和找到情緒的出口。

案子不順遂時去找一個「停損點」

不可能所有案子都按造你的期待去走，你可能會遇到時程壓力、沒 Sense 的客戶、成果不如預期…

如果在這種情境下依舊投入大量心力，你會非常的痛苦，然後走不出來。

當案子不順遂時，我們需要去找一個停損點，這不是要你擺爛，你還是要圓滿地完成它。

我只是要你停止從這個案子獲得成就感的想法，並將這份期待轉移到下一個案子上面。

不過如果每個案子都不順遂，那可能要思考是公司還是自己要調整了。

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

在上完「設計思考全方位」的第一堂課後，我發現，設計的理念超越了技能和背景，它更像是一種生活方式。

設計思考：解決問題的新策略

大部分的人都依賴直覺和經驗來應對生活和職場的挑戰，但設計思考提供了一種更加系統化、深入的策略。以一個日常例子來說，當家中的雞蛋用完，你如何計劃購買？

➤ 釐清需求：選擇雞蛋的類型 — 追求經濟還是品質？

➤ 定義問題：選擇購買地點和交通方式 — 市場還是超市？步行還是開車？

➤ 附加價值：除了雞蛋，還需要購買哪些食材或生活用品？

🥹 如果沒有想清楚，你可能會把事情拆成好幾次來做，比如：

➤ 在超市買完雞蛋後發現需要買肉，然後再跑一趟大賣場，隔天發現衛生紙用完了，需要再跑一趟超商。

但上述任務是可以「一次性」解決的。透過「設計思考」，我們不僅能解決問題，還能進一步優化流程，讓日常生活更加合理。

用「同理」來平衡商業與創作

出社會後，你的創作不能只考慮到「自己」，還要考量到「客戶」與「消費者」。

站在自我成長、自我實現的角度，你可能會想使用最新的技術、時下流行的設計；但可能會遇到題材不適合，或是想法太前衛客戶無法接受。

為你設計買單的是「客戶」，帶來商業價值的是「消費者」，但這兩者的想法可能有很大的衝突。以電影的廣告來說，滿足導演期待的內容可能太過深奧、無聊，滿足消費者的又太沒氣質、商業。

「自己 VS 客戶 VS 消費者」是一個商業與創作的三角，如果想做到「同理」，你就要跳出這個三角，從旁觀者去思考會更明白自己應該要去做的事，正所謂「當局者迷，旁觀者清」。

即使主題相同，也都有各自的風格

像「憤怒」這個情緒，他在每個人身上呈現的方式是不同的。有些人使用暴力、有些人選擇沈默、有些人笑的讓你發慌。

所以我們不妨思考一下，我的憤怒跟別人的憤怒差在哪裡？如果用顏色、線條來表現，會長什麼樣子？

這個道理可以套用在不同的領域中，如果你常逛「購物網站」就會發現，儘管 PCHome、MOMO、蝦皮都是購物網站，但彼此的風格有很大的差異；因為 TA 的年齡層、性別、喜好都不一樣。

在面對需求時，如果能快速判別出這些與競爭對手不同的點，就更有機會取得成果。

回答「我覺得這樣比較好看」很不專業

如果問設計師為何這樣設計，而他只回你：「我覺得這樣比較好看。」

如果繼續細問還是無法給出具體邏輯時，設計師可能根本沒搞清楚自己在做什麼東西。

以網頁設計來說，每個元件的大小、顏色、間距、位置、層級，都有它背後代表的含義，而不會只是「我覺得這樣比較好看」。

如果遇到沒有 Sense 的客戶

不要期待客戶擁有跟你一樣的專業，不會表達自己需求的客戶才是大多數。

為了減少分歧，你要先了解客戶對作品的期待，而不是先入為主的認為這個主題應該要怎麼做。

如果遇到意見衝突，可以從三個面向來嘗試溝通：

• 客戶對作品的期待：有些案子的時程比較長，客戶根本忘記當初自己說了些什麼，你可以把情境再來回來一次。
• 消費者的想法：嘗試讓客戶扮演消費者，用不同的角度來看規劃的合理性。
• 設計師本身的專業：說明自己設計的邏輯、理由，以及可以帶來的效果。

有些客戶可能需求是：「我想要做獨一而二，沒有人做過的嘗試！」

遇到願意讓自己隨意發揮的客戶很幸運，但站在設計師的角度來講，應該把他拉回來，畢竟產品是需要賣錢的（如果不在乎錢的客戶當我沒說）。

而且設計也不要完全按造自己的喜好，以平面設計來說，假如要設計一個 Logo、圖案；在配色、線條上可能要思考它是可以在不同媒材上可以展現的嗎？

因為活動、品牌時常會出一些周邊產品，他在毛巾、扇子、瓶子上面都是可以呈現的嗎？會有需要特殊印刷導致增加的成本嗎？

如果到最後生產時才突然多出這些成本，是會 GG 的。

設計合約時，先設想最差的狀況

建議簽約時要有附加條款：「在產生初稿後，如果有巨大的修改，可以有 N 次修改的機會；若超過則會需要增加多少錢。」

設計合約時，要先思考的不是這個專案會完美結案，要去思考最糟糕的狀況可以如何處理、自己犯錯的時候怎麼辦。把所有最壞的情境都考慮到後，我們更有可能完美的完成專案。

PS. 如果特殊情境沒時間簽約，那請在 Email 留下紀錄，不要在 FB、LINE 這類可以移除訊息的軟體上溝通。

容許失敗、面對失敗、持續試錯

為什麼研發會很貴？因為研發就是不斷地試錯！

好的作品背後往往有無數次的失敗經驗，與其去研究成功作品有哪些元素，不如探討他背後經歷了哪些失敗。

面對失敗的心態很重要，我們不需要自我否定。 先承認自己是一個人，而絕大多數人都是一般人，犯錯是難免的事，很少有發生一個失誤人生就直接完蛋的情境（除非按到核彈發射按鈕）。

不要妄想去建立一個完美人設，不然遲早會翻車。不要想把每個作品都做到淋漓盡致，那只會逼死自己。

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

別誤會，雖然我開過課、也講了很多場講座，但我還沒斜槓到設計領域😆

我是工程師×作家×講師，今年收到的 Email 以講座邀請最為大宗，也有部份課程推廣的邀約，不過大多以 AI 或科技領域為主。

但收到 Hahow 好學校 的邀約時，我愣了大概幾秒；因為這次是要推廣【設計實戰全方位】的課程。

當下甚至懷疑是不是有哪位業界大佬跟我同名同姓🤔 畢竟我又不是設計領域的專家，怎麼會請我推廣呢😆

不過等待 ChatGPT 撰寫婉拒信的過程中…

我點開了課程網頁，一邊看課程介紹，一邊望向前幾天印刷出包的名片😅

然後再回到 FB 看看自己設計的廣告文宣，恩…雖然不想面對，但是時候提升自己對設計敏銳度了。

接著看到師資陣容，雖然設計界的大師我一位也認不得😅

但 Google 後才發現這些講師都很有名氣（原諒小弟有眼不識泰山QQ）

真佩服 二棲知學 能集結這麼多領域的大師，並讓他們願意在課程中分享自己多年的實戰經驗，帶領大家從金曲獎、美感教科書、台灣設計展、國慶…等知名專案中學習。

雖然設計軟體不見得每個人都用得到，但設計思維卻是我所需要的；比起知道一個工具怎麼使用，了解什麼是「好」的設計更加重要！

以往在學習的道路上，我們要跌跌撞撞的成長，而現在這堂課直接給你完整的學習地圖。

讓【設計實戰全方位】成為你的第一堂，也是最後一堂線上設計課！

投資理財有賺有賠，但投資自己絕對不虧💪

🌟課程特色🌟

• 20 位頂尖大師親自授課，寶貴經驗分享
• 從基礎到進階，系統性學習一套就夠
• 從美感培養，到提案技巧全方位攻略
• 成為你的第一堂，也是最後一堂設計課

⏳限時優惠⏳

• 課程募資優於 6 折，越早買贈品越豪華！
• 使用專屬折扣碼「dean500」可享募資價再折 $500！
• 折扣碼使用期間： 2023/8/15(二）～ 9/18(一） 23:59

🔗課程連結🔗

https://go.hahow.in/LteOl/dean500

我已經等不及上課了🔥你呢？

如果你擔任公司的 PM 或主管，在下次專案出現 Bug 時，不妨參考文章的方式來溝通；如果你是工程師，也能採用文章的建議，減少自己修 Bug 時被打擾的次數。

釐清問題前，盡量不要強壓時間

有些主管在 Bug 出現後，根本不管問題複雜度，直接命令工程師：「給我在 15 分鐘內修復完成！」

如果是問題明確的小 Bug，那壓個時間倒也還好；但如果問題複雜度高，強壓一個不合理的時間，那對解決問題並沒有幫助。

說實話，遇到 Bug 的時候工程師就已經很緊張了，如果再加一個很短的時間限制；在腦袋一團亂的狀態下，就算解決了表面上的 Bug，可能背後又同時埋下了更多的 Bug。

筆者比較建議的詢問方式為：「大概需要多少時間釐清問題？」

這裡想表達的是，讓有專業能力的人來估時間；而不是由搞不清楚狀況的人，隨意定一個時間。

工程師要「主動」給出回報時間

要給的是「回報時間」，而不是「解決時間」。

面對完全摸不著頭緒的問題，如果直接說自己可以在 xxx 時間內解決，那會給主管一個錯誤的期待。

如果你真的順利在時間內解決那是皆大歡喜，但萬一還是無法解決那怎麼辦？

就算之前都運氣好順利解決，但只要你失敗過一次，許多主管就只會記得失敗的那次。

因此筆者建議用這種方式回覆：「這邊我們先釐清問題，半小時後向您回報 Bug 處理狀況，如果有順利提前解決也會即時回報。」

這樣做有以下好處：

1. 主管知道什麼「時間點」會收到回報。
2. 如果提前解決，你會被認為是效率高。
3. 我們說的是「回報時間」並非「解決時間」，給自己一點緩衝空間。

工程師千萬別說自己會「盡快」解決

如果說自己會盡快解決，那有高機率每 3~5 分鐘就被打擾一次。

因為每個人對「盡快」的時間定義不同，人一但急了就會催促，而對工程師來說，如果在釐清邏輯時被打斷，那可能會需要再重新順一遍；所以筆者建議要說出「具體時間」，避免在解決問題的過程被頻繁打擾。

總結

遇到 Bug 時，無論主管、PM 還是工程師都很緊張；但有時越急犯的錯越多，下次不妨嘗試看看：

1. 讓工程師自己定下回報時間：建議將回報時間設定在 30 ~ 60 分鐘。
2. 回報時間內不要打擾工程師：大家都很急，如果耐不住性子打斷工程師的思緒，就可能導致需要更多的時間來解決 Bug。
3. 要求工程師定時回報處理進度：如果判定問題無法短時間解決，工程師就需要「定時」回報處理進度（若沒有定時回報的機制，有些人就算卡住了也不會主動說）；這個「定時」會給人增加一些安全感，並減少工程師被打擾的次數。

希望這篇文章的建議，能讓大家日後遇到 Bug 時合作更為和諧；如果您有不一樣的觀點，也歡迎留言討論。

舉個簡單的例子，如果你有在玩電腦遊戲，一定會先看簡介裡的「系統需求」，避免買了跑起來卡頓，甚至開不了的遊戲。

以 STEAM 遊戲舉例，在「作業系統」的部分，可能會建議電腦要有「Windows 7 64 位元 （不支援 32 位元）」以上的配備，如果你的電腦還是 Windows XP 32 位元，那基本上是無法運行的。

當然人不會像程式一樣那麼死板，但也只能做出自己認知範圍內的決策。

沒有相同權力，就很難擁有相同視野

因為筆者曾擔任過 Developer、Project Manager、Tech Lead 等角色，所以很清楚如果沒有真的站在那個位置，就很難理解對方為何會做出這樣的決策；畢竟不同角色面對的人、事、物差異極大，彼此的情報也有很大的落差。

當然市面上有非常多管理學、人際學、溝通學的書籍可以參考，業界也有很多優秀的講師分享、傳授自己的經驗；但說真的…無論讀多少本書、上多少堂課，都遠遠比不上自己實戰得到的經驗。

這不是在說學習沒有用，如果你有深厚的理論知識，在未來面臨突發狀況時，你的應對進退一定會比那些完全沒有準備的人更加完善（這裡我們排除那些天賦異稟的領導者）。

擴增自己的認知範圍

儘管職位不到，但我們還是有其他方法獲得實戰經驗。

就如同標題所述，大部分的主管都希望下屬站在他們的角度去思考，畢竟這樣他們交代任務會更為輕鬆。

向上兼容是跳出舒適圈的過程，需要勇氣與毅力。

在科技業，如果只站在工程師的角度，你可能會覺得沒必要幫主管想這麼多；但如果想在職涯上更進一步（ex：資深技術職、晉升管理職），懂主管在想什麼是非常重要的。

筆者建議要多與主管溝通，並適時表達自己的想法，在規劃任務時，可以看看自己與主管的想法是否一致；如果有分歧，可以與主管討論，了解他為何會做出這個決策（主管的決策也並非萬無一失，彼此的交流能讓規劃更為完整）。

這些交流是非常寶貴的，因為它讓你在取得權力前，能借用對方的視野去看問題，以此擴增自己的認知範圍；當然這一切的前提是，你有優秀的主管，並且他願意與你交流。

警告：

這邊特別提醒大家，如果主管要你幫忙做出「不符職權的重要決策」，筆者建議要裝傻推掉；因為有些主管將做決策的任務交給下屬，不是為了重用他，而是在找人背黑鍋。

結語

如果一直做相同的事，在職場只會獲得年資，待在久也不會提升自己的認知範圍。

而本文提出的方法，儘管無法擁有與主管相同的權力，但我們能借用主管的視野，透過一次次反饋去優化我們的思維。

最近身旁有位工程師朋友，他與筆者分享了部門主管在團隊 Tech Lead 離職後遇到的諸多問題，因為談話內容值得警惕，所以特別寫了這篇文章與大家分享。

有些工程師在升上管理職後，因為忙於專案管理，所以會慢慢把技術放掉，都交給底下的人去學習、操作；但只要一放掉，隨著年齡的增長，技術會越來越難重拾回來。

接下來就讓我們來看看，如果技術部門主管不熟悉技術，那在團隊的 Tech Lead 離職後，他會遇到哪些困境。

因為太久沒碰技術，各項判斷能力大幅下降

如果過去都靠 Tech Lead 協助判斷、整理報告，那現在只靠自己就會遇到許多問題：

• 用舊時代的技術評斷新時代的需求：科技日新月異，現在跟過去的技術也是天差地別，要一個只用過 HTML、CSS、JavaScript 的人，去判斷哪個前端框架更適合專案，說實話有點強人所難。
• 無法判斷各項功能的合理估時：因為脫離技術太久，如果別人說這個功能會用到 xxx 技術所以會花很多時間，自己也很難判斷是否所言屬實。
• 技術的可行性由別人說了算：有些 Feature 會需要用到新技術，但因為自己連開發環境都架不太起來，所以當別人說新技術不可行時也無從判斷。
• 面試只能碰運氣找人才：因為現在專案用的技術自己都不太熟悉，所以在面試時很難提出適當的技術問題，只能從對方的從業經驗來判斷。

這邊筆者補充一下，如果團隊氣氛和諧，每個人都有自己的專業，那上面所提出的問題是有機會避免的（前提是大家估時都很有良心、評估技術時都拿出專業態度，面試時主管也願意讓團隊成員一起參與）。

想要重拾技術，但是…

朋友說他的部門主管是想重拾技術的，但這個想法有點力不從心（部門主管年紀約 40 出頭，脫離技術近 8 年），主要原因為：

• 上班沒時間，下班沒體力：當初會放掉技術，就是因為上班忙於專案管理、談判溝通，還有一些行政上的雜事；而下班後精疲力盡，能學習的時間太少。
• 太久沒碰技術，挫折感太大：好不容易擠出時間學習了，卻發覺現在的技術都看不太懂，連跑範例程式都要搞一段時間，學習與理解能力跟年輕時相比衰退了不少。
• 快要學不動了：過去的技術相對單純，而近幾年技術則是爆炸性的成長，框架、套件、雲端服務如雨後春筍般出現，要學的東西越來越多。

30 歲跟 40 歲的學習能力、身體素質還是有一定差別的，隨著年齡增長、職務上升，技術要跟上潮流確實有其困難性，我們只能盡可能地保持對技術的敏銳度，至少要理解現在專案用了哪些技術。

結語

相信上面的案例已經充分地讓大家體會到，如果技術部門主管不熟悉技術，又沒人能給出合適的建議時，他將會面臨的種種痛點。

最後再統整一下筆者與朋友聊完後的心得：

1. 不要因為當上「管理職」就完全把技術放掉。
2. 技術不要完全倚賴副手（ex：Tech Lead），你要隨時做好自己面對的準備。
3. 不要讓自己落入重拾技術的窘境，要盡可能保持對技術的敏銳度。

只要還待在科技業，就不要輕易放棄技術；因為你很難保證自己永遠都是「管理職」，或是只需要做管理職的事。

過去同甘共苦，一起熬夜加班罵主管的同事，如今搖身一變，成了自己的直屬主管。

在升官後，他變得越來越陌生，不只講話的態度不一樣，還做出許多自己曾經唾棄的決策，他這樣跟之前的主管有什麼差別？

在職場上，除非升官的人德高望重，或比自己強大太多；否則很多人的腦中都會浮現：「為什麼升官的人不是我？」

如果你腦中出現這個想法，那日後與新主管合作時，就可能產生一些主觀意識造成的偏見；為了盡可能減少偏見帶來的衝突，今天這篇文章會與大家討論：

1. 心理因素造成的偏見有哪些？
2. 如何調適自己的心態？
3. 站在對方的角度去思考，爭取下次升官機會。

備註：本文不討論同事升官後性情大變、整組壞掉的情境。

心理因素造成的偏見

如果你也想升官，但最後升的不是你；那在心理不平衡的時候，容易帶著有色眼鏡去看對方的所有行動，比如：

• 討論解決方案時對方講話比較大聲 ➝ 你會覺得：「有官威喔！升官後講話口氣都不一樣了。」
• 指派只有你能解決的困難任務 ➝ 你會想：「怎麼難搞的任務都丟給我？是故意的吧！」

也許你們的溝通方式沒有改變，而你也比較擅長解決某些問題；但在對方升官後，偏見會導致你覺得對方無論做什麼都是錯的，就算他沒這個意思也容易被曲解。

升官是綜合因素考量，沒升上去不代表你比較差，只是對方的某些條件比你更為合適（ex：更懂主管的心、具備群眾基礎、過去展現過領導力）。

調整自己的心態

很多時候我們覺得換個位置就換個腦袋，假使對方是工程師升管理職，那你可能還會對他升官後的許多決策感到不解，比如：

• 這個需求一定要加班才有辦法完成，不久前你也是工程師，應該很清楚啊！？
• 過去我們不是都在吐槽前主管亂接需求，怎麼換了你還是一樣什麼都接？
• 這個時程估的太緊繃了，之前專案怎麼爆掉的你都忘了嗎？

我們感到困惑的同時，可以思考一個問題：「是不是之前的主管也是這樣？」

公司不會因為換一個主管就減輕部門壓力（沒增加就很好了），因此除非新主管有能力優化工作流程，或是擁有極強的職場社交能力；否則對基層來說，換誰上去都差不多。

在理解對方的無奈後，如果沒有離職的打算，就要調整自己的心態，無論感性還是理性都要把對方當成自己的主管，以後說的話、做的動作也要注意界線，像是：

• 以前你們一起罵主管，如果現在你還敢直接批評就可能要倒霉了。
• 過去如果會勾肩搭背，現在建議避免這類肢體動作。

每間公司的文化不同，請依實際狀況酌情參考。

但這不是指主管說什麼都要附和，如果公司只剩下一種聲音，那也不是健康的狀況。

站在對方的立場，成為副手

很多人在升官後是恐慌的，如果這時有人可以跟他站在同一陣線，他會特別有印象。

這邊提醒一點，你要成為的是「副手」而不是「奴隸」；幫主管最好的方式並不是替他把事情做完，而是讓其他人也願意服從新主管的命令。

「雪中送炭」才會被人記住，跟主管關係良好，與同事合作順利；如果之後有合適的主管缺，或主管再次升官時，你會比其他人有更高的機率升官。

對工程師來說，做事的能力很重要；但如果想在一間工作待得舒服，無論你想不想升官，做人都是很重要的（至少不要跟主管起衝突，跟同事吵架）。

以筆者的角度來看，錄取一個不合適的人是主管的問題，但這又牽扯到公司願意在這個職位撥多少預算；如果預算有限，主管通常會選一個「感覺」有潛力的新人，先找進公司再做培養。

但被錄取的菜鳥 PM 真的很可憐；在缺乏專業能力的狀態下，他很容易變成主管、客戶、合作部門的傳聲筒，運氣差點還會成為 RD 的受氣包。

當傳聲筒除了無法獲得成就感外，也容易厭倦工作環境待不久。

如何脫離傳聲筒？

PM 是部門對外的聯繫窗口，每天會收到來自各方的訊息。

但在剛到職的時候，菜鳥 PM 會有一種無力感，因為在對專案、部門、文化都不熟悉的狀態下，他只能扮演「傳聲筒」的角色，沒有處理訊息的能力，只能單純的轉發。

如果想脫離傳聲筒，首先要對收到的訊息有自己的看法，並有能力給出合適的處理方案；但想跨出這一步並不容易，因為看懂訊息本身就是一個門檻，如果看不懂訊息還亂回，只會把事情弄得更糟。

了解大家的專業

傳聲筒人人能當，所以沒有人會重視傳聲筒。

當然這不是說傳聲筒完全沒有意義，當 A 不想跟 B 直接聯繫時，就可以透過傳聲筒來轉達消息；又或者有些主管不想親自安排工作，就會列出清單讓傳聲筒來指派任務。

不過比起 PM，筆者覺得上面的工作內容更像是助理在做的。

想讓自己從「傳聲筒」進化為溝通的「橋樑」，關鍵點在於你了解大家的「專業」；每個行業都有自己的專業術語、不同的部門對同一個名詞也會有不同的解釋；如果想協調各部門的資源，PM 就需要像個翻譯員，把資訊轉換成大家都能迅速理解與吸收的語言。

資訊落差、認知不同是許多衝突的起點，如果能讓彼此都了解對方想表達的意涵，合作會更為順暢。

對專案有更高的掌握度

擁有專業後，就能理解每個「訊息、命令」背後的意義，這對專案是非常有幫助的，比如：

1. 能分辨對方提出的需求是否合理
2. 收到 Bug 時，有辦法初步判斷問題點與負責人
3. 遇到緊急狀況時，知道哪位 Key man 能處理
4. 對任務估時更有概念
5. 溝通較不容易被唬爛

如果擔任 PM 時能做到以上事項，會發現專案越跑越順，原本跟你作對的人，也會認同你的工作能力。

結語

PM 這個職位並不會熟能生巧，因為筆者看過有些人，一當傳聲筒就是好幾年。

但我相信絕大多數人選擇 PM 這個職位，並不是為了當傳聲筒；而是想在公司與大家齊心協力，一起做出讓眾人感到驕傲的產品。

筆者認為對 PM 來說，進入新領域並不算突破舒適圈，有能力在新領域彙整資源，使部門效益最大化才稱得上突破舒適圈。

我想上面這個情境，應該在許多公司不斷上演；規格變更的原因很多，比如：

1. 客戶突然想要增加／修改／刪除某個功能，而 PM 無力阻擋、談判。
2. 規格打從一開始就有問題，但開發到一半才發現。
3. 規格本身很模糊，每個人對規格的見解都不一樣，導致做出來的成品不符預期。

問題千千萬萬，但總歸都跟「人」有關係。

在文章開始前，筆者先跟大家取得一個共識：「PM 不是萬能的存在，客戶也沒那麼好溝通，規格一次到位的可能性趨近於零。」

在認知到規格變更是必須要面對的狀況後，我們接著來討論：「如何減少非必要的規格變更，盡可能降低自己的 Loading。」

準備相關證據

因為規格變更導致工程師加班的狀況並不罕見，但有些工程師的抱怨，會被不明事理的主管認為是能力不足。

為了避免上述狀況發生，我們需要準備「具體可量化」的證據，筆者建議從幾個面向來準備：

1. 記錄每次規格變更：有些規格變更並不是在會議上提出，而是透過私訊、電話或口頭告知，這些紀錄全部都要保存；如果團隊有使用專案管理系統，就能更好的記錄這些變更是由誰提出的（別忘記 tag 提出的人）。
2. 紀錄每次規格變更所增加的工時：絕大多數的規格變更，都需要花更多的時間來處理，這些時數都要記錄下來。
3. 哪些規格變更是可以避免的： 有些規格變更，是因為一開始根本沒想清楚，只是單純把客戶的需求寫上規格，這類問題有機會透過內部溝通協調來改善。

與主管溝通

建議一開始先跟 PM 溝通，如果溝通多次無果（請留存證據）再去找主管。

與主管溝通時記得拿出先前準備的「證據」，並強調以下幾點：

1. 頻繁的更動規格，會影響到專案穩定性（ex：測試程式都需要改寫）。
2. 建議先與客戶在規格上取得共識後，再進行開發（ex：先用 Wireframe 讓客戶確認流程），避免重工浪費時間。
3. 自己不是不能接受規格變更，但 A、B、C… 這幾項規格變更應該是可以避免的。
4. 現在的 Loading 實在太重（提出因規格變更導致的加班時數），假使規格變更無法避免，是否有補充人力或延長專案交期的可能性。

有些問題應該是主管要自己發現並去解決的，但主管日理萬機，偶有遺漏在所難免；我們能做到的就是透過「證據」把問題攤在陽光下，並說出建議的改善方向。

筆者過去曾寫過一篇文章，分享主管面對問題時會考慮的點。

結語

如果問題是長時間累積下來的，那想在短時間，或透過一套方案解決並不現實。

假使提出證據，並且充分溝通後還是沒有改善的跡象；而你也無法忍受這樣的工作環境，也許是時候考慮自己職涯了。

人，不是只有在痛苦的環境中才能成長；在合適的環境中，成長才會更加快速。

轉職一定要經過謹慎評估，筆者僅是提出個人觀點。