Nên thuê offshore theo dự án hay theo đội ngũ?
Thuê offshore là hợp tác với đội phát triển ở một quốc gia khác. Nhưng khi chọn cách hợp tác, câu hỏi không chỉ là cần bao nhiêu kỹ sư. Doanh nghiệp phải biết muốn giao một kết quả đã xác định hay cần người cùng phát triển và điều chỉnh sản phẩm liên tục.
Bài viết dùng hai ví dụ giả định: xây cổng tiếp nhận yêu cầu với đầu ra rõ và duy trì một sản phẩm còn thay đổi theo phản hồi. Các tên gọi “theo dự án” hay “theo đội ngũ” chỉ giúp mở cuộc trao đổi; trách nhiệm, cách tính phí và điều kiện nhân sự phải được xác nhận trong đề xuất thực tế.
1. Giao dự án hay thuê đội ngũ khác nhau ở đâu?
Theo dự án, hai bên tập trung vào phạm vi, đầu ra và tiêu chí xác nhận. Ví dụ cổng tiếp nhận có các bước gửi, phân công và theo dõi đã thống nhất. Đối tác tổ chức triển khai trong phạm vi được giao, còn doanh nghiệp cung cấp thông tin, giải đáp nghiệp vụ và xác nhận kết quả. Giao dự án không có nghĩa khách hàng hết phần việc.
Theo đội ngũ, hai bên duy trì một năng lực làm việc trong thời gian thỏa thuận, còn công việc có thể được sắp xếp theo ưu tiên sản phẩm. Ví dụ, đội lần lượt cải thiện chức năng theo phản hồi từ vận hành. Cần biết ai biến mục tiêu thành việc đủ rõ, chọn ưu tiên và kiểm tra phần đã hoàn thành; thuê người không tự tạo ra vai trò quản lý sản phẩm.
Hai cách này không tự tương ứng với giá cố định hoặc trả theo giờ. Một dự án có thể được chia giai đoạn và tính phí theo điều kiện đã thỏa thuận; một đội ngũ vẫn có đầu ra và trách nhiệm chất lượng. Cần đọc đề xuất về phạm vi, nguồn lực và cơ chế thay đổi thay vì suy ra nghĩa vụ từ tên gói dịch vụ.
2. Chọn theo công việc và khả năng tham gia
Công việc có đầu ra khá ổn định, người xác nhận rõ và các kết nối quan trọng đã được khảo sát có thể phù hợp để cân nhắc giao theo dự án. Tuy vậy, nếu cổng tiếp nhận còn một kết nối chưa rõ, nên làm rõ phần đó trước khi coi toàn bộ phạm vi đã chắc chắn. Ép chốt mọi thứ quá sớm có thể tạo nhiều lần điều chỉnh về sau.
Sản phẩm liên tục thay đổi có thể cần đội làm việc lâu dài để giữ kiến thức và phản hồi nhanh hơn. Nhưng lợi ích này phụ thuộc vào nhân sự thực tế, tài liệu và cách chuyển giao khi thay người. Cần hỏi độ ổn định, cách thay thế và thời gian để người mới hiểu sản phẩm, không mặc định đội chuyên trách sẽ luôn giữ nguyên thành viên.
Doanh nghiệp cũng phải xem mình có thể tham gia đến đâu. Một người phụ trách chỉ có mặt để duyệt cuối tháng sẽ khó giải quyết các quyết định hằng ngày cho đội liên tục. Nếu thiếu năng lực đó, có thể thỏa thuận đối tác đảm nhận thêm quản lý, nhưng cần xác định quyền quyết định nào vẫn thuộc doanh nghiệp và khi nào phải phản hồi.
Dù chọn mô hình nào, thông tin nghiệp vụ và phản hồi vẫn phải đi qua đầu mối rõ ràng. Bài Làm sao để phối hợp hiệu quả với đội offshore? giúp tổ chức việc trao đổi và xác nhận để các phòng ban không giao những ưu tiên khác nhau trực tiếp cho từng kỹ sư.
Một đầu ra rõ vẫn có thể phù hợp với đội lâu dài nếu doanh nghiệp đã có sản phẩm cần duy trì sau lần ra mắt. Ngược lại, sản phẩm nhiều bất định có thể bắt đầu bằng dự án khảo sát giới hạn. Vì vậy, hãy tách quyết định về giai đoạn trước mắt khỏi cách hợp tác dài hạn, rồi ghi rõ điều kiện để đánh giá lại thay vì chọn một tên mô hình cho mọi phần việc.
Nếu cần thay một thành viên, phải biết kiến thức và việc đang làm được chuyển cho ai, ai kiểm tra và việc thay người ảnh hưởng kế hoạch ra sao. Những điều này nên được hỏi ở cả hai mô hình. Cam kết có đội ngũ không thay thế được một cách chuyển giao thực tế, cũng như giao theo dự án không làm mất nhu cầu duy trì kiến thức trong quá trình thực hiện.
3. Làm rõ trách nhiệm trước khi so sánh chi phí
Đặt cùng một yêu cầu lên hai đề xuất để so sánh: ai làm rõ yêu cầu, thiết kế, kiểm thử, triển khai và hỗ trợ sau phát hành? Nếu một báo giá gồm quản lý và kiểm thử còn báo giá kia chỉ gồm phát triển, số tiền thấp hơn chưa cho thấy phương án nào có tổng chi phí phù hợp hơn.
Cũng cần xác nhận cách đo hoàn thành. Theo dự án, có thể kiểm tra đầu ra từng giai đoạn. Theo đội ngũ, cần biết việc ưu tiên nào được hoàn tất, chất lượng và phần bị hoãn. Số người có mặt hoặc số giờ đã làm chưa đủ để biết công việc quan trọng đã tạo kết quả gì.
Tính cả công việc phía doanh nghiệp: họp xác nhận, chuẩn bị dữ liệu, kiểm tra và hướng dẫn người dùng. Cần biết khi người chủ chốt không sẵn sàng thì công việc được chờ, thay thế hay đổi ưu tiên. Một phương án có nhiều kỹ sư hơn nhưng thiếu người ra quyết định ở phía khách hàng vẫn có thể bị tắc.
4. Thống nhất cách bắt đầu, thay đổi và kết thúc
Khi công việc thay đổi, cần biết ai đánh giá ảnh hưởng và ai chấp nhận phần phải dời lại. Bài Yêu cầu thay đổi giữa dự án: Xử lý thế nào? giúp thống nhất cơ chế này để tính linh hoạt không biến thành việc nhận thêm yêu cầu mà không có quyết định.
Có thể bắt đầu bằng một giai đoạn khảo sát hoặc một phần đầu ra nhỏ để kiểm tra cách phối hợp, rồi mới quyết định phạm vi tiếp. Giai đoạn đầu cần mục tiêu và kết quả xác nhận rõ, không chỉ kéo dài để làm quen. Kết hợp mô hình cũng phải có ranh giới trách nhiệm, không để phần chuyển tiếp bị cả hai bên hiểu khác nhau.
Kết thúc một giai đoạn hoặc đổi đội không nên đồng nghĩa mất kiến thức sản phẩm. Bài Bàn giao phần mềm sao cho đội mới tiếp quản được? giúp chuẩn bị tài liệu, quyền và bước người nhận tự thực hiện để việc chuyển tiếp có thể kiểm tra được.
Bạn có thể trao đổi với Fenix từ độ rõ của công việc, hướng phát triển và người có thể tham gia phía doanh nghiệp. Đó là cơ sở chọn cách hợp tác và phân công trước khi chốt một danh sách nhân sự hoặc so giá theo đầu người.
