Back to Details

estimate-effort

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Estimate Man-day cho dự án phần mềm

估算软件项目的 Man-day

Skill này estimate khối lượng công việc của một dự án phần mềm bằng man-day, dựa trên danh sách functional requirements và techstacks.
该 Skill 基于功能需求列表和技术栈，使用 man-day 估算软件项目的工作量。

Giả định cố định

固定假设

  • Level dev: Mid-level developer
  • 1 manday = 8 giờ làm việc thực tế
  • Estimate cho full SDLC, không chỉ riêng phần code
  • 开发者级别： 中级开发者
  • 1 人天 = 8 小时实际工作时间
  • 估算针对完整 SDLC，而不仅仅是编码部分

Input cần có

所需输入

  1. Functional requirements — danh sách các đầu việc cần làm.
  2. Techstacks — các stack sẽ dùng (FE / BE / DB / third-party...).
Nếu thiếu một trong hai, hỏi user trước khi estimate. Nếu một đầu việc mô tả mơ hồ, ghi rõ giả định đã đặt ra ở cột Ghi chú.
  1. 功能需求 — 需要完成的工作项列表。
  2. 技术栈 — 将要使用的技术栈（FE / BE / DB / 第三方...）。
如果缺少其中一项，在估算前先询问用户。如果某个工作项描述模糊，在“备注”列中明确记录已做出的假设。

Quy trình estimate (làm cho TỪNG đầu việc)

估算流程（针对每个工作项）

Bước 1 — Sizing

步骤 1 — 规模评估（Sizing）

Với mỗi requirement, mô tả rõ:
  • Phần công việc Frontend phải làm (nếu có).
  • Phần công việc Backend phải làm (nếu có).
Sau đó chấm điểm theo 2 trục cho mỗi role.
对于每个需求，明确描述：
  • 需要执行的前端工作（如果有）。
  • 需要执行的后端工作（如果有）。
然后为每个角色按两个维度打分。

FE — 2 trục

前端 — 2 个维度

UI Complexity — Giao diện phức tạp đến đâu?
  • 1: Static content, layout đơn giản, ít state. (FAQ page, static links)
  • 2: Form có validation, conditional rendering, responsive phức tạp. (Address toggle, contact form)
  • 3: Nhiều state combinations, real-time update, animation/interaction nặng. (Calculator, gamification, plan selector với nhiều conditions)
Integration — FE phụ thuộc bên ngoài nhiều không?
  • 1: Self-contained, không gọi API. (Static banner, video playback)
  • 2: Gọi 1–2 API đơn giản, handle vài error states. (Promo code validate, preference submit)
  • 3: Nhiều API, third-party SDK, real-time data, CMS-driven content. (OneMap + smart meter logic, MessageBird, Google Tag + Meta Pixel combo)
UI 复杂度 — 界面有多复杂？
  • 1： 静态内容，简单布局，状态少。（FAQ 页面，静态链接）
  • 2： 表单带验证、条件渲染、复杂响应式。（地址切换，联系表单）
  • 3： 多种状态组合、实时更新、重动画/交互。（计算器、游戏化、多条件套餐选择器）
集成 — 前端对外部依赖多吗？
  • 1： 自包含，不调用 API。（静态横幅，视频播放）
  • 2： 调用 1–2 个简单 API，处理少量错误状态。（优惠码验证，偏好提交）
  • 3： 多个 API、第三方 SDK、实时数据、CMS 驱动内容。（OneMap + 智能电表逻辑，MessageBird，Google Tag + Meta Pixel 组合）

BE — 2 trục

后端 — 2 个维度

Business Logic — Logic nghiệp vụ phức tạp đến đâu?
  • 1: CRUD đơn giản, ít rules. (Serve FAQ content, static config)
  • 2: Conditional logic rõ ràng, vài business rules, validation. (SD amount theo housing type, retailer detection "93")
  • 3: Rule engine, configurable bởi non-dev, nhiều edge cases, stacking logic. (Stackable promo codes, configurable pop-up rules, plan visibility per page)
Integration — BE kết nối ra ngoài nhiều không?
  • 1: Database nội bộ, không external service. (CRUD plans, save preferences)
  • 2: 1–2 external APIs hoặc services. (OneMap proxy, email routing)
  • 3: Nhiều external systems, webhook, queue, sync data phức tạp. (Third-party retailer verification, CMS + multi-channel banner delivery)
业务逻辑 — 业务逻辑有多复杂？
  • 1： 简单 CRUD，规则少。（提供 FAQ 内容，静态配置）
  • 2： 清晰的条件逻辑，少量业务规则，验证。（按房屋类型的 SD 金额，零售商识别“93”）
  • 3： 规则引擎、可由非开发人员配置、多边缘情况、叠加逻辑。（可叠加优惠码，可配置弹窗规则，每页套餐可见性）
集成 — 后端对外连接多吗？
  • 1： 内部数据库，无外部服务。（套餐 CRUD，保存偏好）
  • 2： 1–2 个外部 API 或服务。（OneMap 代理，邮件路由）
  • 3： 多个外部系统、webhook、队列、复杂数据同步。（第三方零售商验证，CMS + 多渠道横幅投放）

Tổng hợp size (mỗi role tính RIÊNG)

汇总规模（每个角色单独计算）

Cộng 2 trục của role đó:
  • S = 2–3 điểm
  • M = 4–5 điểm
  • L = 6 điểm
Một đầu việc có cả FE và BE → có 2 size riêng (size FE và size BE).
将该角色的两个维度得分相加：
  • S = 2–3 分
  • M = 4–5 分
  • L = 6 分
一个工作项同时包含前端和后端 → 有 2 个单独的规模（前端规模和后端规模）。

Bước 2 — Quy đổi sang Man-day (Build effort)

步骤 2 — 转换为 Man-day（构建工作量）

Quy đổi size → man-day. Đây là effort của riêng phase Build (≈ chiếm 40% SDLC, xem bước 3):
SizeĐiểmMan-day (Build)
S2–3~0.5–1.5
M4–5~2–4
L6~5–8+ (nên cân nhắc tách nhỏ)
  • Chọn 1 con số đại diện trong khoảng (không để dạng range ở bảng tổng hợp; range chỉ là guideline).
  • Nếu đầu việc có cả FE và BE → cộng man-day Build của FE + BE.
  • Nếu size = L → ghi chú "nên tách nhỏ".
将规模转换为 man-day。这是仅针对构建阶段的工作量（约占总 SDLC 的 40%，见步骤 3）：
Size得分Man-day（构建）
S2–3~0.5–1.5
M4–5~2–4
L6~5–8+（应考虑拆小）
  • 在范围内选择一个代表数字（不要在汇总表中以范围形式呈现；范围仅供参考）。
  • 如果工作项同时包含前后端 → 将前端 + 后端的构建人天相加。
  • 如果规模 = L → 备注“应拆小”。

Bước 3 — Bổ sung Full SDLC

步骤 3 — 补充完整 SDLC

Man-day ở bước 2 mới chỉ là phase Build. Một đầu việc thực tế gồm 3 phase:
PhaseBao gồmTrọng số
PrepareCreate Requirement + UI/UX30%
BuildDev + Unit Test + Self Test + Fix bug40%
VerificationAcceptance Test + E2E Test + manual30%
Build = 40% → quy đổi full SDLC:
Manday_FullSDLC = Manday_Build / 0.40 = Manday_Build × 2.5
Đây là cột estimate cuối cùng cần xuất ra.
步骤 2 中的 man-day 仅为构建阶段。一个实际工作项包含 3 个阶段：
阶段包含权重
准备创建需求 + UI/UX30%
构建开发 + 单元测试 + 自测 + 修复缺陷40%
验证验收测试 + E2E 测试 + 手动测试30%
构建 = 40% → 转换为完整 SDLC：
Manday_FullSDLC = Manday_Build / 0.40 = Manday_Build × 2.5
这是需要输出的最终估算列。

Output

输出

Xuất ra bảng markdown cho từng đầu việc + phần tổng hợp. Dùng đúng format dưới đây.
为每个工作项 + 汇总部分输出 markdown 表格。请使用以下格式。

Bảng chi tiết từng đầu việc

每个工作项的明细表

#Đầu việcMô tả FEMô tả BEFE (UI/Intg → Size)BE (Logic/Intg → Size)MD Build (FE+BE)MD Full SDLC (×2.5)Ghi chú
1.........2/2 → M1/1 → S2.5 + 1 = 3.58.75...
Quy ước cột:
  • FE / BE size: ghi 
    <điểm trục 1>/<điểm trục 2> → <S/M/L>
    . Nếu role không có việc, ghi 
    —
    .
  • MD Build: hiển thị phép cộng FE+BE rồi ra tổng.
  • MD Full SDLC: 
    MD Build × 2.5
    , làm tròn 2 chữ số thập phân hoặc 0.25.
  • Ghi chú: giả định, rủi ro, hoặc cờ "nên tách nhỏ" (size L).
#工作项前端描述后端描述前端（UI/集成 → 规模）后端（逻辑/集成 → 规模）构建人天（前端+后端）完整 SDLC 人天（×2.5）备注
1.........2/2 → M1/1 → S2.5 + 1 = 3.58.75...
列约定：
  • 前端 / 后端规模： 写 
    <维度1得分>/<维度2得分> → <S/M/L>
    。如果该角色没有工作，写 
    —
    。
  • 构建人天： 显示前端+后端相加后得到的总数。
  • 完整 SDLC 人天： 
    MD Build × 2.5
    ，四舍五入到 2 位小数或 0.25。
  • 备注： 假设、风险或“应拆小”（规模 L）标记。

Bảng tổng hợp

汇总表

Hạng mụcGiá trị
Tổng MD Build...
Tổng MD Full SDLC...
Quy đổi giờ (×6.5h)...
Số đầu việc... (S: x, M: y, L: z)
Đầu việc nên tách nhỏ...
Sau bảng, thêm phần Giả định & Lưu ý:
  • Liệt kê các giả định đã đặt khi requirement mơ hồ.
  • Cảnh báo các đầu việc size L cần tách.
  • Nêu rủi ro phụ thuộc third-party / integration cao (trục Integration = 3).
  • Nhắc rằng đây là estimate cho 1 Mid-level dev; chưa tính buffer quản lý dự án, meeting, hay thời gian onboard.
项目值
总构建人天...
总完整 SDLC 人天...
转换为小时（×6.5h）...
工作项数量...（S: x, M: y, L: z）
应拆小的工作项...
在表格后添加假设与注意事项部分：
  • 列出当需求模糊时所做的假设。
  • 警告需要拆分的 L 规模工作项。
  • 指出高第三方/集成依赖的风险（集成维度 = 3）。
  • 提醒这是针对 1 名中级开发者的估算；尚未包含项目管理缓冲、会议或入职时间。

Nguyên tắc khi estimate

估算原则

  • Chấm điểm bảo thủ nhưng trung thực — đừng cố ép xuống thấp. Khi phân vân giữa 2 mức, chọn mức cao hơn và ghi chú lý do.
  • Mỗi điểm số phải bám vào mô tả công việc thật — không chấm điểm chung chung. Tham chiếu techstack: stack lạ/mới với team → tăng Integration hoặc thêm ghi chú rủi ro.
  • Tách đầu việc size L thành các sub-task nhỏ hơn khi có thể, rồi estimate lại từng cái.
  • Tổng man-day ra số cụ thể, không để range trong bảng cuối (range chỉ dùng để suy luận nội bộ).
  • 打分要保守但诚实 — 不要刻意压低。在两个级别之间犹豫时，选择较高级别并注明原因。
  • 每个分数必须基于实际工作描述 — 不要泛泛打分。参考技术栈：对团队来说陌生/较新的技术栈 → 增加集成维度得分或添加风险备注。
  • 尽可能将 L 规模的工作项拆分为更小的子任务，然后重新估算每个子任务。
  • 总 man-day 应输出具体数字，不要在最终表格中保留范围（范围仅用于内部推理）。