Làm sao để phối hợp hiệu quả với đội offshore?
Khi thuê một đội phát triển ở nước ngoài, doanh nghiệp thường băn khoăn liệu hai bên có hiểu đúng yêu cầu và công việc có đang đi theo kế hoạch hay không. Những câu hỏi này càng khó trả lời nếu người phụ trách phía khách hàng không có nhiều kinh nghiệm làm dự án phần mềm.
Bạn không cần biết lập trình để tham gia hiệu quả. Phần việc quan trọng của phía doanh nghiệp là giải thích công việc thực tế, kết nối những người có thể đưa ra quyết định và kiểm tra xem phần mềm có đáp ứng cách làm việc đã thống nhất hay chưa. Để làm được điều đó khi hai bên không cùng văn phòng, cần một cách trao đổi và theo dõi đủ rõ.
Bài viết tập trung vào việc phối hợp sau khi đã chọn đội phát triển offshore. Nếu bạn còn đang cân nhắc mô hình này, có thể đọc bài tổng quan trước.
1. Thống nhất ai trao đổi và ai quyết định
Một dự án có thể liên quan đến nhiều bộ phận, nhưng không phải ai cũng có cùng trách nhiệm. Người tổng hợp câu hỏi chưa chắc là người có quyền xác nhận quy trình; người duyệt ngân sách cũng chưa chắc trực tiếp kiểm tra từng chức năng.
Ví dụ giả định, doanh nghiệp đang xây hệ thống duyệt đề nghị mua sắm. Bộ phận mua hàng hiểu cách tiếp nhận đề nghị, tài chính xác nhận điều kiện ngân sách, còn người quản lý có quyền quyết định mức duyệt. Nếu mọi câu hỏi đều gửi cho một đầu mối nhưng người này không biết cần hỏi ai, đội phát triển có thể phải chờ hoặc tiếp tục làm dựa trên giả định.
Vì vậy, hai bên nên xác định người phụ trách cho từng nhóm vấn đề. Phía khách hàng cần biết ai làm rõ nghiệp vụ, ai xác nhận thay đổi và ai kiểm tra kết quả. Phía đội phát triển cũng cần có người tổng hợp tiến độ, giải thích vướng mắc và đưa câu hỏi đến đúng người.
Việc phân công không nhất thiết phải phức tạp. Với một dự án nhỏ, một người có thể đảm nhận nhiều vai trò, miễn là hai bên hiểu người đó được quyết định đến đâu và khi nào cần hỏi thêm người khác.
Cùng với đầu mối, nên thống nhất khung giờ có thể trao đổi, cách xử lý việc cần phản hồi sớm và người thay thế khi đầu mối vắng mặt. Nếu có chênh lệch múi giờ hoặc lịch nghỉ khác nhau, thông tin này cần được đưa vào kế hoạch để hai bên không vô tình chờ nhau.
2. Ghi lại yêu cầu để hai bên cùng hiểu
Trong quá trình làm việc, một yêu cầu có thể được nhắc đến trong cuộc họp, giải thích thêm qua tin nhắn rồi thay đổi sau khi xem bản thử. Nếu kết luận chỉ nằm rải rác ở những nơi đó, người thực hiện sẽ khó biết phiên bản nào đang được áp dụng.
Hai bên nên có một nơi lưu yêu cầu và các quyết định liên quan, chẳng hạn công cụ quản lý công việc hoặc tài liệu chung. Mỗi yêu cầu cần đủ thông tin để tìm lại phần đang trao đổi, nội dung đã xác nhận và câu hỏi còn mở.
Với hệ thống mua sắm ở trên, “thêm chức năng phê duyệt” vẫn còn nhiều cách hiểu. Đội phát triển cần biết ai gửi đề nghị, ai duyệt, điều gì xảy ra nếu bị từ chối và người gửi có được sửa rồi gửi lại không. Khi trao đổi theo những tình huống như vậy, phía doanh nghiệp có thể giải thích bằng công việc quen thuộc mà không cần tự viết đặc tả kỹ thuật.
Sau cuộc trao đổi, người phụ trách nên ghi lại kết luận để những người liên quan cùng kiểm tra. Nếu một điểm chưa được quyết định, hãy để rõ trạng thái đang chờ thay vì ghi chung với phần đã thống nhất. Khi có thay đổi sau đó, cần cập nhật lại tài liệu đang dùng.
Với dự án sử dụng nhiều ngôn ngữ, tên vai trò và trạng thái cũng nên được giải thích nhất quán. Chẳng hạn, “đã duyệt” có nghĩa là quản lý đã đồng ý hay tài chính đã xác nhận cả ngân sách? Nếu hai bên hiểu khác nhau, bản dịch đúng từ vẫn chưa đủ để xây đúng cách xử lý.
3. Xem tiến độ qua công việc có thể kiểm tra
Một báo cáo ghi “đã hoàn thành 80%” có thể khiến người nhận yên tâm, nhưng vẫn chưa cho biết phần nào đã dùng thử được và việc gì còn cản trở mốc tiếp theo. Muốn đánh giá tiến độ, cần hiểu nhóm công việc đang ở bước nào và kết quả nào có thể xem hoặc kiểm tra.
Ví dụ, đội phát triển đã viết xong chức năng gửi đề nghị mua sắm nhưng chưa kiểm tra với các quyền người dùng. Thông tin này khác với việc chức năng đã sẵn sàng để bộ phận mua hàng dùng thử. Hai bên cần thống nhất cách gọi trạng thái và điều kiện để chuyển sang bước tiếp theo.
Khi nhận cập nhật chưa rõ, người phụ trách có thể hỏi thêm:
| Thông báo tiến độ | Câu hỏi nên làm rõ |
|---|---|
| “Đã lập trình xong” | Đã kiểm tra đến đâu và khi nào phía khách hàng có thể xem hoặc dùng thử? |
| “Đang chờ xác nhận” | Cần quyết định điều gì, ai trả lời và việc chờ đang ảnh hưởng đến đâu? |
| “Đã sẵn sàng để kiểm tra” | Đó là phiên bản nào, kiểm tra ở đâu và đối chiếu với kết quả mong đợi nào? |
| “Đã xử lý phản hồi” | Nội dung nào đã sửa và ai sẽ kiểm tra lại tình huống từng gặp vấn đề? |
Không nhất thiết phải dùng cùng một bộ trạng thái cho mọi dự án. Điều cần đạt là khi đọc báo cáo, hai bên có cùng cách hiểu về phần đã làm, phần còn lại và những việc cần hỗ trợ.
Bên cạnh cập nhật bằng văn bản, nên có các buổi xem kết quả vào thời điểm phù hợp với kế hoạch. Với chức năng phê duyệt, thay vì chỉ xem từng màn hình, có thể đi qua một tình huống hoàn chỉnh: nhân viên tạo đề nghị, quản lý từ chối, nhân viên sửa và gửi lại.
Cách xem này giúp người hiểu nghiệp vụ nhận ra phần mềm có phản ánh đúng công việc hay không. Nếu có điều chưa phù hợp, hai bên có thể trao đổi trên cùng tình huống, thay vì chỉ nói chung rằng giao diện “chưa đúng ý”.
Tuy nhiên, một buổi trình bày thuận lợi chưa thay thế toàn bộ việc kiểm thử hoặc nghiệm thu. Khi chức năng đã sẵn sàng, cần sắp xếp người dùng kiểm tra theo phạm vi và tiêu chí của dự án.
4. Phản hồi rõ và xử lý những việc đang chờ
Sau khi xem kết quả, phản hồi càng cụ thể thì đội dự án càng dễ hiểu cần điều chỉnh ở đâu. Ví dụ, thay vì viết “phần duyệt chưa ổn”, có thể nêu: “Khi quản lý từ chối đề nghị, nhân viên chưa thấy lý do nên không biết cần sửa nội dung nào”.
Mô tả như vậy cho biết tình huống xảy ra, kết quả hiện tại và khó khăn của người dùng. Khi cần, có thể bổ sung ảnh chụp hoặc các bước thực hiện, nhưng không cần viết dài nếu vài câu đã đủ rõ.
Trong danh sách phản hồi, cũng nên phân biệt phần chưa đúng với nội dung đã thống nhất và nhu cầu mới xuất hiện khi dùng thử. Hai nhóm này có thể cần cách xử lý khác nhau. Nếu có đề xuất mới, đội dự án cần đánh giá ảnh hưởng trước khi đưa vào kế hoạch; không nên để một ý kiến trong cuộc họp tự trở thành công việc đã được chấp thuận.
Thay đổi yêu cầu khi đang phát triển phần mềm: Xử lý thế nào?
Ngoài phản hồi về sản phẩm, cần chú ý đến những câu hỏi đang làm công việc bị chờ. Một dòng “chờ khách xác nhận” sẽ hữu ích hơn nếu ghi rõ đang cần xác nhận điều gì, ai trả lời và nếu chậm thì phần việc nào bị ảnh hưởng. Phía khách hàng cũng nên báo lại khi cần thêm thời gian để đội phát triển xem xét điều chỉnh thứ tự công việc.
Với vấn đề có nhiều cách hiểu hoặc trao đổi qua tin nhắn chưa đi đến kết luận, một cuộc họp ngắn với đúng người có thể phù hợp hơn việc tiếp tục gửi thêm tài liệu. Sau cuộc họp, kết luận và người thực hiện vẫn cần được ghi lại để những người không tham dự có thể tiếp tục công việc.
Phối hợp với đội offshore vì thế đòi hỏi sự tham gia của cả hai bên. Khi trách nhiệm rõ, thông tin được cập nhật và kết quả được kiểm tra theo công việc thực tế, người phụ trách phía doanh nghiệp sẽ có cơ sở để theo dõi dự án và đưa ra quyết định, ngay cả khi không trực tiếp tham gia phần kỹ thuật.
Nếu đang chuẩn bị hợp tác với một đội offshore, doanh nghiệp có thể bắt đầu bằng việc thống nhất cách trao đổi yêu cầu, xem kết quả và xử lý thay đổi. Đây cũng là những nội dung nên làm rõ với đối tác phát triển trước khi bước vào công việc hằng ngày.
