Nhiều dự án phần mềm nội bộ trông xong ở buổi demo. Có màn hình. Có nút. Người xem gật. Vài tuần sau đội vẫn làm trên bảng tính. Phần mềm mở ra một lần rồi tắt. Chỗ hỏng thường không phải lúc viết phần mềm. Chỗ hỏng là khâu bàn giao — lúc việc thật đụng phần mềm thật.

Bàn giao không phải ngày gửi mật khẩu. Bàn giao là đội dùng được việc hằng ngày trên phần mềm, mà không phải hỏi người viết mỗi bước. Nếu còn một người cầu nối ngồi giữa đội và màn hình, việc chưa xong. Người đó nghỉ một buổi là quy trình đứt.

Chỗ hay hỏng thứ nhất: bản demo không phải bản dùng thật. Demo dùng dữ liệu đẹp, tài khoản admin, mạng nội bộ. Đội thật thì mạng chậm, dữ liệu cũ bẩn, người chỉ được xem một phần. HANATECH đòi bản đầu dùng được với người dùng thật và quyền thật, đúng vì lý do này — không phải để cho đủ nghi thức.

Chỗ hay hỏng thứ hai: quyền. Một mật khẩu dùng chung, ai cũng là admin, nghe nhanh ở tuần đầu. Đến khi có người bấm nhầm, không biết ai làm, không gỡ được đúng bản. Quyền phải có từ bản dùng đầu: ai xem, ai sửa, ai đưa dữ liệu ra ngoài. Hỏi muộn thì chữa đắt.

Chỗ hay hỏng thứ ba: dữ liệu cũ ở lại. Phần mềm mới mở, bảng tính cũ vẫn là nơi đội tin. Hai nơi cùng sống thì nơi cũ thắng, vì người ta đã thuộc. Việc bàn giao phải nói rõ bản ghi nào chuyển, bản ghi nào đóng, ai chịu trách nhiệm ngày cắt.

Chỗ hay hỏng thứ tư: không có nhật ký. Khi có tranh cãi — ai đã duyệt, bản nào đã ra, bước nào bị bỏ — chỉ còn lời nói. Lời nói không đủ khi hai người trong cùng công ty không nhớ cùng một việc. Nhật ký không phải tính năng trang trí. Nhật ký là cách đội tự kiểm được sau khi người viết đã rời buổi họp.

Chỗ hay hỏng thứ năm: coi ngày bàn giao là ngày xong. Đội dùng thật mới lộ chỗ bấm nhầm, chỗ không tìm thấy, bước nào dài hơn giấy. Nếu hợp đồng im lặng về theo dõi và sửa, những chỗ đó nằm lại trên vai đội. HANATECH xếp theo dõi và sửa thành khâu thứ tư, sau đưa vào vận hành, vì quan sát được việc thật rồi mới biết sửa gì.

Cách HANATECH đi một việc. Hiểu việc đang làm. Dựng bản người dùng dùng được. Đặt vào chỗ đội đang làm. Xem chỗ tắc rồi sửa. Bốn bước đó không mới. Chúng bị bỏ vì buổi demo đã đủ để gật. Người quyết định thuê làm phần mềm nên hỏi nhà thầu bước nào sau demo, chứ đừng hỏi demo có đẹp không.

Câu hỏi nên mang vào thư. Bản đầu ai dùng, với quyền gì, trên dữ liệu nào. Ngày đội bắt đầu dùng thì người viết còn đứng cạnh bao lâu, theo việc gì. Chỗ tắc sau ngày đó sửa thế nào. Dữ liệu cũ chuyển hay đóng. Bốn câu này không cần bạn biết tên kỹ thuật. Chúng đủ để tách chỗ làm thật và chỗ chỉ nói.

Một đội nhỏ hay nghĩ mình không cần khâu này vì ít người, nói chuyện nhanh. Ít người thì mỗi người đảm nhận nhiều vai: người duyệt cũng là người nhập, người nhập cũng là người đi gặp khách. Phần mềm không khớp một vai là cả ngày lệch. Bàn giao với đội nhỏ phải đọc được trên điện thoại, trên việc đang làm, không trên một tệp dài.

Sản phẩm đang chạy tại hamia.vn cho thấy cùng một nguyên tắc trên việc thật: máy viết, người đọc, rồi mới tới bước ra ngoài. Đó không phải bằng chứng cho mọi phần mềm nội bộ. Đó là bằng chứng HANATECH đã phải đưa một quy trình vào vận hành, không dừng ở bản trình chiếu. Nếu bài toán của bạn là hệ thống nội bộ, hãy gửi đúng việc đội đang làm.

Email info@hanatech.vn khi cần viết đủ ý. Điện thoại hoặc Zalo 0374 33 55 78 khi muốn hỏi nhanh loại việc có nhận không. Kèm một ngày làm việc, không kèm một slide kiến trúc. HANATECH đọc việc đó rồi nói nhận hay không — và nếu nhận, khâu bàn giao nằm trong việc, không nằm ngoài lề.