開發工作量怎麼評估提示詞（需求拆任務 + 三點估算 + 風險緩衝，給出有依據的工期）
產品經理或老闆問「這個需求多久能做完」時用：把需求拆成足夠細的開發任務，每項用樂觀、可能、悲觀三個數估算，識別不確定性和依賴，最後給出帶置信度的工期區間，而不是拍腦袋報一個數。
通用大模型 對話模型通用
你是一名經驗豐富的技術負責人，擅長做靠譜的工作量評估。請幫我評估下面這個需求。 - 需求描述：[需求描述或 PRD 要點] - 技術棧與相關係統現狀：[如需要改動的模組、是否有現成組件] - 參與人員與熟悉程度：[如 2 名後端，其中 1 人熟悉訂單模組] - 已知的外部依賴：[如需要第三方接口、需要其他團隊配合] - 需要包含的環節：[如開發、自測、聯調、修復測試問題、上線] 步驟： 1. 澄清：列出影響工作量的未明確事項（每條說明它會讓工作量相差多少），並先給出你在本次評估中採用的假設。 2. 拆分任務：按「前端 / 後端 / 數據 / 測試配合 / 上線」等維度拆，每項任務不超過 2 人天；超過的繼續拆。別漏掉容易被忽略的工作：數據遷移腳本、權限配置、埋點、文檔、兼容舊數據、監控告警、代碼評審與修改。 3. 三點估算（PERT 公式，任務清單即 WBS 工作分解結構）：每項給出樂觀值 O、最可能值 M、悲觀值 P（人天），用 (O + 4M + P) / 6 計算期望值；悲觀值明顯偏大的任務，說明不確定性來自哪裏。 4. 彙總： - 總工作量（人天）； - 考慮並行與依賴後的日曆工期（要說明關鍵路徑是哪幾項）； - 風險緩衝：根據不確定性給出緩衝比例並說明理由； - 最終給出一個區間，例如「大概率 8 到 11 個工作日」。 5. 降低風險的建議（含技術預研 spike、排期里程碑、範圍砍除清單）：哪些任務可以先做技術驗證；如果工期必須壓縮，可以砍掉或延後哪些範圍（而不是隻說加班）。 輸出任務表：編號 | 任務 | 負責方向 | O | M | P | 期望值 | 依賴 | 備註。 報給業務方的數字一律寫成區間加前提假設，別寫單個日期；人天換算日曆日時扣除會議、評審、請假等非編碼時間（按每人每天約六成有效工時估）。
高亮處換成你自己的內容：[需求描述或 PRD 要點]、[如需要改動的模組、是否有現成組件]、[如 2 名後端，其中 1 人熟悉訂單模組]、[如需要第三方接口、需要其他團隊配合]、[如開發、自測、聯調、修復測試問題、上線]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[參與人員與熟悉程度] 影響很大：同樣的任務，熟悉模組的人可能一天完成，新人需要三天。[需要包含的環節] 要和對方對齊，很多「開發說兩天、實際兩週」的分歧，來自一方只算了寫代碼的時間。
常見坑：
- 只估「寫代碼」的時間，漏掉聯調、修測試提的問題、評審修改、上線和驗證。這些加起來常常和開發時間一樣多。
- 任務拆得太粗（「後端接口 5 天」），估算基本靠感覺。每項拆到 2 人天以內，估算才有依據。
- 被追問後不斷壓縮數字。工期要壓縮，應該討論砍掉哪些範圍，而不是把估算改小。
追問技巧：開發過程中可以把實際進度貼回來，問「按目前已完成任務的實際耗時，重新預測剩餘工期」；也可以追問「把這份評估寫成一段給產品經理的說明，講清楚區間和前提假設」。
示例輸出
示例，僅供參考（需求：訂單列表導出 Excel，節選）
假設：導出上限 10 萬行；超過 5000 行時轉為異步導出，完成後在站內通知。
| 編號 | 任務 | O | M | P | 期望值 |
|---|---|---|---|---|---|
| 1 | 導出接口與篩選條件複用 | 1 | 1.5 | 2 | 1.5 |
| 2 | 異步導出任務與文件存儲 | 1.5 | 2 | 4 | 2.25 |
| 3 | 數據權限校驗（只能導出自己可見的訂單） | 0.5 | 1 | 2 | 1.08 |
| 4 | 過期文件清理定時任務 | 0.5 | 0.5 | 1 | 0.58 |
| 5 | 前端導出按鈕與任務狀態 | 1 | 1.5 | 2 | 1.5 |
| 6 | 聯調、修復測試問題 | 1 | 2 | 3 | 2 |
總期望約 8.9 人天。任務 2 的悲觀值較大，原因是文件存儲方案尚未確定，建議先花半天確認。
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～