
Trong các dự án chúng tôi tiếp nhận từ đội khác, gần như không có dự án nào chết vì "công nghệ khó quá". Chúng chết vì những lý do rất đời thường, lặp đi lặp lại. Dưới đây là bảy lý do hay gặp nhất, kèm dấu hiệu nhận biết sớm.
1. Phạm vi được mô tả bằng tính từ
Hợp đồng ghi "hệ thống quản lý bán hàng đầy đủ, thân thiện, dễ mở rộng". Không ai biết "đầy đủ" là tới đâu, nên đến lúc nghiệm thu thì hai bên hiểu khác nhau và cãi nhau về đúng chữ đó.
Cách tránh: phạm vi phải viết bằng danh sách việc hệ thống làm được, ở dạng người dùng nói: "thu ngân tạo được đơn có nhiều mặt hàng, áp chiết khấu theo phần trăm hoặc số tiền, in hoá đơn ra máy in nhiệt". Câu nào không kiểm tra được bằng cách bấm thử thì viết lại.
2. Không có một người quyết định duy nhất
Khi năm phòng ban cùng góp ý mà không ai có quyền chốt, dự án sẽ đi vòng tròn: kế toán muốn thế này, kho muốn thế kia, và đội lập trình chờ. Mỗi vòng chờ là một tuần trôi qua.
Cách tránh: chỉ định một người chủ trì phía doanh nghiệp, có quyền chốt và có thời gian thật để làm việc đó — thường là 3–5 giờ mỗi tuần trong suốt dự án. Đây là chi phí thật, hãy tính vào từ đầu.
3. Số hoá nguyên si một quy trình đang hỏng
Nếu quy trình hiện tại có bốn lần duyệt chỉ vì trước đây không ai tin số liệu, thì đưa cả bốn lần duyệt vào phần mềm là bê nguyên vấn đề sang chỗ mới, kèm thêm chi phí.
Số hoá một quy trình tồi chỉ tạo ra một quy trình tồi chạy nhanh hơn và khó sửa hơn.
Cách tránh: với mỗi bước duyệt, hỏi "bước này đang phòng ngừa rủi ro gì, và phần mềm đã tự ngăn được rủi ro đó chưa?". Rất nhiều bước duyệt biến mất sau câu hỏi này.
4. Dữ liệu bẩn được nạp vào hệ thống mới
Danh mục hàng hoá có ba dòng cho cùng một sản phẩm, đơn vị tính lúc "thùng" lúc "hộp", khách hàng trùng tên khác mã. Nạp nguyên trạng vào hệ thống mới thì mọi báo cáo đều sai, và người dùng kết luận "phần mềm này không chính xác".
Cách tránh: tách hẳn một hạng mục "làm sạch dữ liệu" trong kế hoạch, có người phụ trách và có tiêu chí nghiệm thu (không còn mã trùng, mọi mặt hàng có đúng một đơn vị tính gốc).
5. Đào tạo bị coi là việc phụ
Một buổi họp trực tuyến 60 phút cho toàn công ty rồi phát file hướng dẫn PDF — đó không phải đào tạo. Nhân viên kho, thu ngân và kế toán dùng ba phần khác nhau của hệ thống với ba mức độ thành thạo khác nhau.
Cách tránh: đào tạo theo nhóm công việc, tại chỗ làm việc thật, trên dữ liệu thật của họ. Và luôn đào tạo lại sau 2–3 tuần, khi người dùng đã va vào các tình huống khó.
6. Không có giai đoạn chạy song song
Tắt hệ thống cũ vào thứ Hai và bắt cả công ty dùng hệ thống mới ngay hôm đó là canh bạc. Một lỗi nhỏ trong tuần đầu đủ làm mất niềm tin, và sau đó rất khó kéo lại.
Cách tránh: chạy song song 2–4 tuần với tiêu chí rõ ràng để dừng: ví dụ "ba tuần liên tiếp số liệu hai bên khớp, không có lỗi chặn nghiệp vụ".
7. Không ai giữ chìa khoá sau khi bàn giao
Dự án xong, đội làm rút đi, và doanh nghiệp không có mã nguồn, không có tài liệu, không có quyền quản trị máy chủ. Một năm sau cần sửa một biểu mẫu thì chỉ còn cách quay lại đúng đội cũ với giá do họ đặt.
Cách tránh: đưa việc bàn giao mã nguồn, tài liệu vận hành và tài khoản quản trị thành điều kiện thanh toán đợt cuối. Chi tiết hơn ở bài Bàn giao mã nguồn: vì sao doanh nghiệp phải đòi.
Kiểm tra nhanh trước khi ký
- Phạm vi có được viết thành danh sách việc kiểm tra được không?
- Ai là người chốt phía doanh nghiệp, và họ có bao nhiêu giờ mỗi tuần?
- Hạng mục làm sạch và chuyển dữ liệu có nằm trong báo giá không?
- Kế hoạch đào tạo có chia theo nhóm công việc không?
- Có bao nhiêu tuần chạy song song, và tiêu chí dừng là gì?
- Điều khoản bàn giao mã nguồn nằm ở đâu trong hợp đồng?
Sáu câu này trả lời được hết thì rủi ro đã giảm đi phần lớn — bất kể bạn chọn đối tác nào.
Cần bàn cụ thể?
SealCore khảo sát tại doanh nghiệp bạn và báo giá trọn gói sau buổi đầu tiên — kể cả khi kết luận là bạn chưa cần viết phần mềm riêng.


