Cách xác định nguyên nhân cốt lõi xung đột công nghệ

Vì vậy, nhận diện nguyên nhân cốt lõi không phải là tìm xem ai có lập luận kỹ thuật tốt hơn. Cần xác định điều gì khiến bất đồng tiếp tục tồn tại ngay cả khi các dữ kiện kỹ thuật đã được làm rõ. Phần còn lại đó thường chỉ ra lớp xung đột sâu hơn.

Hai bên nói về cùng một công nghệ nhưng đang bảo vệ những mục tiêu khác nhau

Một trong những dấu hiệu rõ nhất của nguyên nhân cốt lõi là hai bên cùng thảo luận một giải pháp nhưng sử dụng những tiêu chí thành công khác nhau.

Chẳng hạn, đội kỹ thuật có thể muốn thay một hệ thống vì kiến trúc hiện tại làm tăng độ phức tạp vận hành. Bộ phận kinh doanh lại phản đối vì quá trình chuyển đổi có thể làm chậm một kế hoạch ra mắt. Bộ phận tài chính quan tâm đến tổng chi phí, còn nhóm an toàn thông tin ưu tiên khả năng kiểm soát rủi ro.

Bề mặt của cuộc tranh luận là một lựa chọn công nghệ. Cấu trúc thật của nó lại là:

Cùng một quyết định → nhiều mục tiêu → nhiều cách đánh giá → kết luận khác nhau.

Trong trường hợp này, việc tiếp tục chứng minh rằng một công nghệ “tốt hơn” thường không giải quyết được xung đột. Cần hỏi mỗi bên đang cố tối ưu điều gì và điều gì họ không muốn đánh đổi.

Một số câu hỏi có giá trị chẩn đoán cao gồm:

·         Điều gì khiến phương án này được xem là thành công?

·         Nếu phải lựa chọn, yếu tố nào không thể hy sinh?

·         Rủi ro nào được mỗi bên coi là nghiêm trọng nhất?

·         Kết quả nào khiến một bên dù công nghệ hoạt động tốt vẫn xem quyết định là thất bại?

Nếu câu trả lời khác nhau đáng kể, vấn đề cốt lõi nhiều khả năng nằm ở xung đột mục tiêu hoặc ưu tiên, thay vì bản thân công nghệ.

Dữ kiện kỹ thuật không kết thúc được tranh cãi cho thấy bất đồng nằm ở tiêu chí đánh giá

Một dấu hiệu quan trọng khác xuất hiện khi các bên đã có cùng dữ liệu nhưng vẫn đi đến kết luận trái ngược.

Giả sử một thử nghiệm cho thấy phương án mới đáp ứng yêu cầu về hiệu năng. Một bên xem đó là bằng chứng đủ để triển khai, trong khi bên còn lại tiếp tục phản đối vì lo ngại khả năng phục hồi, chi phí chuyển đổi hoặc sự phụ thuộc vào nhà cung cấp.

Điều này không nhất thiết có nghĩa một bên thiếu hiểu biết. Hai bên có thể đang đặt trọng số khác nhau lên cùng một tập bằng chứng.

Cơ chế của xung đột khi đó thường là:

Dữ liệu giống nhau → tiêu chí khác nhau → trọng số khác nhau → quyết định khác nhau.

Do đó, trước khi thu thập thêm dữ liệu, cần kiểm tra xem hai bên đã thống nhất tiêu chí quyết định hay chưa. Nếu chưa có một chuẩn chung về điều gì quan trọng hơn, việc bổ sung thêm số liệu có thể chỉ làm cuộc tranh luận dài hơn.

Dấu hiệu đặc biệt đáng chú ý là khi mỗi bên liên tục đưa ra bằng chứng thuộc một nhóm khác nhau. Một bên nói về tốc độ, bên kia nói về độ ổn định; một bên nói về chi phí ngắn hạn, bên kia nói về khả năng mở rộng dài hạn. Các lập luận đều có thể đúng trong phạm vi riêng, nhưng chúng chưa thực sự trả lời cùng một câu hỏi.

Trong trường hợp đó, nguyên nhân cốt lõi thường là không thống nhất khung đánh giá, chứ không đơn thuần là thiếu thông tin.

Những lập luận lặp lại thường che giấu lợi ích, rủi ro hoặc quyền kiểm soát sâu hơn

Khi một luận điểm đã được giải đáp nhưng liên tục quay trở lại dưới hình thức khác, đó là tín hiệu nên tìm một lớp nguyên nhân sâu hơn.

Ví dụ, một nhóm liên tục nói rằng hệ thống mới “quá phức tạp”. Sau khi vấn đề kỹ thuật được giải thích, phản đối vẫn không giảm. Khi truy sâu hơn, nguyên nhân có thể là nhóm này sẽ phải chịu trách nhiệm vận hành một hệ thống mà họ chưa có năng lực hỗ trợ. “Quá phức tạp” khi đó chỉ là biểu hiện bề mặt của một lo ngại về trách nhiệm và khả năng kiểm soát.

Có thể hình dung ba tầng:

Phát biểu bề mặt: “Giải pháp này không phù hợp”

Lý do trực tiếp: “Nó làm tăng rủi ro vận hành”

Mối quan tâm cốt lõi: “Nhóm của tôi sẽ chịu trách nhiệm cho một rủi ro mà chúng tôi không kiểm soát được”

Càng đi xuống dưới, cuộc tranh luận càng ít mang hình thức thuần túy kỹ thuật.

Một cách truy nguyên hiệu quả là tiếp tục hỏi “tại sao điều đó quan trọng?” thay vì chỉ hỏi “tại sao anh/chị phản đối?”. Logic này tương đồng với tư duy phân tích nguyên nhân gốc: không dừng ở nguyên nhân đầu tiên có vẻ hợp lý mà tiếp tục kiểm tra quan hệ nguyên nhân cho đến khi tìm được yếu tố có khả năng giải thích nhiều biểu hiện cùng lúc.

Tuy nhiên, không nên áp dụng máy móc một số lượng câu hỏi “tại sao” cố định. Một chuỗi hỏi chỉ có giá trị khi mỗi bước thực sự làm rõ quan hệ nguyên nhân. Nếu câu hỏi bắt đầu dẫn sang suy đoán không có căn cứ, quá trình cần quay lại dữ kiện và lời giải thích trực tiếp của các bên.

Truy ngược lập luận bề mặt bằng giả định, nhu cầu và hệ quả mà mỗi bên đang bảo vệ

Để xác định nguyên nhân cốt lõi có hệ thống, có thể phân rã mỗi lập luận thành bốn lớp: quan điểm, lý do, giả định và lợi ích hoặc nhu cầu phía sau.

Giả sử một bên nói: “Không nên chuyển hệ thống này lên nền tảng mới.”

Quan điểm là không chuyển. Nhưng quan điểm chưa phải nguyên nhân.

Hỏi tiếp: “Vì sao?” Câu trả lời có thể là: “Quá trình chuyển đổi có rủi ro.”

Đó là lý do trực tiếp. Tiếp tục hỏi: “Rủi ro nào đáng lo nhất?” Có thể nhận được câu trả lời: “Nếu xảy ra sự cố, bộ phận của chúng tôi không đủ khả năng khôi phục nhanh.”

Đến đây đã xuất hiện một giả định quan trọng: năng lực khôi phục hiện tại không tương xứng với mức độ thay đổi.

Tiếp tục kiểm tra: “Tại sao điều đó đặc biệt quan trọng?” Câu trả lời có thể là: “Chúng tôi chịu trách nhiệm trực tiếp nếu dịch vụ gián đoạn.”

Lúc này, tranh luận đã chuyển từ “nền tảng mới có tốt hay không” sang một vấn đề cụ thể hơn: phân bổ trách nhiệm không tương xứng với khả năng kiểm soát rủi ro.

Đây là bước quan trọng vì nguyên nhân cốt lõi phải có sức giải thích. Một giả thuyết tốt không chỉ giải thích một câu nói mà còn phải giải thích vì sao một bên kiên trì với quan điểm của họ, vì sao một số bằng chứng không thuyết phục được họ và điều kiện nào có thể khiến họ thay đổi lập trường.

Khi áp dụng thực tế, nên ghi lại chuỗi:

Quan điểm → lý do → giả định → rủi ro hoặc lợi ích → nhu cầu cần bảo vệ

Chuỗi này giúp tránh lỗi phổ biến là coi phát biểu đầu tiên của một bên như nguyên nhân cuối cùng.

Cần phân biệt nguyên nhân cốt lõi với yếu tố kích hoạt và biểu hiện của xung đột

Không phải yếu tố xuất hiện ngay trước cuộc tranh cãi cũng là nguyên nhân cốt lõi.

Một bản cập nhật thất bại có thể làm cuộc tranh luận bùng nổ, nhưng đó có thể chỉ là yếu tố kích hoạt. Xung đột sâu hơn đã tồn tại từ trước dưới dạng thiếu niềm tin vào quy trình kiểm thử, bất đồng về quyền quyết định hoặc khác biệt trong mức chấp nhận rủi ro.

Tương tự, các cuộc họp căng thẳng, phản đối gay gắt hay việc các bên liên tục bác bỏ đề xuất chỉ là biểu hiện. Chúng cho biết xung đột tồn tại nhưng chưa giải thích vì sao nó tồn tại.

Có thể phân biệt ba lớp:

·         Biểu hiện: Điều có thể quan sát thấy trong tranh luận

·         Yếu tố kích hoạt: Sự kiện làm bất đồng trở nên rõ ràng hoặc nghiêm trọng hơn

·         Nguyên nhân cốt lõi: Điều kiện hoặc mâu thuẫn nền tảng khiến xung đột tiếp tục tái diễn

Một phép thử hữu ích là tưởng tượng loại bỏ yếu tố đang được nghi ngờ.

Nếu một sự cố kỹ thuật được khắc phục hoàn toàn nhưng các bên vẫn bất đồng về phương án tiếp theo, sự cố đó không phải nguyên nhân cốt lõi.

Nếu đổi công nghệ nhưng cuộc tranh luận tương tự lại xuất hiện quanh quyền phê duyệt, trách nhiệm vận hành hoặc mức chấp nhận rủi ro, nguyên nhân nhiều khả năng nằm ở lớp quản trị hoặc lợi ích.

Nguyên nhân cốt lõi vì thế thường có tính tái tạo xung đột: nếu không xử lý nó, tranh cãi có thể xuất hiện lại ngay cả khi đối tượng công nghệ cụ thể đã thay đổi.

Kiểm tra giả thuyết nguyên nhân cốt lõi trước khi kết luận

Một lời giải thích nghe hợp lý chưa đủ để được xem là nguyên nhân cốt lõi. Cần kiểm tra xem nó có thực sự giải thích được cấu trúc của cuộc xung đột hay không.

Có thể sử dụng bốn phép kiểm tra.

Thứ nhất là khả năng giải thích. Giả thuyết phải giải thích được nhiều hành vi hoặc lập luận quan sát được, thay vì chỉ khớp với một câu nói riêng lẻ.

Thứ hai là khả năng dự đoán thay đổi. Nếu nguyên nhân được xử lý, lập trường của các bên có khả năng thay đổi hay không? Chẳng hạn, nếu vấn đề thực sự là trách nhiệm vận hành, việc bổ sung cơ chế hỗ trợ và phân chia trách nhiệm hợp lý phải làm mức phản đối giảm xuống. Nếu không có thay đổi, giả thuyết ban đầu có thể chưa đúng.

Thứ ba là kiểm tra phản chứng. Cần chủ động tìm dữ kiện có thể bác bỏ kết luận của mình. Nếu cho rằng một bên phản đối vì chi phí nhưng họ vẫn phản đối khi chi phí đã được xử lý, phải tìm nguyên nhân khác thay vì cố bảo vệ chẩn đoán ban đầu.

Thứ tư là xác nhận trực tiếp với các bên liên quan. Phân tích hành vi có thể tạo giả thuyết, nhưng không nên biến suy đoán về động cơ thành sự thật. Những câu hỏi như “Nếu rủi ro này được xử lý, anh/chị có còn phản đối không?” thường hữu ích hơn việc tự gán động cơ cho người khác.

Một nguyên nhân cốt lõi đáng tin cậy thường đáp ứng được chuỗi logic:

Nó giải thích được xung đột hiện tại → phù hợp với dữ kiện → có thể bị kiểm chứng → khi được xử lý, cấu trúc bất đồng thay đổi.

Xác định nguyên nhân cốt lõi của xung đột công nghệ vì thế không bắt đầu bằng câu hỏi “công nghệ nào đúng hơn”, mà bằng câu hỏi “điều gì đang khiến những người có cùng dữ kiện vẫn không thể đi đến cùng một quyết định?”. Các dấu hiệu đáng chú ý nhất là sự khác biệt về mục tiêu, tiêu chí đánh giá, mức chấp nhận rủi ro, trách nhiệm, quyền kiểm soát và các giả định nền.

Khi tách được quan điểm khỏi lợi ích phía sau, phân biệt được biểu hiện với yếu tố kích hoạt và kiểm chứng giả thuyết nguyên nhân bằng khả năng giải thích lẫn phản chứng, cuộc tranh cãi sẽ trở nên dễ chẩn đoán hơn. Lúc đó, công nghệ được đặt trở lại đúng vị trí: một đối tượng của quyết định, không mặc nhiên là nguyên nhân của xung đột.

:::