Recommended
More Related Content
What's hot
What's hot (20)
Similar to 從乙方PM的角度看敏捷
Similar to 從乙方PM的角度看敏捷 (20)
從乙方PM的角度看敏捷
- 1. 臺 北 站 從乙方PM的角度看敏捷 AGILE TOUR TAIPEI, 2018 KC LIU
- 2. • KC是誰? • PMP, CSM, CSPO • 半途而廢的Java工程師 • 18年在應用程式開案專案裏打滾 • 工作經歷：前進國際、台灣IBM、 台灣微軟 • 以軟體應用程式開發為主(Application) • 對敏捷(agile)有興趣，持續在推廣、 實作及試誤 • 目前擔任某醫院HIS專案PM • 70+人團隊，正在進行以Scrum為 基礎的敏捷旅程
- 3. 何謂乙方PM • PM = Project Manager (專案經理, PjM) • Not Product Manager (不是產品經理) • Project： • 有時間限制、有資源限制 • 合約中明確規範了指定/固定交付標的 • 非產品研發 • 乙方PM： • 拿到Project Charter，得到乙方公司授權，受合約規範 • 負責與客戶溝通，帶領團隊執行/交付專案 • 不是業務或銷售(Sales)的角色
- 4. (慘)案例分享 • 新戶役政系統: 2014上線, 上線即出包 • 某人壽SAP導入專案: 2014起案，報載花費 100億，上線一個月狀況頻出 • 台鐵購票系統: 2014發包中華電信, 至今尚 未上線 • 還有很多不會上新聞的案例 如果你是這幾個案子的PM？
- 5. 專案失敗的原因 • 需求無法確定下來 (目標不明) • 開發人員不知道你要什麼 • 你不知道客戶要什麼 • 客戶不知道他的用戶要什麼 • 用戶不知道他老闆要什麼 • 老闆對專案產出有不切實際的期望 • 做不完 (執行不到位) • 資源不足 • 時程不合理 • 技術有缺口 70%+ 溝通問題 災難會隨著專案規模， 呈非線性放大
- 6. 如何讓專案不要失敗 策略 說明 結局 後遺症 1 外包 • 把全部或部分工作轉 包給其他廠商 • 逃得了一時，逃不了 一世，如果下包做壞 了，還是得收回來做 • 太爛的案字根本包不 出去 2 終極SA • 把文件和規格寫得鉅 細靡遺，只用最簡單 的技術 • 客戶會變需求，文件 會改到死 • 客戶不願意簽文件， 或是持續審文件，造 成無法進入開發 • 寫得愈仔細，死得愈 慘 3 只做T&M • 風險低，以量取勝 • 風險低，但利潤更低 • 競爭者眾，殺價競爭 • 駐點工程師武功全廢， 不是逃走就是爛掉 4 風險加成 • 把風險成本分攤至專 案報價 • 價錢沒競爭力，搶不 到案子 • 公司縮編
- 7. 敏捷軟體開發宣言 藉著親自並協助他人進行軟體開發， 我們正致力於發掘更優良的軟體開發方法。 透過這樣的努力，我們已建立以下價值觀: 個人與互動 重於 流程與工具 可用的軟體 重於 詳盡的文件 與客戶合作 重於 合約協商 回應變化 重於 遵循計劃 也就是說，雖然右側項目有其價值， 但我們更重視左側項目。
- 8. 敏捷是PM的救命丹嗎？ • 敏捷宣言 • 敏捷案例 • 每個敏捷成功的案例都讓人很興奮 • 成功案例的環境和你的不同 • 要改變的人事物太多 • 別人的敏捷都成功了，自己遇到的都不是 敏捷思維的啟發：回歸到人與合作 • 甲方 x 乙方 • 開發者 x 終端用戶 • 專案經理 x 專案成員
- 10. 面對敏捷，PM要面對的問題 • 合約怎麼簽？ • 需求如何展開與收斂？(讓需求明確) • 進度如何控管？(讓執行到位) • 如何面對敏捷架構下的客戶關係？ • 我收得到錢嗎？
- 11. 合約怎麼簽？ • 什麼是合約？ • 有時候也包含對應的工作說明書(SOW)，規範了甲乙兩方的權利義務 • 乙方要交付什麼(時間/標的) ？甲方要如何付款(時間/金額/條件) ？ • PM所有的權限都來自合約，合約影響你能做什麼，你不能做什麼 • 敏捷對合約有何影響 • 專案規模如果不大，是否敏捷對專案的影響有限 • 但超過一定規模後，開始有影響，半年/台幣1000萬是一個分界點(依個人經驗) • 超過半年的專案或里程碑，複雜度會陡升(aka: 收不到錢的風險爆增) • 合約的種類 • 固定價金 (Fixed Fee) • 固定容積 (Based on Time & Material)
- 12. 專案金三角 範圍(固定) 時間成本 範圍 時間(固定)成本(固定) 固定價金 固定容積 • 業主的年度預算己經確定 • 承辦人的年度KPI己定 (系統今年要上線) • 外包的目的就是要轉嫁風險
- 13. 敏捷友善的合約 • 敏捷友善合約 = 有限成本 + 有限時間 + 彈性產出/交付 • 方案1: 產能合約 (固定容積) • 依據實際成本計費，由固定人月反推產出專案時程 • 業主預算有限，無法管理、無法確定會拿到什麼 • 標的物不明確，客戶很難跟老闆交待 • 方案2: 變形合約 / 滾動式合約 • 先做N個Sprint，業主再評估是否要往下做 • 做到客戶滿意，剩下的部分退錢(30-70%)，鼓勵客戶訂下優先級 • 但客戶不滿意怎麼辦？國情不同…..
- 14. 敏捷友善的合約 • 敏捷友善合約 = 有限成本 + 有限時間 + 彈性產出/交付 + 密切參與 • 方案3: 掛羊頭賣狗肉 • 走傳統固定價金合約，但把敏捷友善的條件放入合約或SOW裏 • 要求甲方PO角色出線，定期排定優先級 • 強制終端用戶全程參與(定期定點，與團隊一同運作) • 短週期交付，要求客戶即時反饋 • 減少不必要的文件 (使用活文件、Wiki或產出歷程等)
- 15. 估算 • 估算是報價和資源調度的基礎 • 大家都不喜歡面對 • 估算是核心問題，但永遠估不準 • 如何才能做出好的評估 • 對需求的掌握是充份的，包含產 業知識(Domain Knowledge)和 技術需求(Technical) • 對團隊能力和潛能的了解 • 對專案的風險有足夠的理解 • 如何做報價估算 • 走原本的老路，你原本怎麼做，就 怎麼做。WBS列出來，好好地算出 你需要的人天 • 類比法，先做一小段實作，再反推 其他需求的Effort • 以團隊為計算基礎，而非個人 • 成案後，在Sprint Planning及 Refinement時還要反覆做
- 16. 面對敏捷，PM要面對的問題 • 合約怎麼簽？ • 需求如何展開與收斂？(讓需求明確) • 進度如何控管？(讓執行到位) • 如何面對敏捷架構下的客戶關係？ • 我收得到錢嗎？
- 18. Product Backlog Sprint Backlog Daily Review Product Increment Sprint Refinement Sprint Review Retrospective Sprint Planning Produt Planning • User Story (3C) • 跨職能團隊，自己談自己做 • Sprint Review，收集客尸 反饋，看客戶是否買單
- 19. Project Scope Clarity Requirement Consolidated Chaotic Uncertainty Certainty SOW Sprint Planning Produt Planning Refinement
- 20. 常見的需求訪談誤區(搭配敏捷) • 見樹不見林 • 見樹不見林是最常被質疑的地方 • 一定要對整個專案有宏觀的View，不管 敏捷與否 (可以先做Design Thinking或 Workshop) • Sprint 0或前期的Sprint要對所有的需求 做整理 (非常值得的投資) • 談得太淺 • 最怕”你先做出來，我才有想法” (永遠 改不完) • 沒有專業或熟悉領域知識的團隊，很容 易中槍 • 相信專業(SA是一種專業) • 各功能之間有斷點 • 前期需要不斷梳理系統流程 • 後期靠E2E測試 • 敏捷不寫文件 • 我們是跑敏捷，所以不用寫文件 (超級大誤 區) • 沒有文件，幾乎沒有驗收的可能 • 文件仍然需要客戶簽字 • 留下客戶參與的歷程 • 原本PM要做的工作，一項也少不了 • 讓終端客戶自己寫用戶故事 (User Story)
- 21. 用戶故事 • 用戶故事(User Story)是有難度的 • 一開始會非常難拿揑大小 • 和以Feature為基礎的功能拆分不同 • 更像一個個大小不一的情境(Scenario) • 不管是用戶故事或功能清單，都可 以做為需求的單位 (不用執著) • 我們的目標是要收錢，沒錢付不出大 家的薪水 • 漏網之魚，估評如何做估算 -> 報價基 礎
- 22. 面對敏捷，PM要面對的問題 • 合約怎麼簽？ • 需求如何展開與收斂？(讓需求明確) • 進度如何控管？(讓執行到位) • 如何面對敏捷架構下的客戶關係？ • 我收得到錢嗎？
- 25. 進度如何控管？ • 燃盡圖(Burndown Chart) • 用戶故事點數(User Story Point) • 量化是一個誤區，愈容易量化的指標愈危險 • 當整個專案進度，只剩下一個數字，這個數 字就會迷惑所有的人，包括PM你 • 直接參與站會、各類大小討論，傾聽等，都 能幫助你”smell”到專案實際的狀況 • 團隊成員的Commitment最重要 • 當專案的成員超過一定的數目，很難鉅細彌 遺的管。如何讓團隊自己動起來，自己組織 起來，有榮譽心才能讓團隊敏捷起來 • 受限於台灣的產業環境，非常多外包人員， 沒有Career，沒有葫蘿蔔和棒子，怎麼讓人 就範？
- 26. 開發者的日常 Thursday Friday Monday Tuesday Wednesday Thursday Friday Monday Tuesday Wednesday Thursday Friday Monday Tuesday Wednesday 10:00 Dev Team Daily Standup Dev Team Daily Standup Dev Team Daily Standup Dev Team Daily Standup Dev Team Daily Standup Dev Team Daily Standup Dev Team Daily Standup Dev Team Daily Standup Dev Team Daily Standup Dev Team Daily Standup Dev Team Daily Standup Dev Team Daily Standup Dev Team Daily Standup Dev Team Daily Standup Dev Team Daily Standup 10:30 Sprint N-1 Dev Team Internal Retro 11:00 Dev Leads Daily Standup Dev Leads Daily Standup Dev Leads Daily Standup Dev Leads Daily Standup Dev Leads Daily Standup Dev Leads Daily Standup Dev Leads Daily Standup Dev Leads Daily Standup Dev Leads Daily Standup Dev Leads Daily Standup Dev Leads Daily Standup Dev Leads Daily Standup Dev Leads Daily Standup Dev Leads Daily Standup Dev Leads Daily Standup 11:30 Sprint N-1 Dev Leads Internal Retro 12:00 12:30 13:00 13:30 14:00 14:30 15:00 15:30 16:00 16:30 17:00 Code Freeze 17:30 18:00 Sprint N+1 Planning Sprint Review Dry Run Sprint Review Retro and Sprint N+1 Forecast Sprint N Week One Week Two Week Three Usability Test for Sprint N-1 Paper Prototyping for Sprint N+1 Backlog Grooming and Prioritization for Sprint N+X DB Schema Design for Sprint N+1 DB Schema Finalize for Sprint N+1 Paper Prototyping Run for Sprint N+1 Planning Poker Story Points 每日立會 Leader每日立會 回顧會議 Leader回顧會議 可用性測試 紙本雛型設計 紙本雛型團隊討論 資料庫設計討論 衝刺計畫 資料庫設計定案 尺寸估計 Dry Run PO會議 Review會議
- 27. 敏捷軟體開發宣言 藉著親自並協助他人進行軟體開發， 我們正致力於發掘更優良的軟體開發方法。 透過這樣的努力，我們已建立以下價值觀: 個人與互動 重於 流程與工具 可用的軟體 重於 詳盡的文件 與客戶合作 重於 合約協商 回應變化 重於 遵循計劃 也就是說，雖然右側項目有其價值， 但我們更重視左側項目。 要產出可用的軟體，重點是紀律 • 把整體需求(Product Backlog)轉成可以執行的細項(Sprint Backlog) • 避免見樹不見林，Planning和Refinement需要反反覆覆地做 • 團隊不是烏拖邦，導敏捷不是辦夏令營 回應變化不是客戶要什麼都改給他 • 做了一年，客戶終於知道自己要了什麼，之前都做白工 (賠死) • Product Backlog要提前固定，最為上線的baseline • 文件與會議記錄是不可缺少
- 28. 面對敏捷，PM要面對的問題 • 合約怎麼簽？ • 需求如何展開與收斂？(讓需求明確) • 進度如何控管？(讓執行到位) • 如何面對敏捷架構下的客戶關係？ • 我收得到錢嗎？
- 30. 敏捷軟體開發宣言 藉著親自並協助他人進行軟體開發， 我們正致力於發掘更優良的軟體開發方法。 透過這樣的努力，我們已建立以下價值觀: 個人與互動 重於 流程與工具 可用的軟體 重於 詳盡的文件 與客戶合作 重於 合約協商 回應變化 重於 遵循計劃 也就是說，雖然右側項目有其價值， 但我們更重視左側項目。
- 31. 如何面對敏捷架構下的客戶關係？ • 價值導向驅動甲乙方合作方式轉變 • 客戶需要被教育 (反覆教育與洗腦) • 將客戶納入專案團隊，以One Team的方式合作 • 與客戶更多更深入的合作，尤其是終端用戶 • 從單點的溝通，轉為全面的網狀溝通 • 快速產出，以交付物來跟客戶溝通 • 文件可是提供詳細的資訊，但也會產生認知及解讀差異 • 透過Review及Usability Test收集用戶迴饋
- 33. 乙方 甲方業務單位 (用戶) 甲方資訊單位 (客戶) 業務主管 資訊主管 乙方PM PO 終端用戶 跨功能並跨 組織之專案 團隊
- 34. 如何面對敏捷架構下的客戶關係？ • 需要時間改變 • 跟客戶的關係，不要期望會一夕改變 • 期望客戶能持續的參與與投入 • 要付出代價 • 大部分的客戶對敏捷感興趣(敏捷是顯學)，但實際參與後，叫苦連天，因 為投入的時間和Effort遠超過想像 (很多) • 但是系統是乙方在用的，持續參與對未來的實際使用體驗很重要 • 透過參與與討論/Workshop和客戶溶成一個Team，客戶的評價大多是正 面的 • 有可能會失敗
- 35. 面對敏捷，PM要面對的問題 • 合約怎麼簽？ • 需求如何展開與收斂？(讓需求明確) • 進度如何控管？(讓執行到位) • 如何面對敏捷架構下的客戶關係？ • 我收得到錢嗎？
- 36. 我收得到錢嗎？ • 在合約階段，就必需考慮驗收事宜 • 短期專案/小規模專案，是否敏捷，影響很小 • 大系統，怎麼有效的分段驗收，尤其是切milestone的方法變了，原本是 縱切，現在變成橫切 • 可能的請款條件 • 頭期款(第一期) • 交付物產出(文件/程式碼) • 達成哩程碑(Milestone)，如SIT、UAT或上線等 • 保固結束(交回保證金) • 驗收(客戶簽字)
- 37. 傳統付款排程 2018 2019 2020 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 1 2 3 4 5 頭 期 款 交 付 需 求 規 格 完 成 系 統 開 發 通 過 系 統 系 統 上 線 整 合 測 試 • 依據專案階段請款，常見比例 20%-30%-30%-20% • 如下圖所示，開發期長達9個月，所有風險會在最後一 刻爆發，比如開發不完或品質不佳等。 • 進入測試後用戶才陸續接觸到系統，很容易產生異動的 風險(例如人員異動或認知差異)
- 38. 付款排程(增量交付請款, 一次上線) 2018 2019 2020 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 1 2 7 頭 期 款 3 4 5 6 系 統 上 線 第 一 次 交 付 第 二 次 交 付 第 三 次 交 付 第 四 次 交 付 通 過 系 統 整 合 測 試 • 前期逐次交付，依交付成果請款。後期依測試進度驗收 及上線請款。 • 配合可用性測試(Usability Test)交付，交付後請款。 • 如下圖所示，風險會在各次交付後曝露。 • 最後仍然會面臨需求不完整或開發不完的風險。 以協助客戶維運 及交付為主
- 39. 2018 2019 2020 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 付款排程(MVP上線 + 增量交付請款) 1 2 7 頭 期 款 3 4 5 6 系 統 上 線 第 一 次 交 付 第 二 次 交 付 第 三 次 交 付 第 四 次 交 付 通 過 系 統 整 合 測 試 8 第 五 次 交 付 • 前期只交付MVP，並進行測試驗收及上 線請款。 • 上線後再以PCR或切Phase分式逐次交 付及請款。 • 提早曝險，上線後維運風險低，對乙方 說更容易評估如何投入人力(人力需求不 會暴起暴落)。 持續協助客戶維運及交付 以協助 客戶維運 及交付為主
- 40. 我如何更”敏捷”地收錢？ • 定期及增量交付 • 以Sprint或固定時間區間做請款週期 • 以”可用的軟體”做為交付標的，確保產出物可用，可執行 • 用戶故事儘可能地切薄切細，有意義的scenario • 如果先有基礎建設，增量交付的效果更好 • 文件 • 敏捷也是要寫文件的 -> 活文件/最小文件 • 文件仍然是請款的主要依據 • 留下歷程文件，如故事清單、PO Grooming會議記錄等。
- 41. 敏捷浪潮下的PM生存指南 • 收不到錢，什麼都是假的。 • Scrum不是敏捷唯一的實作方法 • 內在精神更重要 • 大處著眼，小處著手 • 敏捷從自己開始 • 好的教練比上課讀書更有效果 • 不怕你不懂，最怕一知半解和全照課本做 • 好的Sponsor可遇不可得，但非常重要 • 堅持，敏捷導入是長期抗戰 • 有時候你的失敗，只因為你堅持不夠久
- 42. Does Not Matter Agile Scrum vs. Waterfall, No Methodology is a Silver Bullet User-Centric Agile Scrum vs. Waterfall, will Increase Project Success Rate, and will Produce Working Software Earlier AGILE vs. WATERFALL 2015 CHAOS Report, Standish Group
- 44. 臺 北 站 感謝 特別贊助協辦