前陣子與朋友聚會時，我們交流了彼此用 AI 開發專案的心得。

然後發現一個值得討論的議題：「同樣在用 AI，有些人花很少額度就完成一堆任務；但有些人額度燒光，卻連一個問題都沒有解決。」

這種落差，大到讓人懷疑，我們真的在用同一個工具嗎？

為了釐清問題，我們乾脆直接打開電腦，實際 Demo 彼此的操作方式。

看完之後，發現問題其實不在 AI，而在「使用方式」。

我把幾個最關鍵的操作整理給你 👇

1️⃣ 遇到問題就丟給 AI，但每次都跑很久、還不一定解得掉

→ 因為沒有指定範圍，所以 AI 要掃描整個專案，過程不但浪費時間、消耗額度，還很容易改錯方向，衍生更多問題

2️⃣ 請 AI 新增功能，但沒有考量到既有架構

→ 在沒有足夠上下文與規格資訊的狀況下，AI 往往選擇「從頭做一份」，這種做法除了浪費額度外，還會讓專案越來越難維護

3️⃣ 每次調整功能，都要重新提醒規則與習慣

→ 在新的對話視窗中，AI 未必會記住你過去的使用習慣、判斷邏輯，所以要花很多時間在「資訊對齊」上面，甚至要自己手動調整細節

老實說，這些問題真的很常見。

因為很多人即使用了 AI 程式碼編輯器，還是把它當成「問答工具」。

但我認為 AI 的價值，是在幫你建立一套「可重複使用的工作流」。

而現在的 AI Agent 其實已經有對應的解決方案了

✔ 指定資料夾、文件，限定 AI 讀取範圍

💡 可以用「@」的方式，給予 AI 參考資料；當目的、方向明確後，AI 的效率與穩定性會大幅上升。

✔ 建立需求規格，讓 AI 迭代功能時有文件依據

💡 無論新舊專案，都可以透過 OpenSpec 來輔助建立專案的需求規格；這不但能解決團隊專案缺乏文件的痛點，還能讓 AI 與人類在未來迭代功能時更有依據，減少重工的問題。

✔ 設計 Rules / Commands / Agent Skills

💡 不管個人還是團隊，都一定會有自己的「使用習慣、判斷邏輯」，我們可以把通用規則寫在 Rules（不要說廢話、專注解決問題），特定情境的工作流放在 Commands（觸發多個 Skills 的固定流程），而希望 AI 使用的技能記錄到 Agent Skills（前端設計能力、撰寫 Commit、PR）。

不要讓 AI 的「快」，變成未來的「債」。

我自己現在更在意的，其實不是 AI 寫多快，而是：

1. 專案的規格是否足夠清晰，可以持續迭代
2. 新增修改功能時，有沒有影響到既有功能
3. 這次做出的成果，能否整理成 Agent Skill，讓下次直接使用

這些，才是真正會拉開差距的地方。

我在 4/21（二）有一場線上說明會，將透過實際 Demo，分享如何從「用 AI 寫程式」，轉變成「用 AI 建立開發流程」，邀請你免費參加！

如果你希望 AI 不只幫忙寫幾段程式碼，而是真正融入需求拆解、規格整理、開發協作、測試驗證與任務交付，或是有問題想與我線上討論。

那千萬別錯過這場說明會！

👉 立即報名: https://tibame.tw/Rsc3G

結果昨晚打開線上簡報準備練習時，螢幕上顯示兩個大大的字：「喔！不。」

一開始以為是網路問題，所以我試著重新整理頁面。

但畫面依舊頑強地顯示：「喔！不。」

看到這個結果後我狂冒冷汗，因為這幾乎代表簡報已經沒救了…

然後我嘗試了各種手段祈禱能恢復：

• 重新命名檔案
• 把檔案複製一份後開啟
• 用無痕頁面重新登入
• 邀請其他人共筆編輯
• 聯繫客服

但奇蹟沒有發生，上面的方案全部行不通，客服到今天都還沒回我訊息。

不要讓自己沈浸在負面情緒

在簡報故障當下，我心情非常糟。

因為過去已經花了 2 週時間備課，有種努力完全失去意義的感覺。

但當我想到隔天有數百名學員等著上課，我瞬間就清醒了。

抬頭看了一下時間，晚上 9 點。

而課程安排在明天下午 2 點，我告訴自己：「一切還來得及！」

還有什麼方法可以挽救？

冷靜下來後，我並沒有馬上重做簡報。

而是思考還有沒有其他開啟簡報的方式，並給自己一個時限：「半小時。」

如果時間內找不到解決方案，我就認命重做。

在嘗試的過程中，突然想到早上做完課前測試後，有傳一個「僅供檢視」的簡報連結給主辦單位。

我不抱希望的點開連結，結果發現居然可以順利檢視！！！

最終只花了半個多小時做資料移轉，並在今天順利完成企業內訓。

簡報故障後我學到的 5 件事

這次意外給了我一個警鐘：「不要預設線上服務都能順利運行，你永遠要有一個以上的備案。」

1. 任何線上服務都有風險，僅管線上簡報很好用，但出問題時，你根本求助無門。
2. 人遇到意外時難免沮喪，但別忘記只有做出行動才能解決問題。
3. 若要嘗試救援，請訂下「時限」，因為不是每次運氣都這麼好。
4. 如果你還是要使用線上簡報軟體，請記得下載可以離線瀏覽的版本（PDF、PPT）。
5. 建議將圖片素材備份到自己電腦，否則雲端出問題時你很難救回來。

現在回想起來，要是我沒有在前一晚打開簡報練習，今天應該會在企業內訓的現場爆掉。

儘管我們沒辦法預知未來，但做好事前準備就能將傷害降到最小。

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

如何讓車子降速

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

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

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

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

如何保護路上的行人

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如果遇到沒有 Sense 的客戶

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

靠著 AI 紅利，筆者出版「ChatGPT 與 AI 繪圖效率大師」的書籍後，收到各大企業與平台的邀約；有些講得很順利，而有些則遇到各種意想不到的問題，在這篇文章我將會把自己踩過的坑一一向大家分享。

現場授課要注意的事項

有些企業是在平面的演講廳授課，這樣會遇到幾個問題：

1. 字幕不清楚：只有前幾排才能看清楚螢幕上的字。
2. 畫面被人擋到：後面的觀眾除了看不清楚字外，還可能被前排的觀眾擋住。
3. 缺乏互動：現場觀眾看不到講者時，就容易進入物我兩忘的休眠狀況。
4. 聲音品質不穩定：有時用麥克風會有回音、雜訊、沒電的狀況。

可以如何改善？

1. 向主辦單位取得演講的場地圖：知道是平面還是階梯式。
2. 了解預計會有幾排座位：如果場地太深就需要調整簡報字體大小，才能讓後排也看得清楚畫面，如果有現場演示的部分，也一併考慮進去。
3. 詢問是否有高講台與高腳椅：平面的場地容易有觀眾看不到講者的情況，如果觀眾看不到講者就可能缺乏互動，此時我們可以用高講台與高腳椅讓講師被更多的人看見。
4. 提前到場地試音：因為有些麥克風有 echo 的設定，或靠近某個位置會產生雜音；建議除了無線麥克風外，再準備一個有線麥克風以處理突發狀況。

遠端直播課程要注意的事項

如果你是在家遠端直播課程，那可能會遇到以下問題：

1. 網路不穩定：使用手機熱點分享可能會遇到訊號不穩的狀況。
2. 背景音干擾：像是家人、鄰居發出的聲響，附近施工、消防演習、救護車經過的聲音。
3. 不得不處理的狀況：突然被按電鈴、家裡的室內電話響起。

可以如何改善？

1. 盡可能使用網路線或是 Wifi：不過如果會與多個人共用網路，那也要注意頻寬是否穩定；如果不得已要用手機熱點，請準備第二台手機且搭配其他電信作為備用。
2. 向家人說明自己的講課時間：請他們在講課時間盡可能降低音量，並且不要突然與自己講話。
3. 使用麥克風收音：如果背景音問題無法解決，可以考慮用麥克風收音已取得較好的品質。
4. 把市內電話線拿起來：直接從根源斷絕電話響起的可能性。
5. 先處理完再講課：萬一遇到按電鈴、電話鈴響這類的狀況，建議先跟觀眾說聲抱歉，並快速解決狀況後再回來講課，否則干擾會持續發生。

現場直播課程要注意的事項

所謂的現場直播課程，就是講師到主辦方的攝影棚做直播課程，通常這樣是為了保證課程進行時的網路品質，但也可能遇到一些突發狀況：

1. 現場網路問題：可能網路線沒有網路、Wifi 訊號不穩定、網路速度不夠。
2. 設備不熟悉：有些單位會要求講師使用主辦方的電腦，但如果作業系統不同、快捷鍵與外掛沒有設定；那這些使用習慣上的差異，就可能導致實際演練時發生意外。
3. 分享的畫面出問題：可能遇到色偏、解析度不夠、畫面變形、螢幕斷電的問題。
4. 遇到技術問題需要暫停：有時課程講到一半，會需要臨時進入中場休息處理技術問題。
5. 需要操作多台電腦：簡報用電腦與現場操作的電腦是分開的，在講課過程需要提示導播現在要切到哪個畫面。

可以如何改善？

1. 提前到現場測試網路：無論網路線或 Wifi，在沒什麼人用的時候都很順暢，但如果現場有一堆人在使用就會把頻寬吃掉，一定要先測試極限值的狀態下是否可以穩定播放。
2. 盡可能使用自己的設備：自己熟悉的設備，就算出事也比較知道該怎麼處理，如果是不熟悉的設備可能出事就直接升天。
3. 提前到現場測試設備：如果自己帶電腦，一定要提前確認畫面符合預期。
4. 準備臨時中斷的話：像是「目前直播遇到了一點技術問題，為了給大家更好的體驗，課程到先進入中場休息 10 分鐘，如果對剛才的課程內容有任何問題可以先打在留言區。」
5. 一定要提前體驗多個電腦的操作方式：為了讓直播課程的畫質更好，有時會需要講者操控多台電腦，一台用簡報筆操控、另一台現場操作；這對沒有相關操作經驗的講者來說難度較高，因為你講課的節奏需要重新調適，比如簡報的下一頁就需要在兩個地方都按，且講簡報時無法跳頁，如果沒意識到這些情境就會導致你講課的品質下降。

結論：每場演講都是學習

無論現場還是直播教學，對觀眾來說都是「一次」的體驗；如果你失誤了，那他們就會記住這個場景，進而對你的專業產生懷疑。

可能是筆者運氣太好，所經歷的演講或多或少都遇到了可以改進與注意的地方。

你靠專業獲得演講的機會，但演講本身也是一個專業。

熟悉演講的內容是本份，這樣在遇到突發狀況時才可能有較為理想的發揮（ex：縮短演講、臨時暫停、跳轉到其他頁面）。

如果讀者剛好有遇到我失誤的場景，筆者在這邊致上萬分的歉意；我會直面錯誤並尋求改進的方式，相信每場歷練都是成長的契機，也期待自己在未來能分享更好的內容給大家！

如果想將 AI 導入自己的職場與生活，歡迎報名筆者與商業週刊合作的實體教學課程：「AI高效工作術！ChatGPT職場全方位應用實作速成班」

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

大綱
ㄧ、客戶、專案經理、開發人員，3 者沒有共同語言
二、Scrum 淪為形式
三、專案到最後時刻才發現一堆 Bug
四、Tech Lead 沒辦法發揮應有的作用
五、團隊失去成長動能
六、不是每個成員都按照流程走
七、血淚小結

ㄧ、客戶、專案經理、開發人員，3 者沒有共同語言

為了讓每個角色各司其職，在溝通需求時，都是由專案經理跟客戶溝通，得到結論後再跟開發人員說明。

儘管看起來很合理，但在實務上容易遇到以下問題：

1. 名詞定義：同一個名詞，大家的定義都不一樣；這導致 3 者在溝通上雞同鴨講，彼此以為對方懂了，但根本在說不一樣的東西。
2. 專案經理與開發人員都不具備專案的背景知識：如果碰上大型專案，在開發團隊沒有相關背景知識的狀態下，光是架構的設計就很容易出問題；又因為沒有相關背景，所以根本沒有共同語言。
3. 規格書不明確：開發人員按照規格書來開發，但如果規格書很模糊，工程師在開發時會浪費很多時間在額外的溝通。（最悲慘的狀況是工程師放棄溝通，選擇按照直覺來開發）

上面的問題，想嘗試透過以下方法解決：

1. 專案經理與開發人員以「英文」來溝通欄位：資料庫都是英文欄位，如果規格書上的欄位都以中文表達，就不能怪工程師在開發上直接選擇「感覺」意思最接近的欄位。
2. 由專案經理建立一套「中英文名詞定義對照表」：內部可以用英文律定欄位，但跟客戶溝通時，大多情況還是使用中文；所以需要建立一份對照表，避免彼此的誤解。
3. 需求規格參數明確：對客戶來說好像差不多，但對工程師來說，差一個欄位就好似差了一個宇宙。

二、Scrum 淪為形式

我們期待導入「Agile(敏捷)」開發後，可以提升團隊的生產力、向心力，但實際上會遇到以下問題：

1. 只在意自己要講什麼：跑 Scrum 的原意是希望大家瞭解彼此工作的進度，透過資訊透明讓專案更加順利；但很多時候我們只在意自己今天要講什麼，這種狀況在 Scrum Master 為固定人選時更為明顯。
2. 規格不明確導致需求時常變更：在 Sprint Plan 時，我們會先估點來計算每個人工作需要的時間；但在開發階段若發現規格有問題，專案經理就要再跟客戶溝通，這一來一往與程式調整的時間，將會完全破壞這個 Sprint 預計要完成的項目。
3. 安排額外的任務：如果臨時安排不在這個 Sprint 的任務給工程師，又沒有明確告知任務優先度，當這種狀況頻繁發生時，Scrum 就變成單純的個人報告，工作內容逐漸與 Sprint Plan 脫鉤。

上面的問題，想嘗試透過以下方法解決：

1. 讓每個人輪流當 Scrum Master：在這個位置上，就算不願意，你還是得知道每個人的進度、卡住的問題、要做的事。
2. 指派任務前，充分確認客戶需求：如果在商談時就定下明確的需求規格，那工程師就有開發的依據，發現邏輯問題時也能第一時間提出，不至於自由發揮到一半才發現問題。
3. 盡量不要讓突發狀況影響現在的 Sprint Plan：工程師也是人，臨時安排的工作勢必會影響到現在的專案，如果可以，突發的狀況盡量安排到下個 Sprint。

三、專案到最後時刻才發現一堆 Bug

我們花 20% 的時間完成 80% 的功能，卻在最後 20% 的功能上花了 80% 的時間。

如果問題發生不只一次，那肯定要想辦法解決；通常會有這樣的狀況是因為：

1. 架構規劃不良：專案啟動後，一開始大家都是摸著石頭過河，無法確定自己現在的方向是否正確；往往到後期，才發現當初的規劃有某些後遺症。
2. 前期進度按照時程走很安心：因為前期每個 Check point 都很準時，所以產生接下來也會繼續準時的心理預期。
3. 想要一次交卷：有時我們會想等作品完成到某個程度後再給客戶看，但…有時客戶看過後會發現許多與他們理念不合的設計。
4. 新舊系統功能不吻合：就算功能都是 Copy＆Paste，但程式底層的運作邏輯往往不同，部分欄位可能也存在誤會；你以為執行得很順利，殊不知早已偏離方向。

上面的問題，想嘗試透過以下方法解決：

1. 別管架構，先交出 MVP：我們規劃了太多功能，卻沒有一個 MVP，在一切都不明朗的狀態下，能規劃出好架構根本是靠運氣；與其在前期完成那麼多功能，還不如先交一個勉強能動的 MVP，以此向客戶確認是否符合需求。
2. 在一開始規劃時，就把容錯時程拉長：過往的經驗告訴我，意外通常在最後一刻才發生；因為在後期，我們才有辦法用整體的思維去看專案。（如果團隊有經驗非常豐富的架構師，那有機會規避這些問題，筆者目前還不具備這個實力）
3. 開發階段頻繁更新系統：讓客戶隨時體驗最新的功能，如果與預想不合也可以盡快作出調整；避免工程師要砍一堆程式，做無意義的重工。
4. 如果要改寫舊系統，就需要對方提供可以驗證的資訊：通常舊系統程式的參考價值不高，我們只能從操作流程來推估資料間的關聯性，但這些「都是靠想像」的，如果客戶沒有提供足夠的舊系統操作案例給工程師來驗證，就很可能開發出無法與舊系統銜接的系統。

四、Tech Lead 沒辦法發揮應有的作用

我們期待 Tech Lead 可以照顧到整個團隊的技術，但如果開發時程太趕，在 Tech Lead 也投入大量時間在開發時，會衍生以下問題：

1. Code Review 淪為形式：連自己的任務都快做不完了，Code Review 時頂多看一下 Coding Style，沒辦法從整體的架構去判斷他的演算法、邏輯是否合適。
2. 專案程式碼品質下降：因為 Code Review 不確實，很多功能只是為了解決當下的問題，這種時候很容易創造出一堆耦合性高的程式。
3. 沒辦法顧及所有人的進度：如果專案經理與 Tech Lead 配合不夠默契，那很容易發生 Tech Lead 埋頭開發，沒有從整體的視角來看專案的進度。

上面的問題，想嘗試透過以下方法解決：

1. 分配給 Tech Lead 的開發任務，不要超過他 60% 的工作時間：如果把 Tech Lead 當單純的 Developer 來使用，那團隊程式碼的品質就無法保證；為了避免日後要花更多的時間解決後遺症，建議多給 Tech Lead 一些靈活運用的時間。
2. 專案經理與 Tech Lead 訊息流暢：就算有專案管理系統輔助，但每個任務進度的細節、時程還是專案經理最清楚；如果能在發現進度 Delay 前期就做適當的調整與釐清，也許不會走到時程緊繃這一步。
3. 律定專案管理系統操作方式：開發人員 Commit 的內容也需要附註在 Ticket 上面（盡量白話），這樣更方便專案經理掌握實際進度；若該 Ticket 有相依性（後端完成後交付給前端），那開發人員也要將相關的 API doc 附在上面。

五、團隊失去成長動能

我們期待團隊裡的每個人都能夠隨著專案持續成長，但在管理出現問題時，團隊會慢慢轉變為 80/20 法則的模式，也就是 20% 的人完成了 80% 的任務，下面是筆者個人推估的原因：

1. 到 Deadline 時，總有人能幫忙解決問題：如果團隊成員發現沒做完的東西，在接近 Deadline 時就會有其他人來拯救，那很可能就會養成依賴性，喪失自己解決問題的能力。
2. 獎懲機制不夠透明：如果大家發現拼死拼活的結果跟躺平耍廢一樣，那我們為什麼不躺平？
3. 連坐制度：Deadline 就壓在那裡，你幫了，他無法成長；你不幫，專案就爆掉，自己也跟著倒霉，這種狀況到底要幫還是不幫？

上面的問題，想嘗試透過以下方法解決：

1. 幫忙時只給方向：可以提供一些關鍵字、網頁、參考資料、過去的程式碼，但不要直接解決問題。
2. 如果必須親自解決問題，先確認對方已經發揮所有潛能：儘管我們都希望給方向就能解決問題，但每個人的背景知識不同，如果給方向還是無法解決；在親自解決問題前，要先請對方說出自己過去所做出的研究，確保他已經盡力，任務難度真的超過了他的能力範圍。
3. 不影響健康的壓力：如果發現成員的能力有提升的空間，那或許可以提醒他，適度犧牲下班後與放假的時間持續鑽研是必須的，唯有做足功課，在上班時才能更快地趕上大家的腳步。
4. 律定獎懲機制：我們希望每個人都有想成長的自覺，但如果有必要，賞罰機制還是要存在的。

六、不是每個成員都按照流程走

我們秉持互信的原則來合作，就算有些人沒按照流程走，只要不出包，也可以睜一隻眼閉一隻眼；但如果這些行為產出的結果不符預期，甚至導致團隊損失，那勢必要做出改善。

這邊就以程式碼 Commit＆Push 舉例，原則上我們期待每位開發人員一天至少 Push 一版程式，且裡面 Commit 都有詳細紀錄更動的部分。

會有這個要求是因為專案是「協作」的，如果有人憋了一個禮拜才 Push 一大包，會衍生以下問題：

1. Tech Lead 很難 Code Review：因為內容太多、太雜，釐清功能所需的時間反而更多。
2. 如果架構有問題，改善成本太高：如果在 Code Review 時才發現程式的結構問題，那又需要浪費很多時間改寫。
3. 如果把所有更新的內容塞到一個 Commit 裡面，很難對應功能與程式：因為程式往往散落在多個檔案，如果 Commit 內容太多，就很難知道彼此的對應關係。
4. 萬一發生狀況，接手的人會崩潰：如果做完的功能沒有 Push 上去，接手的人等於要重寫。

上面的問題，想嘗試透過以下方法解決：

1. 向開發人員說明定時 Commit＆Push 的重要性：開發人員可能不知道自己這麼做會影響到其他人，需要講清楚問題嚴重性。
2. 如果任務太複雜，盡量做功能上的切分：有時被分配到的任務涉及面太廣，導致遲遲不敢 Push 上去；面對這種情況，可以依據開發的進度來 Commit＆Push，反正有 Git 這種程式碼版控系統，不會影響到主分支。

七、血淚小結

1. 問題是長期沒改善積累而成的，想解決肯定會遇到不少阻力。
2. 只有被攤在陽光下的問題，才有機會被解決。
3. 許多問題互為因果，如果不解決，問題會像病毒般不斷變種。
4. 每個人都在適應自己的角色，專案經理不知道需求規格怎麼寫才能讓開發人員理解，開發人員不清楚遇到問題時要如何解決，Tech Lead 不確定怎麼帶人才是最合適的。
5. 規則律定出來就要執行，如果沒有執行；那其他乖乖遵守規則的人，也遲早會學壞。

工程師血淚史
▋ 團隊在系統開發上遇到了哪些問題(本篇)
▋ 需求不斷變更，到底哪個環節出錯了
▋ 當 Scrum Master 跟 PM 同時存在，權力與責任該如何區分？
▋ 如果沒有明確的開發流程，團隊將會無所適從
▋ 你知道對專案來說，README.md 有多麼重要嗎？