Dự án phần mềm nội bộ hiếm khi sụp đổ trong một ngày. Nó trượt dần: mốc bàn giao lùi vài tuần, phạm vi phình thêm vài tính năng, người phụ trách nghiệp vụ bận việc khác, rồi một ngày không ai còn nhắc tới nó nữa. Sáu nguyên nhân dưới đây xuất hiện lặp đi lặp lại, và cả sáu đều phòng được nếu nhận ra sớm.
1. Không ai được quyền quyết định cuối cùng
Đây là nguyên nhân số một. Khi mỗi bộ phận có một cách hiểu khác nhau về quy trình, đội phát triển không thể tự chọn — họ sẽ chờ, hoặc tệ hơn, làm cả hai cách và để người dùng chọn lúc chạy.
Cách phòng: chỉ định một người quyết định nghiệp vụ, có thẩm quyền nói "làm theo cách này" ngay cả khi một bộ phận không hài lòng. Ghi tên người đó vào tài liệu dự án, không để mặc định là "ban giám đốc".
2. Phạm vi mô tả bằng tính năng thay vì bằng kết quả
Danh sách "50 màn hình" nghe rõ ràng nhưng không đo được. Khi nghiệm thu, hai bên sẽ tranh luận màn hình đã đủ hay chưa, thay vì kiểm tra công việc đã chạy được hay chưa.
Cách phòng: mô tả phạm vi bằng câu hoàn chỉnh về nghiệp vụ. Ví dụ: "kế toán phát hành được đề nghị thanh toán, qua hai cấp duyệt, và xuất được bảng theo dõi công nợ theo nhà cung cấp". Nghiệm thu là chạy đúng câu đó với dữ liệu thật.
3. Người dùng thật chỉ xuất hiện ở phút cuối
Nếu người trực tiếp nhập liệu chỉ nhìn thấy hệ thống lúc nghiệm thu, gần như chắc chắn sẽ có những phản hồi lớn và muộn: thiếu trường dữ liệu bắt buộc, thao tác quá nhiều bước, không xử lý được tình huống thường gặp.
Cách phòng: cho người dùng thật chạm vào sản phẩm theo chu kỳ ngắn, ngay từ khi mới có màn hình thô. Phản hồi sớm rẻ hơn nhiều so với phản hồi đúng, nhưng muộn.
4. Trường hợp ngoại lệ bị bỏ tới cuối
Mọi doanh nghiệp đều có ngoại lệ: khách hàng đặc biệt được duyệt vượt hạn mức, đơn hàng trả lại một phần, hợp đồng ký trước khi có mã dự án. Những tình huống này thường chỉ lộ ra khi kiểm thử với dữ liệu thật, và mỗi cái có thể kéo theo thay đổi cấu trúc.
Cách phòng: hỏi thẳng ngay ở giai đoạn phân tích — "tháng trước có trường hợp nào phải làm khác quy trình không?" — và xử lý những ngoại lệ phổ biến nhất trước, thay vì để dành.
5. Dữ liệu cũ bị coi là việc nhỏ
Nhiều kế hoạch xếp việc chuyển dữ liệu vào tuần cuối cùng. Thực tế, dữ liệu cũ luôn bẩn hơn dự đoán và việc đối chiếu cần nhiều vòng. Khi dữ liệu chưa khớp, hệ thống dù chạy đúng vẫn không dùng được, vì không ai tin con số nó đưa ra.
Cách phòng: bắt đầu thử chuyển dữ liệu ngay khi cấu trúc ổn định, chạy lại nhiều lần, và đặt tiêu chí khớp số rõ ràng trước ngày chạy chính thức.
6. Không có người "sở hữu" hệ thống sau khi bàn giao
Dự án kết thúc, đội triển khai rút đi, và trong công ty không ai chịu trách nhiệm trả lời câu hỏi hàng ngày hay quyết định thay đổi nhỏ. Hệ thống dần lệch khỏi thực tế, người dùng lặng lẽ quay lại Excel.
Cách phòng: chọn người sở hữu hệ thống từ trước khi bắt đầu, cho họ tham gia suốt quá trình, và dành ngân sách thường niên cho những thay đổi nhỏ.
Dấu hiệu cảnh báo sớm
Dự án đang trượt thường im lặng hơn dự án đang chạy tốt. Ít câu hỏi không phải là tin vui.
Ba tín hiệu đáng lo:
- Cuộc họp tiến độ chuyển từ bàn nghiệp vụ sang bàn lịch bàn giao.
- Số yêu cầu thay đổi tăng dần ở giai đoạn cuối, trong khi giai đoạn đầu gần như không có.
- Người phụ trách nghiệp vụ vắng mặt ở hai buổi làm việc liên tiếp.
Cách làm giảm rủi ro một cách đơn giản
Chia dự án thành những mảnh đủ nhỏ để mỗi mảnh đưa vào dùng thật trong vòng vài tuần. Mỗi lần đưa vào dùng thật là một lần kiểm chứng: người dùng có dùng không, số liệu có khớp không, quy trình có bớt thao tác không. Một dự án gồm nhiều mảnh nhỏ đã chạy thật khó thất bại toàn phần, vì phần giá trị đã được giao từ sớm.
