技術債怎麼管理提示詞：技術債盤點清單、影響評分與償還排期（說服產品經理給排期）
團隊技術債越積越多、卻總排不上期，需要系統盤點並向管理者或產品經理爭取時間時用：把零散的吐槽整理成一份有分類、有影響評估、有成本估算的技術債清單，按投入產出排序，並寫成業務方看得懂的說明。
通用大模型 對話模型通用
你是一名技術負責人，擅長把工程問題翻譯成業務語言。請幫我整理團隊的技術債並制定償還計劃。 材料： - 系統簡介：[系統用途與規模] - 團隊成員提到的問題（吐槽、待辦、代碼裏的待處理註釋都可以，原樣粘貼）： [粘貼問題列表] - 近期的事故或效率問題：[如上月兩次因為同一模組出事故] - 每個迭代可以投入的時間：[如每兩週 2 人天，或比例 20%] - 讀者：[如產品負責人、技術總監] 請完成： 1. 歸類整理：把材料中的問題合併去重，分類為：代碼質素、架構設計、測試缺失、依賴與版本過舊、基礎設施與部署、文檔與知識缺失、安全隱患。 2. 逐條評估，輸出清單表：編號 | 技術債 | 分類 | 現在造成的影響（盡量量化：事故次數、每次需求多花的時間、上線耗時）| 不處理的風險（會怎樣惡化）| 償還成本（人天，粗估）| 優先級。 3. 優先級規則：影響大且成本低的優先；有安全風險或依賴即將停止維護的單獨標出，不受排序約束；「看着難受但影響很小」的放到最後，並明確可以暫不處理。 4. 償還計劃：根據每個迭代可投入的時間，排出接下來 3 個迭代的計劃；說明哪些可以和業務需求一起做（「順手修」），哪些需要單獨排期。 5. 業務版說明：寫一段給 [讀者] 看的 300 字左右說明，不用技術術語，講清楚「如果不處理，會對上線速度、穩定性、成本產生什麼影響」，以及「投入多少時間，能換來什麼」。 6. 防止新增：建議 2 到 3 條團隊約定，減少新的技術債（例如新代碼必須有測試、依賴每季度升級一次）。 材料中沒有的數字不要編造，在影響一列寫「待估」。
高亮處換成你自己的內容：[系統用途與規模]、[粘貼問題列表]、[如上月兩次因為同一模組出事故]、[如每兩週 2 人天，或比例 20%]、[如產品負責人、技術總監]、[讀者]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[團隊成員提到的問題] 不用整理，越原始越好。代碼裏的待處理註釋可以用搜索批量導出。[近期的事故或效率問題] 是說服業務方的最好證據，有具體事件就寫上。
常見坑：
- 清單裏全是「代碼寫得醜」這種主觀問題，業務方看不出為什麼要花時間。要把每一條和可觀察的影響掛鉤：多花了多少時間、出過幾次事故。
- 想一次性把技術債全還清，申請一整個月的「重構期」，幾乎不會被批准。持續地每個迭代留出固定比例，更現實。
- 依賴庫、框架、運行時的版本停止維護是有明確期限的風險，不能和普通技術債一起慢慢排。
追問技巧：追問「針對第一優先級的技術債，寫一份一頁的立項說明：問題、方案、成本、收益、風險」，可以直接拿去評審。
示例輸出
示例，僅供參考（清單節選）
| 編號 | 技術債 | 分類 | 現在的影響 | 不處理的風險 | 成本 | 優先級 |
|---|---|---|---|---|---|---|
| TD-01 | 訂單模組無自動化測試 | 測試缺失 | 近兩個月 2 次事故源於此模組；每次發佈手工迴歸半天 | 改動越來越不敢做 | 8 人天 | 高 |
| TD-02 | 運行時版本即將停止安全更新 | 依賴過舊 | 暫無 | 停止更新後的漏洞無法修補 | 5 人天 | 單獨標出 |
| TD-03 | 工具類命名混亂 | 代碼質素 | 待估，影響較小 | 低 | 2 人天 | 低（暫不處理） |
業務版說明（節選）：訂單模組目前沒有自動檢查手段，每次上線都要人工花半天迴歸，近兩個月仍有兩次問題漏到了線上。如果接下來兩個迭代各投入 4 人天補齊關鍵流程的自動化測試，預計每次發佈可節省約半天，並降低同類事故再次發生的概率。
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～