---
title: "軟體工程師生存指南，如何報告專案預估工時"
description: "分享軟體工程師如何拆解工作清單、預估專案工時並與主管有效溝通，包含 WBS 工具應用與面對不合理 Deadline 的協商策略。"
canonical_url: "https://blog.markkulab.net/post/talk-about-estimate-timetable-of-project"
author: "Mark Ku"
author_url: "https://blog.markkulab.net/author/mark-ku"
site: "Mark Ku's Blog"
date_published: "2024-08-28 01:01:35 +0800"
category: "Management"
tags: ["estimate", "wbs", "timetable", "project", "management", "deadline"]
language: "zh-TW"
license: "CC BY 4.0"
license_url: "https://creativecommons.org/licenses/by/4.0/"
attribution: "轉載或引用請註明作者並附上原文連結"
---

# 軟體工程師生存指南，如何報告專案預估工時

> **TL;DR** — 歡迎收聽 Mark 的技術雜談，我是主持人璦廷。在軟體開發的過程中，你是否也常被突如其來的隕石級需求砸得措手不及呢？今天，我們要探討每位工程師必備的生存技能，也就是如何精準預估專案工時，並與主管進行有效溝通。 讓我們來看看面對不合理的死線時，該如何應對。這個重點值得注意，千萬別急著拒絕。我們應該先釐清專案背後的商業目標，接著將需求拆解成具體的工作清單，從模組到元件一一條列，這樣才能客觀評估所需的開發時間。 在實務應用上，雖然一天有八小時，但扣除會議與日常瑣事，以六小時作為一個人天來估算會更為精準，同時也要為專案預留充足的測試期。如果上線時間真的無法妥協，你可以帶著準備好的清單與主管協商，提出分階段交付核心功能、增加人手或是安排加班等具體的解決方案。 專案預估很難百分之百完美，但透過良好的溝通與優先交付核心價值，就能在團隊中建立信任。隨著人工智慧的到來，基礎的程式撰寫工作正逐漸被取代。這也提醒了我們，除了寫程式，你是否已經準備好提升自己不可替代的底層邏輯與專案協調能力了呢？

## 專案時程預估
大多工程師對於要剛開始如何老闆報告時程，困擾於及不知道怎麼溝通，在死線前做不完或項目超大，也不知道，如何解釋需要多少時間，最近我被問到這問題，我就順便整理了一下，我自身的經驗。  

在軟體開發的職業生涯中，能夠獨當領導一個專案，分析及時程預估是尤其重要的事，因為你一開始可以是預估一個人工作，到後面要帶著好幾一人一起工作，需要和上級討論，並去尋求他人的協助，才不會讓專案失去控制。

## 有趣的自然現象，隕石一直都在
從事軟體開發工作快滿10年，我們都想找間沒隕石的公司，其實工作久了，發現每間公司多多少少都會有些隕石，隕石其實就像是個真實世界自然現象，可能每天都在發生，而你不知道，公司總會有更重要又臨時的商業目標，或是那個老闆又想插單，就會影響團隊的做事情的排序，但就看怎麼應對及克服，怎麼協調減少對團隊的衝擊，只要能從天天被隕石砸到，到兩週才被砸一次，這就算是團隊很大的進步。  

而大多公司的高層多半是業務出身，所以更在意專案帶來的商業效益，對於專案心裡的預期是越快越好，能夠將產品或功能越快的推上線，越快賺錢越好，對於大多業務出身的老闆思考的方式是，先定目標，在畫箭靶，所以更在意的是上線時程。  

但因為看待問題的角度不同，對於工程師來說，我們得先了解需求要做什麼，拆解成工項，才能知道要做什麼，需要多久，因此工程師得先產出工作清單 (Work breakdown structure)，才能估大概估的時間。  

## 讓我們先回顧一下，軟體開發流程
教科書上定義的軟體開發流程如下，但礙於現今的市場對於軟體需求，變得越來越快，也不是每間公司都能夠這樣運行，很多 In house 的軟體工程師，可能需求訪談到系統分析及測試上線，可能都是一條龍。

* 需求訪談 > 此階段產出-需求資訊或需求確認書  
* 系統分析 > 此階段產出-需求資訊分析資料或系統分析書  
* 程式撰寫 > 此階段產出-程式地基、功能撰寫
* 測試 > 此階段產出-問題單或測試報告
* 上線
* 運維

## 首先，面對一個做不到的目標需求，或是不合理的 Deadline 
先不急著去拒絕，而是先去了解規劃分析，回過頭在和使用者討論，能不能有其他折衷的做法，或是尋求上級獲得更多資源的幫助。

## 接著，理解需求
先了解要這個專案在做什麼 ? 去確認你理解的需求是不是和未來要做一致，並去理解這個需求是要達成什麼目的 ?   

## 分析需求
充份理解需求後，並展開分析，怎麼做更好，或是有那些開源的資源可以加速開發，接著盤點可以用的資源，並找出需要誰的協助及需要幾個人或是去評估有沒有重大的技術難點，針對較複雜技術難點，可以在此階段做個POC。

## 拆解工作
從模組、頁面、元件把所有的工作項列出來，並評估工時。

![WBS](https://blog.markkulab.net/content/markku/posts/talk-about-estimate-timetable-of-project/images/WBS.png)

## 預估工時
雖然一天有8小時工作時間，但扣掉開會討論，上廁所，預留一些Buffer time ，一個人天，實務上，通常是算6小時，會比較精準。

## 測試
如果是大的專案，上線前預留兩週做測試。

## 如果上線的死線( Deadline ) 不能變
盤點可以用的資源
* 拆分階段 - 使用者的需求一定很多，但真正在意的就是某幾個，找出那些必要的功能，並拆分階段，評估先將主要功能完成，能不能如期。
* 補人 - 提出來需要更多的人手，補人不一定立刻有幫助，要適應熟悉專案適應，團隊也要段時間。(通常只能把較簡單的功能拆解給新人，這樣就不會變趕專案時邊帶人)。
* 加班 - 前提是公司有加班費，並且同仁有意願或是找機會和老闆談補班機制。

## 協商及討論
拿著你的前面準備好規劃好的工作清單及時程及解決方案，去和主管去討論。

## 最後
專案預估大多時候，不一定是精準的，但其實能在死線前交付使用者最在意的事，剩下的拆分階段，慢慢補完，並能夠解釋為什麼，盡力去做，好好溝通，其實大多使用者或主管，都能接受。

AI 的到來，有點像溫水煮青蛙，己拿走一些軟體開發的基礎的工作，減少了很多基層及中層的工作，但賦予每個工程師更多的生產力及效率，同時也帶來新的機會，在每個專案裡還有很多可以學的，底層邏輯，是不可以替代的，不要只會寫程式，不然等到工具取代你的工作時，而你還沒找到下條路。

---

## 關於本文與作者

本文出自 [Mark Ku's Blog](https://blog.markkulab.net/post/talk-about-estimate-timetable-of-project)

授權條款： [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) — 轉載或引用請註明作者並附上原文連結

### 關於作者

**[Mark Ku](https://blog.markkulab.net/author/mark-ku)** — Software Solution Provider

- 10+ 年資深軟體工程師，現為 AI 應用 Builder
- 專注大型平台架構設計，從北美電商到AI SaaS訂閱收費系統
- 結合 AI Agent 與自動化，打造高效可演進的產品技術基礎

### 作者開發的免費工具

以下工具皆可免費使用：

- [免費 PDF 簽名工具](https://blog.markkulab.net/tools/pdf-sign): 線上 PDF 簽名工具，瀏覽器內完成手繪、打字、上傳簽名，可拖曳放置、縮放、下載。所有處理都在你的裝置完成，檔案不會上傳。
- [VS Code Refactory](https://blog.markkulab.net/tools/refactory): Refactory 是一款 VS Code 重構擴充套件：34 個重構動作、37 條 code smell 檢查、Code Health 儀表板、18 種語言、534 支測試。懂你的專案慣例：介面放哪、DI 註冊寫在哪、'use client' 該不該加；還會用 git 修改頻率 × 複雜度排出「該先修哪個檔案」，並一鍵把壞味道交給你自己電腦上的 Claude Code 修。免費使用，原始碼不離開你的機器。
- [DB-Kit 資料庫管理工具](https://blog.markkulab.net/tools/db-kit): DB-Kit 是一個用 Tauri + Rust + React 打造的輕量跨平台資料庫管理工具，用單一一致的介面同時管理 MySQL、MariaDB、PostgreSQL、SQL Server、Oracle、SQLite、MongoDB、Redis、Kafka、Elasticsearch 與 RabbitMQ 十一種資料來源：連線密碼以 OS keychain 加密、SSH Tunnel、完整 CRUD、視覺化查詢建構器、多結果集同時顯示、跨連線資料傳輸與比對同步、Excel / CSV 匯入匯出、執行計畫視覺化、ER 圖、排程備份、SQL 壓力測試（p50～p99 延遲百分位）、15 條規則的 SQL 審查、Kafka 訊息瀏覽與監控告警；繁中 / 英文雙語介面，內建 AI 助手（自然語言生成 SQL、AI 審查與調校建議）與命令列工具 dbk。免費開源（MIT），提供 Windows / macOS / Linux 安裝檔。
- [VS Code Super Mermaid](https://blog.markkulab.net/tools/super-mermaid): Super Mermaid 是一款 VS Code 擴充套件：開箱即用的漂亮 Mermaid 圖表，自動上色、即時預覽、滑鼠平移縮放、PNG / SVG 高解析匯出，內建 21 種範本與多種主題。免費開源（MIT）。
- [React Super Mermaid](https://blog.markkulab.net/tools/react-super-mermaid): react-super-mermaid 是一個開源 React 元件庫：一行 <MermaidViewer> 即可渲染漂亮的 Mermaid 圖表，內建 colorful / sketch 主題、平移縮放、圖內搜尋、SVG / PNG 高解析匯出。輕量、SSR 安全、完整 TypeScript 型別。免費開源（MIT）。
- [Jira / Confluence Super Mermaid](https://blog.markkulab.net/tools/jira-super-mermaid): Atlassian Forge app：在 Jira issue 與 Confluence 內文直接寫 Mermaid 語法，畫流程圖、時序圖、狀態機與甘特圖。11 種圖表、SVG / PNG 匯出、明暗主題、完整中日韓文字支援。取得 Runs on Atlassian 資格：圖表存在你自己的站台，app 不呼叫任何第三方服務。免費，即將上架 Atlassian Marketplace。
- [Mermaid 線上預覽](https://blog.markkulab.net/tools/mermaid-preview): 在瀏覽器裡寫 Mermaid、即時看圖，整張圖表壓進網址就能分享。免註冊、不上傳伺服器，相容 mermaid.live 的分享連結。
- [React Intl Phone Number](https://blog.markkulab.net/tools/react-intl-phone-number): react-intl-phone-number 是一個開源 React 元件：framework-agnostic、不依賴 antd，提供 E.164 進出、可搜尋國旗 / 國碼下拉、可配置驗證等級（strict / mobile-strict / loose）、可主題化 CSS 與 i18n，電話邏輯由 google-libphonenumber 驅動。輕量、完整 TypeScript 型別。免費開源（MIT）。
- [Uptime Kuma Cluster](https://blog.markkulab.net/tools/uptime-kuma-cluster): 把單機版 Uptime Kuma 改造成高可用叢集：OpenResty + Lua 智慧負載平衡、MariaDB 共享狀態、健康檢查與自動 Failover，附叢集管理 REST API，一行 Docker Compose 啟動。免費開源（MIT）。
- [特教專案](https://blog.markkulab.net/education): 為特殊教育學生製作的學習教材

### 每日 Podcast

- [科技新鮮事](https://blog.markkulab.net/category/tech-news): 每日精選 AI 與科技趨勢，透過語音摘要快速掌握最新技術動態，涵蓋 AI 應用、軟體架構、DevOps 與工程實戰。 — RSS: https://blog.markkulab.net/feed.xml
- [AI股市蝦聊](https://blog.markkulab.net/category/ai-stock-chat): 每個交易日用 AI 分析台股盤勢，以雙人對話聊當天的盤中觀察與隔日預測。 — RSS: https://blog.markkulab.net/ai-stock-chat/feed.xml

### 電子報

[訂閱電子報](https://blog.markkulab.net/subscribe) — 第一時間收到新文章通知，無垃圾信、隨時可取消訂閱。
