Scope Creep
Phạm vi dự án lớn dần lên bằng những đề nghị nhỏ không ai duyệt chính thức, cho tới lúc timeline và ngân sách vỡ mà không chỉ ra được thời điểm nào đã sai.
Định nghĩa
"Thêm cái này tí thôi mà." Câu đó, nghe mười lăm lần trong ba tháng, là cách một dự án đúng tiến độ biến thành một dự án trễ hai tháng. Scope creep không đến bằng một cú sốc lớn. Nó đến bằng những đề nghị nhỏ, hợp lý, khó từ chối, và không cái nào đi qua quy trình duyệt.
Phân biệt nhanh: thay đổi có duyệt là change request, quản lý được. Thay đổi không duyệt là scope creep, không quản lý được. Còn khi chính đội phát triển tự thêm thứ khách không yêu cầu vì "cho nó xịn", cái đó có tên riêng là gold plating.
Phạm vi lớn lên thì bình thường. Nó lớn lên mà không ai trả giá cho phần lớn thêm mới là chuyện đáng lo.
| Ai khởi xướng | Có duyệt không | Ảnh hưởng tới kế hoạch | |
|---|---|---|---|
| Change request | Khách hoặc nội bộ | Có, kèm phân tích tác động | Được cập nhật vào timeline |
| Scope creep | Khách, qua nhiều đề nghị nhỏ | Không | Âm thầm ăn vào buffer |
| Gold plating | Chính đội phát triển | Không, khách không hề đòi | Tốn công mà không tính tiền |
Dấu hiệu nhận biết sớm
- Sprint nào cũng có 2–3 việc "phát sinh nhỏ" không nằm trong kế hoạch, và không ai ghi lại tổng.
- Yêu cầu đến qua Zalo, cuộc gọi, hành lang; không có nơi nào tập trung.
- Ước lượng ban đầu 8 tuần, đã sang tuần 11, mà danh sách việc còn lại vẫn dài như tuần 6.
- Dev bắt đầu nói "cái này hôm trước chị bảo khác".
- Không ai mở được tài liệu chốt phạm vi, hoặc mở ra thì thấy nó chưa từng được ký.
Dấu hiệu cuối là gốc rễ. Đa số dự án bị scope creep nặng là dự án chưa bao giờ có baseline rõ ràng.
Vì sao nó xảy ra
Không phải vì khách xấu tính. Vài lý do thật hay gặp ở dự án VN:
Khách chỉ hình dung ra được nhu cầu thật khi nhìn thấy màn hình chạy. Trước đó họ ký vào tài liệu mà chưa hiểu hết mình đang ký gì. Đây là lý do chính đáng, và cách chữa là cho họ nhìn thấy sớm bằng prototype, chứ không phải trách họ đổi ý.
Rồi tới chuyện quan hệ. Người quản lý dự án phía nhà cung cấp ngại nói "không" với khách hàng lớn, nên gật đầu trước rồi tìm cách nhét vào sau. Vài lần như vậy thì đội phát triển gánh phần chênh.
Và gốc rễ hay gặp nhất: yêu cầu ban đầu mơ hồ. "Hệ thống có chức năng báo cáo" — câu đó dung nạp được từ 3 báo cáo tới 30 báo cáo, và khách sẽ hiểu theo hướng 30.
Ví dụ thực tế
Tuần thứ ba của một dự án website bán hàng cho thương hiệu thời trang. Phạm vi đã chốt: 6 tính năng, 10 tuần, đội 4 người.
Diễn biến: tuần 3 khách xin thêm bộ lọc theo màu (nửa ngày, ai cũng thấy hợp lý). Tuần 4 xin thêm ảnh theo màu (một ngày rưỡi, vì phải sửa cấu trúc dữ liệu sản phẩm). Tuần 5 xin thêm quản lý tồn kho theo size và màu (bốn ngày, đụng vào đồng bộ với hệ thống kho). Tuần 7 xin thêm báo cáo bán chạy theo màu (hai ngày). Tổng cộng khoảng 8 ngày công không nằm trong hợp đồng, và cả bốn đều bắt đầu bằng "tí thôi".
Dự án về đích chậm 2,5 tuần. Khi ngồi lại, phía khách thật lòng không nghĩ họ đã yêu cầu nhiều đến vậy, vì không lần nào có con số đặt lên bàn.
Cách chặn mà không làm hỏng quan hệ
Ghi lại mọi đề nghị, kể cả cái nửa ngày công. Một bảng đơn giản: ngày, ai đề nghị, mô tả, ước lượng, trạng thái. Không phán xét, chỉ ghi. Sau ba tuần mở ra cùng khách xem tổng, cuộc trò chuyện tự nó đổi chiều.
Dùng nguyên tắc đánh đổi thay vì nguyên tắc từ chối. "Thêm được, nhưng đội đang kín; anh chị muốn hoãn tính năng nào để nhường chỗ" — cách nói này đặt quyền quyết định về đúng người và giữ nguyên thiện chí. MoSCoW rất hợp cho tình huống này.
Chốt phạm vi bằng thứ nhìn được, không bằng câu chữ. Danh sách màn hình, danh sách báo cáo có tên cụ thể, danh sách những gì không làm ở phase này. Mục "không làm" là mục quý nhất và cũng là mục ít người viết nhất.
Và nếu bạn là BA trong một dự án đã trôi quá xa, đừng cố sửa bằng cách siết quy trình giữa chừng. Dừng lại, đếm lại phần đã phát sinh, đưa ra một mốc mới có căn cứ. Chấp nhận một cuộc nói chuyện khó chịu ở tuần 8 vẫn dễ hơn một cuộc nói chuyện ở tuần 14.
