Mở đầu — vì sao bài này quan trọng
Ở Bài 16, bạn đã làm quen với Roadmap cơ bản trong Jira — công cụ tuyệt vời để một team đơn lẻ nhìn thấy các Epic của mình trải dài trên trục thời gian. Nhưng thực tế công việc của một PM hiếm khi dừng lại ở một team. Khi công ty lớn lên, bạn sẽ đối mặt với câu hỏi khó hơn nhiều: "Làm sao để 3 team, mỗi team một board riêng, một sprint riêng, một velocity riêng, cùng phối hợp giao một sản phẩm lớn đúng hạn?"
Đây chính là lúc Advanced Roadmaps (trước đây gọi là Portfolio for Jira, và trong giao diện mới của Jira Cloud gọi là Plans) trở thành vũ khí không thể thiếu. Nó là tính năng cao cấp cho phép bạn lập kế hoạch xuyên nhiều team, nhiều project, quản lý một tầng phân cấp cao hơn Epic (thường là Initiative), và quan trọng nhất: kiểm tra xem team của bạn có đủ năng lực (capacity) để hoàn thành kế hoạch đó không — trước khi cam kết với sếp và khách hàng.
Bài học này quan trọng vì nó đánh dấu bước chuyển từ "PM quản lý một team" sang "PM điều phối nhiều team" — một kỹ năng phân biệt PM junior với PM có thể ngồi vào bàn hoạch định chiến lược. Nếu bạn từng phải lập một bảng Excel khổng lồ để dự đoán ngày ra mắt tính năng dựa trên năng lực của các team, thì Advanced Roadmaps sinh ra để thay thế cái Excel đó bằng một công cụ sống, tự cập nhật, gắn thẳng vào dữ liệu thật của Jira.
Khái niệm cốt lõi
Advanced Roadmaps (Plans) là gì và khác Roadmap cơ bản ra sao
Roadmap cơ bản (Basic Roadmap) hoạt động trong phạm vi một project và chỉ hiển thị đến cấp Epic. Nó phù hợp khi bạn chỉ cần một cái nhìn timeline cho một team.
Advanced Roadmaps thì khác về bản chất. Nó là một lớp lập kế hoạch (planning layer) tách biệt, kéo dữ liệu (issue) từ nhiều nguồn — nhiều board, nhiều project, nhiều filter — vào cùng một "Plan". Điểm mấu chốt cần nhớ: mọi thay đổi bạn làm trong một Plan ban đầu chỉ nằm trong "kịch bản" (scenario) của Plan đó, chưa ảnh hưởng đến dữ liệu thật cho đến khi bạn bấm Save/Review changes để đẩy ngược về Jira. Điều này cực kỳ giá trị: bạn có thể thử nghiệm "nếu dời sprint này thì sao", "nếu thêm 2 người vào team này thì sao" mà không làm loạn board của các team.
Lưu ý về license: Advanced Roadmaps có sẵn trong Jira Premium (Cloud) hoặc thông qua Jira Software Data Center. Ở gói Standard, bạn chỉ có Basic Roadmap. Đây là điều bạn cần biết trước khi hứa với sếp là "để em set up cái này".
Tầng phân cấp Initiative > Epic > Story
Đây là trái tim của Advanced Roadmaps. Trong Jira mặc định, tầng cao nhất bạn có là Epic. Nhưng khi lập kế hoạch xuyên team, một Epic thường vẫn quá nhỏ. Bạn cần một tầng cao hơn để nhóm nhiều Epic thuộc nhiều team lại thành một mục tiêu kinh doanh chung.
Advanced Roadmaps cho phép bạn tạo và quản lý tầng phân cấp tùy chỉnh. Cấu trúc kinh điển là:
- Initiative (Sáng kiến): mục tiêu lớn, thường kéo dài nhiều quý, xuyên nhiều team. Ví dụ: "Ra mắt ví điện tử tích hợp trong app".
- Epic (thuộc từng team): "Tích hợp cổng thanh toán VNPay", "Xây màn hình nạp tiền", "KYC xác thực người dùng".
- Story / Task: công việc cụ thể trong từng sprint.
Capacity check — so kế hoạch với velocity thật của team
Đây là tính năng khiến Advanced Roadmaps "đắt tiền" nhưng xứng đáng. Với chế độ Sprint capacity, bạn khai báo:
- Velocity của mỗi team (ví dụ team Payment làm được trung bình 40 story point/sprint).
- Độ dài sprint (2 tuần).
- Số lượng người và ngày nghỉ (qua Team calendar, sẽ học sâu ở Bài 28).
Auto-schedule và Dependencies
Advanced Roadmaps có nút Auto-schedule — thuật toán sẽ tự sắp xếp toàn bộ công việc dựa trên: thứ tự ưu tiên (rank), capacity của team, và dependencies (phụ thuộc) giữa các issue. Nếu Epic B phải chờ Epic A xong (link "is blocked by"), auto-schedule sẽ tự đẩy Epic B ra sau. Trên timeline, các đường phụ thuộc hiện ra dưới dạng đường nối, giúp bạn nhìn thấy ngay "nút thắt cổ chai" nằm ở team nào.
Tình huống thực tế
Tình huống 1 — Fintech Việt Nam ra mắt tính năng "Mua trước trả sau"
Một công ty fintech ở TP.HCM (giả định tên VíXanh) muốn ra mắt tính năng BNPL (Buy Now Pay Later) trong Q3. Đây là một Initiative lớn liên quan 3 team: team Core Payment, team Risk & Scoring, và team Mobile App. Mỗi team có board riêng, sprint riêng.
Chị Trang — PM phụ trách — ban đầu dùng Google Sheet để ghép timeline. Kết quả là mỗi lần một team dời sprint, chị phải sửa tay 3 chỗ, và luôn có cảm giác con số không đáng tin.
Sau khi chuyển sang Advanced Roadmaps, chị tạo một Plan gom board của cả 3 team. Chị tạo một Initiative "BNPL Launch" và gắn các Epic của từng team dưới nó. Khi nhập velocity thật (Core Payment 45 point/sprint, Risk 30, Mobile 50), công cụ auto-schedule và lập tức cho thấy: team Risk & Scoring là điểm nghẽn — họ chỉ làm được 30 point/sprint nhưng gánh tới 180 point công việc, đẩy ngày ra mắt trễ 4 tuần so với kỳ vọng của ban giám đốc.
Bài học: Advanced Roadmaps biến "cảm giác trễ hạn" thành "con số cụ thể team nào là nút thắt". Nhờ đó chị Trang có cơ sở đề xuất mượn 1 engineer từ team khác qua Risk trong 3 sprint — một quyết định dựa trên dữ liệu, không phải cãi nhau cảm tính.
Tình huống 2 — Công ty e-commerce Đông Nam Á và bài toán "what-if"
Một sàn thương mại điện tử khu vực Đông Nam Á (giả định ShopLago) chuẩn bị cho mùa sale 11.11. Anh Minh — Group PM — cần trả lời câu hỏi của CEO: "Nếu chúng ta ưu tiên tính năng livestream shopping lên trước tính năng gợi ý AI thì ngày go-live thay đổi thế nào?"
Trước đây câu hỏi này mất cả tuần để tổng hợp. Với Advanced Roadmaps, anh Minh dùng tính năng scenario: anh tạo một kịch bản, kéo Epic "Livestream" lên trên "AI Recommendation" trong bảng rank, bấm auto-schedule. Trong vài phút, timeline mới hiện ra — và vì mọi thay đổi nằm trong scenario, board thật của các team không bị đụng chạm. Anh trình bày hai kịch bản song song cho CEO ngay trong cuộc họp.
Bài học: Sức mạnh lớn của Advanced Roadmaps không chỉ là "vẽ timeline" mà là mô phỏng an toàn. Bạn được thử nghiệm các quyết định ưu tiên và thấy hệ quả về thời gian ngay lập tức, trước khi commit.
Tình huống 3 — Startup dùng sai công cụ
Một startup 8 người (giả định Cỏ May Tech) nghe nói Advanced Roadmaps "xịn" nên nâng cấp lên Jira Premium chỉ để dùng nó. Nhưng họ chỉ có một team duy nhất, tất cả ngồi chung một phòng, một sprint. Kết quả: họ mất phí Premium mà mỗi tuần vẫn chỉ nhìn vào Basic Roadmap, còn Plan thì rối rắm vì phải cấu hình hierarchy, capacity cho một team mà ai cũng đã biết đang làm gì.
Bài học: Advanced Roadmaps tỏa sáng khi bạn có nhiều team và nhiều tầng phụ thuộc. Với một team đơn, Basic Roadmap gọn nhẹ hơn nhiều. Đừng chọn công cụ theo "độ xịn" mà theo bài toán thực tế của bạn (chủ đề chọn tool chúng ta sẽ mổ xẻ ở Bài 41).
Hướng dẫn từng bước
Dưới đây là quy trình thiết lập một Plan xuyên team trong Jira Cloud Premium:
Bước 1 — Tạo Plan mới. Vào menu Plans trên thanh điều hướng, chọn Create plan. Đặt tên rõ ràng theo mục tiêu, ví dụ "BNPL Launch Q3 2026".
Bước 2 — Chọn nguồn dữ liệu (issue sources). Thêm các board, project hoặc filter của từng team liên quan. Đây là bước quyết định Plan của bạn "nhìn thấy" công việc của những team nào. Với tình huống VíXanh, chị Trang thêm board của cả 3 team.
Bước 3 — Thiết lập Teams. Trong Plan, tạo hoặc gắn các Team và khai báo velocity cùng độ dài sprint cho từng team. Nếu team dùng story point, chọn đơn vị estimation là point; nếu dùng ngày, chọn hours/days.
Bước 4 — Cấu hình Hierarchy. Vào phần cài đặt hierarchy để đảm bảo Initiative nằm trên Epic. Nếu chưa có issue type Initiative, bạn cần phối hợp Jira Admin tạo nó và map vào tầng phù hợp.
Bước 5 — Tạo Initiative và gắn Epic con. Tạo các Initiative đại diện cho mục tiêu kinh doanh, rồi kéo các Epic của từng team vào làm con.
Bước 6 — Đặt dependencies. Link các issue có quan hệ phụ thuộc (ví dụ "Màn hình nạp tiền" is blocked by "Tích hợp VNPay"). Việc này giúp auto-schedule sắp lịch đúng logic.
Bước 7 — Auto-schedule và đọc capacity warning. Bấm Auto-schedule. Quan sát các cảnh báo quá tải (thanh sprint chuyển đỏ). Đây là lúc bạn phát hiện nút thắt.
Bước 8 — Thử nghiệm scenario (tùy chọn). Nếu cần trả lời câu hỏi "what-if", tạo scenario, thay đổi rank hoặc capacity, so sánh kết quả — mọi thứ vẫn an toàn chưa đụng dữ liệu thật.
Bước 9 — Review và Save changes. Khi hài lòng, bấm Review changes. Jira liệt kê chính xác những gì sẽ ghi ngược về board thật (đổi sprint, đổi ngày, đổi parent). Bạn chọn lọc rồi Save. Chỉ đến đây dữ liệu mới thật sự thay đổi.
Bước 10 — Chia sẻ view. Dùng View settings để lọc theo team, theo Initiative, theo quý; lưu view và chia sẻ link cho các stakeholder. Bạn có thể xuất hình ảnh timeline để đưa vào slide báo cáo lãnh đạo.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhập velocity ảo. Nhiều PM nhập velocity theo kỳ vọng ("mong team làm 50 point") thay vì con số lịch sử thật. Kết quả là timeline đẹp nhưng dối trá. Mẹo: lấy velocity trung bình của 3–5 sprint gần nhất (Bài 14 dạy cách tính), và trừ hao cho ngày nghỉ, họp, on-call.
Lỗi 2 — Quên rằng thay đổi trong Plan chưa được lưu. Người mới thường hoảng khi thấy sprint bị dời, tưởng làm hỏng board. Nhớ: thay đổi nằm trong scenario cho tới khi bạn Save changes. Ngược lại, cũng có người quên Save rồi tưởng đã cập nhật cho team — trong khi board thật chưa đổi gì.
Lỗi 3 — Hierarchy không đồng bộ với Jira Admin. Nếu issue type Initiative chưa được tạo và map đúng, bạn sẽ không kéo Epic vào Initiative được. Đừng tự loay hoay — phối hợp Admin từ đầu.
Lỗi 4 — Đưa quá nhiều board vào một Plan. Gom 10 team vào một Plan khổng lồ làm nó chậm và khó đọc. Mẹo: chia Plan theo Initiative hoặc theo nhóm team có phối hợp thật sự với nhau.
Lỗi 5 — Bỏ qua dependencies. Không link phụ thuộc thì auto-schedule sắp lịch song song những việc lẽ ra phải nối tiếp, cho ra ngày go-live lạc quan giả tạo. Mẹo: dành thời gian map dependencies trước khi auto-schedule.
Mẹo vàng: Dùng Advanced Roadmaps như một công cụ giao tiếp, không chỉ để lập lịch. Cái đẹp nhất của nó là khi họp với sếp, bạn chỉ vào thanh sprint đỏ và nói "đây là lý do chúng ta cần thêm người cho team Risk" — thuyết phục hơn mọi lời nói suông.
Bài tập thực hành
- Dựng Plan đầu tiên: Trong một Jira Premium (dùng bản trial nếu chưa có), tạo một Plan gom board của 2 project khác nhau. Ghi lại các issue source bạn đã thêm.
- Thiết lập hierarchy: Tạo (hoặc yêu cầu Admin tạo) issue type Initiative. Tạo 1 Initiative và gắn ít nhất 3 Epic thuộc 2 team khác nhau vào dưới nó.
- Nhập capacity và auto-schedule: Khai báo velocity cho 2 team (dùng con số giả định 40 và 25 point/sprint), sprint 2 tuần. Bấm auto-schedule và chụp lại màn hình cảnh báo quá tải (nếu có). Team nào là nút thắt?
- Bài tập what-if: Tạo một scenario, đổi thứ tự ưu tiên (rank) của 2 Epic, auto-schedule lại, và so sánh ngày kết thúc Initiative giữa hai kịch bản. Viết 3 câu nhận xét về sự khác biệt.
- Review changes an toàn: Thực hiện một thay đổi trong Plan, mở Review changes, đọc kỹ danh sách những gì sẽ được ghi ngược. Chọn lưu chỉ 1 thay đổi và quan sát board thật để xác nhận đúng phần đó bị đổi.
Tóm tắt
Advanced Roadmaps (Plans) là bước nâng cấp từ việc lập kế hoạch cho một team sang điều phối nhiều team — kỹ năng cốt lõi của PM khi tổ chức lớn lên. Ba trụ cột cần nhớ: (1) Tầng phân cấp Initiative > Epic > Story giúp gom công việc của nhiều team vào một mục tiêu kinh doanh; (2) Capacity check so kế hoạch với velocity thật, buộc bạn đối diện sự thật về nút thắt thay vì vẽ timeline trong mơ; (3) Scenario và auto-schedule cho phép mô phỏng an toàn các quyết định ưu tiên trước khi commit, với dữ liệu thật chỉ thay đổi khi bạn chủ động Save changes.
Hãy nhớ ba tình huống: VíXanh phát hiện nút thắt ở team Risk nhờ con số cụ thể; ShopLago trả lời câu hỏi what-if của CEO ngay trong cuộc họp; và Cỏ May Tech nhắc ta rằng công cụ mạnh chỉ đáng tiền khi bài toán đủ phức tạp. Advanced Roadmaps không phải để khoe "đồ xịn", mà là để bạn cam kết ngày ra mắt bằng dữ liệu và bảo vệ team khỏi những lời hứa không thể giữ.