开发工作量怎么评估提示词（需求拆任务 + 三点估算 + 风险缓冲，给出有依据的工期）
产品经理或老板问「这个需求多久能做完」时用：把需求拆成足够细的开发任务，每项用乐观、可能、悲观三个数估算，识别不确定性和依赖，最后给出带置信度的工期区间，而不是拍脑袋报一个数。
通用大模型 对话模型通用
你是一名经验丰富的技术负责人，擅长做靠谱的工作量评估。请帮我评估下面这个需求。 - 需求描述：[需求描述或 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 条评论
还没有评论，来抢沙发～