Copyright © 2025 - 吉莉數位 | Lucky Nomads
【Google PM 證照 #6】Capstone: Applying Project Management in the Real World：整合規劃 × 執行 × 敏捷，打造可複製的網站改版工作流
Hi！我是吉莉。
如果你現在正在：
- 準備一次「正式的網站改版」，卻很難抓出合理的時程與預算
- 想把追蹤配置、內容架構一起整理，但覺得風險很多、變動很大
- 需要跟老闆、合作夥伴或供應商協調時間與範圍，卻總覺得溝通不上力
- 每次專案結束都說要回顧，但實際上只是一句「下次再更好」
心裡是不是也常冒出那句話：
「嗯…這樣真的安全嗎？」
— 安全的不只是上線日，而是這整個專案的方法到底站不站得住腳。
過去這系列文章，我多半用「學習筆記」的角度記錄課程。
現在，我把角色調整為：
「網站 × 專案整合顧問」＋「實際使用者」
來重新拆解 Google PM 最後一門課 Capstone: Applying Project Management in the Real World，把它濃縮成一套可複製的網站改版工作流底層邏輯。
本文會幫你解決的四件事
這篇文章，我會用實務視角幫你整理四個關鍵：
- 用三點估算法設計情境時程
不再只丟一個日期，而是建立「樂觀／最可能／悲觀」的完整時間邏輯。 - 把「說不出口的拒絕」變成有根據的協商
用談判框架與同理心，讓時間與範圍討論更理性，而不是情緒拉扯。 - 把回顧會議變成真正有輸出的改善工具
避免流於「檢討會」，而是累積出一套可複製、可調整的工作節奏。 - 讓 AI 成為專案助手，而不是多一個待辦
用 TCREI Prompt 架構把 AI 放進你的工作流：估算、溝通、紀錄與回顧。
一、從「一次算準」到「情境估算」：三點估算法如何保護你的網站改版時程
在 Capstone 裡，三點估算法（Three-Point Estimating）是非常重要的一塊。
它不是要你變成數學專家，而是教你在不確定環境裡，設計出「有彈性」又「有根據」的時程。
課程裡提到兩種估算方式：
- 📐 三角分佈 Triangular
- 🧮 Beta 分佈 PERT
但放回網站改版情境，其實可以想成：
- 樂觀估算（o）：如果一切順利，這個階段最短多久？
- 最可能估算（m）：以過去經驗或合理推估，大多數情況會落在哪裡？
- 悲觀估算（p）：若出現常見的風險（決策延遲、素材晚交、技術問題），最壞會拖到什麼程度？
三角分佈 vs PERT：什麼時候用哪一種？
| 估算重點 | Triangular 三角分佈 | PERT Beta 分佈 |
|---|---|---|
| 適合的專案階段 | 網站改版剛起步，資訊還不完整，需要先抓一個「大致可行」的時程。 | 已經有較完整需求、線框或版型方向，需要更精準地規劃各階段 Milestone。 |
| 對「最可能估算」的權重 | 三個值平均看待，適合不確定性較高的情境。 | 對最可能估算（m）給予較高權重，適合已有歷史經驗或參考專案。 |
| 在網站專案中的應用 | 先估整體專案期程：例如「從需求確認到上線，大約需要多久」。 | 拆細到階段：設計交付、前端切版、追蹤配置、上線前測試等。 |
| 對利害關係人的說明方式 | 提供一個「合理區間」，說明還會因需求變動調整。 | 搭配歷史數據或類似專案，說明為何這個時程是可被信任的。 |
| 風險管理的幫助 | 讓大家先接受「不可能一次估準」，而是共同管理不確定。 | 幫助你設計緩衝時間與檢查點，避免多個延誤疊加成為系統性問題。 |
實務上，我會先用 Triangular 幫自己抓專案大方向，再在細部排程時，用 PERT 讓每一段時間更貼近「實際可能發生的狀況」。
二、協商不是討價還價：用同理心談時間與範圍
Capstone 裡對「時間估算的協商（Negotiating Estimates）」著墨很多。
重點不是比誰更會堅持，而是：如何在有限資源下，找到彼此能接受的方案。
可以想像這樣幾個情境：
- 主管希望「下個月就要看到新官網」，但設計與內容都還在變動。
- 團隊覺得已經超出原本約定的工作量，但又說不清楚哪裡「更多了」。
- 每次有人說「就先做一版看看」，卻沒有人真的調整時程與預算。
在這裡，課程提醒幾個關鍵原則：
- 🎯 聚焦在目標與限制，而不是誰對誰錯
- 🧩 把需求拆小，討論「先做哪一塊」
- 🪜 提供選項，而不是只說「可以／不可以」
同時，協商不會脫離「人」。
課程特別強調同理心，強調在談估算時，要看見對方背後的壓力與期待
當我在整理自己的專案方法論時，我會把協商拆成三個步驟：
- 先用三點估算把「現實邊界」算出來
- 再用對方的視角，盤點他真正擔心的是什麼（時間？預算？曝光？內部壓力？）
- 最後用「選項」而不是「答案」討論（例如：先上線精簡版、再滾動優化）
這樣一來，你不是在「拒絕工作」，而是在共同守護一個可交付的結果。
三、讓回顧會議有輸出：Retrospective 的設計關鍵
Capstone 對回顧會議（Retrospectives）有很清楚的提醒：
好的回顧會議應該是 正向、無責備、聚焦改善流程。
我在整理自己專案節奏時，會把回顧拆成兩個層次：
- 專案內部回顧：每一個 Milestone 或 Sprint 結束時，檢查：
- 這一輪做得好的地方是什麼？（保留）
- 哪些地方卡住？是資訊不足？決策太晚？或工具不合適？
- 下次具體要改什麼？（流程、溝通頻率、文件模板…）
- 方法論回顧：
- 這個網站改版專案，有沒有逼你調整整套流程？
- 哪些做法應該被寫進「標準工作流」？
- 哪些踩雷應該變成下個專案一開始就會提醒的風險？
如果每一次回顧會議都只停在「下次再注意」，那工作流就不會真正進化。
我更傾向讓每一次專案都變成：更新方法論的一次實驗。
四、用同儕回饋校正盲區：Peer Review 的啟發
Capstone 有一段是做專案作業，並且參與 Peer Review（互評）。
我們需要：
- 把自己的專案計畫書交出去
- 用評分規則（Rubric）去看其他人的成果
- 也接受別人對自己作品的評論
這對我來說，有兩個很實用的提醒：
- 先寫出可以被評估的東西
很多專案卡住，是因為大家都還在「腦裡想」，沒有變成具體文件。
一旦寫成 Project Charter、Timeline 或 Risk Log，就能拿來討論與調整。 - 用結構化的方式給回饋
Rubric 的好處，是讓回饋不是「我覺得」，而是「有沒有對齊這些指標」。
未來把這套思維放進網站改版時，就能：- 幫自己設計一份「網站改版檢查表」
- 讓團隊或合作對象知道：哪些是必要條件、哪些是加分選項
即使現在還沒有大量實際專案案例，先把「評估架構」寫出來，本身就是一種專業累積。
五、AI 不是取代專案經理，而是讓流程更穩定
Capstone 的最後一部分，把 AI 放進專案管理的情境。
其中一個很實用的框架，是 TCREI Prompt 架構：
Task（任務）
Context（情境）
References（參考資料）
Evaluate（檢查輸出）
Iterate（反覆調整）
在網站改版或數位專案裡，AI 可以幫忙的地方其實很多：
- 草擬 Project Charter 初稿，讓你不用從空白頁開始
- 協助整理需求訪談紀錄、會議重點
- 協助檢查待辦清單是否覆蓋到所有關鍵步驟
- 提供風險清單建議，提醒你容易忽略的環節
- 根據情境，整理出「可能的 Milestone 與估算維度」
- 幫你產出第一版的 Risk Log，再由你判斷哪些適用
關鍵不是把決定交給 AI，而是：讓 AI 把重複、瑣碎、整理型工作接走，讓你專心做判斷與協調。
六、如何把 Capstone 轉成你自己的網站改版工作流？
綜合前面幾個重點，我會這樣把 Capstone 轉成一套「可複製」的網站改版方法基礎：
- 建立估算模型
- 對整體專案用 Triangular 抓出大區間
- 對每個階段用 PERT 精細估算，並標註對應的風險假設
- 設計協商節點
- 不是等到 delay 才溝通，而是事先設計「回顧與調整的時間點」
- 每次調整範圍，都對應到一次「重估」與「重新記錄」
- 讓回顧會議有固定格式
- 固定三個問題：Keep / Problem / Try
- 會議結束一定留下：下次具體要改什麼？誰負責？什麼時候檢查？
- 把 Peer Review 變成內部或外部校正機制
- 找可信任的同儕，用簡化版 Rubric 看你的專案規劃是否合理
- 先從文件開始，而不是等專案卡住才求救
- 把 AI 鑲嵌進流程，而不是當作靈感工具而已
- 固定幾個場景：估算初稿、會議紀錄整理、風險清單草稿、回顧重點彙整
- 用 TCREI 管理 Prompt，讓輸出可重複、可調整
未來當我有更多實際專案案例時，這些元素會拆成一篇篇延伸文章，
對應不同情境（例如：品牌官網改版、教育型內容網站、產品導向網站等），
但核心方法都會回到：估算 × 協商 × 回顧 × 同儕校正 × AI 助攻。
常見問題 FAQ｜Google PM Capstone 與網站改版專案管理
Q1｜如果我不是專案經理，只是負責網站改版，也需要學三點估算法嗎？
需要，尤其是當你負責協調時程與需求時。三點估算法不是為了做學術研究，而是幫你在不確定的情況下，說出「樂觀、最可能、悲觀」三種情境，讓利害關係人知道風險在哪裡，避免大家只記得最樂觀的日期。
Q2｜網站改版規模不大，也有必要做這麼多估算與回顧嗎？
有必要，但可以用輕量的方式做。小型網站專案更容易被忽略流程，變成「邊做邊改」。即使用簡化版的三點估算與短版 Retrospective，也能幫助你累積方法論，避免每次都從零開始摸索。
Q3｜只有兩三個人的小團隊，也要開 Retrospective 嗎？會不會太正式？
可以不用開「很正式」的會議，但回顧本身不能省略。你可以用 30 分鐘完成一輪：這次做對什麼、哪裡卡住、下次要改什麼。重點是把結論寫下來，讓下一個專案可以沿用，而不是每次只靠印象。
Q4｜AI 真的能幫忙專案管理嗎？會不會讓流程變得太機械？
AI 最適合處理「整理與草擬」的工作，例如：整理會議紀錄、產出第一版時程草案、彙整風險清單。真正的判斷與協商仍然需要人來做。善用像 TCREI 這樣的 Prompt 架構，可以讓 AI 穩定地幫你省下重複性工作，而不是取代你的專業。
Q5｜要先上完整 Google PM 課程，才能把 Capstone 的內容用在網站改版嗎？
不一定。本篇文章已經把 Capstone 中與「網站改版 × 專案整合」高度相關的部分先提煉出來，你可以先從三點估算、協商框架、回顧設計與 AI 應用這幾個元素開始實作。若之後想進一步系統化學習，再回頭修完整系列課程，會更有脈絡。
吉莉結語｜把「一次專案」變成可複製工作流
對我來說，Google PM 的 Capstone 不是單純的期末作業，而是一個整理方法論的節點。
如果把這門課對應到「網站改版 × 專案整合」，可以濃縮成幾句話：
- 不要追求一次估準，而是設計情境與緩衝
- 不要只說可以或不行，而是帶著同理心一起調整範圍與節奏
- 不要讓回顧變成形式，而是每次都留下具體要改什麼
- 不要把每個專案當作孤立事件，而是一次次更新自己的方法論
- 不要期待 AI 幫你做決策，而是讓它替你整理資訊、穩定流程
當你下次準備一個網站改版、內容重構或追蹤配置專案時，
可以先從這篇文章裡挑一兩個工具開始用：
例如從三點估算＋一次簡短 Retrospective 起步，
再慢慢加入協商框架、Peer Review 與 AI 工具，
你的工作流會愈來愈穩定，也愈來愈「可複製」。
Extended reading：
- Google PM license "Agile Project Management" Study Notes: Agile taught me not only project Management, but brave decision-making in life
- ChatGPT + Canva：接案必學！設計高質感品牌視覺的技巧
Lovely reader，
Do you have any other ideas?
You are welcome to leave a message to discuss with Lucky!
