Roadmap trên tường nhìn khá hợp lý. Mỗi card có tên, có quarter, có màu làm kế hoạch trông có trật tự. Rồi thứ Hai đến cùng hai production issue, một người nghỉ phép, một vendor delay, và một feature hóa ra cần migration mà không ai tính vào. Roadmap không trở nên vô dụng. Nó trở nên thật.
Đây là khoảnh khắc nhiều team xử lý chưa tốt. Khi roadmap gặp capacity thật, cuộc trò chuyện rất dễ thành cảm xúc. Product nghe thấy delay. Engineering nghe thấy pressure. QA nghe risk đến muộn. Leadership nghe uncertainty. Mọi người nhìn cùng một plan, nhưng mỗi nhóm mang một nỗi lo khác nhau.
Một roadmap khỏe không phải lời hứa rằng reality sẽ ngoan ngoãn nghe theo. Nó là công cụ ra quyết định. Nó nên giúp team thấy điều gì quan trọng nhất, điều gì có thể dời, điều gì không nên nén, và trade-off nào đang được chọn. Nếu roadmap không sống nổi qua một cuộc nói chuyện về capacity, có lẽ nó đang hoạt động giống decoration hơn là planning.
Bước hữu ích đầu tiên là làm capacity hiện ra bằng ngôn ngữ bình thường. Không chỉ story point, không chỉ sprint velocity, và không chỉ calendar của từng người. Capacity thật gồm support load, code review time, discovery work, QA depth, release coordination, meeting, onboarding, incident và cái thuế lặng lẽ của context switching. Một team bỏ qua các việc này sẽ tiếp tục plan như thể con người có nhiều giờ hơn thực tế.
Bước thứ hai là tách priority khỏi sequence. Một feature có thể quan trọng nhưng vẫn chưa thể làm trước nếu dependency chưa sẵn. Một compliance fix nhỏ có thể đi trước một ý tưởng product thú vị hơn vì cửa sổ rủi ro đang đóng. Một technical cleanup có thể xứng đáng có chỗ vì mọi feature sau đều trả giá nếu nó bị bỏ qua. Thứ tự roadmap không chỉ là value. Nó là value, risk, dependency và learning được sắp xếp trong thời gian.
Thay vì hỏi mình có nhét được hết không, hãy hỏi: nếu capacity là cố định, outcome nào cần được bảo vệ trước, và mình chủ ý không làm điều gì?
Team cũng cần một cách sạch sẽ để nói không mà không làm nó thành chuyện cá nhân. “Không” không nên có nghĩa idea đó dở, người request vô lý, hoặc team không cố gắng đủ. Thường nó có nghĩa hệ thống đã chạm constraint. Chỉ có từng ấy attention, review bandwidth và release risk mà team có thể mang cùng lúc. Gọi tên constraint bảo vệ mối quan hệ. Nó chuyển cuộc trò chuyện từ blame sang choice.
Một thực hành tôi thích là viết cost cạnh change. Nếu team kéo một việc urgent mới vào, việc gì đi ra? Nếu không có gì đi ra, quality bar nào đổi? Ít testing hơn? Ít documentation hơn? Overtime nhiều hơn? Một plan nhận thêm việc mà không gọi tên việc bị đẩy ra không phải linh hoạt. Nó đang giấu debt trong con người.
Capacity conversation sẽ bình tĩnh hơn nếu nó diễn ra đều, không chỉ khi có xung đột. Một weekly roadmap check có thể rất nhỏ: điều gì đổi, mình học được gì, risk nào lớn lên, việc gì nên dời, decision nào cần stakeholder? Việc này giúp plan không thành đồ trưng bày. Nó cũng cho product và engineering một thói quen chung: cập nhật reality trước khi reality trở thành bất ngờ.
Có sự khiêm tốn trong kiểu planning này. Team thừa nhận mình không thể làm mọi thứ cùng lúc. Team xem focus là resource, không phải phẩm chất cá nhân. Team chấp nhận rằng dời một card đôi khi là quyết định có trách nhiệm, không phải thất bại của commitment. Delivery tốt không phải không có thay đổi. Nó là khả năng đổi plan mà không đánh mất outcome.
Khi roadmap gặp capacity thật, mục tiêu không phải bảo vệ plan cũ hay đầu hàng chaos. Mục tiêu là làm lựa chọn tiếp theo trung thực. Bây giờ điều gì quan trọng nhất? Ta biết điều gì mà trước đây chưa biết? Điều gì cần được bảo vệ để team vẫn deliver tốt? Nếu team bạn có roadmap trước mặt, cuộc trò chuyện hữu ích có thể bắt đầu từ phần việc không ai đặt lên roadmap nhưng mọi người đã đang làm mỗi ngày.