Lúc mới chuyển ngành chị tiếp quản 1 dự án cũng khá lớn, khoảng 400 mandays. PM cũ nghỉ việc, team cũ còn đúng 2 người, bên khách hàng cũng đổi tới 3 PM, team khách hàng cũng nghỉ việc quá trời, hỏi lại scope cũ đã thoả thuận họ cũng chẳng rõ, rồi mấy PM cũ của 2 bên hứa hẹn gì với nhau mà không có document lại gì hết, họ cứ khăng khăng là giờ họ muốn thế này mới đáp ứng được nhu cầu của họ. Rồi PM cũ bên chị hứa hươu hứa vượn hứa tới cung trăng luôn nên câu cửa miệng của họ là “nhưng mà anh PM cũ nói thế này”, “Sao hồi trước công ty chị hứa thế này”. Còn nội bộ thì câu cửa miệng của team là “chị chẳng biết gì hết á”.
Scope thay đổi từa lưa, thành phẩm thì rối mù, bugs quá trời mà bên khách hàng lẫn bên mình không test, không sửa được. Project đáng lẽ tới milestone UAT mà bên khách hàng không chịu. Issue logs tính tới hàng trăm. Budget dĩ nhiên bị over nghiêm trọng rồi.
Chị phải pick resource lại cho team dự án, mô tả lại tình hình dự án cho team. Tìm giải pháp, review lại code và tìm lại nhiều document nhất có thể. Họp với khách hàng nhiều lần để thống nhất lại scope và phương pháp test, rồi đập đi xây lại vài function theo thống nhất với khách. Mất mấy tháng trời mới UAT được mà chỉ còn minor bugs, rồi lại mất mấy tháng để go-live.
Mà pick resource lại cho team thì lúc đó công ty chị không có nhiều lựa chọn vì dự án đó bể quá, ai nghe cũng chạy, không chịu vào team. Chị đành lựa một bạn BA cũng mới chuyển ngành và một bạn Tech Lead cứng. Nhưng cũng gặp khó khăn vì bạn BA thì mới, chị cũng mới, đành ngồi mò cùng nhau. Bạn Dev thì giỏi nhưng bạn ấy không coi trọng PM không có Tech background, tại kiểu bạn nói chị cũng không theo kịp. View của chị là từ business qua, của bạn là thuần Tech, có nhiều cái bạn muốn làm cho kỹ nhưng budget không cho phép, cũng cãi nhau nhiều lắm.
>>Tìm hiểu thêm về Business Analyst (BA) tại đây !
Chưa kể team khách hàng cũng đổi liên tục nên chính họ cũng không hiểu scope ban đầu là gì, data của họ thì loạn, không cung cấp được lean data để test chính xác. Mà họ có ấn tượng xấu về mình nữa, giao tiếp cũng khó khăn lắm. Ngày nào chị cũng nghe complain, từ nội bộ đến khách hàng, stress dã man. Nghĩ lại thấy dự án đó ác mộng!
Chắc hẳn trong vai trò quản lý dự án, bạn đã không ít lần chứng kiến sự xung đột tương tự như câu chuyện của Project Manager (PM) một công ty ITO tại Hà Nội kể trên. Vậy, đã bao giờ bạn suy nghĩ kĩ hơn về bản chất xung đột là gì, nguyên nhân dẫn đến xung đột, hay làm thế nào để giải quyết xung đột? Hãy cùng khám phá các chiến lược và kỹ thuật để giải quyết xung đột trong nhóm dưới góc nhìn của chuyên gia thực chiến nhé!
Xung đột là một phần không thể tránh khỏi trong các nhóm dự án. Theo Sách Kiến thức Quản lý Dự án (PMBOK), quản lý xung đột là một trong những thách thức lớn nhất mà Project Manager (PM) phải đối mặt. Theo báo cáo “Workplace Conflict and How Businesses Can Harness It to Thrive” của The Myers-Briggs Company, 85% số người được hỏi cho biết họ phải giải quyết xung đột ở một mức độ nào đó và 29% còn lại giải quyết xung đột gần như liên tục.
4 Loại xung đột nhóm thường gặp khi làm việc nhóm
Chia sẻ về vấn đề này, chuyên gia Huỳnh Thiện Khiêm – Agile Coach, Roche Pharma Việt Nam, với hơn 20 năm kinh nghiệm trong lĩnh vực phần mềm và thực hành, huấn luyện các đội nhóm triển khai Scrum, Kanban thành công, cho biết: tình huống xung đột là những tình huống mà mối quan tâm của hai người không tương thích với nhau. Trong đó, xung đột có thể được chia thành 5 cấp độ theo mô hình của Speed B.Leas – một chuyên gia về quản lý và giải quyết xung đột, bao gồm:
Ngôn ngữ, lời nói của hai bên cởi mở, thảo luận tích cực dựa trên những thông tin, dữ liệu, dữ kiện
Ngôn từ, lời nói bắt đầu mang tính thiếu tính xây dựng, mang tính chủ quan, chủ yếu nhằm mục đích bảo vệ bản thân, muốn luận điểm của mình là ưu thế lớn hơn nhu cầu giải quyết vấn đề.
Ngôn từ mang tính công kích, kiểu “nâng cao quan điểm” với mục tiêu chiến thắng cho bản thân chứ không nhằm giải quyết vấn đề
Chia phe phái và tấn công nhau, ngôn từ mang tính lý tưởng, nguyên tắc. Nhóm bị phân mảnh thành các phe phái và họ cố gắng lôi kéo sự ủng hộ về phe mình, để tấn công phe kia.
Một mất một còn
Thông qua mô hình này, chúng ta có thể phân tích tình trạng xung đột hiện tại bằng cách quan sát ngôn ngữ được các bên sử dụng để chẩn đoán và cuối cùng chọn ra chiến lược tốt nhất để giảm leo thang xung đột.
Với vai trò là người điều phối hoặc hòa giải – điều quan trọng là luôn phải khách quan, cố gắng tách biệt cảm xúc khỏi câu chuyện về các sự kiện đang diễn ra và cố gắng hết sức để giúp những người liên quan đến xung đột giảm leo thang và tiếp tục tiến về phía trước.
Xung đột có thể đến từ nội bộ team dự án hoặc giữa team dự án với bên ngoài, giống như câu chuyện ở trên. Với vai trò là PM, điều quan trọng là phải nhận ra rằng xung đột có thể phát sinh do sự khác biệt về quan điểm, phong cách làm việc hoặc các vấn đề liên quan đến dự án.
Cũng theo chuyên gia Huỳnh Thiện Khiêm, nguyên nhân gây xung đột trong nhóm thường xuất phát từ:
Giải quyết hiệu quả xung đột trong nhóm là điều cần thiết để duy trì năng suất, thúc đẩy môi trường làm việc tích cực và đảm bảo sự thành công của dự án.
Vậy Project Manager nên làm gì:
Theo Speed B.Leas, mục tiêu trong việc quản lý xung đột là hạ thấp từng cấp độ (trừ cấp độ đầu tiên) xuống cấp độ dễ quản lý hơn, nếu có thể. Tùy từng tình huống, với vai trò là Project Manager, bạn có thể vận dụng linh hoạt các chiến lược quản lý xung đột, theo đó mức độ hợp tác hoặc mức độ căng thẳng giữa các bên. Sau đây là 5 cơ chế xử lý xung đột của Thomas Kilmann mà bạn có thể tham khảo:
5 cơ chế xử lý xung đột của Thomas Kilmann mà bạn có thể tham khảo
Đây là một chiến lược trong đó một bên nhượng bộ những mong muốn hoặc yêu cầu của bên kia. Họ hợp tác nhưng không quyết đoán. Đây có vẻ là một cách nhân từ để nhượng bộ khi một người nhận ra rằng mình đã sai trong một cuộc tranh luận. Sẽ ít hữu ích hơn khi một bên giúp đỡ bên kia chỉ để duy trì sự hòa hợp hoặc để tránh sự gián đoạn.
Một chiến lược khác là thỏa hiệp, trong đó những người tham gia có phần quyết đoán và hợp tác. Quan niệm là mọi người đều từ bỏ một chút những gì họ muốn và không ai có được mọi thứ họ muốn. Nhận thức về kết quả tốt nhất khi làm việc theo thỏa hiệp là điều “chia đôi sự khác biệt”. Thỏa hiệp được coi là công bằng, ngay cả khi không ai đặc biệt hài lòng với kết quả cuối cùng.
4. Xử lý xung đột kiểu lảng tránh
Né tránh là khi mọi người phớt lờ hoặc rút lui khỏi cuộc xung đột. Họ chọn phương pháp này khi sự khó chịu của việc đối đầu vượt quá lợi ích tiềm tàng của việc giải quyết xung đột. Với các vấn đề ít quan trọng, mình có thể lảng tránh, rút lui khỏi vấn đề đó. Nếu lạm dụng chiến lược này, dễ dẫn đến các vấn đề tích tụ dần, kéo theo những hậu quả khó lường sau này. Khi tránh xung đột, không có gì được giải quyết.
Hợp tác là phương pháp được sử dụng khi mọi người vừa quyết đoán vừa hợp tác. Một nhóm có thể học cách cho phép mỗi người tham gia đóng góp với khả năng cùng tạo ra một giải pháp chung mà mọi người đều có thể hỗ trợ.
Bên cạnh đó, chuyên gia Huỳnh Thiện Khiêm cũng chia sẻ một số thực hành giúp ngăn ngừa và xử lý xung đột trong nhóm Scrum như:
Cụ thể về Team Canvas
Đây là một công cụ tốt giúp bạn đưa ra phản hồi hiệu quả hơn, giúp bạn tập trung ý kiến vào tình huống, hành vi cụ thể, sau đó chỉ ra tác động của hành vi đến người khác, chứ không phải đánh giá về phần cá nhân.
Xung đột là một phần tự nhiên trong sự hợp tác của con người. Nó xảy ra với tất cả mọi người, bất kể bạn có kỹ năng như thế nào. Bản thân xung đột không phải là xấu hay là điều nên tránh. Trên thực tế, xung đột là một nguồn học hỏi và phát triển tuyệt vời, miễn là chúng ta học cách điều hướng nó một cách hiệu quả và không để nó leo thang (Christiaan Verwijs).
Bài viết liên quan:
Khóa học liên quan:
