Ước lượng: vì sao developer luôn sai?
Vì chúng ta ước lượng theo best case (mọi thứ suôn sẻ). Thực tế: meeting, hotfix, code review, học API mới, refactor code cũ. Quy tắc: nhân đôi con số ban đầu, rồi thêm buffer 20% nữa.
| Cách ước lượng | Phù hợp cho | Ví dụ |
|---|---|---|
| T-shirt size (S/M/L/XL) | Backlog grooming, planning poker | Feature auth = L, fix typo = S |
| Story points (Fibonacci) | Sprint planning | 1, 2, 3, 5, 8, 13 (tương đối) |
| Ngày cụ thể | Deadline cam kết | “2-3 ngày, có risk nếu API chưa sẵn sàng” |
Giao tiếp với non-tech
Business không cần biết bạn dùng PostgreSQL hay MongoDB. Họ cần biết: (1) Bao lâu xong? (2) Có risk gì? (3) Cần gì từ họ? Nói bằng ngôn ngữ của họ: “tốn 3 ngày” thay vì “phải refactor module auth”.
// File: communication.md
## Template báo cáo cho business:
**Yêu cầu:** Thêm tính năng export PDF cho báo cáo.
**Ước lượng:** 5 ngày dev + 2 ngày test = 7 ngày làm việc.
**Risk:**
- Thư viện PDF mới, cần 1 ngày nghiên cứu (có thể lâu hơn)
- Phụ thuộc API bên thứ 3 cho template
**Cần từ business:**
- Mẫu PDF mong muốn (design)
- Danh sách field cần xuất
**Phương án:**
1. MVP: export cơ bản (3 ngày) → release trước
2. Full: thêm template đẹp, chart (thêm 4 ngày)
Nói “không” mà không mất lòng
Không phải “không”, mà là “không với scope này trong thời gian này”. Đưa ra phương án thay thế: “Chúng ta có thể làm phiên bản đơn giản trước trong 3 ngày, rồi nâng cấp sau. Hoặc làm đầy đủ nhưng cần 2 tuần.”
❓ Business yêu cầu tính năng "gấp, cần xong tuần này" nhưng bạn biết cần 2 tuần. Cách tốt nhất?
- Ước lượng có buffer, không dùng best case
- Giao tiếp với business bằng ngôn ngữ của họ
- Đưa phương án thay thế khi nói “không”
- Viết báo cáo rõ ràng: ước lượng, risk, cần gì