Assumption
Điều được coi là đúng để lập kế hoạch và viết yêu cầu, nhưng chưa được xác nhận. Ghi ra thì thành rủi ro có tên; không ghi thì thành cuộc cãi nhau ở tuần thứ mười.
Định nghĩa
Mỗi khi bạn ước lượng một việc, bạn đang giả định một đống thứ: API của bên thứ ba có sẵn tài liệu, dữ liệu cũ tương đối sạch, người dùng đã quen dùng máy tính, phòng IT khách sẽ cấp môi trường trong hai ngày. Không cái nào được xác nhận. Tất cả đều có thể sai.
Assumption là những niềm tin đó, được viết ra thành chữ. Viết ra không làm chúng đúng hơn, nhưng làm chúng nhìn thấy được — và cái gì nhìn thấy được thì có thể kiểm chứng, có thể theo dõi, có thể đẩy trách nhiệm về đúng người.
Giả định không ghi ra không biến mất. Nó chỉ chuyển từ tài liệu sang biên bản sự cố.
Vì sao phải ghi ra
Lý do đầu tiên là ước lượng. "8 tuần" và "8 tuần, với điều kiện môi trường tích hợp sẵn sàng trước 10/6" là hai lời hứa khác nhau — và khi môi trường trễ hai tuần, bạn không phải giải thích lại từ đầu.
Ghi ra cũng biến giả định thành việc có người phải làm: ai xác nhận, hạn nào. Xác nhận xong thì nó rời danh sách, thành sự thật hoặc thành vấn đề.
Còn một lý do ít ai nói thẳng: tự vệ. Trong dự án outsourcing, mục Assumptions là chỗ bạn nói trước cái gì nằm ngoài tầm tay mình. Viết giọng trung tính, đừng phòng thủ, nhưng phải viết.
So sánh assumption, constraint, risk và dependency
Bốn thứ này hay bị nhét chung vào một mục "Ghi chú" và mất hết ý nghĩa.
| Định nghĩa gọn | Ví dụ | Xử lý bằng cách | |
|---|---|---|---|
| Assumption | Coi là đúng, chưa xác nhận | Dữ liệu khách hàng cũ có đủ số điện thoại | Kiểm chứng sớm, có người chịu trách nhiệm |
| Constraint | Giới hạn đã biết chắc, không đổi được | Ngân sách 800 triệu, phải chạy trên server hiện có | Thiết kế trong phạm vi đó |
| Risk | Việc có thể xảy ra và gây hại | Chuyên gia nghiệp vụ duy nhất nghỉ thai sản giữa dự án | Kế hoạch phòng ngừa, phương án dự phòng |
| Dependency | Phụ thuộc vào bên khác mới làm được | Chờ đối tác mở sandbox API | Theo dõi mốc, có người bám |
Một giả định sai thường biến thành risk, rồi thành issue. Chuỗi đó xảy ra rất nhanh và đó chính là lý do phần assumption nên được rà lại mỗi vài tuần chứ không viết một lần rồi bỏ đó.
Ví dụ thực tế
Dự án tích hợp hệ thống bán hàng của một nhà phân phối với phần mềm kế toán do bên thứ ba cung cấp, khoảng 2.350 hoá đơn mỗi ngày.
Danh sách giả định lúc ký:
| Giả định | Ai xác nhận | Hạn | Kết quả |
|---|---|---|---|
| Phần mềm kế toán có API tạo hoá đơn, hỗ trợ ghi hàng loạt | IT khách | 20/5 | Sai — chỉ có import file, mỗi 15 phút một lần |
| Danh mục mã hàng hai bên đã đồng bộ | Trưởng phòng kinh doanh | 25/5 | Sai — lệch 640 mã |
| Môi trường test được cấp trước 1/6 | IT khách | 1/6 | Trễ 9 ngày |
Ba giả định, ba cái sai. Nhưng vì chúng được ghi và được kiểm chứng vào cuối tháng 5 chứ không phải cuối tháng 7, đội kịp đổi thiết kế sang cơ chế đẩy file theo lô và kịp mở một CR cho phần làm sạch danh mục. Dự án trễ 2 tuần thay vì đổ vỡ.
Lỗi hay gặp
Viết giả định chung chung tới mức không kiểm chứng nổi. "Khách hàng phối hợp đầy đủ" — thế nào là đầy đủ, ai đo. Viết cụ thể: "Khách bố trí một chuyên viên nghiệp vụ tối thiểu 8 giờ mỗi tuần cho các buổi làm rõ yêu cầu."
Còn một kiểu nữa: dùng mục assumption làm chỗ trút mọi thứ mình lười xác nhận. Nếu chỉ cần một cuộc gọi 10 phút là biết đúng hay sai, thì gọi đi, đừng ghi thành giả định. Danh sách 30 dòng giả định thường có nghĩa là BA chưa làm hết phần khảo sát.
Và kinh điển nhất: ghi xong rồi không bao giờ mở lại. Đặt lịch rà danh sách giả định vào mỗi mốc lớn của dự án. Mất 20 phút, và thường lần nào cũng phát hiện ít nhất một dòng đã âm thầm sai.
