Nghịch lý Đồng ý: Làm Chủ Giao Tiếp và Phản hồi với Đội ngũ Việt Nam của Bạn

Nếu bạn đã quản lý một đội phát triển phần mềm Việt Nam ở nước ngoài, bạn có thể đã gặp phải "Nghịch lý đồng ý". Bạn hỏi một nhà phát triển xem liệu một tính năng phức tạp có thể được hoàn thành vào thứ Sáu hay không. Họ mỉm cười, gật đầu và nói, "Có". Thứ Sáu đến, tính năng vẫn thiếu, và bạn tự hỏi liệu có sự thiếu trung thực hay năng lực hay không.

Là một người kỳ cựu trong cả chu kỳ sản phẩm Thung lũng Silicon và các trung tâm kỹ thuật Đông Nam Á, tôi có thể nói với bạn: đó không phải là cả hai. Những gì bạn gặp phải là một thuật toán văn hóa tinh vi được gọi là "Giữ thể diện" (giữ thể diện). Trong thế giới CNTT toàn cầu có mức độ rủi ro cao, việc hiểu được nghịch lý này là sự khác biệt giữa một dự án có thể mở rộng và một dự án bị đình trệ.

Giải mã "Có": Bối cảnh cao so với Bối cảnh thấp

Để quản lý một đội CNTT nước ngoài hiệu quả, bạn phải hiểu công trình của nhà nhân chủng học Edward T. Hall về văn hóa bối cảnh cao so với văn hóa bối cảnh thấp. Các nền văn hóa phương Tây (Mỹ, Úc, Đức) là "Bối cảnh thấp". Chúng ta ưu tiên các hướng dẫn bằng lời nói rõ ràng. Chúng ta nói chính xác những gì chúng ta muốn nói.

Việt Nam là một nền văn hóa "Bối cảnh cao". Giao tiếp có nhiều lớp lang. Một tiếng "Có" thường không có nghĩa là "Tôi đồng ý rằng nhiệm vụ này có thể khả thi về mặt kỹ thuật vào thứ Sáu". Nó thường có nghĩa là:

• "Tôi hiểu bạn"
   

• "Tôi tôn trọng thẩm quyền của bạn với tư cách là người lãnh đạo"
   

• "Tôi muốn duy trì sự hòa hợp trong cuộc họp này"

Trong khuôn khổ này, việc nói "Không" trong một cuộc họp công khai được coi là "mất thể diện" đối với cả nhà phát triển (người có vẻ không có khả năng) và người quản lý (người có vẻ đã đưa ra một yêu cầu vô lý). Để thu hẹp khoảng cách giao tiếp trong gia công này, bạn phải thay đổi cách bạn hỏi, chứ không chỉ là những gì bạn hỏi.

Chuyển từ "Cái gì" sang "Như thế nào": Quy tắc Ba

Một trong những chiến lược hiệu quả nhất mà tôi đã triển khai để bỏ qua "Nghịch lý đồng ý" là Quy tắc Ba. Thay vì đặt câu hỏi nhị phân ("Bạn có thể làm điều này không?"), hãy hỏi ba hướng thực hiện riêng biệt.

Ví dụ: "Thay vì cho tôi biết liệu điều này có khả thi không, bạn có thể cho tôi thấy ba cách chúng ta có thể tiếp cận kiến ​​trúc này được không? Một cách 'nhanh', một cách 'có thể mở rộng' và một cách 'lý tưởng'."

Bằng cách chuyển trọng tâm từ nhị phân "Có/Không" sang thảo luận kỹ thuật đa lựa chọn, bạn loại bỏ áp lực xã hội để "Giữ thể diện". Bạn cho nhà phát triển sự an toàn về tâm lý để làm nổi bật rủi ro dưới vỏ bọc "đánh giá sự đánh đổi". Điều này phù hợp hoàn hảo với Agile tại Việt Nam, nơi mục tiêu là lặp lại nhanh chóng dựa trên phản hồi kỹ thuật trung thực.

An toàn tâm lý trong kỹ thuật trong Đánh giá mã

Trong nhiều hệ thống giáo dục Việt Nam, phân cấp được tôn trọng nghiêm ngặt. Điều này có thể dẫn đến "Thiên vị thâm niên" khi các nhà phát triển cấp dưới ngần ngại chỉ ra những sai sót trong mã của cấp trên. Trong lực lượng lao động CNTT hiện đại, đây là công thức cho nợ kỹ thuật.

Để giải quyết vấn đề này, các nhóm chuyên nghiệp áp dụng các vòng lặp Phản hồi Vô đồng bộ và Vô danh. Các công cụ như hệ thống yêu cầu kéo của GitHub là một món quà ở đây. Khi phản hồi được viết thay vì được nói, và được đóng khung là "Đánh giá về Mã" thay vì "Phê bình về Người", rào cản văn hóa đối với sự thẳng thắn sẽ biến mất.

Thông tin chuyên môn: Sử dụng quy tắc "Khen ngợi công khai, Sửa lỗi riêng tư". Nếu bạn phải đưa ra phản hồi gay gắt, hãy thực hiện nó trong cài đặt 1-1. Sửa lỗi công khai một nhà phát triển trong cuộc gọi Zoom với 10 người sẽ khiến họ "tắt máy" để bảo vệ địa vị xã hội của mình.

Các câu hỏi thường gặp (FAQ)

"Nghịch lý đồng ý" có nghĩa là tôi không thể tin tưởng thời hạn của nhóm mình không?

Không hề. Nó có nghĩa là bạn cần xác thực "Có" bằng dữ liệu. Sử dụng biểu đồ thời gian hoàn thành Jira và báo cáo sprint tự động của bạn làm "Nguồn sự thật". Nếu dữ liệu cho biết một tác vụ đang bị trễ nhưng nhà phát triển nói "Có", hãy sử dụng dữ liệu làm bên thứ ba trung lập để bắt đầu cuộc trò chuyện: "Biểu đồ cho thấy chúng ta đang ở mức 40%, làm thế nào để chúng ta gỡ bỏ chặn điều này?"

Làm thế nào để tôi khuyến khích các nhà phát triển Việt Nam của tôi lên tiếng trong các cuộc họp?

Cấu trúc các cuộc họp của bạn. Thay vì hỏi "Có ai có câu hỏi nào không?", hãy gọi tên từng cá nhân để lấy thông tin đầu vào kỹ thuật cụ thể: "Long, dựa trên công việc của bạn với API, bạn thấy rủi ro lớn nhất ở đây là gì?" Việc giao cho một nhà phát triển "sàn" một cách rõ ràng khiến họ có trách nhiệm chia sẻ kiến ​​thức hơn là một hành động "cắt ngang".

Khả năng thông thạo tiếng Anh có phải là nguyên nhân gốc rễ của những khoảng trống giao tiếp này không?

Hiếm khi. Mặc dù Khả năng thông thạo tiếng Anh ở Việt Nam đã có sự cải thiện đều đặn, "Nghịch lý đồng ý" vẫn tồn tại ngay cả trong số những người nói thông thạo. Nó là một hệ điều hành xã hội, không phải là một hệ thống ngôn ngữ. Hãy tập trung vào quá trình phản hồi, không chỉ là vốn từ vựng.

Cách tốt nhất để xử lý thời hạn bị bỏ lỡ là gì?

Tránh "Ngôn ngữ đổ lỗi". Thay vì "Tại sao bạn không nói với tôi rằng bạn đã bị trễ?", hãy sử dụng "Mốc thời gian đã thay đổi. Những sự phụ thuộc kỹ thuật nào đã mất nhiều thời gian hơn dự kiến?" Điều này mời một phân tích kỹ thuật thay vì một sự bảo vệ cá nhân.

Kết luận: Chuyển đổi thành Đối tác Đổi mới

Khi bạn làm chủ các sắc thái trong giao tiếp của Việt Nam, nhóm của bạn sẽ không còn là "người thực hiện" nữa mà bắt đầu là Đối tác Đổi mới. Bằng cách tạo ra một văn hóa an toàn về tâm lý và sử dụng các khuôn khổ quản lý phù hợp, bạn sẽ mở khóa toàn bộ sức mạnh của "DNA Toán học" mà chúng ta đã thảo luận ở đây