Scope và đánh đổi: iron triangle, MoSCoW, cắt scope

Cuộc trò chuyện mà tech lead né lâu nhất chính là cuộc trò chuyện về scope. Team đã căng cứng, stakeholder lại đòi thêm một tính năng nữa, và việc nói "không" nghe có vẻ chính trị. Chương này giới thiệu hai khung làm việc - iron triangle và MoSCoW - giúp biến cuộc trò chuyện ấy trở về kỹ thuật chứ không phải cảm xúc, kèm theo template để giữ thoả thuận lâu bền.

Khi nào scope cần được bảo vệ một cách rõ ràng?

Có ba thời điểm hay gặp.

Yêu cầu mới xuất hiện ở giữa dự án. Câu nói "có thể tiện thể thêm..." - chín trên mười lần là khoảnh khắc dự án bắt đầu trượt nếu không ai gọi tên đánh đổi.

Có deadline cố định và đến từ bên ngoài. Một chiến dịch marketing, một ngày quy định, hay một cam kết với khách hàng. Khi đó scope phải linh hoạt vì thời gian thì không.

Chất lượng đang bào mòn trong im lặng. Test coverage giảm dần, nợ kỹ thuật tăng lên, on-call bị page nhiều hơn - đây thực ra là những lần cắt scope mà bạn quên gọi tên.

Nếu dự án có thể linh hoạt mọi mặt, kỷ luật về scope sẽ ít quan trọng hơn. Nhưng phần lớn dự án thì không như vậy.

Cái giá khi coi scope là cố định là gì?

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

Hoàn thành kiểu hành quân tử thần. Team làm cuối tuần để giữ nguyên scope ban đầu vào ngày ban đầu. Chất lượng đi xuống một cách vô hình, và tỉ lệ nghỉ việc bám theo sau.

Cắt chất lượng trong im lặng. Bỏ test, nén code review, hoãn handover sang ops. Lúc launch trông như thành công, đến postmortem 6 tháng sau mới lộ ra.

Mất niềm tin với stakeholder. Câu nói "chúng tôi kịp ngày" được phát ra trong khi cả team biết một nửa scope ban đầu đã ship mà không có tài liệu. Sớm muộn stakeholder cũng phát hiện. Niềm tin sẽ tốn nhiều năm để xây lại.

Iron triangle trong thực tế là gì?

flowchart TB
    Time[Thời gian<br/>deadline cố định] -.đánh đổi.- Scope[Scope<br/>tính năng có]
    Scope -.đánh đổi.- Quality[Chất lượng<br/>test, doc, polish]
    Quality -.đánh đổi.- Time
    Note[Cố hai -<br/>cái thứ ba trôi]
    style Note fill:#fffbe6,stroke:#d97706

Có ba góc, hãy chọn cố hai trong số đó. Điểm cốt yếu không phải là bạn có thể ship được mọi thứ chỉ bằng cách hy sinh góc còn lại - mà là mọi quyết định trong dự án đều ngầm là một đánh đổi giữa ba góc này. Iron triangle giúp biến cái ngầm đó thành rõ ràng.

Trong thực tế, các dự án phần mềm thường cố thời gian và scope, và đòn bẩy thật sự co giãn lại là chất lượng. Khi bạn nghe câu "chúng ta phải đẩy lên", thực chất nghĩa là chất lượng đang bị cắt. Hãy biến nó thành một lựa chọn có ý thức, chứ đừng để nó là mặc định ngầm.

Chạy cuộc trò chuyện MoSCoW như thế nào?

Có ba bước, mất khoảng 60 phút cho một dự án có 30-50 item ứng cử viên.

Bước 1: liệt kê tất cả. Mọi tính năng được yêu cầu, mọi item được đề xuất, không lọc gì. PM gõ lại trong khi team brainstorm.

Bước 2: từng stakeholder bỏ phiếu M/S/C/W. Bỏ phiếu riêng tư trước, sau đó công khai cùng lúc. Những chỗ xung đột làm lộ ra nơi các stakeholder không đồng thuận về ưu tiên - đây là dữ liệu quý giá nhất trong phòng họp.

Bước 3: ép theo budget. Các item Must phải vừa với timeline. Nếu Must thổi bay deadline, đây chính là lúc cần đàm phán - chứ không phải chờ đến ba tuần trước launch. Hãy chuyển item xuống bậc (M→S, S→C, C→W) cho đến khi phép toán ăn khớp.

Cột Won't là cột mạnh nhất. Stakeholder luôn muốn giữ mọi thứ trong scope; danh sách Won't tài liệu hoá lại những gì họ đã đồng ý hoãn. Khi họ đòi sau này, bạn có biên bản trong tay.

Template MoSCoW cụ thể là gì?

Một bảng markdown cho mỗi dự án, được cập nhật vào mỗi kickoff và mỗi lần ưu tiên lại:

# MoSCoW — {{ Tên dự án }} — Cập nhật 2026-06-05

## Must (không có thì không ship được)

| ID | Tính năng | Owner | Ước lượng | Note |
|----|-----------|-------|-----------|------|
| M1 | User đăng ký bằng email + password | TL | 1 tuần | Auth provider tích hợp |
| M2 | User mua sản phẩm một lần | TL | 2 tuần | Stripe; idempotent |
| M3 | Admin refund trong 30 ngày | TL | 1 tuần | Tái dùng Stripe refund API |
| M4 | Email xác nhận đơn | EM | 0.5 tuần | Mailgun |
| M5 | Xoá data tuân thủ GDPR | TL | 1 tuần | Yêu cầu pháp lý |

Tổng Must: 5.5 tuần. Available: 6 tuần. Đệm: 0.5 tuần.

## Should (giá trị cao, đau khi bỏ)

| ID | Tính năng | Ước lượng | Chi phí khi hoãn |
|----|-----------|-----------|------------------|
| S1 | Lưu phương thức thanh toán | 2 tuần | Khách phải nhập lại thẻ mỗi lần |
| S2 | Receipt đa ngôn ngữ | 1 tuần | Chỉ tiếng Anh lúc launch |

## Could (có thì hay)

| ID | Tính năng | Ước lượng |
|----|-----------|-----------|
| C1 | Dark mode cho admin | 0.5 tuần |
| C2 | Tool refund hàng loạt | 1 tuần |

## Won't (rõ ràng hoãn vòng này)

| ID | Tính năng | Hoãn đến | Lý do |
|----|-----------|----------|-------|
| W1 | Subscription billing | Q4 2026 | Domain model khác |
| W2 | Đa tiền tệ | 2027 | Cần tích hợp FX provider |
| W3 | Template email tuỳ chỉnh | TBD | Marketing chưa yêu cầu |

Tổng hàng Must xấp xỉ với thời gian sẵn có chính là kết quả của cuộc đàm phán. Sponsor sẽ thích một dự án giao đủ mọi Must đúng hạn ngay cả khi Should và Could chỉ ship được một phần. Ngược lại, họ ghét dự án ship được mọi thứ nhưng cái nào cũng dở dang.

Scale lên đa team ra sao?

Có ba thay đổi:

flowchart TB
    Roadmap[Roadmap quý<br/>theme M/S/C/W] --> ProjA[Scope dự án A<br/>MoSCoW riêng]
    Roadmap --> ProjB[Scope dự án B<br/>MoSCoW riêng]
    Roadmap --> ProjC[Scope dự án C<br/>MoSCoW riêng]
    ProjA --> SprintA[Backlog sprint]
    ProjB --> SprintB[Backlog sprint]
    ProjC --> SprintC[Backlog sprint]

Ở mức tổ chức, MoSCoW gắn với theme chứ không phải tính năng. "Việc về hiệu năng" là một theme Must; các dự án bên dưới sẽ chạy MoSCoW riêng trong phần budget được giao của mình. Chương planning sẽ nói về hình dạng của roadmap. Còn backlog sprint (sprint execution) thì quá chi tiết để áp MoSCoW; chỗ đó dùng story point.

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

• Mọi thứ đều là Must. Stakeholder đánh dấu mọi item là Must; budget vỡ; không có gì được ưu tiên thật sự. Cách phòng: ép budget cho phần Must (ví dụ tối đa 60% capacity) để buộc team phải có kỷ luật ngay từ đầu.
• Danh sách Won't bị quên. Câu "chúng ta đã đồng ý không làm cái này" bị un-đồng ý vào lần đổi lãnh đạo kế tiếp. Cách phòng: link danh sách Won't trong mọi status report; coi việc chuyển một item ra khỏi Won't là một thay đổi scope cần sponsor phê duyệt.
• Cắt scope một cách lén lút. Team âm thầm bỏ một item Should vì các item Must đã ăn hết thời gian. Cách phòng: mọi thay đổi scope đều phải là một sự kiện trong status report; status report có trách nhiệm gọi tên những gì đã chuyển bậc.
• Chỉ nghĩ tới thời gian. "Chúng ta kịp ngày" - nhưng với chất lượng nào? Hãy luôn gọi tên rõ ràng góc nào của tam giác đang dịch chuyển.

Khi nào kỷ luật scope là quá liều?

Có hai trường hợp.

Việc thật sự mang tính khám phá. Một spike kéo dài 2 tuần để học xem một ý tưởng có khả thi không thì không có scope nào để bảo vệ. Kết quả của spike chính là deliverable; MoSCoW không áp dụng được.

Team chạy continuous-flow. Loại team luôn làm việc quan trọng nhất tiếp theo (kiểu Kanban, không có sprint). Họ ưu tiên theo từng item qua chương Kanban; MoSCoW chỉ xuất hiện ở mức roadmap hàng quý.

Dưới mức dự án, kỷ luật về scope ít quan trọng hơn so với việc ship nhanh. Kỷ luật chỉ thật sự đáng cân nhắc khi có một ngày bắt buộc phải kịp.

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

Bạn đã có đủ nền tảng: vai trò, ước lượng, rủi ro, comms, và scope. Chương tiếp theo: Scrum cơ bản cho engineer - phương pháp đầu tiên biến những nền tảng đó thành một nhịp tuần mà team có thể chạy được.