Mở đầu — vì sao bài này quan trọng
"Khi nào xong?"
Chỉ ba từ, nhưng đây có lẽ là câu hỏi khiến nhiều engineer cảm thấy bực bội, lúng túng và bị dồn vào chân tường nhất trong sự nghiệp. Bạn ghét nó vì bạn biết một sự thật mà người hỏi thường không muốn nghe: phần mềm là thứ chưa từng được xây, và bạn không thể biết chắc thời gian hoàn thành của một thứ chưa từng tồn tại. Nhưng phía bên kia — PM, sếp, khách hàng, sales — lại thực sự cần con số đó. Họ cần nó để lên kế hoạch marketing, để hứa với khách, để phân bổ ngân sách, để báo cáo lên cấp trên.
Đây là một xung đột cấu trúc, không phải xung đột cá nhân. Và cách nhiều engineer xử lý nó lại làm mọi thứ tệ hơn: hoặc là buông một con số bừa ("chắc khoảng 2 tuần") rồi sau đó khổ sở vì bị chốt cứng vào lời hứa hớ hênh đó, hoặc là né tránh ("khó nói lắm, còn tùy nhiều thứ") khiến stakeholder thấy bạn không đáng tin và không hợp tác.
Bài học này không dạy bạn cách ước lượng chính xác hơn — đó là chuyện của kỹ năng kỹ thuật và kinh nghiệm. Bài này dạy bạn cách giao tiếp về ước lượng và sự không chắc chắn (uncertainty) một cách chuyên nghiệp: làm sao để đưa ra con số mà không tự bắn vào chân mình, làm sao để truyền đạt rủi ro mà không bị coi là kẻ né việc, và làm sao để biến câu hỏi "khi nào xong?" từ một cái bẫy thành một cuộc đối thoại lành mạnh. Đây là kỹ năng phân biệt một IC (individual contributor) giỏi kỹ thuật với một IC mà cả team và management đều tin tưởng.
Khái niệm cốt lõi
Estimate không phải là lời hứa
Sai lầm nền tảng nhất: coi ước lượng (estimate) và cam kết (commitment) là một. Estimate là dự đoán tốt nhất dựa trên thông tin hiện có. Commitment là lời hứa bạn sẽ giao đúng hạn. Khi bạn nói "khoảng 2 tuần", trong đầu bạn đó là estimate; nhưng trong tai stakeholder, đó là commitment. Khoảng cách nhận thức này chính là nguồn gốc của gần như mọi mâu thuẫn về deadline.
Nhiệm vụ giao tiếp của bạn là làm cho khoảng cách này hiện rõ ra, thay vì để nó âm thầm gây hiểu lầm. Mỗi lần đưa estimate, bạn cần ngầm (hoặc rõ ràng) trả lời: đây là dự đoán hay đây là cam kết? Và nếu là dự đoán, thì độ tin cậy của nó là bao nhiêu?
Range estimate: công cụ số một
Con người tự nhiên muốn một con số duy nhất (point estimate): "3 ngày". Nhưng point estimate là lời nói dối tinh vi nhất trong nghề — nó che giấu toàn bộ sự không chắc chắn. Công cụ mạnh nhất để giao tiếp uncertainty là range estimate (ước lượng theo khoảng): thay vì "3 ngày", bạn nói "nhanh nhất 2 ngày, nhiều khả năng 4 ngày, xấu nhất 8 ngày".
Range làm được ba việc cùng lúc. Thứ nhất, nó trung thực — nó thừa nhận bạn không biết chắc. Thứ hai, nó truyền tải mức độ không chắc chắn: khoảng "2–8 ngày" nói với người nghe rằng việc này rủi ro cao hơn nhiều so với "3–4 ngày". Thứ ba, nó bảo vệ bạn — khi bạn giao ở ngày thứ 6, bạn vẫn nằm trong khoảng đã cam kết, không phải là "trễ".
Một biến thể hữu ích là mô hình ba điểm kiểu PERT: Optimistic (lạc quan, mọi thứ thuận lợi), Most Likely (khả năng cao nhất), Pessimistic (bi quan, gặp trục trặc). Con số bạn đưa cho stakeholder không nên là điểm lạc quan — đó là lỗi kinh điển. Hãy đưa điểm most likely, và luôn kèm điểm pessimistic để họ biết mặt xấu.
Confidence level: gắn độ tự tin vào con số
Một kỹ thuật giao tiếp cực kỳ hiệu quả là gắn mức độ tự tin vào ước lượng: "Tôi tự tin 90% việc này xong trong 2 tuần" khác hoàn toàn với "Tôi tự tin 50% việc này xong trong 2 tuần". Cùng một con số 2 tuần, nhưng thông điệp về rủi ro hoàn toàn khác. Khi bạn nói confidence thấp, bạn đang mời stakeholder cùng bạn giảm rủi ro — bằng cách cắt scope, cho thêm thời gian điều tra, hoặc chấp nhận buffer.
Cone of Uncertainty: độ chính xác tăng theo thời gian
Có một khái niệm kinh điển tên là Cone of Uncertainty (hình nón bất định). Ở giai đoạn đầu dự án — khi mới có ý tưởng, chưa design, chưa spike — sai số ước lượng có thể lên tới 4 lần (một việc "1 tuần" thực tế có thể là 3 ngày hoặc 4 tuần). Càng đi sâu vào dự án, càng làm rõ yêu cầu, thiết kế xong kiến trúc, thì hình nón càng thu hẹp và ước lượng càng chính xác.
Ý nghĩa giao tiếp: đừng để bị ép đưa con số chính xác ở giai đoạn quá sớm. Thay vào đó, hãy nói: "Ở giai đoạn này tôi chỉ đưa được con số cấp độ tháng. Cho tôi 2 ngày spike để làm rõ kiến trúc, sau đó tôi sẽ đưa con số cấp độ tuần chính xác hơn." Đây là cách trả lời vừa trung thực, vừa cho thấy bạn có lộ trình rõ ràng.
Phân biệt "không biết vì thiếu thông tin" và "không biết vì bản chất rủi ro"
Có hai loại uncertainty và bạn phải giao tiếp chúng khác nhau. Loại một là thiếu thông tin — bạn chưa đọc code cũ, chưa rõ yêu cầu. Loại này giải quyết được bằng cách bỏ công điều tra, và bạn nên chủ động nói "cho tôi thời gian tìm hiểu". Loại hai là rủi ro cố hữu — phụ thuộc vào bên thứ ba, tích hợp với hệ thống legacy chưa ai hiểu, công nghệ mới chưa dùng bao giờ. Loại này không biến mất dù bạn điều tra bao nhiêu, và bạn phải giao tiếp nó như một rủi ro cần được quản lý, không phải một con số cần được chốt.
Tình huống thực tế
Ví dụ 1: Cái bẫy "khoảng 2 tuần" tại một startup fintech ở TP.HCM
Minh là backend engineer tại một startup ví điện tử ở Quận 1. Trong một cuộc họp, PM hỏi khi nào tính năng "chia hóa đơn nhóm" xong. Minh, muốn tỏ ra hợp tác, buột miệng: "Chắc khoảng 2 tuần." PM ghi ngay vào roadmap, và tuần sau team marketing đã bắt đầu chuẩn bị chiến dịch ra mắt tính năng vào đúng ngày thứ 14.
Vấn đề: khi bắt tay vào làm, Minh phát hiện tính năng chia hóa đơn phải tích hợp với cổng thanh toán của bên thứ ba, mà tài liệu API của họ đã lỗi thời, và mỗi lần hỏi support họ trả lời sau 2–3 ngày làm việc. Đến ngày thứ 14, tính năng mới xong 60%. Marketing phải hoãn chiến dịch đã tốn tiền chạy quảng cáo. Minh bị nhìn như người "làm chậm", dù thực chất anh đã làm việc rất chăm chỉ.
Diễn giải: Minh mắc hai lỗi. Một, anh đưa point estimate ("2 tuần") thay vì range. Hai, con số của anh dựa trên kịch bản lạc quan, chưa tính đến rủi ro tích hợp bên thứ ba mà anh thực ra đã lờ mờ biết. Nếu anh nói: "Nếu chỉ là logic nội bộ thì khoảng 1 tuần. Nhưng việc này phải tích hợp cổng thanh toán bên ngoài, mà tôi chưa biết API của họ ổn định thế nào — nên khoảng an toàn là 2 đến 4 tuần, và tôi tự tin khoảng 60%. Cho tôi 2 ngày để test thử API của họ, sau đó tôi sẽ chốt con số chính xác hơn," thì cả marketing lẫn PM đã có quyết định khác — và không ai phải chịu thiệt.
Bài học: đừng bao giờ đưa con số dựa trên kịch bản đẹp nhất, và luôn nói ra rủi ro bạn đã nhận ra, ngay cả khi nó khiến con số của bạn xấu đi.
Ví dụ 2: Range estimate cứu một team ở công ty gia công phần mềm Đà Nẵng
Hương là tech lead tại một công ty outsourcing ở Đà Nẵng làm cho khách hàng Nhật. Khách hỏi thời gian xây dựng module báo cáo. Thay vì đưa một con số, Hương gửi email với bảng: "Optimistic: 3 tuần (nếu dữ liệu đầu vào sạch và không đổi yêu cầu). Most likely: 5 tuần. Pessimistic: 8 tuần (nếu phát sinh yêu cầu về xuất Excel phức tạp và phải làm sạch dữ liệu legacy)." Kèm theo, cô ghi rõ ba giả định (assumptions) mà con số này dựa vào.
Khách hàng Nhật, vốn quen làm việc chi tiết, phản hồi rằng họ chắc chắn sẽ cần xuất Excel phức tạp. Nhờ đó, ngay từ đầu hai bên thống nhất mốc 8 tuần thay vì để nó phát sinh giữa chừng gây tranh cãi. Dự án về đích ở tuần thứ 7, khách rất hài lòng vì "sớm hơn dự kiến".
Diễn giải: cùng một khối lượng công việc, nhưng cách giao tiếp của Hương biến một rủi ro tiềm ẩn thành một cuộc thảo luận rõ ràng ngay từ đầu. Việc nêu assumptions đóng vai trò then chốt — nó cho phép stakeholder xác nhận hoặc bác bỏ các giả định, và chính họ giúp Hương chọn đúng điểm trong range. Đây là kỹ thuật "estimate có điều kiện": con số của tôi đúng nếu những giả định này đúng.
Bài học: range estimate kèm assumptions không chỉ bảo vệ bạn, nó còn kéo stakeholder vào cùng chịu trách nhiệm về quyết định — vì họ là người xác nhận giả định.
Ví dụ 3: Cập nhật lại estimate giữa chừng thay vì im lặng
Tại một công ty SaaS ở Hà Nội, Tú nhận ước lượng ban đầu 3 tuần cho việc migrate hệ thống authentication. Đến giữa tuần 2, anh phát hiện có hàng loạt edge case về tài khoản cũ mà không ai lường trước. Ước lượng mới thực tế là 5 tuần.
Nhiều engineer trong tình huống này chọn im lặng, hy vọng "cày" bù kịp. Tú thì khác. Anh nhắn ngay cho manager: "Cập nhật về việc migrate auth: tôi phát hiện khoảng 4 loại tài khoản legacy cần xử lý riêng mà estimate ban đầu chưa tính. Con số cập nhật là 5 tuần thay vì 3. Nguyên nhân, phương án đang cân nhắc, và nếu cần gấp, chúng ta có thể tạm bỏ qua nhóm tài khoản thứ 4 (chỉ chiếm 2% người dùng) để về đúng hạn cũ — tôi đề xuất cách này." Manager cảm ơn vì được biết sớm, chọn phương án cắt scope, và dự án về đích đúng hạn ban đầu với 98% người dùng được phục vụ.
Diễn giải: uncertainty không dừng lại ở lúc đưa estimate — nó cần được cập nhật liên tục khi thông tin mới xuất hiện. "Bad news early is good news" (tin xấu báo sớm là tin tốt). Điều làm Tú chuyên nghiệp là anh không chỉ báo con số mới, mà đi kèm nguyên nhân và một lựa chọn khả thi để stakeholder ra quyết định.
Bài học: một estimate là ảnh chụp tại một thời điểm. Trách nhiệm giao tiếp của bạn kéo dài suốt dự án, đặc biệt là báo lệch sớm và luôn kèm phương án.
Hướng dẫn từng bước
Khi ai đó hỏi "khi nào xong?", hãy đi theo quy trình sau thay vì buột miệng một con số:
- Đừng trả lời ngay bằng con số. Nếu bị hỏi bất ngờ, hãy nói: "Để tôi trả lời chính xác, tôi cần khoảng nửa ngày xem qua độ phức tạp. Chiều nay tôi gửi con số kèm giả định." Việc mua thời gian này gần như luôn được chấp nhận và tránh cho bạn con số bừa.
- Chia nhỏ công việc. Ước lượng một khối lớn luôn sai nhiều hơn tổng của các phần nhỏ. Tách thành các đầu việc con, ước lượng từng phần, rồi cộng lại — sai số sẽ trung hòa bớt.
- Xác định các assumptions và rủi ro. Việc này phụ thuộc vào gì? Bên thứ ba nào? Code cũ nào bạn chưa hiểu? Viết chúng ra rõ ràng.
- Đưa ra range, không phải point. Optimistic / Most likely / Pessimistic. Đưa most likely làm con số chính, luôn kèm pessimistic.
- Gắn confidence level. "Tôi tự tin khoảng 70% với con số này." Nếu confidence dưới 50%, đó là tín hiệu cần spike (điều tra) trước khi cam kết.
- Đề xuất bước giảm bất định. "Cho tôi 1 ngày làm proof-of-concept phần rủi ro nhất, sau đó tôi sẽ thu hẹp range." Điều này biến bạn từ người báo tin xấu thành người đề xuất giải pháp.
- Chốt lại bằng văn bản. Ghi estimate và giả định vào ticket/email. Lời nói bay đi; văn bản giúp cả hai bên nhớ đúng bối cảnh.
- Cập nhật khi có thông tin mới. Đặt lịch tự nhắc: nếu ước lượng lệch quá X%, báo ngay kèm nguyên nhân và phương án.
Lỗi thường gặp & mẹo
Lỗi: Đưa con số lạc quan để làm hài lòng người hỏi. Bạn nghĩ nói con số nhỏ sẽ khiến sếp vui. Thực tế, khi bạn trễ, bạn mất uy tín nhiều hơn cả lợi ích ngắn hạn ban đầu. Mẹo: luôn đưa most likely, không bao giờ đưa optimistic làm con số chính.
Lỗi: Cộng buffer âm thầm. Bạn nghĩ 3 ngày nhưng nói 5 ngày để "an toàn", mà không nói ra. Vấn đề: nếu ai cũng làm vậy, tổng estimate của dự án phồng lên vô lý và mất niềm tin. Mẹo: buffer nên minh bạch — nói "3 ngày most likely, tôi thêm buffer thành 5 vì có rủi ro X" thay vì giấu.
Lỗi: Để bị "thương lượng" con số. Sếp hỏi "làm trong 1 tuần được không?" và bạn gật cho xong. Nhưng estimate là dữ kiện kỹ thuật, không phải thứ để mặc cả. Mẹo: tách bạch — "Thời gian thì không thương lượng được, nhưng scope thì có. Nếu cần trong 1 tuần, ta bỏ được phần nào?"
Lỗi: Trả lời "không biết" mà không kèm gì. Trung thực nhưng vô dụng và làm stakeholder bực. Mẹo: luôn biến "không biết" thành "chưa biết, nhưng đây là cách tôi sẽ biết và khi nào tôi sẽ có câu trả lời".
Mẹo: Dùng đơn vị phù hợp với độ chắc chắn. Ước lượng cấp giờ, ngày, tuần, tháng, quý — hãy chọn đơn vị thô tương ứng với mức bất định. Nói "khoảng 1 quý" ở giai đoạn ý tưởng trung thực hơn nhiều so với "khoảng 63 ngày".
Mẹo: Ghi lại estimate cũ và đối chiếu. Sau mỗi task, so sánh estimate với thực tế. Đây là cách duy nhất để cải thiện độ chính xác và để biết "hệ số lạc quan" của riêng bạn (nhiều engineer thường xuyên ước lượng thấp hơn thực tế khoảng 1.5–2 lần).
Bài tập thực hành
- Viết lại một estimate. Nhớ lại một lần bạn đưa point estimate ("khoảng X ngày"). Viết lại nó thành một câu range hoàn chỉnh: optimistic / most likely / pessimistic, kèm confidence level và ít nhất hai assumptions.
- Kịch bản bị dồn ép. Soạn sẵn 2–3 câu trả lời cho tình huống sếp hỏi "làm trong 1 tuần được không?" khi bạn nghĩ cần 3 tuần. Câu trả lời phải: (a) không gật bừa, (b) đưa scope ra để thương lượng thay vì thời gian.
- Phân loại uncertainty. Với task tiếp theo trong công việc thật, liệt kê mọi nguồn bất định và phân loại: cái nào giải quyết được bằng điều tra, cái nào là rủi ro cố hữu. Với nhóm điều tra được, viết ra bước spike cụ thể.
- Theo dõi độ lệch. Trong 2 tuần tới, với mỗi task ghi lại estimate ban đầu và thời gian thực tế. Cuối kỳ tính hệ số lệch trung bình của bạn — con số này sẽ khiến bạn bất ngờ và giúp bạn hiệu chỉnh các estimate sau.
Tóm tắt
"Khi nào xong?" là câu hỏi không thể né, nên thay vì sợ nó, hãy học cách trả lời chuyên nghiệp. Cốt lõi: estimate là dự đoán, không phải lời hứa — và nhiệm vụ của bạn là làm cho sự không chắc chắn hiện rõ ra thay vì che giấu. Hãy dùng range estimate (optimistic / most likely / pessimistic) thay cho point estimate, gắn confidence level để truyền tải mức rủi ro, và luôn nêu assumptions để kéo stakeholder cùng chịu trách nhiệm về quyết định. Đừng đưa con số lạc quan để làm vừa lòng ai; khi bị ép, hãy thương lượng scope chứ không thương lượng thời gian. Và nhớ rằng uncertainty cần được cập nhật liên tục — báo lệch sớm kèm nguyên nhân và phương án luôn tốt hơn im lặng rồi trễ hạn. Làm được những điều này, bạn không chỉ ước lượng đúng hơn theo thời gian, mà quan trọng hơn, bạn trở thành người mà cả team và management tin tưởng khi cần một câu trả lời trung thực.