Transition Requirement
Loại yêu cầu chỉ tồn tại trong giai đoạn chuyển từ hệ thống cũ sang hệ thống mới: chuyển dữ liệu, chạy song song, đào tạo, phương án quay lui. Hết chuyển đổi là hết vòng đời.
Định nghĩa
Có một loại yêu cầu chỉ sống được vài tuần rồi chết, và chính vì thế nó hay bị bỏ quên tới tận lúc không kịp làm nữa. Transition requirement là những gì cần có để tổ chức đi được từ trạng thái hiện tại sang trạng thái mới: dữ liệu cũ chuyển sang thế nào, nhân viên học ở đâu, chạy song song bao lâu, hỏng thì quay lui ra sao.
BABOK v3 xếp nó thành một tầng riêng chứ không nhét vào solution requirement, và lý do rất thực tế: những yêu cầu này không nằm trong sản phẩm cuối. Sau khi go-live ổn định, chúng biến mất.
Hệ thống mới chạy đúng chưa chắc dự án đã chạy được. Phần còn thiếu thường nằm ở đây.
Vì sao nó quan trọng
Vì đây là loại yêu cầu duy nhất mà làm sai thì không có bản vá. Import nhầm 200.000 dòng công nợ vào production lúc 2 giờ sáng chủ nhật thì không có hotfix nào cứu được, chỉ có restore và làm lại — nếu bạn đã kịp chuẩn bị bản backup.
Nó cũng là phần hay bị ước lượng thiếu nhất. Dev nhìn vào và thấy "một cái script import", trong khi thực tế là làm sạch dữ liệu, ánh xạ danh mục, xử lý các bản ghi rác từ 8 năm trước, chạy thử ba vòng, đối soát, và một cửa sổ downtime phải xin phép nghiệp vụ trước cả tháng.
Gồm những gì
Chuyển đổi dữ liệu là phần to nhất: phạm vi dữ liệu chuyển, quy tắc ánh xạ, cách xử lý bản ghi lỗi, tiêu chí đối soát sau khi chuyển. Đi kèm nó gần như luôn là một giai đoạn chạy song song — hai hệ cùng chạy bao lâu, nhập liệu hai lần hay đồng bộ, và ai là người ngồi so kết quả cuối ngày.
Phần còn lại ít người viết đủ:
- Đào tạo và tài liệu người dùng: bao nhiêu lớp, cho nhóm nào, hướng dẫn ở dạng gì.
- Phương án quay lui: điều kiện nào thì huỷ go-live, ai ra quyết định, mất bao lâu để về lại hệ cũ.
- Chuyển giao vận hành và ngừng hệ cũ: bàn giao quyền và tài khoản, quy trình hỗ trợ sau go-live, lưu trữ dữ liệu lịch sử, thu hồi license, ngày tắt máy chủ.
Ví dụ thực tế
Chuyển sáu năm dữ liệu tồn kho và công nợ sang hệ mới trong một đêm chủ nhật — nghe thì gọn, nhưng gọn tới đâu? Nhà phân phối hàng tiêu dùng này có 3 kho và 10.700 mã hàng.
| Yêu cầu chuyển đổi | Tiêu chí chấp nhận |
|---|---|
| Chuyển danh mục hàng hoá | 10.700 mã, sai lệch 0 mã, đơn vị tính ánh xạ đủ 100% |
| Chuyển tồn kho tại thời điểm cắt | Chênh lệch giá trị tồn giữa hai hệ dưới 0,1% và giải thích được từng dòng |
| Chạy song song | 2 tuần đầu nhập cả hai hệ, đối soát cuối ngày, hệ cũ là bản gốc khi lệch |
| Đào tạo | 4 lớp cho 46 nhân viên kho và kế toán, hoàn thành trước go-live 5 ngày |
| Rollback | Nếu sau 48 giờ tỷ lệ đơn xuất lỗi vượt 5%, quay về hệ cũ trong 4 giờ |
Cột bên phải là cột hay bị để trống nhất. Lần gần nhất mình thấy nó trống, hai bên cãi nhau ba ngày về nghĩa của chữ "xong".
Mẹo khi đi làm
Chạy thử migration ít nhất ba vòng: vòng một để biết dữ liệu bẩn cỡ nào, vòng hai sau khi làm sạch, vòng ba là bản diễn tập đúng kịch bản go-live có bấm giờ. Vòng ba cho bạn con số thật để xin cửa sổ downtime, thay vì đoán.
Chốt sớm ai là người ký xác nhận dữ liệu sau khi chuyển. Trong hầu hết dự án ở VN, chỗ này rơi vào vùng xám: IT bảo nghiệp vụ phải kiểm, nghiệp vụ bảo IT chuyển thì IT chịu trách nhiệm. Đưa tên người vào tài liệu từ đầu.
Và viết luôn kịch bản "ngày đầu tiên": 7 giờ sáng thứ Hai, 46 người đăng nhập cùng lúc, ai trực hỗ trợ, số điện thoại nào, lỗi báo về đâu. Cái này không có trong bất kỳ tài liệu chuẩn nào, nhưng nó quyết định người dùng nhớ về hệ thống mới theo cách nào.
