Mở đầu — vì sao bài này quan trọng
Có một câu nói đùa cay đắng trong giới kỹ sư phần mềm: "Lấy con số estimate ban đầu, nhân đôi nó lên, rồi đổi đơn vị sang đơn vị lớn hơn kế tiếp." Nghĩa là nếu kỹ sư bảo "2 ngày", bạn nên chuẩn bị tinh thần cho "4 tuần". Câu đùa đó tồn tại vì nó phản ánh một sự thật khó chịu: estimation trong phần mềm gần như luôn sai, và thường sai theo hướng lạc quan quá mức.
Là một Technical PM, bạn không cần tự mình estimate từng task — đó là việc của engineer. Nhưng bạn là người phải đứng ra cam kết deadline với business, với CEO, với khách hàng. Bạn là người dịch những con số estimate thành lời hứa về ngày ra mắt tính năng, về doanh thu, về kế hoạch marketing. Nếu bạn không hiểu bản chất của estimation — tại sao nó sai, sai bao nhiêu, và làm sao quản lý sự bất định đó — thì bạn sẽ liên tục rơi vào tình huống: hứa với sếp một đằng, team giao một nẻo, và cuối cùng người mất uy tín là bạn.
Bài này không dạy bạn cách làm estimate "chính xác hơn" — vì điều đó gần như bất khả. Thay vào đó, nó dạy bạn cách làm việc với sự bất định: hiểu các kỹ thuật estimate phổ biến, biết khi nào dùng cái nào, và quan trọng nhất là biết cách biến một con số mong manh thành một cam kết có thể bảo vệ được trước business.
Khái niệm cốt lõi
Tại sao estimation luôn sai
Trước khi học kỹ thuật, bạn phải hiểu gốc rễ của vấn đề. Estimation sai không phải vì engineer kém, mà vì bản chất công việc.
Planning fallacy (ngụy biện lập kế hoạch). Đây là một bias tâm lý đã được chứng minh qua hàng chục nghiên cứu: con người có xu hướng đánh giá thấp thời gian hoàn thành công việc của chính mình, ngay cả khi họ biết những việc tương tự trong quá khứ đã trễ. Khi một engineer hình dung việc xây một tính năng, họ tưởng tượng ra "kịch bản đẹp": code chạy ngay, không bug, không họp hành, không ai làm phiền. Họ quên mất overhead: review code, fix bug staging, đợi QA, viết test, deploy, merge conflict, đồng nghiệp nghỉ ốm. Phần "happy path" thì họ estimate khá chính xác; phần overhead — vốn chiếm 40-60% thời gian thực tế — thì họ gần như bỏ qua.
Unknown unknowns (những thứ chưa biết là mình chưa biết). Đây là kẻ thù lớn nhất. Có ba tầng nhận thức: thứ ta biết (cần gọi API thanh toán), thứ ta biết là mình chưa biết (chưa biết cổng thanh toán VNPay xử lý refund thế nào — nhưng biết là phải tìm hiểu), và thứ ta không biết là mình chưa biết (hóa ra VNPay yêu cầu ký hợp đồng riêng cho refund mất 3 tuần phê duyệt). Tầng thứ ba này không thể đưa vào estimate vì theo định nghĩa, bạn không nhìn thấy nó lúc estimate. Càng nhiều thứ mới mẻ — công nghệ mới, đối tác mới, domain mới — thì tầng "unknown unknowns" càng lớn, và estimate càng vô nghĩa.
Cone of Uncertainty (hình nón bất định). Một khái niệm nền tảng: độ chính xác của estimate phụ thuộc vào việc bạn đang ở đâu trong vòng đời dự án. Ở giai đoạn ý tưởng ban đầu, một estimate có thể lệch tới ±400% (việc bạn nghĩ 1 tháng thực ra mất từ 1 tuần đến 4 tháng). Càng tiến gần, khi đã làm rõ requirement, đã thiết kế xong, độ lệch mới thu hẹp dần về ±10%. Bài học cho PM: đừng bao giờ lấy estimate từ giai đoạn đầu rồi đóng đinh thành deadline cứng.
Các kỹ thuật estimation phổ biến
Story Points và Planning Poker. Thay vì estimate theo thời gian (giờ, ngày), nhiều team Agile dùng story point — một con số tương đối thể hiện độ phức tạp/công sức của một task so với các task khác. Thường dùng dãy Fibonacci (1, 2, 3, 5, 8, 13, 21) vì khoảng cách giữa các số lớn dần phản ánh sự bất định tăng theo kích thước. Planning Poker là cách team cùng "bốc bài": mỗi người chọn điểm độc lập, lật bài cùng lúc, nếu chênh lệch lớn thì người cao nhất và thấp nhất giải thích lý do — thường lộ ra một requirement bị hiểu sai hoặc một rủi ro kỹ thuật ai đó nhìn thấy mà người khác không thấy. Giá trị thật của Planning Poker không nằm ở con số cuối, mà ở cuộc thảo luận nó tạo ra.
T-shirt sizing (S/M/L/XL). Khi cần estimate nhanh cho một roadmap quý gồm hàng chục hạng mục lớn, không ai đi chia story point từng cái. T-shirt sizing cho phép phân loại thô: tính năng này là M, cái kia là XL. Phù hợp cho giai đoạn lập kế hoạch cấp cao, khi bạn chỉ cần biết "cái này có khả thi trong quý không" chứ chưa cần con số chính xác.
Three-point estimation (PERT). Thay vì một con số, bạn lấy ba: Optimistic (O — thuận lợi nhất), Most likely (M — khả năng cao nhất), và Pessimistic (P — tệ nhất). Estimate kỳ vọng = (O + 4M + P) / 6. Kỹ thuật này ép người estimate phải nghĩ tới kịch bản xấu, kéo con số ra khỏi vùng lạc quan, và cho bạn một dải thay vì một điểm. Rất hữu ích khi báo cáo lên trên: "tính năng này mất từ 6 đến 14 tuần, kỳ vọng khoảng 9 tuần."
Velocity và empirical forecasting. Đây là cách trưởng thành nhất. Thay vì hỏi "việc này mất bao lâu", bạn nhìn vào lịch sử: trong các sprint qua, team này hoàn thành trung bình bao nhiêu story point mỗi sprint (velocity)? Nếu backlog còn 80 điểm và velocity là 20 điểm/sprint, thì cần khoảng 4 sprint. Dữ liệu thực tế đáng tin hơn nhiều so với cảm giác chủ quan. Các công cụ hiện đại còn dùng mô phỏng Monte Carlo trên dữ liệu lịch sử để cho ra xác suất: "70% khả năng xong trước 15/8, 90% khả năng xong trước 30/8."
Estimate là một dải, không phải một điểm
Đây là chuyển dịch tư duy quan trọng nhất của bài. Một estimate tốt không bao giờ là một con số duy nhất ("3 tuần"). Nó là một dải kèm mức độ tự tin ("70% khả năng trong 3-5 tuần"). Khi PM trình bày estimate dạng dải cho business, bạn đang giáo dục họ về sự bất định, và bảo vệ chính mình khỏi việc bị quy trách nhiệm khi con số đơn lẻ không thành hiện thực.
Tình huống thực tế
Ví dụ 1: Cú trễ deadline của một sàn TMĐT tại TP.HCM
Một công ty thương mại điện tử (gọi là ShopViet) lên kế hoạch tích hợp thanh toán trả góp qua thẻ tín dụng để kịp mùa sale 11/11. PM hỏi tech lead, nhận được câu trả lời nhanh: "Tích hợp API ngân hàng thôi mà, khoảng 3 tuần." PM mừng rỡ, cam kết với ban giám đốc ngày ra mắt là 1/11, và marketing bắt đầu chạy quảng cáo "trả góp 0%".
Thực tế: dự án mất 11 tuần. Vì sao? Tầng unknown unknowns ập đến. Mỗi ngân hàng (Sacombank, Techcombank, VPBank) có một spec API khác nhau, không có chuẩn chung. Môi trường sandbox của một ngân hàng down liên tục. Bộ phận pháp lý của ngân hàng yêu cầu ký phụ lục hợp đồng về chia sẻ dữ liệu, mất 3 tuần phê duyệt. Đội security nội bộ chặn release vì lo ngại lưu trữ thông tin thẻ chưa đạt chuẩn PCI.
Bài học: Con số "3 tuần" của tech lead chỉ tính phần code happy path mà anh ấy nhìn thấy. Nếu PM hiểu về cone of uncertainty, lẽ ra phải hỏi: "Đây là lần đầu ta tích hợp ngân hàng phải không? Vậy đây là estimate giai đoạn sớm, độ lệch có thể rất lớn. Trước khi cam kết với marketing, hãy dành 1 tuần làm spike kỹ thuật để giảm bất định." Một tuần spike sẽ phơi bày vấn đề hợp đồng pháp lý ngay từ đầu.
Ví dụ 2: Grab và sức mạnh của velocity
Tại các công ty quy mô lớn như Grab, các team sản phẩm trưởng thành gần như không còn hỏi "việc này mất bao lâu" theo kiểu phỏng đoán. Một squad làm tính năng đặt xe ổn định có velocity khoảng 30-35 story point mỗi sprint hai tuần, đo được qua sáu tháng dữ liệu. Khi product lead muốn biết khi nào một epic 120 điểm sẽ xong, họ không hỏi cảm tính — họ chia 120 cho velocity trung bình, cộng thêm bộ đệm cho sự dao động, rồi báo cáo dưới dạng xác suất: "khoảng 4 sprint, tức 8 tuần, với độ tin cậy 80%."
Điều thú vị là khi một engineer mới ước lượng quá lạc quan ("cái này 2 điểm thôi"), dữ liệu velocity lịch sử sẽ tự động điều chỉnh: nếu mỗi sprint team luôn cam kết 40 điểm nhưng chỉ giao được 30, thì kế hoạch dựa trên velocity thực vẫn đúng, bất kể từng estimate lẻ có lạc quan tới đâu.
Bài học: Estimate của cá nhân luôn nhiễu, nhưng velocity của team qua nhiều sprint thì ổn định một cách đáng ngạc nhiên. Là PM, hãy đầu tư vào việc đo velocity và dùng nó để forecast, thay vì tin vào cảm giác của một người trong một cuộc họp.
Ví dụ 3: Planning Poker phơi bày hiểu nhầm requirement
Một fintech tại Singapore triển khai tính năng "chuyển tiền theo lịch định kỳ". Trong buổi Planning Poker, một backend engineer giơ thẻ 3, trong khi một engineer khác giơ 13. Chênh lệch lớn buộc cả hai phải giải thích. Hóa ra người giơ 3 nghĩ đây chỉ là tạo một bản ghi lịch và một cron job đơn giản. Người giơ 13 thì nhìn thấy hàng loạt vấn đề: xử lý khi tài khoản không đủ tiền vào ngày đến hạn, retry thế nào, thông báo cho user ra sao, xử lý timezone, và tuân thủ quy định chống rửa tiền cho giao dịch tự động.
Nếu không có Planning Poker, team đã estimate 3 điểm và lao vào code, rồi vỡ trận giữa chừng.
Bài học: Giá trị lớn nhất của estimation đôi khi không phải con số, mà là cuộc đối thoại bóc tách rủi ro mà nó kích hoạt. Một PM giỏi không cắt ngang "thôi chốt 5 điểm đi cho nhanh" — mà lắng nghe cuộc tranh luận đó để hiểu phạm vi thật của công việc.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng khi cần đưa ra một cam kết về thời gian cho business:
Bước 1 — Xác định bạn đang ở đâu trong cone of uncertainty. Requirement đã rõ chưa? Công nghệ đã quen chưa? Đối tác bên ngoài đã làm việc bao giờ chưa? Càng nhiều "chưa", độ bất định càng cao, và bạn càng không nên đưa con số cứng.
Bước 2 — Giảm bất định trước khi estimate, nếu rủi ro cao. Với những phần nhiều unknown unknowns, đề xuất một spike (một khoảng thời gian giới hạn, ví dụ 2-3 ngày, chỉ để nghiên cứu và làm prototype). Spike biến "unknown unknowns" thành "known unknowns" — và đó là tiền đề để estimate có ý nghĩa.
Bước 3 — Chọn kỹ thuật phù hợp với mục đích. Roadmap quý cấp cao → T-shirt sizing. Sprint planning chi tiết → story point + Planning Poker. Báo cáo deadline rủi ro cao lên ban lãnh đạo → three-point estimation để có dải. Forecast dài hạn cho team ổn định → velocity-based.
Bước 4 — Để engineer estimate, bạn đặt câu hỏi. Không bao giờ PM tự áp con số. Vai trò của bạn là hỏi những câu khơi rủi ro: "Phần nào khiến em lo nhất? Có phụ thuộc team khác không? Nếu kịch bản xấu nhất xảy ra thì sao?"
Bước 5 — Cộng buffer một cách minh bạch, đúng chỗ. Đừng nhân đôi mọi thứ một cách mù quáng. Hãy thêm buffer vào nơi bất định cao (tích hợp bên ngoài, công nghệ mới) và giữ buffer ở cấp dự án thay vì giấu trong từng task — vì buffer giấu trong task thường bị "xài hết" theo định luật Parkinson (công việc nở ra để lấp đầy thời gian cho phép).
Bước 6 — Trình bày dưới dạng dải kèm độ tin cậy. Thay vì "xong ngày 1/11", hãy nói "70% khả năng xong trong khoảng 25/10 đến 8/11; nếu khâu tích hợp ngân hàng phát sinh, có thể trễ thêm 2 tuần." Điều này giáo dục business và bảo vệ uy tín của bạn.
Bước 7 — Theo dõi và cập nhật liên tục. Estimate không phải lời tiên tri một lần. Mỗi sprint, đối chiếu thực tế với dự báo, cập nhật velocity, và thông báo lại nếu dải thời gian thay đổi. Re-forecast sớm và thường xuyên luôn tốt hơn một "bất ngờ" vào phút chót.
Lỗi thường gặp & mẹo
Lỗi: Coi estimate là cam kết. Đây là sai lầm chết người. Estimate là một dự báo dựa trên thông tin hiện có; commitment là một lời hứa. Khi PM lấy estimate thô từ kỹ sư rồi biến nó thành deadline ký với khách hàng, bạn đã đổ rủi ro bất định lên đầu mình. Mẹo: luôn phân biệt rõ trong giao tiếp "đây là estimate" và "đây là cam kết", và chỉ cam kết khi đã ở phần hẹp của cone of uncertainty.
Lỗi: Ép kỹ sư estimate thấp xuống. Một số PM gây áp lực "sao lâu thế, làm nhanh hơn được không" cho tới khi con số nghe vừa tai. Kết quả: kỹ sư miễn cưỡng gật đầu, rồi trễ — và lần sau họ sẽ phóng đại estimate để tự vệ. Mẹo: tạo môi trường an toàn để estimate trung thực; thưởng cho độ chính xác, không thưởng cho sự lạc quan.
Lỗi: Quên các chi phí "vô hình". Họp, code review, onboarding người mới, hỗ trợ on-call, sửa bug tồn đọng, ngày lễ Tết. Một kỹ sư hiếm khi có 5 ngày làm việc thuần code mỗi tuần — thực tế thường chỉ 3-3.5 ngày. Mẹo: áp dụng hệ số "focus factor" (thường 0.6-0.7) khi quy đổi từ effort sang lịch.
Lỗi: Không tính dependency giữa các team. Tính năng của bạn cần API từ team Platform, nhưng team đó đang bận. Estimate của riêng team bạn có thể đúng, nhưng thời gian giao hàng thực tế bị kéo dài vì chờ đợi. Mẹo: vẽ rõ dependency và estimate cả thời gian phối hợp, không chỉ thời gian code.
Mẹo vàng: Padding minh bạch tốt hơn padding bí mật. Nếu bạn cần thêm thời gian dự phòng, hãy nói rõ lý do với business ("chúng tôi thêm 2 tuần buffer vì đây là lần đầu tích hợp đối tác này"). Buffer minh bạch xây dựng lòng tin; buffer giấu giếm khi bị lộ sẽ phá hủy nó.
Bài tập thực hành
- Bóc tách một estimate quá lạc quan. Lấy một task mà một kỹ sư trong team bạn vừa nói "khoảng 2 ngày là xong". Hãy liệt kê ít nhất 6 hoạt động overhead không được tính trong "2 ngày" đó (ví dụ: code review, viết test, deploy, đợi QA, họp đồng bộ, fix bug staging). Ước lượng lại thời gian thực tế sau khi cộng overhead.
- Áp dụng three-point estimation. Chọn một tính năng sắp tới trong roadmap của bạn. Hỏi (hoặc tự ước lượng) ba con số: Optimistic, Most likely, Pessimistic. Tính estimate kỳ vọng theo công thức (O + 4M + P)/6. So sánh con số này với con số "trực giác" ban đầu — chúng lệch nhau bao nhiêu?
- Viết lại một cam kết theo dạng dải. Lấy một câu kiểu "Tính năng X sẽ ra mắt ngày 15/8" và viết lại thành một phát biểu có dải thời gian và độ tin cậy, kèm nêu rõ rủi ro lớn nhất có thể làm trễ. Tự hỏi: bản nào dễ bảo vệ hơn trước CEO khi có sự cố?
- Phân tích một lần estimate sai trong quá khứ. Nhớ lại một dự án từng trễ deadline mà bạn biết. Nó trễ vì planning fallacy (quên overhead), unknown unknowns (phát sinh ngoài dự kiến), hay dependency bên ngoài? Việc phân loại đúng nguyên nhân giúp bạn phòng tránh đúng chỗ cho lần sau.
Tóm tắt
Estimation trong phần mềm luôn sai, và đó không phải lỗi của ai cả — đó là bản chất của việc dự đoán công việc sáng tạo có nhiều bất định. Là một Technical PM, mục tiêu của bạn không phải làm cho estimate "chính xác" (bất khả), mà là quản lý sự bất định một cách chuyên nghiệp.
Hãy ghi nhớ những điểm cốt lõi: planning fallacy khiến chúng ta luôn lạc quan và quên overhead; unknown unknowns là rủi ro lớn nhất và chỉ giảm được bằng spike, không bằng suy nghĩ kỹ hơn; cone of uncertainty nhắc bạn rằng estimate giai đoạn sớm có thể lệch tới ±400%, nên đừng đóng đinh nó thành deadline cứng. Về kỹ thuật, hãy chọn đúng công cụ cho đúng mục đích: T-shirt sizing cho roadmap, story point và Planning Poker cho sprint, three-point cho báo cáo rủi ro cao, và velocity-based forecasting cho dự báo trưởng thành nhất.
Trên hết, hãy luôn phân biệt estimate (một dự báo) với commitment (một lời hứa), trình bày thời gian dưới dạng dải kèm độ tin cậy thay vì một con số đơn lẻ, và minh bạch về buffer. Khi bạn làm được những điều này, bạn không chỉ tránh được những cú trễ deadline bẽ bàng — bạn còn xây dựng được lòng tin với cả engineer lẫn business, thứ tài sản quý giá nhất của một Technical PM.