Nhiều chủ doanh nghiệp ngại thuê ngoài lập trình vì một lo lắng rất thật: mình không đọc được mã nguồn, thì làm sao biết đội kia làm tốt hay không? Đến lúc phát hiện phần mềm chạy chập chờn, sửa chỗ này hỏng chỗ kia, thì tiền và thời gian đã đi khá xa.
Tin tốt là kiểm soát chất lượng phần lớn không nằm ở việc đọc mã. Nó nằm ở chỗ bạn định nghĩa kết quả rõ ràng, nhìn thấy sản phẩm chạy thật thường xuyên, và giữ những thứ quan trọng trong tay mình. Những việc đó người không làm kỹ thuật hoàn toàn làm được.
Viết rõ thế nào là "xong" trước khi bắt đầu
Phần lớn tranh cãi giữa doanh nghiệp và đội thuê ngoài không phải vì đội làm kém, mà vì hai bên hiểu chữ "xong" khác nhau. Bạn nghĩ "chức năng đặt hàng" bao gồm cả gửi email xác nhận và in phiếu giao; đội lập trình nghĩ chỉ cần lưu được đơn.
Ảnh: Shixart1985, CC BY 2.0, qua Wikimedia Commons.
Cách tránh: với mỗi tính năng, viết ra vài tình huống cụ thể bằng ngôn ngữ của người dùng, kiểu:
- Khách đặt 2 sản phẩm, một sản phẩm hết hàng → hệ thống báo gì, đơn có được tạo không?
- Nhân viên sửa đơn sau khi đã xác nhận → ai được sửa, có lưu lại lịch sử không?
- Mở trên điện thoại → các nút có bấm được bằng một tay không?
Danh sách này chính là tiêu chí nghiệm thu. Bạn không cần biết kỹ thuật để viết nó, vì nó mô tả công việc của chính bạn. Một đội làm nghiêm túc sẽ hỏi thêm để bổ sung, chứ không nhận việc khi tiêu chí còn mơ hồ.
Xem phần mềm chạy thật, không chỉ đọc báo cáo
Báo cáo bằng chữ ghi "đã hoàn thành 80%" không nói được nhiều. Thứ cho bạn biết sự thật là phần mềm chạy được trước mặt bạn.
Ảnh: Robert Scoble, CC BY 2.0, qua Wikimedia Commons.
Khi đội làm theo từng chặng ngắn (sprint) và demo cuối mỗi chặng, hãy tận dụng buổi demo:
- Tự tay bấm, đừng chỉ xem người khác thao tác. Lỗi thường lộ ra khi người dùng thật làm theo cách mình quen, không theo kịch bản đội đã chuẩn bị.
- Thử các tình huống trong danh sách nghiệm thu, đặc biệt các trường hợp ngoại lệ: nhập sai, bỏ trống, bấm hai lần.
- Gọi người sẽ dùng hằng ngày — nhân viên kho, kế toán, thu ngân — cùng thử. Họ thấy những điều bạn không thấy.
- Ghi lại phản hồi bằng văn bản sau buổi demo, để chặng sau có căn cứ đối chiếu.
Nếu sau vài chặng mà bạn vẫn chưa được thấy phần mềm chạy, chỉ nhận được báo cáo và hình chụp, đó là tín hiệu cần hỏi lại ngay.
Đọc báo cáo tuần để tìm rủi ro, không tìm lời khen
Một báo cáo tuần có ích thường trả lời ba câu: việc gì đã xong, việc gì đang làm, và việc gì cần bạn quyết định. Phần thứ ba quan trọng nhất và hay bị bỏ qua nhất.
Khi đọc, hãy để ý:
- Một đầu việc nằm ở mục "đang làm" nhiều tuần liền mà không có giải thích → có thể đội đang vướng mà chưa nói.
- Mục rủi ro luôn trống → hiếm dự án nào thật sự không có rủi ro; trống mãi thường là chưa ai chịu nhìn.
- Câu hỏi đội gửi cho bạn bị treo lâu → chậm trễ lúc này nằm ở phía bạn, và nó sẽ đẩy lùi tiến độ chung.
Trả lời nhanh các câu hỏi của đội là một cách kiểm soát chất lượng mà nhiều doanh nghiệp không nghĩ tới: đội phải đoán thay bạn càng ít thì phần mềm càng đúng ý.
Giữ những thứ quan trọng đứng tên doanh nghiệp
Đây là phần chỉ mất một buổi để làm, nhưng bảo vệ bạn lâu dài, kể cả khi hai bên dừng hợp tác.
- Kho mã nguồn (repository): tạo bằng tài khoản của doanh nghiệp, mời đội thuê ngoài vào làm. Nếu đội dùng kho của họ, thống nhất lịch bàn giao định kỳ trong hợp đồng.
- Tên miền, máy chủ, dịch vụ đám mây, tài khoản cửa hàng ứng dụng: đăng ký đứng tên doanh nghiệp, cấp quyền cho đội khi cần, thu hồi khi kết thúc.
- Tài liệu: mô tả cách cài đặt, cách triển khai, mật khẩu quản trị — lưu ở nơi bạn kiểm soát, không chỉ nằm trong máy của một lập trình viên.
Khi những thứ này nằm trong tay bạn, đổi đội hay thêm người đều không phải bắt đầu lại từ đầu.
Nhờ một người ngoài rà lại ở các mốc quan trọng
Bạn không đọc được mã nguồn, nhưng có thể nhờ người đọc được. Một lập trình viên độc lập, hoặc người quen có kinh nghiệm, rà lại mã ở các mốc lớn (trước khi đưa vào chạy thật, trước khi thanh toán đợt lớn) sẽ cho bạn cái nhìn thứ hai về những điều demo không thể hiện được: mã có dễ bảo trì không, có lỗ hổng bảo mật rõ ràng không, có tài liệu không.
Đội thuê ngoài làm tốt thường không ngại việc này. Nếu đội phản ứng gay gắt hoặc tìm cách trì hoãn khi bạn đề nghị cho người ngoài xem mã, đó cũng là một thông tin đáng giá.
Những dấu hiệu nên dừng lại để hỏi
- Mỗi lần sửa một lỗi lại thấy lỗi khác xuất hiện ở chỗ đã chạy ổn.
- Câu trả lời cho câu hỏi "khi nào xong" thay đổi mỗi tuần mà không kèm lý do.
- Người làm việc với bạn thay đổi liên tục, mỗi lần lại phải giải thích lại từ đầu.
- Bạn không được cấp quyền truy cập vào kho mã hay môi trường chạy thử.
- Mọi đề xuất thay đổi đều được nhận ngay, không ai nói về ảnh hưởng tới tiến độ hay chi phí.
Không dấu hiệu nào trong số này tự nó có nghĩa là đội làm kém. Nhưng gặp từ hai dấu hiệu trở lên, nên ngồi lại với đội để làm rõ trước khi đi tiếp.
Cách HD Web Services làm
Khi nhận outsourcing, chúng tôi làm theo sprint: lên kế hoạch đầu sprint, demo cuối sprint để bạn thấy phần mềm chạy, không chỉ đọc báo cáo. Mỗi tuần bạn nhận báo cáo gồm việc đã xong, việc đang làm và rủi ro cần bạn quyết định. Đội làm việc trực tiếp trên kho mã của bạn, hoặc bàn giao định kỳ nếu dùng kho của chúng tôi, và ký thoả thuận bảo mật (NDA) trước khi trao đổi chi tiết dự án. Nếu một thành viên không phù hợp, bạn báo lại, chúng tôi trao đổi nguyên nhân và thay người khi cần, đồng thời lo việc bàn giao công việc giữa hai người.
Nếu bạn đang cân nhắc thuê ngoài lần đầu, đọc thêm bài chọn mô hình thuê ngoài lập trình, hoặc kể cho chúng tôi nghe dự án của bạn.