網站專案時程

挑戰跟威脅

TonyQ  @ WebConf 2024 

專案管理

• 什麼是專案?
• 為何我們總是在談專案管理?

專案管理的本質

• 不是管理專案，而是管理風險
• 不是追求完美，而是確保到達

為什麼我們總抱持幻想

• 理想中的系統
• 理想中的開發時程
• 理想中的使用者行為

一家虛構的電商準備在雙11前上線新功能。老闆規劃：

• 全新的商品搜尋體驗
• AI商品推薦
• 即時庫存查詢
• 跨店合併結帳
• 會員積分整合
• 社群分享功能

距離上線前3週：
"那個社群分享...其實可以之後再做"

距離上線前2週：
"AI推薦先用簡單的規則就好，不用太複雜"

距離上線前1週：
"跨店結帳太複雜了，會員積分也暫時不要動"

上線前3天：
"搜尋功能只要能用就好，美化之後再說"

上線前1天：
"只要能正常結帳就好..."

這個案例是有點誇張

換個案例

最重要的不是夢想而是實現

• 在目標時間內上線 > 追求完美功能
• 穩定可靠的最小可行產品
• 以時間為框架，而非以功能為框架

專案的三條時間軸

• 市場機會的時間
• 開發可能的時間
• 團隊整合的時間

團隊如同機器

• 每個齒輪都有自己的節奏
• 運轉效率取決於協調性
• 關鍵在於掌握週期

掌握個人週期

• 每個任務需要多少時間
• 評估自己的產能
• 預判風險點

任務導向

• 將每個 release 切割成屬人的任務
• 單一任務周期不應超過整個團隊的整合周期
• 使用任務管理器 (issue tracker) 進行管理

齒輪之間的配合

• 任務相依性分析
• 減少等待時間
• 卡住時的處理機制

健康度監控指標

• 個人任務完成率
• 跨團隊交接順暢度
• 阻塞時間統計

專案中的人

• 能力差異如何影響專案
• 團隊組成的影響
• 跨組織協作的挑戰

團隊配置的影響

• 探索者：對問題理解較少需較長探索時間，進度難預估
• 誤判者：以為自己知道結果 但是常常整合時才發現不對
• 經驗者：可以協調各方，降低溝通成本
• 執行者：需要明確規格，不適合模糊需求

團隊的成員

本質上就是一種抽卡

公司的等級

會影響出卡機率

不可能湊好好牌才出發

團隊政治

• 溝通頻率與方式的差異
• 組織文化衝突
• 決策鏈過長
• 權責劃分不明

管理建議

• 讓經驗者帶領探索者，提供方向
• 誤判者需要更多檢核點
• 執行者需要更細緻的工作分解
• 跨組織間建立單一對口窗口

時程偏移的三大挑戰

• 人員能力差異造成的週期不確定性
• 跨團隊整合點的等待時間
• 週期估算的即時更新問題

最小等待原則

• 識別關鍵路徑上的依賴關係
• 調整任務順序降低阻塞
• 建立即時回饋機制

團隊工作配置

• 核心成員負責主要開發，需保持穩定進度
• 支援成員機動調配，填補等待空窗
• 團隊領導需一定周期掌握各項任務狀態
• 設立明確的整合檢查點

高效能整合的關鍵

• 頻繁的小規模整合優於大規模整合
• 自動化操作降低整合成本
• 建立明確的分支管理策略

專案經理的角色

• 整體節奏的掌握
• 資源的調度與分配
• 瓶頸的及早發現與排除

團隊健康度指標

• 需求調整成功的次數
• 團隊達成周期目標的次數
• 團隊上線的成功次數
• 團隊 context switch 的次數

團隊健康度指標

• 需求調整成功的次數
• 團隊達成周期目標的次數
• 團隊上線的成功次數
• 團隊 context switch 的次數

個人如何參與-評估

• 基於經驗提供合理預估
• 明確表達不確定性
• 及早提出風險點

個人如何參與-執行

• 保持進度透明度
• 即時回報阻礙
• 主動尋求協助

個人如何參與-監控

• 記錄實際工時
• 分析偏差原因
• 總結經驗教訓

意外與應變

• 常見的專案危機

上線後發現
系統有bug怎麼辦

只要出問題，推給「駭客入侵」就對了！

請勿認真

不管發生什麼事情

先做可行性評估

不可逆的問題

盡速止損

可透過更新處理的問題

透過規劃安排

所謂的意外就是

插入一到多個 iteration

專案的收尾

進入專案的第一天就要想著離開的那天。
文件、必要的參數管理、權限管理，
都要確保隨時可以交接。

Q & A

延伸工商

行動自然人憑證

你還在煩惱電子文件簽署有沒有手寫簽名以外的方案嗎？

目前有四十五萬使用者，介接系統數百個，開放非政府單位介接。

API 簡單到只有兩個 API 要接，有興趣的歡迎來聯繫

歡迎申請介接！ 

介接申請辦法與聯絡email/電話請參考

https://fido.moi.gov.tw/pt/agency

也可以直接找我喔！