Planning và Roadmap: Now / Next / Later

Roadmap là artifact biến kickoff doc thành kế hoạch quý, và cũng là artifact mà phần lớn dự án cố tình diễn vai. Phiên bản giả mạo thường là một biểu đồ Gantt đầy ngày tự tin mà chẳng ai tin. Chương này giới thiệu phiên bản trung thực hơn

• Now / Next / Later kèm mức tin cậy - và cách truyền tải nó mà không làm mất niềm tin của stakeholder.

Khi nào một roadmap viết bắt đầu mang lại giá trị?

Có ba tín hiệu chính.

Dự án dài hơn một quý. Dưới mức đó, kickoff doc cộng plan sprint là đã đủ. Vượt qua đó, cả team và stakeholder đều cần một bản nhìn ở mức horizon.

Có dependency xuyên team. Khi việc của Team A phụ thuộc vào API của Team B, cả hai team đều cần thấy hình dạng timeline. Roadmap chính là nơi các dependency lộ ra trước khi chúng kịp gây hại.

Cần truyền tải thông tin ra ngoài. Sales muốn cam kết với khách hàng, marketing muốn lên plan launch, lãnh đạo muốn dự báo nhu cầu tuyển dụng. Mỗi bên đọc roadmap theo một cách khác nhau, nhưng cùng một artifact phải phục vụ được cả ba.

Nếu dự án chỉ một team, một quý, và hoàn toàn nội bộ, bạn có thể bỏ qua roadmap chính thức và dùng kickoff doc làm plan luôn.

Cái giá khi roadmap mơ hồ hoặc vắng mặt là gì?

Có ba kiểu lỗi thường gặp.

Stakeholder bất ngờ. Sales đã bán tính năng cho tháng 1; team lại đang plan ship tháng 3. Sự không khớp này lộ ra ở buổi review hàng quý.

Team bị quá tải. Khi không có tầm nhìn, lãnh đạo cứ liên tục thêm việc lên đĩa của team. Tính capacity gần như bất khả thi nếu không có một plan viết.

Lag trong tuyển dụng. Một engineer mới cần khoảng một quý để ramp lên đầy đủ. Nếu roadmap cho thấy nhu cầu tăng trưởng đến trong 2 quý nữa, việc tuyển dụng phải bắt đầu ngay từ bây giờ. Nếu không có roadmap, việc tuyển chỉ bắt đầu khi cơn đau đã tới.

Roadmap tối thiểu trông thế nào?

# Roadmap — {{ Team / Sản phẩm }}, cập nhật 2026-06-10

## Now (Q3 2026 — cam kết, 90% tin cậy)
- Luồng refund đầu cuối (Sponsor: VP CS) — owner: Bob — 6 tuần
- Upgrade Postgres 16 (Sponsor: Infra) — owner: Carol — 4 tuần
- Dashboard rate-limit API (Sponsor: VP Eng) — owner: Alice — 3 tuần

## Next (Q4 2026 — plan, 70% tin cậy)
- Subscription billing (phụ thuộc luồng refund ship)
- Đa tiền tệ (phụ thuộc chọn FX provider)
- Luồng checkout mobile (phụ thuộc pattern checkout web đáp)

## Later (Q1 2027 trở đi — ý định, 30% tin cậy về cụ thể)
- Billing hợp đồng B2B
- Self-service refund (sau khi luồng refund ổn)
- Analytics: dashboard doanh thu

Có ba chi tiết đáng chú ý. Một là các ghi chú "phụ thuộc" phải rõ, vì việc promote một item từ Next lên Now đòi hỏi dependency phải xong trước. Hai là tên sponsor làm lộ ra ai là người chịu trách nhiệm cho từng item. Ba là phần trăm tin cậy giúp đóng khung kỳ vọng cho stakeholder.

Gantt dependency trông thế nào?

Cho phối hợp trong quý xuyên 3 team:

gantt
    title Q3 2026 — Initiative Refund
    dateFormat YYYY-MM-DD
    section Backend
    API endpoint refund           :a1, 2026-07-01, 14d
    Tích hợp Stripe               :a2, after a1, 7d
    Audit logging                 :a3, after a1, 5d
    section Frontend
    Nút refund trang đơn          :b1, 2026-07-08, 5d
    View lịch sử refund           :b2, after b1, 7d
    section Comms
    Template email refund         :c1, 2026-07-15, 3d
    Runbook customer support      :c2, after c1, 5d
    section Launch
    QA + UAT                      :d1, after a2 b2 c2, 7d
    Go-live                       :milestone, after d1, 0d

Gantt chỉ dùng trong phạm vi một quý. Mọi thứ vượt quá quý thì để ở Now/Next/Later. Mermaid render được Gantt trực tiếp trong view detail, nên roadmap có thể sống dưới dạng markdown ngay cạnh kickoff doc.

Roadmap ở quy mô đa team trông thế nào?

flowchart TB
    OrgRoadmap[Roadmap tổ chức<br/>theme, 1 trang] --> TeamA[Roadmap Team A<br/>Now/Next/Later]
    OrgRoadmap --> TeamB[Roadmap Team B<br/>Now/Next/Later]
    OrgRoadmap --> TeamC[Roadmap Team C<br/>Now/Next/Later]
    TeamA --> SprintA[Backlog sprint]
    TeamB --> SprintB[Backlog sprint]
    TeamC --> SprintC[Backlog sprint]

Roadmap ở mức tổ chức là một trang gồm các theme ("hiệu năng Q3", "billing Q4"). Roadmap của từng team rút Now / Next / Later từ các theme đó. Còn backlog sprint thì rút từ roadmap team. Ba tầng, mỗi tầng đều tóm tắt tầng phía dưới.

Roadmap có thể tạo ra những lỗi nào?

• Roadmap bị coi như cam kết. Stakeholder coi các item trong Later như là lời hứa. Cách phòng: gắn nhãn tin cậy cạnh mỗi entry; nhắc lại trong mỗi lần cập nhật hàng tháng rằng Later là ý định chứ không phải hợp đồng.
• Promote như diễn kịch. Item được đẩy từ Later lên Next mà không kiểm tra capacity. Nhóm Now phồng to lên. Cách phòng: khi promote, hãy check capacity ở vị trí đích; demote một thứ khác nếu cần.
• Bỏ qua việc cập nhật. Roadmap được tạo vào đầu quý rồi bị bỏ quên cho đến quý kế. Cách phòng: đặt sẵn cuộc review hàng tháng trên lịch, với cùng những người tham gia review dự án.
• Chính xác giả tạo trên Gantt. Ngày được đặt cụ thể đến từng ngày mà không có cơ sở. Cách phòng: dùng ranh giới tuần (ví dụ "tuần 8/7") chứ không phải ngày chính xác cho tới khi việc đã được cam kết.

Khi nào roadmap là quá liều?

Có hai trường hợp.

Team thuần khám phá. Khi việc nặng về nghiên cứu, mà trong đó 6 tuần tới sẽ định hình 6 tháng tiếp theo, thì roadmap gần như vô nghĩa. Trong trường hợp đó, retrospective mới là artifact quan trọng.

Team ops phản ứng. Các team Platform, SRE, hay support

• nơi việc đến không dự đoán được - nên dùng Kanban. Mức roadmap đối với họ chỉ là các theme toàn tổ chức, chứ không phải công việc hàng ngày.

Roadmap đáng chi phí cập nhật khi có đủ việc cần lên kế hoạch để các quyết định về thứ tự thật sự có giá trị.

Đi tiếp từ đây như thế nào?

Chương tiếp theo: sprint execution - nhịp tuần bên trong quý của roadmap. Sau đó, launch và handover sẽ nói về những gì xảy ra ở cuối nhóm Now.