用途
Time & Resource Estimator 用于软件项目的时间与资源估算，目标是避免过度承诺、按时交付，并给出更贴近实际的估算结果。其输入为项目范围与功能，输出为现实的时间线、工时拆分、缓冲计算以及客户沟通内容。
主要能力
按功能类型的基础工时
- 认证与用户管理：6-8 小时（登录/注册、密码重置、用户角色、会话管理）
- CRUD 操作（每个模型）：4-6 小时（增删改查、基础校验、列表视图）
- 表单（每个复杂表单）：3-5 小时（输入校验、错误处理、成功状态）
- 仪表盘/分析：8-12 小时（数据可视化、实时更新、筛选/排序）
- 文件上传：4-6 小时（存储设置、上传界面、查看/下载）
- PDF 生成：6-8 小时（模板设计、数据格式化、下载/邮件发送）
- 邮件通知：4-6 小时（邮件模板、触发逻辑、发送基础设施）
- 集成（每个服务）：10-15 小时（API 设置、数据映射、错误处理、测试）
- 移动端响应式：总工时 +20%（响应式设计、移动端测试、触控交互）
缓冲公式
技能强调绝不在没有缓冲的情况下给出估算。经验规则为：基础估算 = 各功能工时之和；未知与边界情况加 25%；修订与客户反馈加 15%；测试与缺陷修复加 10%；总计 = 基础 × 1.5。示例：基础功能 60 小时，含缓冲后 60 × 1.5 = 90 小时，对客户说“6-8 周”而非“60 小时”。
工时换算为时间线
全职（40 小时/周）：40 小时 = 1 周，80 小时 = 2 周，120 小时 = 3 周。兼职（20 小时/周）：40 小时 = 2 周，80 小时 = 4 周，120 小时 = 6 周。始终为以下情况额外增加 1-2 周：客户延迟（反馈、访问权限、审批）、假期/病假、意外复杂度。安全时间线公式：（估算工时 ÷ 每周工时）+ 2 周。
项目时间线拆分示例
以消防检查软件（80 基础工时）为例：第 1-2 周基础搭建（20 小时：项目设置、数据库设计、认证、基础 UI 框架）；第 3-4 周核心功能（30 小时：楼宇管理、检查排程、用户角色）；第 5-6 周现场功能（20 小时：移动检查表单、照片上传、数据校验）；第 7 周打磨与测试（10 小时：缺陷修复、UI 优化、测试）；第 8 周客户评审与修订（客户测试、反馈整合、最终调整）。总计 8 周（80 小时 × 1.5 缓冲 ÷ 20 小时/周 = 6 周 + 2 周缓冲）。
面向客户的沟通
应说：“基于范围，从启动到上线需要 6-8 周。”不应说：“这是 80 小时的工作，全职做就是 2 周。”原因：工时对客户没有意义，周数是可感知的。提案中应写明时间线及其假设：客户在 2 个工作日内提供反馈、系统/数据访问就绪、项目中途范围不变；若任一条件变化，时间线相应调整。写入书面文件可避免“为什么这么久”的质疑。
影响时间线的风险信号
“我们两周内就要”对任何实质性项目都不现实；需求不清晰会导致延迟与返工；多个利益相关者会拖慢审批；“就像某个复杂 SaaS 那样”说明低估了复杂度；客户从不快速回复会增加数周时间。解决方案：把时间线预期写入合同。
延期时的沟通
尽早诚实告知，例如：说明某功能出现意外复杂度，增加 3-5 天，给出新的交付日期，并表示宁愿做对也不赶工。提前重置预期好过错过截止日期。
估算检查清单
给出时间线前需确认：所有功能已识别、技术复杂度已评估、集成需求清晰、客户响应速度已纳入考虑、已包含 50% 缓冲、已包含测试时间、已考虑假期/休假。若有任何不清楚：增加更多缓冲，或说“我需要在承诺时间线之前进一步明确范围”。
置信度矩阵
高置信度（±1 周）：做过类似项目、需求清晰、无复杂集成、客户响应及时。中置信度（±2 周）：存在一些未知、新技术栈、客户审批可能延迟。低置信度（±4 周或“待定”）：大量未知、复杂集成、需求模糊、多个利益相关者。据此调整缓冲。
使用方式
该技能以项目范围与功能为输入，按上述基础工时表逐项累加，套用 1.5 倍缓冲公式，再按每周可投入工时换算为周数并额外加 2 周，最后用面向客户的话术沟通时间线。技能还提供检查清单与置信度矩阵用于复核。
适用场景
适用于自由职业者、外包团队或内部项目在提案、报价与排期阶段进行时间与资源估算，尤其适合需要向客户承诺交付时间的软件项目。
限制
资料未提供该技能的具体安装方式、运行环境、平台支持、收费模式或价格信息，这些内容暂未提供。基础工时与缓冲比例为经验参考值，实际项目需结合具体情况判断。