title: "Quản trị kỳ vọng về thời gian: Cách đưa ra deadline thực tế mà khách vẫn đồng ý"
series: "Thư viện Kỹ năng BA·PO·EA: 45 Bài học Thực chiến"
part: "Phần 2 — Kỹ năng Thực chiến"
skill_number: 23
audience: "BA, PO, EA & vai trò làm việc trực tiếp với khách hàng"
reading_time: "9 phút đọc"
tags:

• quan-tri-ky-vong
• uoc-luong-du-an
• deadline
• stakeholder-management
• ba-skills

Quản trị kỳ vọng về thời gian: Cách đưa ra deadline thực tế mà khách vẫn đồng ý

Bạn đã bao giờ ngồi trong phòng họp, nghe khách hàng nói "3 tuần là xong, đúng không?" — trong khi đầu bạn biết rõ con số thật gần với 6 tuần hơn? Nói "vâng" thì dễ nhưng chắc chắn vỡ trận sau này; nói "không" ngay lập tức thì dễ mất niềm tin ngay từ đầu. Vấn đề không nằm ở chỗ ước lượng sai, mà ở chỗ ta thường đưa ra MỘT con số duy nhất cho một việc vốn dĩ đầy bất định.

🎯 Kỹ thuật cốt lõi: Ước lượng theo khoảng (Range Estimate)

Thay vì cam kết một con số cứng ("3 tuần"), BA/PO/EA có kinh nghiệm luôn đưa ra một khoảng thời gian gắn với xác suất và lý do rủi ro đi kèm. Kỹ thuật này gồm 4 thành phần:

1. Điểm lạc quan (Best case) — nếu mọi thứ suôn sẻ, không có rủi ro nào xảy ra, không phát sinh yêu cầu. Đây là con số khách hàng thường nghe được từ tin đồn hoặc ước tính vội của sales.
2. Điểm khả dĩ nhất (Most likely) — dựa trên dữ liệu lịch sử (velocity của team, độ phức tạp tương tự đã làm trước đây), đây là con số bạn thực sự tin tưởng.
3. Điểm bi quan (Worst case) — nếu các rủi ro đã biết trước xảy ra: bên thứ ba trễ tích hợp, khách đổi yêu cầu, nhân sự nghỉ ốm, môi trường UAT chưa sẵn sàng.
4. Danh sách giả định & rủi ro đi kèm — mỗi con số trong khoảng phải gắn với ĐIỀU KIỆN cụ thể, không phải nói suông. Ví dụ: "6 tuần nếu API bên thứ ba bàn giao đúng hạn 20/8; nếu trễ, cộng thêm số ngày trễ tương ứng."

Công thức đơn giản dùng được ngay (biến thể của PERT — Program Evaluation and Review Technique):

Ước lượng kỳ vọng = (Lạc quan + 4 × Khả dĩ nhất + Bi quan) / 6

Ví dụ: Lạc quan 15 ngày, Khả dĩ nhất 20 ngày, Bi quan 35 ngày →
(15 + 4×20 + 35) / 6 = 130/6 ≈ 21.7 ngày.

Điểm mấu chốt: con số này KHÔNG dùng để tranh cãi đúng/sai với khách, mà dùng để CHUYỂN cuộc trò chuyện từ "cam kết một ngày" sang "quản trị rủi ro cùng nhau". Khi khách hiểu rủi ro nào kéo deadline ra xa, họ có động lực giúp bạn loại bỏ rủi ro đó (ví dụ thúc bên thứ ba giao API đúng hạn) thay vì chỉ ép bạn cam kết suông.

Bối cảnh (Situation)

Tình huống dưới đây là minh hoạ tổng hợp từ các dự án phần mềm phổ biến tại Việt Nam, không phải case cụ thể của một công ty có thật.

Chị H., BA/PO của một dự án xây dựng hệ thống quản lý bán hàng đa kênh cho một chuỗi bán lẻ vừa, đang trong buổi kick-off giai đoạn 2 — module tích hợp với ba sàn thương mại điện tử để đồng bộ tồn kho theo thời gian thực.

Anh T., giám đốc vận hành phía khách hàng, mở đầu cuộc họp bằng một câu chắc nịch: "Bên anh cần xong trước 30/8 để kịp mùa sale tháng 9. Team kỹ thuật của em nói 4 tuần là đủ đúng không? Anh đã báo với sếp anh là tháng 9 chạy được rồi."

Chị H. biết ngay đây là con số bị neo (anchor) từ một cuộc trao đổi không chính thức trước đó giữa sales bên mình và anh T., chưa qua bất kỳ phân tích kỹ thuật nào. Trong khi đó, team dev vừa họp nội bộ tuần trước và ước tính riêng phần tích hợp API của một trong ba sàn (do tài liệu API của sàn đó rất sơ sài và lịch sử từng có đối tác khác mất 3 tuần chỉ để làm việc với đội hỗ trợ kỹ thuật của sàn) có thể kéo dài bất định.

Thách thức (Task)

Cái khó của chị H. không phải là "tính toán ra con số đúng" — team đã có ước lượng nội bộ khá rõ ràng. Cái khó là:

• Con số "4 tuần" đã được anh T. báo cáo lên cấp trên của anh ấy, nghĩa là bây giờ nó không còn là ước lượng kỹ thuật nữa mà đã thành cam kết chính trị. Bác bỏ nó đồng nghĩa với việc khiến anh T. mất mặt với sếp.
• Nếu chị H. gật đầu theo 4 tuần chỉ để giữ hoà khí, rủi ro tích hợp API sàn thứ ba (vốn phụ thuộc vào bên ngoài, team không kiểm soát được) gần như chắc chắn sẽ đẩy dự án trễ — và lúc đó, người chịu trách nhiệm giải trình không phải anh T. mà là chính team dự án.
• Nếu chị H. nói thẳng "8 tuần" mà không giải thích được lý do thuyết phục, khách hàng dễ diễn giải thành "team này chậm, không quyết đoán" — nhất là khi timeline gắn với một cột mốc kinh doanh có ý nghĩa thật (mùa sale tháng 9).
• Cửa sổ thời gian để đàm phán lại kỳ vọng chỉ có trong buổi họp này — nếu để anh T. về báo cáo "đã chốt 4 tuần" thêm một lần nữa, việc renegotiate sau này sẽ khó gấp nhiều lần.

Hành động (Action)

Chị H. không phản bác con số 4 tuần ngay lập tức, mà xử lý theo trình tự sau:

Bước 1 — Ghi nhận trước, không bác bỏ ngay. Chị H. mở lời: "Em hiểu mốc 30/8 rất quan trọng vì gắn với mùa sale tháng 9, anh có thể chia sẻ thêm lý do mốc đó không thể lùi được không?" — câu hỏi này vừa thể hiện tôn trọng áp lực kinh doanh thật của khách, vừa lấy thêm dữ liệu để sau này dùng làm căn cứ đàm phán (nếu mốc thực sự cứng, phải đàm phán về SCOPE thay vì thời gian).

Bước 2 — Trình bày ước lượng theo khoảng, kèm dữ liệu cụ thể, không phải cảm tính. Chị H. đưa ra bảng nhanh trên màn hình chiếu:

Chị H. nói rõ: "Con số 4 tuần không sai — đó là kịch bản MỌI THỨ đều thuận lợi. Nhưng theo dữ liệu tụi em có từ dự án tương tự, khả năng cao nhất rơi vào khoảng 6 tuần, và rủi ro lớn nhất nằm ở sàn C — cái này nằm ngoài kiểm soát của cả hai bên."

Bước 3 — Chỉ rõ rủi ro cụ thể, biến nó thành việc CÙNG xử lý chứ không phải lời bào chữa. Thay vì nói chung chung "có rủi ro tích hợp", chị H. chỉ đích danh: "Rủi ro lớn nhất là sàn C — tài liệu API của họ thiếu phần webhook đồng bộ tồn kho. Nếu anh T. có đầu mối liên hệ trực tiếp với đội kỹ thuật bên sàn C, việc rút ngắn thời gian phản hồi hỗ trợ có thể giúp tụi em bám sát được mốc 6 tuần, thậm chí gần hơn với 4 tuần."

Đây là bước quan trọng nhất: chị H. biến deadline từ "trách nhiệm một chiều của team dự án" thành "rủi ro chung mà khách hàng có thể tác động được" — anh T. có network với sàn C mà team kỹ thuật không có.

Bước 4 — Đề xuất phương án đánh đổi (trade-off) thay vì chỉ đưa ra tin xấu. Chị H. đưa thêm lựa chọn: "Nếu mốc 30/8 thực sự không thể lùi, tụi em có thể đề xuất chia giai đoạn: launch trước 2 sàn A và B đúng hạn 4 tuần để kịp một phần mùa sale, sàn C launch riêng sau đó 2 tuần khi rủi ro kỹ thuật đã rõ ràng hơn." Đây là cách dùng MoSCoW ngầm (ưu tiên theo giá trị kinh doanh) để giữ được cả tinh thần cam kết lẫn tính khả thi.

Bước 5 — Chốt lại bằng văn bản ngay trong ngày. Sau họp, chị H. gửi email tóm tắt đúng 3 kịch bản, điều kiện đi kèm, và phương án chia giai đoạn đã thống nhất — có CC cả sếp của anh T. để tránh tình trạng "lời nói gió bay" và để anh T. có tài liệu chính thức báo cáo lên trên, thay vì phải tự giải thích miệng.

Kết quả (Result)

Anh T. đồng ý phương án chia giai đoạn: launch sàn A và B đúng hạn 4 tuần (30/8), sàn C launch ngày 13/9. Vì được giải thích rõ rủi ro và có phương án cụ thể, anh T. chủ động kết nối team kỹ thuật với đầu mối kỹ thuật cấp cao hơn bên sàn C — nhờ đó thời gian phản hồi hỗ trợ rút ngắn đáng kể so với dự đoán bi quan ban đầu.

Kết quả cuối: sàn A, B launch đúng hạn. Sàn C launch trễ khoảng 4 ngày so với mốc 13/9 — không hoàn hảo, vẫn có một khoảng trễ nhỏ do một lỗi đồng bộ tồn kho phát sinh lúc UAT — nhưng nằm gọn trong kỳ vọng đã đặt ra từ đầu, và quan trọng nhất: không ai bất ngờ. Anh T. không phải "chữa cháy" với sếp vì đã có dữ liệu và phương án dự phòng từ tuần đầu tiên.

Điều chị H. tự rút ra sau dự án: lẽ ra nên trình bày bảng ước lượng khoảng ngay trong buổi kick-off ĐẦU TIÊN của giai đoạn 1, thay vì để đến khi bị neo bởi một con số không chính thức mới xử lý. Quản trị kỳ vọng hiệu quả nhất khi làm chủ động, không phải khi đàm phán lại.

📋 Áp dụng ngay

• Trước khi báo bất kỳ deadline nào ra ngoài, luôn tính 3 điểm (lạc quan / khả dĩ nhất / bi quan) — đừng để miệng buột ra một con số duy nhất, kể cả khi bị hỏi dồn trong họp.
• Gắn mỗi con số với một ĐIỀU KIỆN cụ thể ("6 tuần nếu X xảy ra đúng hạn"), không nói rủi ro chung chung "có thể phát sinh vấn đề".
• Khi phát hiện khách hàng đã "neo" một con số không chính thức (nghe từ sales, từ đồn đoán), xử lý ngay trong cuộc họp gần nhất — càng để lâu, con số càng khó gỡ.
• Luôn kèm một phương án đánh đổi (chia giai đoạn, cắt giảm scope, tăng nguồn lực) khi báo tin thời gian không như kỳ vọng — đừng chỉ đưa tin xấu mà không có lối ra.
• Chốt lại bằng văn bản trong ngày, gửi cho đúng người có thể dùng nó để giải trình lên cấp trên của họ.

💡 Bài học đúc rút (Key Takeaway): Một deadline cứng là một lời hứa dễ vỡ; một khoảng thời gian có điều kiện đi kèm là một cam kết có thể tin được — và chỉ khi khách hàng hiểu RỦI RO NÀO kéo dài thời gian, họ mới trở thành đồng minh giúp bạn rút ngắn nó, thay vì là người chỉ chờ bạn thất hứa.

🔗 Kỹ năng liên quan

• Kỹ thuật ưu tiên yêu cầu (MoSCoW/RICE) — nền tảng để đề xuất phương án chia giai đoạn khi deadline không thể lùi.
• Sử dụng dữ liệu để đàm phán — kỹ thuật dùng số liệu lịch sử để đàm phán thay vì cảm tính.
• Cách xử lý Scope Creep (Phình to phạm vi) — kiểm soát yếu tố khiến ước lượng ban đầu bị lệch theo thời gian.

Bài trước: Xây dựng tài liệu "khách hàng yêu thích" · Bài tiếp theo: Xử lý sự cố bất ngờ