以下幾個職場常見的問題, 不知道大家有沒有既視感 * email 討論事情， 一次一句話這樣來回 （超傻眼） * Line討論完重要事項，沒發email結論出來 * 重要且複雜的事項以爲發了email 問就沒事了, 沒有及時安排會議討論 * 無腦開會， 沒有事先思考議題安排（agenda），一堆人參加但沒有 key person，沒有事先掌握與會者的立場，沒有結論的部分沒壓 checkpoint, follow-ups, owner, and target date 一個好的 PM 要能精準掌握對話的節奏及方向， 溝通不是只有說話，它是你達成目的的一個工具. 只是拉著大部隊開無效會議， 很快團隊跟客戶就會對你失去耐心, 而且專案delay真的剛好而已 除了避免以上錯誤, 我自己開會的時候還會做到以下 * 在場只留必要的人, 不相關的一律先下綫不要浪費團隊的時間 * 議題偏掉直接拉回來, 新議題另外定時間討論 * 遇到需要會議某一方提供細節或確認的部分, 一律壓提供時間然後讓會議往下走, 避免所有人浪費時間等部分人討論 以上分享, 歡迎留言告訴我你遇到的問題哦~

職場

V's studio

【專案現場】關於溝通

今天想要來講一下， 在Agile 管理中， 如果一個 Sprint delay 了，怎麽辦？&nbsp;這是執行agile最大的挑戰，當一個spring的產出有錯誤時，絕對不是純粹的把工作內容塞到下一個sprint就好, 請先做以下三件事：1. 錯誤優先於新需求：建立「品質優先」的原則 當一個 sprint 的產出有錯誤時，第一原則不是討論要不要修，而是「預設必須修，而且要優先處理」。在 Agile 思維中，未修復的錯誤（bug）其實就是未完成的工作（incomplete work），如果放到下一個 sprint，等於持續累積技術債。實務上可以設定規則：只要影響核心功能或使用者價值，必須在下一個 sprint 優先納入，甚至必要時打斷當前 sprint 處理（類似 hotfix 概念）。這樣才能避免 backlog 被「假完成項目」污染。2. 回到源頭：在 Retrospective 找「為什麼會錯」 Agile 的精髓不是避免錯誤，而是快速學習。因此每次 sprint 結束後的 retrospective（回顧會議）非常關鍵。重點不是檢討誰犯錯，而是拆解「錯誤是怎麼產生的」——是需求不清？驗收標準模糊？測試不足？還是跨部門溝通斷層？只有找出系統性原因，才能避免下一個 sprint 重複犯同樣的錯。很多台灣團隊卡住的點就在這裡：有做回顧，但沒有真的改變做事方式。3. 導入「Definition of Done（完成定義）」與品質門檻 如果錯誤一再被帶到下一個 sprint，通常代表團隊對「完成」的定義太寬鬆。Agile 團隊需要明確定義 Definition of Done，例如：必須通過測試、完成 code review、符合驗收標準、甚至包含基本使用者驗證。沒有達到 DoD 的項目，就不應該算完成，也不應該被當作可交付成果。這會強迫團隊在當下把事情做好，而不是把風險延後。長期來看，這比不斷補 bug 更有效率。&nbsp;然而， 以上是預防時程的 delay 繼續擴大， 但已經 delay 的部分要怎麽 mitigate 呢&nbsp;先給一個心態建立=》你不可能「完全不影響時程」，“抗壓” 其實也是我認爲一個 PM 在專案過程中需要學習的， 這是你需要能夠清楚的説明對應方式， 來穩住客戶及團隊的心， 讓影響「可控、可預期、且不擴散」 才是重點。Agile 的強項從來不是準時不變，而是即使發生問題，也不會整個專案一起崩掉。這邊提供三個做法：&nbsp;1. 重排優先順序，而不是單純延後時程 當 sprint 出現錯誤時，關鍵不是問「會不會 delay」，而是問「什麼最重要」。Agile 的核心是價值排序（prioritization），因此你應該和 PO（Product Owner）一起重新檢視 backlog：哪些功能可以延後？哪些錯誤不修會影響使用者？是否有低價值工作可以讓位？ 很多時候，你不需要延長時程，而是「調整交付內容」。這在商業上通常比準時交付一堆低價值功能更合理。&nbsp;2. 預留「容量緩衝（capacity buffer）」而不是滿載排程 很多團隊的 sprint 規劃都是 100% 塞滿，這在理想狀況下看似有效率，但現實是一定會出錯。一旦有 bug 或返工，就直接壓縮到新需求或延誤交付。成熟的 Agile 團隊通常只規劃 70–80% 的實際產能，剩下 20–30% 作為「不確定性緩衝」，專門用來處理突發問題、修 bug 或技術債。這樣當錯誤發生時，你是在「用預留資源吸收波動」，而不是「打亂整個計畫」。&nbsp;3. 切斷連鎖影響：確保每個 sprint 仍可獨立交付價值 如果一個 bug 會拖垮後面三個 sprint，問題通常不是 bug 本身，而是架構或切分方式有問題。Agile 的一個關鍵能力是「降低相依性（dependency）」。做法包括：把功能切成真正可獨立交付的 increments使用 feature toggle 避免未完成內容影響整體將高風險項目提早驗證（shift left）當每個 sprint 都能「獨立成立」，即使某一個 sprint 出問題，也只會影響局部，而不是整條時程線。&nbsp;總結一句話， Agile 不是消除風險，而是把風險「前移、縮小、隔離」。 真正成熟的團隊，不是沒有 delay，而是就算出現問題，也能控制影響範圍，並持續穩定交付價值。&nbsp;歡迎留言問我更多問題哦

【專案現場】Sprint delay 了怎麽辦 （長文）

很多人標榜專案使用 Agile 管理，但其實搞不清楚 Agile 及傳統 Waterfall 兩種模式的差異，以為把需求切小塊、時程縮短就是在做 Agile； 然而每一塊需求間沒有真正獨立，反而在後續的 sprint 中彼此牽制，導致工作不斷堆疊，未竟事項越滾越大。這種表面「看起來很敏捷」的做法，是許多團隊導入 Agile 失敗的關鍵原因。重點不在於工具或形式，不是導入一堆 agile 工具，每天站會就是敏捷，浪費團隊時間不如讓大家去做事， 真正重點在於理解 Agile 的核心精神 =》對變化回應力與交付節奏首先釐清 Agile 與 Waterfall 的本質差異。第一，流程結構不同：Waterfall 採取線性、階段式流程，每個階段完成後才能進入下一步；Agile 則是以短週期迭代（sprint）持續交付成果 。 第二，對變化的態度不同：Waterfall 在專案初期就定義完整需求，後續變更成本高且困難；Agile 則允許甚至鼓勵在過程中調整方向，持續根據回饋修正 （坦白説， 這在台灣的很多甲方是不可能接受的） 那真正的 Agile 應該怎麼做？第一個重點是「小而可驗證的交付内容」，不是單純把需求切小，而是每個項目都具備可獨立展示及驗證的成果，能在每個 sprint 結束時產出可用的產品增量 (incremental，想像堆積木，每個 sprint 堆出一個新樓層)。 第二個重點是「持續回饋與調整」，透過短週期迭代、每日站會與回顧會議，不斷檢視方向與優先順序，讓專案隨著實際情況演進，而不是死守原計畫 。 第三個重點是「高度合作與共同承擔責任」，Agile 團隊強調自組織與高頻溝通，以及時回應每天站會決議的調整方向 。方法大家應該聼很多了， 明天再來講一下那真的凸槌的時候怎麽辦吧~

Agile 不是小型的 waterfall

Financially Independent, Retire Early 聽起來很夢幻嗎？但是有沒有想過 當朋友都在上班，你想要如何安排每一天的空白時間？ 當你交出了名片，接下來你想怎麼認定自己的身分與價值？ 當生活安靜了下來，等同於生命的停滯嗎，還是一個令人興奮的新階段開始？ 比較不重要，但也會面臨的是，你如何處理長輩的各種「善意提醒」，「喔還年輕啊，趁年輕多賺啊」，「我聽xx說，退休應該要ooxx 萬才夠」，這種時候要攤開你的財務報表跟他解釋讓他閉嘴嗎？又或者你會受他傳達的恐懼跟焦慮影響呢？過去一整年，我學習很多 首先，我終於理解到每一個經歷都是更理解自己的過程，理解自己是一生的課題，因此沒有多走的路。然後，不要期望別人來理解你，因為他們沒有經歷你的生命。嗯聽起來蠻像廢話的，但我從去年的許多轉折，當我在與身邊人分享時，他們所問出來的問題，深深理解到他們根本不知道我做這個決策的重點。合理，每一個人在聆聽時都只是套自己的經驗值，所以一個不安全感或缺乏的人，很難理解你幹嘛有錢不賺，大概是這個概念第三，我學會放鬆與活著都是一種價值。有目標很好，但不要讓你的目標，建立於恐懼或向別人證明自己的基礎上。我很幸運是一個有選擇的人，但我想任何的生命狀態裡，都有需要學習的課題，所以很多事情我也在找答案你呢，你喜歡你的工作嗎，還是你也 FIRE 了呢，歡迎留言告訴我～

FIRE (提早退休）

以前在Locol公司的時候管過一個專案，也是後來進外商的關鍵。案子在測試階段需要向客戶拿測試資料，我們對的通常是IT部門，測資通常來自user 單位，在很多甲方IT相對弱勢，所以會有一種狀況，就是他無法向他的上游單位要到乾淨的測試資料，他轉頭過來為難你測很慢怎麼解決，就是要幫他想辦法囉 有時候必須幫客戶想，讓他怎麼對上，或對其他部門好溝通，因為他順你才會順，他爛你也不會好過 所以我們連帶幫他整理了資料有什麼問題，讓他去溝通這是我在那個案子學到的第一課不過那個案子最終fail 了，這時候我學到了第二課因為甲方通常不會把案子委給資本額太小的公司，所以雖然90%的事情是由我們做，在這案我們仍然有一個上包，是個外商 案子 fail 後我們開始跟上包談判，主張還有哪些工項沒有收費，他們主張我們應該退什麼費用 一番廝殺後，以為這個案子只能開庭協商了，結果老闆告訴我沒有喔，業務們打了幾場球之後結束了 更有趣的是，後來原公司有財務狀況我離開了，而當時去拍桌談判的上包問我要不要過去工作，原因是對專案過程的表現肯定所以第二課是什麼，就是有關係，事情就好解決。如果沒關系的話，就先好好提升實力🙂

客戶關係重要嗎

某次又是中途被派進一個專案，發現這群人已駐點在客戶端一年多，客戶驗證（表示可收錢）的產出少的可憐。這天年輕工程師弟弟接了一通客戶電話，細心回答客戶的問題，技術討論了很久，這時候身為PM的你覺得很正常嗎？我覺得很毛第3分鐘我要他把電話放下，問他現在討論的內容有在文件裡嗎（經雙方定義的範圍文件），確認沒有後要他結束對話，回覆客戶這不在本階段範圍內5分鐘後客戶又打來，弟弟又細心的技術討論起來，這次我直接把電話接過來，告訴客戶我們需要專心先完成這階段的範圍，不會再繼續討論這一題， 電話掛掉我開始教育團隊從這個故事想帶出幾個點 1. 範圍沒有框，做到死都做不完。這個團隊一年多來並不是沒有加班，相反地，他們加到沒日沒夜，但他們少了守住範疇的人 2. 請花時間教育你的團隊3. 也花時間教育你的客戶，立場要堅定 （很多時候甲方也有時程壓力，利用這一點） 4. 好但相信我，客戶如果沒有嘗試突破你的範疇，他就不叫客戶了。 真的守不住了，就切吧=》合約內容以外的，不做不會死的（80/20法則，影響多數的只佔20%關鍵）排後面做，欸但是要收費喔 5. 最後, 如果不幸的，很菜的你就是被凹免費做了，也不要難過，請記得這就是你談判的籌碼，要適時地拿出來運用

【專案現場】範疇怎麽守？

直接來聊驗收 把案子結掉、發票開出去，幾乎是一個PM的最大價值，但也很困難。我的專案生涯很常被派到做到一半的爛案裡，負責把案子收完擧之前一個日本專案爲例，專案執行一年，我最後一個月進案協助 日本人用腔調很重的英文要求日會，問的問題不合理又瑣碎，其中包含很多他詢問 AI 這些功能文件該包含什麼，該怎麽測，然後刁難我們都沒有的情節。上線一個月後我還是成功開了發票。過程有幾個點可以一起參考：1. 合理性：該堅持的時候，我會逐漸加強談判力道。區分清楚什麼是協助、什麼是合約範疇内應該交付 2. 切範圍：這個技巧這次沒有用到。但當我真的做不完時，我會判斷原因, 如果原因中包含客戶因素(通常會有..)，我會去談判範圍切分，能做的先上，剩下的下一階段，確保專案金流健康 3. 部分驗收：缺漏不多時, 我會視狀況要求先簽部分驗收, 在驗收單上註明什麼時候補什麼內容給他。當然這部分是否扣幾 % 款項後付，可自行拿捏。 4. 與客戶及團隊的關係：這很大程度上支撐以上策略是否奏效。好的 PM 在專案過程中會建立客戶與團隊的信任，客戶信任你才好談判，團隊信任你才有東西可以交付以上, 希望有幫到你哦~

【專案現場】驗收怎麽談？

在專案報價中，PM (這裏指專案經理) 價格常被粗略的以全案價格10%預估，是客戶最常砍價的角色，也是公司最常隨意找人填補的角色然而，一個好的 PM 不只「讓事情做完」，還確保在對的時間及成本内， 並能複製成功。這樣的複製將確保企業營運穩固反之，隨便塞個 PM 會怎樣呢？• 範籌發散重工整個專案團隊都應該有範疇概念，因為現場會議上的逼迫，一通討論電話，團隊都可能不小心答應新需求。好的 PM 會在這一點防守， 並利用範疇作爲談判籌碼• 時程 delay 一直延, 加班成常態好的 PM 其實不會讓團隊常態加班，而是建立進度回報機制，排序需求，識別風險並預留緩衝• 溝通凌亂資訊分散，會議一堆無結論問題的分類歸納，定期檢視及追蹤，排除凌散的問答，都視 PM 功力; 什麼時候用 Line，發 email 或開會，預期結論跟效益，都要教育團隊並規劃• 驗收不了驗收最考驗一個 PM 的能力，客戶都愛許願的，卻在需要簽字驗收時害怕責任而拖拖拉拉，那到底應該怎麽談呢其實專案管理能説的太多, 這個系列的文章想分享我踩過的雷，體會到的核心概念，也許能幫助你更好地管理你的專案