Hợp đồng ghi đúng ba chữ “module mua hàng”, nghe thì rõ, nhưng module mua hàng 5 input với module mua hàng 15 input là hai thứ rất khác nhau, mà hợp đồng thì không nói là cái nào.
Đây là chuyện mình gặp thật. Phạm vi không được ghi rõ nên change request cứ tới liên tục, scope cứ thế phình ra, và mình không có cách nào từ chối khách, vì chẳng có tờ giấy nào nói cái gì nằm ngoài phạm vi. Scope creep, cái thuật ngữ nghe rất chuyên nghiệp ấy, thực chất là chuyện những cái “thêm tí nữa” không bao giờ dừng, và nó không chỉ là vấn đề của BA mà của cả team, cả dự án, cả cái deadline.
scope creep có phải lỗi của ai không#
Phản xạ đầu tiên thường là đổ lỗi, cho khách không biết mình muốn gì, cho PM nhận bừa, cho dev không phản biện sớm. Nhìn lại chuyện “module mua hàng” ở trên thì theo mình gốc nằm ở chỗ khác, phạm vi không được viết ra đủ rõ ngay từ đầu. Khách đòi thêm là chuyện bình thường của một dự án đang sống, cái không bình thường là chẳng có gì để đối chiếu. Vấn đề là mình có thấy nó từ xa không, và có plan để xử lý hay cứ để nó cuốn đi. Bài BA mới vào nghề: 5 cú sốc không ai nói trước cũng có nhắc, requirement thay đổi mỗi ngày là chuyện cơm bữa.
mấy câu nghe là biết scope sắp phình#
“Cái này nhỏ thôi, một tiếng là xong.” Câu nguy hiểm nhất làng IT, vì chẳng có gì nhỏ một khi nó chạm vào logic nghiệp vụ.
“Làm luôn cái này, đằng nào cũng đang sửa.” Một cái nhỏ ghép với mấy cái nhỏ khác, thành một cục to không ai lường trước.
“Hồi sáng em mới nghĩ ra, hay quá anh ơi.” Ý tưởng mới lúc nào cũng có vẻ hay, câu hỏi là cái hay đó có đáng để trễ deadline không.
“Khách hàng bảo thêm, không làm mất lòng.” Sợ mất lòng khách là cái bẫy lớn nhất của BA mới, mà không có scope rõ thì nỗi sợ này càng to, vì bạn chẳng có căn cứ nào để nói không.
“BA ơi, cái này giống cái kia, copy qua sửa tí thôi.” Nếu đã giống thì sao lúc elicitation không ai nói? Vì nó không giống.
cách xử lý#
Không có công thức thần kỳ nào, đây là những gì mình làm khi có change request, cộng thêm vài điều theo mình nên làm sớm hơn.
Đầu tiên là chốt scope baseline rõ ràng trước khi build, một thứ mà cả hai bên cùng nhìn vào và gật đầu đây là scope, không cần document 50 trang, có thể là một cái bảng, một file spreadsheet, thậm chí một cái email, nhưng phải có. Bài 3 nguyên tắc sống còn để lấy yêu cầu hiệu quả nói kỹ chuyện này.
Rồi tách must-have với nice-to-have, ai bảo thêm cái này nữa thì câu đầu tiên không phải có làm được không, mà là có cần cho go-live không, không cần thì cho vào v2.
Change request phải đi đúng đường. Cách mình làm là ghi nhận yêu cầu, đánh giá impact, nhờ dev estimate, rồi báo cáo sếp để quyết, không có bước nào tên là gật đầu trong cuộc họp. Câu thần chú là “để em xem tác động rồi trả lời anh”, vừa cho mình thời gian đánh giá, vừa cho họ thấy mình không phải cái máy gật đầu.
Và change request nào cũng phải kèm trade-off, kiểu làm cái này thì release trễ X tuần, anh chị chọn thế nào, ai cũng có quyền đổi scope, nhưng phải chịu hậu quả của nó.
không phải lúc nào creep cũng xấu#
Đôi khi cái “thêm tí nữa” lại làm lộ ra một requirement thật mà elicitation bỏ sót. Giả sử khách đòi thêm một cột kiểm tra hạn thanh toán ở màn hình mua hàng, nghe như thêm việc, nhưng thiếu nó thì kế toán phải dò tay mỗi cuối tháng, cái đó đáng làm. Chỗ khó là phân biệt đâu là khám phá giá trị và đâu là thiếu chuẩn bị, cái thêm giải quyết một pain point thật chưa ai nghĩ tới thì là discovery value, còn nó vốn nằm sẵn trong requirement từ đầu mà không ai đọc thì là thiếu chuẩn bị.
Với mình, lúc nên nói không với khách hay với sếp khá rõ, là khi yêu cầu nằm ngoài scope, nhưng muốn nói được câu đó thì scope phải được viết ra trước, đủ chi tiết để “module mua hàng” không còn hiểu sao cũng được. Thế nên việc đáng làm nhất lại nằm ở đầu dự án, đọc kỹ hợp đồng, hỏi cho ra phạm vi chi tiết, rồi ghi lại. Scope không rõ thì nói không cũng chẳng ai nghe.
Bạn từng bị scope creep hành thế nào, và có mẹo gì hay để đỡ câu “cái này nhỏ thôi” chưa?
