Estimating — Nghệ thuật ước lượng (Pragmatic Programmer #15)
Mở đầu
Chào mấy bạn, lại là mình đây!
Hôm nay mình tiếp tục series "The Pragmatic Programmer" với Topic 15 – Estimating (Ước lượng) nằm trong Chapter 2 – A Pragmatic Approach.
Cuốn sách này càng đọc càng thấm, kiểu mỗi topic là một bài học nhỏ mà áp dụng được liền. Hồi mới thấy tựa đề "Estimating" mình nghĩ chắc cũng khô khan lắm, ai ngờ đọc xong thấy gần gũi dữ lắm.
Ảnh: Lukas Blazek — Pexels
Topic 15: Estimating – Nghệ thuật ước lượng
Cái hay là tác giả không biến estimating thành công thức toán học rối rắm. Thay vào đó, họ nói về nó như một kỹ năng mà dev nào cũng rèn được.
Mình nhớ nhất câu: "Where does my estimate come from?" — tự hỏi coi con số ước lượng đó mình lấy từ đâu. Phải chăng mình vừa nghĩ bừa ra? Hay thực sự đã hiểu vấn đề?
Ba cấp độ ước lượng siêu thực tế:
- Order of magnitude — cỡ lớn, sai số có thể tới vài lần
- Rough estimate — độ chính xác tầm 50–100%
- Detailed estimate — gần sát nhất, sau khi break down công việc
Vấn đề là tụi mình hay nhảy thẳng tới detailed estimate mà quên rằng lúc đầu thông tin quá ít. Kết quả là ước lượng sai, rồi tự tạo áp lực cho bản thân.
Sách cũng chỉ ra cái bẫy "mốc giả": estimate 2 tuần nhưng mọi người nghe thành 2 tuần là có hàng, trong khi thực tế đó chỉ là con số ước lượng sơ bộ. Cách tốt nhất là luôn nói rõ khoảng sai số kèm theo.
Ảnh: Kira auf der Heide — Pexels
Cảm nhận của mình
Estimating là cái mà mình thấy rất nhiều dev (kể cả mình) sợ. Sợ vì biết nếu sai sẽ bị "soi" sau này. Nhưng cái hay của topic này là nó nhấn mạnh: estimate không phải là commit. Estimate là dự đoán, commit là lời hứa. Hai cái khác nhau hoàn toàn.
Mình từng estimate một feature mất 2 ngày, nhưng thực tế mất tới 5 ngày vì edge case không lường trước. Lúc đó mình mới hiểu: cái mình cần không phải là "ước lượng nhanh hơn" mà là "ước lượng trung thực hơn" — dám nói ra điều mình chưa biết, dám thêm buffer cho sự không chắc chắn.
Kỹ thuật sách đưa ra đơn giản mà hiệu quả: break down công việc thành phần nhỏ, estimate từng phần, rồi cộng lại. Quan trọng nhất: sau mỗi lần estimate, hãy nhìn lại xem mình đúng hay sai — đó là cách duy nhất để cải thiện. Sách gọi đây là vòng lặp "estimate → track → learn".
Ảnh: Brett Jordan — Pexels
Kết
Topic 15 nhẹ nhàng mà thấm. Nó nhắc mình rằng estimating không phải bói toán, cũng không phải cam kết. Nó là kỹ năng cần rèn luyện, dựa trên kinh nghiệm và sự trung thực với bản thân. Lần tới khi ai hỏi "bao giờ xong?", mình sẽ nhớ: nói estimate kèm độ tin cậy, chứ không nói bừa một con số.
Hẹn mấy bạn bài sau với Topic 16 — "The Power of Plain Text". Chắc chắn cũng thú vị không kém! 📚