Bàn giao phần mềm sao cho đội mới tiếp quản được?
Dự án kết thúc, doanh nghiệp nhận một thư mục mã nguồn và tài liệu nhưng đội mới vẫn không biết cập nhật phần mềm hay xử lý cảnh báo. Vấn đề không hẳn là thiếu file: tài liệu có thể không đúng phiên bản, tài khoản chưa chuyển quyền hoặc một bước quan trọng chỉ người cũ biết.
Bàn giao cần giúp người nhận tiếp tục công việc trong phạm vi đã thống nhất. Ví dụ dưới đây giả định một doanh nghiệp đổi đơn vị vận hành phần mềm nhận đơn. Các mục cần nhận phải được điều chỉnh theo hợp đồng, loại sản phẩm và trách nhiệm thực tế, không phải mọi dự án đều chuyển toàn bộ mã nguồn hoặc quyền sở hữu.
1. Xác định ai nhận và cần tự làm được gì
Trước tiên, phân biệt người dùng nghiệp vụ, đội vận hành và đội sẽ phát triển tiếp. Người dùng cần hướng dẫn thao tác và ngoại lệ; vận hành cần cách theo dõi, khôi phục và nhận sự cố; đội phát triển cần hiểu cấu trúc, phiên bản và cách tạo bản chạy. Gửi cùng một bộ tài liệu cho tất cả chưa bảo đảm mỗi bên đã nhận đúng thứ cần dùng.
Với mỗi nhiệm vụ, ghi rõ người nhận và việc họ phải thực hiện được. Chẳng hạn, người vận hành mới phải nhận được cảnh báo và biết báo cho ai, nhưng không nhất thiết tự sửa mã nguồn. Nếu vẫn thuê bên khác thực hiện kỹ thuật, cần xác định bên đó và phạm vi hỗ trợ để trách nhiệm không bị bỏ trống.
Bàn giao và nghiệm thu có thể diễn ra gần nhau nhưng phục vụ hai việc khác nhau: xác nhận sản phẩm đáp ứng yêu cầu và xác nhận người nhận tiếp tục công việc được. Bài Nghiệm thu phần mềm: Doanh nghiệp cần kiểm tra gì? giúp chuẩn bị phần kiểm tra sản phẩm trước khi dùng biên bản bàn giao để kết thúc dự án.
Nên xác định tiêu chí bàn giao khi bắt đầu hợp tác, nhất là khi biết đội khác sẽ vận hành. Nếu chỉ yêu cầu tài liệu vào tuần cuối, hai bên có thể phát hiện thiếu quyền hoặc giấy phép khi người cũ không còn thời gian xử lý. Lịch bàn giao nên có khoảng để người nhận học, thực hành và xác nhận lại những phần chưa đạt.
2. Chuẩn bị tài liệu, tài khoản và phần việc còn mở
Danh sách bàn giao nên ghi từng mục, nơi lưu, phiên bản, người nhận và cách xác nhận. Với phần phát triển riêng thuộc phạm vi nhận, cần đối chiếu bản mã với bản đang chạy, hướng dẫn triển khai và những cấu hình khác nhau giữa môi trường thử và môi trường thật. Một tài liệu đầy đủ nhưng hướng dẫn bản cũ vẫn có thể khiến đội mới làm sai.
Tiếp theo là tài khoản của môi trường chạy, tên miền, lưu trữ và các dịch vụ kết nối. Cần biết tài khoản đứng tên ai, ai trả phí và người mới được cấp quyền gì. Mã nguồn không thay thế quyền quản lý dịch vụ; cũng không nên gom mật khẩu và khóa truy cập vào một tài liệu chia sẻ rộng.
Giấy phép và thuê bao phải được kiểm tra riêng: phần nào được chuyển, phần nào chỉ được sử dụng và phần nào cần mua hoặc cấp lại. Nếu một dịch vụ không chuyển tài khoản được, phải thống nhất phương án thay thế và kiểm tra hoạt động trước khi đóng tài khoản cũ. Không suy ra quyền sở hữu chỉ từ việc đã thanh toán dự án.
Danh sách lỗi, hạn chế, hạn thuê bao và việc hẹn xử lý cũng là nội dung cần giao. Mỗi việc còn mở phải có người nhận, ảnh hưởng và mốc xác nhận. Nếu chỉ ghi “sẽ hỗ trợ sau”, đội mới sẽ khó biết phải chờ hay tự xử lý khi vấn đề xuất hiện.
Dữ liệu cũng cần có đường tiếp quản nếu doanh nghiệp dừng dùng một dịch vụ. Hãy xác nhận có thể lấy những dữ liệu nào, bằng định dạng gì và đội nhận có mở, đối chiếu được không. Một file xuất thành công chưa cho biết tệp đính kèm và quan hệ giữa các hồ sơ còn đủ. Chỉ xử lý dữ liệu và tài khoản cũ sau khi các yêu cầu lưu giữ đã được người có trách nhiệm xác nhận.
3. Để đội nhận thử thực hiện trước khi ký bàn giao
Hãy để đội nhận tự thực hiện một công việc đã thỏa thuận trên môi trường phù hợp. Ví dụ, họ triển khai bản thử từ tài liệu và mã được nhận, rồi kiểm tra một đơn đi hết quy trình. Bên bàn giao quan sát, ghi chỗ thiếu và chỉ hỗ trợ khi cần. Nếu người cũ vẫn thao tác toàn bộ, buổi trình diễn chưa chứng minh khả năng tiếp quản.
Khi bị vướng, xác định thiếu hướng dẫn, thiếu quyền hay thiếu một thành phần. Sửa đúng phần đó và cho người nhận thử lại. Có thể thử thêm đường nhận cảnh báo hoặc tìm bản sao lưu nếu thuộc phạm vi vận hành. Ghi rõ đã kiểm tra môi trường nào và phần nào chưa thử, tránh hiểu kết quả ở môi trường thử là bảo đảm cho mọi tình huống thật.
Nếu phần mềm được sửa trong thời gian bàn giao, cần cập nhật lại bộ tài liệu và phiên bản tham chiếu. Người nhận có thể đã thực hành trên bản trước trong khi môi trường thật đã thay đổi. Nêu rõ mốc chốt và những cập nhật xảy ra sau mốc đó sẽ giúp hai bên biết kết quả xác nhận còn áp dụng cho bản đang chạy hay phải kiểm tra lại.
4. Chốt trách nhiệm sau khi chuyển giao
Trước khi ký, hai bên cần thống nhất phần hỗ trợ vẫn tiếp tục: đầu mối nhận sự cố, thời gian hỗ trợ đã cam kết và phần sửa cần báo giá riêng. Bài Bảo trì phần mềm gồm những gì? giúp phân biệt trách nhiệm duy trì sau bàn giao với những tài sản đã được giao nhận.
Không nên đóng mọi tài khoản của bên cũ ngay nếu họ còn nhiệm vụ hỗ trợ được chấp thuận; cũng không giữ quyền rộng vô thời hạn. Mỗi quyền còn lại cần lý do, người kiểm soát và thời điểm xem lại. Khi chuyển trách nhiệm, phải có nơi nhận sự cố rõ ràng ngay từ đầu, không để khoảng chờ giữa hai đơn vị.
Việc rà quyền sau chuyển giao nên theo công việc thực sự còn được giao, không chỉ theo danh sách tài khoản cũ. Bài Phân quyền người dùng sao cho đúng việc? giải thích cách xác định quyền cần giữ, giới hạn và những thay đổi phải kiểm tra khi người phụ trách thay đổi.
Nếu chưa nhận đủ một mục quan trọng, biên bản cần thể hiện rõ phần thiếu và điều kiện hoàn tất, thay vì ký nhận chung. Bạn có thể trao đổi với Fenix từ người sẽ tiếp quản và những việc họ cần làm; đó là cơ sở để xây danh sách bàn giao có thể kiểm tra được.
