🧩 “Scope nở như bong bóng xà phòng” – cú shock khi lần đầu ký hợp đồng khung

Chào mọi người,

Hôm nay mình muốn kể một trải nghiệm mà chắc nhiều bạn BRSE (nhất là non-tech như mình) sẽ gặp phải: ký hợp đồng chốt khung, nhưng khi phân tích detail thì scope bắt đầu phình ra. Nghe thì quen rồi đúng không, nhưng lúc rơi vào thì mới thấy vừa buồn cười vừa đau não 😅.

 

❌ Cú lầm tưởng: Hợp đồng đã ký = Yêu cầu đã chốt

Mình còn nhớ dự án đó khách chỉ đưa ra một doc “business requirement” vỏn vẹn 5 trang. Team mình và khách ngồi với nhau, chốt high-level scope:

  • Làm web-app cho bệnh viện 🏥

  • Các chức năng chính: quản lý bệnh nhân, quản lý bác sĩ, đặt lịch, thanh toán online.

Mình hớn hở nghĩ bụng: “Thế là xong, hợp đồng đã ký, scope đã chốt. Giờ chỉ việc đi vào detail để viết spec thôi.”

Nhưng đời không như mơ.

Vừa bước vào phase phân tích detail, những “bất ngờ” bắt đầu nhảy ra:

  • Khách nói “Bệnh nhân đặt lịch xong thì admin sẽ assign bác sĩ.”
    👉 Đi vào chi tiết thì mới lòi ra thêm:
    　・Nếu 2 bệnh nhân cùng book một slot thì ai được ưu tiên?
    　・Nếu bác sĩ duy nhất available trong slot đó nhưng lại không sở hữu 資格/bằng cấp tương ứng với loại bệnh mà bệnh nhân chỉ định thì admin có thể chỉ định bác sĩ này khám bệnh được không?

  • Khách nói “Hệ thống cho phép booking trùng /đè lên nhau"
    👉 Đào sâu thì phát hiện:
    　・Overlap booking cụ thể là overlap như thế nào? Có phải là booking của người tới sau có thể booking đè vào booking đã tồn tại trước đó hay không?
    　・Hệ thống có giới hạn overlap booking trong 1 khung thời gian hay không? hay là cho phép 重複放題/Overlap thoải thích, không giới hạn

    　・Liệu có trường hợp ngoại lệ nào mà không xảy ra case overlap booking hay không?

  • Khách nói “Bệnh nhân có thể hủy lịch.”
    👉 Nhưng khi hỏi thêm thì lại nở ra cả chuỗi rule:
    　・Cancel trước bao lâu thì được hoàn phí? Chính sách về cancel booking và tỉ lệ hoàn phí sẽ được tính toán như thế nào?
    　・Có cho phép hủy vào phút chót không? Nếu có, thì bác sĩ nhận thông báo kiểu gì?
    　・Có cần chức năng auto-fill slot trống cho bệnh nhân khác không?

  • Khách nói “Thanh toán online.”
    👉 Vào detail mới biết:
    　・Không chỉ credit card, mà còn phải có cả QR code, bảo hiểm y tế, và voucher.
    　・Refund thì xử lý tự động hay manual? Ai là người approve?

… Tất cả những thứ này ban đầu không hề có trong doc high-level.
Khách thì bảo “Nghiệp vụ hiển nhiên mà”, còn team dev thì ôm đầu vì effort cứ thế mà tăng gấp rưỡi 😅.

 

🌱 Bài học xương máu: Scope không bao giờ nằm yên trên giấy

Mình mới thấm ra rằng:

  • High-level requirement chỉ là khung sườn.

  • Detail analysis mới là lúc scope thật sự “lộ diện”.

  • Và scope thì… luôn có xu hướng nở (scope creep).

Nếu không cảnh giác, một dự án ký 100 giờ effort có thể dễ dàng biến thành 200 giờ chỉ trong nháy mắt.

 

📚 Tips thực tế để đối phó với “scope nở”

 

1. Luôn làm rõ “ngoại lệ” ngay từ đầu

Khách hàng thường chỉ mô tả happy case:
“Bệnh nhân đặt lịch xong thì admin assign bác sĩ, vậy thôi.”

👉 Nhưng khi đi vào thực tế sẽ phát sinh 1001 ngoại lệ:

  • Nếu 2 bệnh nhân đặt cùng một slot thì ai được ưu tiên?

  • Nếu bác sĩ bị ốm đột xuất thì có auto-forward sang bác sĩ khác không, hay admin gọi điện xử lý tay?

  • Nếu bệnh nhân hủy sát giờ thì có rule phạt phí không?

💡 Kinh nghiệm của mình: ngay từ phase phân tích, hãy ép các case “khó nhằn” này lên bàn luôn, đừng để đến lúc coding mới phát hiện.

 

2. Định nghĩa rõ “out of scope” trong hợp đồng

Khách thường mặc định một số nghiệp vụ là “hiển nhiên” nên không ghi ra. Nhưng “hiển nhiên” với khách ≠ “hiển nhiên” với dev.

Ví dụ điển hình: Thanh toán online.

  • Trong doc ban đầu, chỉ có vỏn vẹn đúng 2 chữ: Online payment.

  • Nhưng khi phân tích detail, khách lại kỳ vọng:
    ・Ngoài credit card, bệnh nhân phải có thể thanh toán bằng bảo hiểm y tế.
    ・Nếu bệnh nhân cancel trước 24h thì được refund tự động, còn cancel sát giờ thì không hoàn phí.
    ・Có case admin phải xử lý refund thủ công vì bệnh nhân claim.
    ・Voucher khuyến mãi cũng cần áp dụng khi thanh toán.

👉 Nếu ngay từ đầu không định nghĩa rõ “cái nào trong scope, cái nào ngoài scope”, thì những chức năng tưởng nhỏ này sẽ đội effort lên gấp nhiều lần.

💡 Cách mình hay dùng là hỏi thẳng để đóng khung:
「保険適用や返金ルールは今回のスコープに含まれますか？」
(Bảo hiểm và rule refund có nằm trong scope lần này không ạ?)

 

3. Recap & confirm ngay khi scope có dấu hiệu trượt

Sai lầm newbie (mình từng dính): thấy khách thêm yêu cầu thì im lặng ghi vào basic design, đợi đến cuối mới báo. Kết quả là cả team sốc vì scope tăng gấp đôi.

Bây giờ, mỗi khi thấy có dấu hiệu scope nở, mình sẽ recap ngay trong họp hoặc follow-up trên kênh chát:

Ví dụ booking case:
「予約キャンセルの際、返金処理が必要と理解しました。これは今回のスコープに含まれますでしょうか？」
(Tôi hiểu là khi bệnh nhân cancel thì cần refund. Xin xác nhận giúp đây có nằm trong scope lần này không?)

👉 Cách này vừa minh bạch, vừa giảm tranh cãi sau này.

 

4. Học cách “deal” nhẹ nhàng nhưng rõ ràng

Scope creep đôi khi không tránh khỏi. Nhưng thay vì để team OT “chết chìm”, BRSE phải là người kéo phanh.

Ví dụ thực tế:
Khách muốn thêm tính năng auto-assign bác sĩ trong booking. Ban đầu hợp đồng không có.

👉 Cách mình xử lý:

  • Giải thích rằng đây là chức năng mới, cần effort ~20 giờ.

  • Đưa ra 2 option:

    1. Bổ sung effort + chi phí.

    2. Giữ nguyên effort, nhưng cắt bớt tính năng khác ít critical hơn.

✨ Mẹo: Trình bày bằng bảng so sánh effort → khách hàng dễ hình dung hơn, và thương lượng cũng nhẹ nhàng, không căng thẳng.

 

🌱 Đúc kết lại

Một BRSE non-tech như mình, ban đầu cứ nghĩ hợp đồng chốt rồi thì scope cũng chốt. Nhưng thực tế, hợp đồng chỉ là điểm xuất phát. Scope chỉ hiện hình thật sự khi đi vào detail.

👉 Giá trị của BRSE không phải chỉ ở việc phân tích requirement, mà còn ở chỗ giữ scope trong tầm kiểm soát:

  • Hỏi kỹ, hỏi vòng ngoài,

  • Recap liên tục,

  • Và biết khi nào cần “kéo phanh” để thương lượng lại với khách.

Nói vui thì: làm BRSE cũng như chơi trò giữ bong bóng xà phòng. Nếu không khéo, scope sẽ phình ra đến lúc… nổ cái “bốp” 😂.