Thao Trinh – Người thích tự do và lang thang như gió - Thao Trinh – Người thích tự do và lang thang như gió
  • Trang chủ
  • Chuyện nghề
  • Đọc
  • Me
Thao Trinh – Người thích tự do và lang thang như gió - Thao Trinh – Người thích tự do và lang thang như gió
Trang chủ
Chuyện nghề
Đọc
Me
  • Trang chủ
  • Chuyện nghề
  • Đọc
  • Me
Chuyện nghề

Cách xử lý bất đồng trong nhóm của bạn

thaotrinh.info__cach-xu-ly-bat-dong-trong-nhom-cua-ban

Khi bạn quản lý một nhóm người, không phải lúc nào bạn cũng có thể đảm bảo rằng họ sẽ hòa hợp với nhau. Sở thích, nhu cầu và các chương trình làm việc cạnh tranh được đưa ra, bạn thậm chí có thể có 2 người phản đối nhau kịch liệt. Vai trò của bạn là quản lý trong tình huống như thế này là gì? Bạn nên tham gia hay để họ tự giải quyết vấn đề của họ?

Lý tưởng nhất là bạn có thể huấn luyện đồng nghiệp trò chuyện với nhau và giải quyết xung đột của họ mà không cần bạn tham gia, đồng thời làm rõ rằng sự bất đồng của họ có hại cho họ và tổ chức. Nhưng điều đó không phải lúc nào cũng khả thi. Trong những tình huống này, chúng tôi tin rằng điều quan trọng là phải can thiệp, không phải với tư cách là quản lý mà là người hòa giải. Để chắc chắn, bạn sẽ không phải là một người hòa giải độc lập, trung lập vì bạn có một số lợi ích trong kết quả, nhưng bạn có khả năng hiệu quả hơn trong cuộc họp có liên quan tới lợi ích mọi người – của bạn, của họ và của tổ chức – nếu bạn sử dụng các kỹ năng hòa giải của mình hơn là quyền hạn của bạn.

Tại sao lại dựa vào hòa giải mà không phải quyền hạn của bạn?

Các đồng nghiệp của bạn có nhiều khả năng nắm giữ quyết định và tuân theo quyết định đó nếu họ tham gia vào việc đưa ra quyết định đó. Nếu bạn quyết định những gì họ phải làm (ra lệnh theo cách truyền thống), họ sẽ chẳng học được gì về cách tự giải quyết xung đột. Thay vào đó, họ sẽ trở nên ngày càng phụ thuộc vào bạn hơn để giải quyết những xung đột của họ.

Tất nhiên, sẽ có lúc bạn phải gác lại vai trò hòa giải của mình và quyết định xem xung đột sẽ được giải quyết như thế nào (những dịp đó rất ít và hiếm khi xảy ra) – ví dụ: nếu có các vấn đề lớn liên quan về chính sách của bộ phận hoặc công ty được đề cập, các vấn đề khẩn cấp hoặc tất cả các cách khác đều thất bại để giải quyết xung đột.

Điều gì sẽ xảy ra nếu đồng nghiệp của bạn mong đợi bạn bước lên làm sếp?

Động thái đầu tiên của bạn là công nhận thẩm quyền của bạn, nhưng giải thích quy trình hòa giải mà bạn có trong đầu. Bạn có thể nói với đồng nghiệp của mình rằng mặc dù bạn có quyền áp đặt kết quả cho họ, nhưng bạn hy vọng rằng cùng nhau bạn có thể tìm ra một giải pháp phù hợp với mọi người. Bạn cũng có thể nói với họ rằng khi ba người làm việc cùng nhau, họ nên dành nỗ lực để đạt được thỏa thuận, thay vì cố gắng thuyết phục bạn rằng quan điểm của họ nên áp dụng.

Ban đầu bạn nên gặp gỡ từng đồng nghiệp riêng hay chung?

Có những ưu và nhược điểm cho cả hai cách tiếp cận. Mục tiêu là để hiểu cả lập trường của họ (người này tuyên bố điều gì và người kia từ chối) và lợi ích của họ (lý do tại sao họ đưa ra giải pháp của mình và từ chối giải pháp khác).

Xung đột thường mang theo trong nó cảm xúc nặng nề. Một hoặc cả hai đồng nghiệp của bạn có thể tức giận nghiêm trọng. Một hoặc cả hai có thể cảm thấy bị đe dọa bởi người kia. Gặp gỡ riêng từng người sẽ tạo cơ hội cho đồng nghiệp đang tức giận trút giận (xả bong bóng giận giữ và điềm tĩnh lại), việc này cũng cho bạn cơ hội trấn an đồng nghiệp bị đe dọa rằng bạn sẽ lắng nghe và có thể đưa ra thông tin cuối cùng hữu ích để giải quyết xung đột – thông tin mà đồng nghiệp chưa chia sẻ với nhau hoặc chưa nghe nếu được chia sẻ.

Nếu lần đầu tiên bạn ngồi riêng với họ, đừng tập trung thảo luận vào cách giải quyết xung đột, mà là tìm hiểu về sự bất đồng và thuyết phục mỗi người rằng bạn sẵn sàng lắng nghe và lo lắng để hiểu mối quan tâm của họ.

Nghiên cứu đã chỉ ra rằng các cuộc họp riêng ban đầu sẽ thành công hơn nếu người quản lý dành thời gian xây dựng sự đồng cảm và hiểu rõ vấn đề. Sẽ có nhiều thời gian trong các cuộc họp tiếp theo để nói về cách giải quyết xung đột. Cũng hãy chắc chắn rằng trong cuộc gặp gỡ đầu tiên này rằng bạn đang sử dụng sự đồng cảm (Điều đó hẳn là rất khó đối với bạn) chứ không phải sự cảm thông (Tôi cảm thấy tiếc cho những gì bạn đã trải qua). Biểu hiện của sự đồng cảm là tôn trọng nhưng tương đối trung lập và nó không ngụ ý ủng hộ lập trường của người đó.

Rủi ro khi bắt đầu một cách riêng rẽ là mỗi đồng nghiệp có thể nghĩ rằng người kia sẽ sử dụng cuộc họp đó để lôi kéo bạn theo quan điểm của người kia. Bạn có thể tránh điều này bằng cách giải thích rằng mục đích của cuộc họp là để hiểu cả hai bên về những gì đang diễn ra, không phải để bạn đưa ra quan điểm về việc ai đúng ai sai.

Gặp gỡ chung lúc đầu cũng có mặt trái của nó. Cho mỗi người cơ hội để trình bày, có kiểm soát trong một phiên họp chung có thể làm dịu không khí giữa họ. Bạn nên nói chuyện với cả hai trước khi đề xuất phương pháp này vì bạn muốn chắc chắn rằng họ có thể tham gia vào một buổi như vậy mà không mất bình tĩnh, khiến việc giải quyết càng khó khăn hơn. Và hãy đảm bảo thiết lập một số quy tắc cơ bản – ví dụ: mỗi người sẽ có một lượt, không bị gián đoạn – trước khi bạn bắt đầu và bạn cần chuẩn bị để kiểm soát chặt chẽ buổi hợp này, thậm chí dừng lại nếu bạn không thể kiểm soát nó, nếu không nó có thể trở nên khó kiểm soát hơn nữa.

Một lý do chính đáng khác để các đồng nghiệp của bạn gặp nhau là cuối cùng, họ cần tự giải quyết xung đột của mình và họ cần phát triển khả năng nói chuyện với nhau khi xung đột phát sinh trong tương lai. Tất nhiên, rủi ro trong cuộc họp chung là bạn không thể kiểm soát quá trình và cuộc họp chỉ làm leo thang xung đột.

Hãy nhớ rằng bạn không phải chọn một phương pháp họp và gắn bó với nó trong suốt quá trình. Bạn có thể chuyển đổi giữa các cách khác nhau. Tuy nhiên, nghiên cứu của chúng tôi cho thấy rằng bắt đầu một cách riêng lẻ và xây dựng sự đồng cảm rồi tiến tới họp chung sẽ hiệu quả hơn trong việc giải quyết xung đột so với bắt đầu cùng nhau và sau đó gặp gỡ riêng lẻ.

Bạn nên hoàn thành điều gì trong cuộc họp đầu tiên của mình?

Cho dù bạn có đang họp cùng nhau hay không, có một số điều bạn muốn làm trong cuộc họp đầu tiên. Giải thích rằng bạn thấy vai trò của mình là giúp họ tìm ra cách giải quyết được cả hai bên chấp nhận cho xung đột của họ, nhưng cũng để đảm bảo rằng giải pháp đó không có ý nghĩa tiêu cực đối với nhóm hoặc tổ chức. Hãy nói rõ rằng việc quyết định xem một thỏa thuận cụ thể có được chấp nhận hay không, cần có sự tham gia của họ và của bạn. Và sau đó đặt ra một số quy tắc cho bất cứ khi nào bạn gặp nhau. Ví dụ: đối xử với mỗi người một cách tôn trọng và không ngắt lời.

Mục tiêu của cuộc gặp ban đầu là để họ rời đi với cảm xúc dịu bớt và cảm thấy được bạn tôn trọng, thậm chí bạn và đồng nghiệp chưa cần hiểu nhau lúc này. Sau đó, bạn có thể tập hợp họ lại với nhau (nếu bạn không gặp nhau lần đầu tiên) và tập trung vào việc nhận được thông tin mà tất cả các bạn cần để giải quyết xung đột.

Bạn cần rút ra thông tin gì trong các cuộc họp tiếp theo?

Để giải quyết xung đột, bạn sẽ cần biết từ cả hai người về vị trí của họ (mỗi người muốn gì), sở thích (tại sao mỗi người lại đảm nhận vị trí đó, vị trí phản ánh mối quan tâm nhu cầu của họ như thế nào) và ưu tiên (điều gì nhiều hơn và ít hơn quan trọng đối với mỗi người và tại sao).

Bạn có thể thu thập thông tin này bằng cách thực hiện các câu hỏi: hỏi “tại sao?” hoặc “tại sao không?” câu hỏi để khám phá những mối quan tâm làm nền tảng cho vị trí của họ, lắng nghe cẩn thận để xác định những mối quan tâm đó, định dạng lại những gì bạn nghĩ rằng bạn hiểu về sở thích của một đồng nghiệp để đảm bảo rằng bạn hiểu và đồng nghiệp kia cũng đang lắng nghe chúng.

Những cạm bẫy cần tránh là gì?

Có một số cách mà các cuộc thảo luận này có thể bị sai. Một trong hai đồng nghiệp có thể cố gắng thuyết phục bạn rằng quan điểm của họ về các sự kiện là quan điểm đúng đắn duy nhất, rằng vị trí của họ là “đúng” hoặc rằng họ nên chiếm ưu thế vì họ có nhiều quyền lực hơn. Chúng tôi gọi đây là những sự thật, quyền và lập luận quyền lực và chúng gây bất lợi vì chúng khiến mọi người phân tâm khỏi việc tìm kiếm một giải pháp thỏa mãn lợi ích của mọi người.

Lập luận về sự thật là một điều thú vị. Cả hai đồng nghiệp có thể đã ở cùng một cảnh nhưng mỗi người nhớ lại nó một cách khác nhau. Cả hai đều nghĩ rằng xung đột chỉ có thể kết thúc nếu thuyết phục được bạn và đồng nghiệp về quan điểm của họ.

Vấn đề là ngay cả khi bạn đã ở đó, việc cố gắng thuyết phục người khác theo quan điểm của bạn sẽ phản tác dụng, vì nếu không có thông tin đáng tin cậy mới, họ khó có thể thay đổi ý định về những gì đã xảy ra. Cách tốt nhất để đóng cái bẫy này là đồng ý không đồng ý và tiếp tục. Vấn đề là ngay cả khi bạn đã ở đó, việc cố gắng thuyết phục người khác theo quan điểm của bạn sẽ phản tác dụng, vì nếu không có thông tin đáng tin cậy mới, họ khó có thể thay đổi ý định về những gì đã xảy ra. Cách tốt nhất để đóng cái bẫy này là đồng ý “không đồng ý” và tiếp tục.

Tranh luận về tính đúng sai có thể xuất hiện dưới hình thức kháng nghị sự công bằng hoặc các thông lệ trước đây. Vấn đề là đối với mọi lập luận về tính đúng đắn mà một đồng nghiệp đưa ra, người kia có thể đưa ra một lập luận khác ủng hộ quan điểm của chính họ. Điều gì một bên coi là công bằng thì bên kia coi là không công bằng và ngược lại. Nếu họ bắt đầu đòi hỏi sự công bằng, hãy đề nghị tạm thời gác cuộc thảo luận sang một bên, trong khi bạn cùng nhau tìm kiếm thông tin có thể hữu ích trong việc giải quyết xung đột.

Các lập luận quyền lực về cơ bản là mối đe dọa. Nếu bạn không đồng ý với vị trí của tôi, tôi sẽ…. Bị đe dọa khiến mọi người trở nên phòng thủ và không tin tưởng, điều này khiến họ miễn cưỡng chia sẻ thông tin về vị trí, sở thích và ưu tiên. Nếu một người đưa ra lời đe dọa, rõ ràng hoặc ẩn ý, hãy nhắc nhở đồng nghiệp của bạn về các quy tắc cơ bản về sự tôn trọng. Bạn cũng có thể lặp lại những gì bạn đang cố gắng làm – chia sẻ thông tin có liên quan để đi đến giải pháp – và cuộc thảo luận về những gì một người sẽ làm nếu không hợp tác giải quyết vấn đề vào thời điểm này.

Làm thế nào bạn có thể tiến tới một thỏa thuận?

Có thể dễ dàng tìm ra các dàn xếp tiềm năng nếu trong quá trình giúp đỡ đồng nghiệp của bạn hiểu được các vị trí và lợi ích khác nhau của họ, có thể thấy rõ rằng xung đột này chỉ là một sự hiểu lầm hoặc rằng có một con đường tiến tới tôn trọng lợi ích của cả hai bên. Nếu rõ ràng rằng lợi ích của họ có nhiều mâu thuẫn với vị trí của họ, việc tìm kiếm một giải pháp có thể khó khăn hơn, nhưng đừng bỏ cuộc.
Nghiên cứu của chúng tôi cho thấy có một số cách để tạo thuận lợi cho một thỏa thuận trong tình huống này. Đáng ngạc nhiên là các bên có thể chỉ cần thỏa thuận về cách họ sẽ tương tác hoặc giải quyết các vấn đề trong tương lai. Họ đặt quá khứ đằng sau họ, chấp nhận rằng thực tiễn trong quá khứ không có tác dụng với cái này hay cái khác hoặc cả hai và cùng nhau tiến lên. Tuy nhiên, điều này có thể phức tạp. Đôi khi một người có thể sẵn sàng tham gia vào một thỏa thuận dựa trên tương lai như thế này nhưng không tin tưởng người kia sẽ tuân theo nó. Trong những trường hợp đó, khi sự không chắc chắn là mối quan tâm, bạn có thể thử một trong các loại thỏa thuận sau:

  • Giới hạn thời gian. Hãy thử một cái gì đó trong một thời gian giới hạn và sau đó đánh giá trước khi tiếp tục.
  • Dự phòng. Các thỏa thuận phụ thuộc vào một sự kiện không xảy ra trong tương lai. Nếu sự kiện trong tương lai xảy ra, một thỏa thuận thay thế có hiệu lực.
  • Thiết lập không có tiền lệ. Các thỏa thuận bảo vệ khỏi rủi ro bởi các bên đồng ý rằng việc dàn xếp sẽ không tạo tiền lệ trong trường hợp có xung đột tương tự phát sinh trong tương lai.

Tốt nhất là đồng nghiệp của bạn có thể đề xuất các giải pháp đáp ứng lợi ích của họ và của người khác. Bạn có thể huấn luyện họ đưa ra các đề xuất như vậy bằng cách tóm tắt các mối quan tâm và ưu tiên khi bạn đã nghe chúng. Sau đó, bạn có thể yêu cầu mỗi đồng nghiệp đưa ra đề xuất có tính đến lợi ích và ưu tiên của người kia. Không khuyến khích mỗi người đưa ra những đề xuất không thực tế có thể làm mất lòng người kia. Bạn có thể cảnh báo họ không đưa ra đề nghị mà họ không thể giải thích một cách hợp lý, bởi vì làm như vậy sẽ làm giảm uy tín của họ.

Nếu bất chấp nỗ lực của mọi người, bạn không thể đạt được thỏa thuận, bạn có thể cần phải nói chuyện riêng với từng đồng nghiệp về hậu quả của việc không đạt được giải pháp. Bạn có thể hỏi, bạn nghĩ điều gì sẽ xảy ra nếu bạn không đạt được thỏa thuận? Câu trả lời tất nhiên là họ không biết. Cách duy nhất để giữ quyền kiểm soát kết quả của cuộc xung đột là tự mình giải quyết. Nếu vẫn không giải quyết được tại thời điểm này, bạn có thể cần phải từ bỏ vai trò hòa giải của mình và với tư cách là ông chủ, áp đặt một kết quả có lợi nhất cho tổ chức. Hãy chắc chắn giải thích lý do của bạn và nói rõ đây không phải là con đường bạn mong muốn. Bạn cũng có thể chỉ ra rằng mục tiêu của bạn trong việc giúp họ làm việc chăm chỉ để tự giải quyết tranh chấp là để họ được trang bị tốt hơn để làm điều đó trong tương lai và mục tiêu đó đã không được hoàn thành đầy đủ. Nhưng đừng để họ bỏ đi khi nghĩ rằng mối quan hệ của họ đã kết thúc. Cung cấp cho cả hai phản hồi về những gì họ có thể làm khác vào lần tới, làm rõ rằng khi họ bắt đầu trở lại, bạn sẽ mong đợi họ tự quản lý.

Dịch từ HBR

August 10, 2020by thaotrinh
Agile (APM)

Cách xử lý bất đồng trong nhóm của bạn

thaotrinh.info__cach-xu-ly-bat-dong-trong-nhom-cua-ban

Khi bạn quản lý một nhóm người, không phải lúc nào bạn cũng có thể đảm bảo rằng họ sẽ hòa hợp với nhau. Sở thích, nhu cầu và các chương trình làm việc cạnh tranh được đưa ra, bạn thậm chí có thể có 2 người phản đối nhau kịch liệt. Vai trò của bạn là quản lý trong tình huống như thế này là gì? Bạn nên tham gia hay để họ tự giải quyết vấn đề của họ?

Lý tưởng nhất là bạn có thể huấn luyện đồng nghiệp trò chuyện với nhau và giải quyết xung đột của họ mà không cần bạn tham gia, đồng thời làm rõ rằng sự bất đồng của họ có hại cho họ và tổ chức. Nhưng điều đó không phải lúc nào cũng khả thi. Trong những tình huống này, chúng tôi tin rằng điều quan trọng là phải can thiệp, không phải với tư cách là quản lý mà là người hòa giải. Để chắc chắn, bạn sẽ không phải là một người hòa giải độc lập, trung lập vì bạn có một số lợi ích trong kết quả, nhưng bạn có khả năng hiệu quả hơn trong cuộc họp có liên quan tới lợi ích mọi người – của bạn, của họ và của tổ chức – nếu bạn sử dụng các kỹ năng hòa giải của mình hơn là quyền hạn của bạn.

Tại sao lại dựa vào hòa giải mà không phải quyền hạn của bạn?

Các đồng nghiệp của bạn có nhiều khả năng nắm giữ quyết định và tuân theo quyết định đó nếu họ tham gia vào việc đưa ra quyết định đó. Nếu bạn quyết định những gì họ phải làm (ra lệnh theo cách truyền thống), họ sẽ chẳng học được gì về cách tự giải quyết xung đột. Thay vào đó, họ sẽ trở nên ngày càng phụ thuộc vào bạn hơn để giải quyết những xung đột của họ.

Tất nhiên, sẽ có lúc bạn phải gác lại vai trò hòa giải của mình và quyết định xem xung đột sẽ được giải quyết như thế nào (những dịp đó rất ít và hiếm khi xảy ra) – ví dụ: nếu có các vấn đề lớn liên quan về chính sách của bộ phận hoặc công ty được đề cập, các vấn đề khẩn cấp hoặc tất cả các cách khác đều thất bại để giải quyết xung đột.

Điều gì sẽ xảy ra nếu đồng nghiệp của bạn mong đợi bạn bước lên làm sếp?

Động thái đầu tiên của bạn là công nhận thẩm quyền của bạn, nhưng giải thích quy trình hòa giải mà bạn có trong đầu. Bạn có thể nói với đồng nghiệp của mình rằng mặc dù bạn có quyền áp đặt kết quả cho họ, nhưng bạn hy vọng rằng cùng nhau bạn có thể tìm ra một giải pháp phù hợp với mọi người. Bạn cũng có thể nói với họ rằng khi ba người làm việc cùng nhau, họ nên dành nỗ lực để đạt được thỏa thuận, thay vì cố gắng thuyết phục bạn rằng quan điểm của họ nên áp dụng.

Ban đầu bạn nên gặp gỡ từng đồng nghiệp riêng hay chung?

Có những ưu và nhược điểm cho cả hai cách tiếp cận. Mục tiêu là để hiểu cả lập trường của họ (người này tuyên bố điều gì và người kia từ chối) và lợi ích của họ (lý do tại sao họ đưa ra giải pháp của mình và từ chối giải pháp khác).

Xung đột thường mang theo trong nó cảm xúc nặng nề. Một hoặc cả hai đồng nghiệp của bạn có thể tức giận nghiêm trọng. Một hoặc cả hai có thể cảm thấy bị đe dọa bởi người kia. Gặp gỡ riêng từng người sẽ tạo cơ hội cho đồng nghiệp đang tức giận trút giận (xả bong bóng giận giữ và điềm tĩnh lại), việc này cũng cho bạn cơ hội trấn an đồng nghiệp bị đe dọa rằng bạn sẽ lắng nghe và có thể đưa ra thông tin cuối cùng hữu ích để giải quyết xung đột – thông tin mà đồng nghiệp chưa chia sẻ với nhau hoặc chưa nghe nếu được chia sẻ.

Nếu lần đầu tiên bạn ngồi riêng với họ, đừng tập trung thảo luận vào cách giải quyết xung đột, mà là tìm hiểu về sự bất đồng và thuyết phục mỗi người rằng bạn sẵn sàng lắng nghe và lo lắng để hiểu mối quan tâm của họ.

Nghiên cứu đã chỉ ra rằng các cuộc họp riêng ban đầu sẽ thành công hơn nếu người quản lý dành thời gian xây dựng sự đồng cảm và hiểu rõ vấn đề. Sẽ có nhiều thời gian trong các cuộc họp tiếp theo để nói về cách giải quyết xung đột. Cũng hãy chắc chắn rằng trong cuộc gặp gỡ đầu tiên này rằng bạn đang sử dụng sự đồng cảm (Điều đó hẳn là rất khó đối với bạn) chứ không phải sự cảm thông (Tôi cảm thấy tiếc cho những gì bạn đã trải qua). Biểu hiện của sự đồng cảm là tôn trọng nhưng tương đối trung lập và nó không ngụ ý ủng hộ lập trường của người đó.

Rủi ro khi bắt đầu một cách riêng rẽ là mỗi đồng nghiệp có thể nghĩ rằng người kia sẽ sử dụng cuộc họp đó để lôi kéo bạn theo quan điểm của người kia. Bạn có thể tránh điều này bằng cách giải thích rằng mục đích của cuộc họp là để hiểu cả hai bên về những gì đang diễn ra, không phải để bạn đưa ra quan điểm về việc ai đúng ai sai.

Gặp gỡ chung lúc đầu cũng có mặt trái của nó. Cho mỗi người cơ hội để trình bày, có kiểm soát trong một phiên họp chung có thể làm dịu không khí giữa họ. Bạn nên nói chuyện với cả hai trước khi đề xuất phương pháp này vì bạn muốn chắc chắn rằng họ có thể tham gia vào một buổi như vậy mà không mất bình tĩnh, khiến việc giải quyết càng khó khăn hơn. Và hãy đảm bảo thiết lập một số quy tắc cơ bản – ví dụ: mỗi người sẽ có một lượt, không bị gián đoạn – trước khi bạn bắt đầu và bạn cần chuẩn bị để kiểm soát chặt chẽ buổi hợp này, thậm chí dừng lại nếu bạn không thể kiểm soát nó, nếu không nó có thể trở nên khó kiểm soát hơn nữa.

Một lý do chính đáng khác để các đồng nghiệp của bạn gặp nhau là cuối cùng, họ cần tự giải quyết xung đột của mình và họ cần phát triển khả năng nói chuyện với nhau khi xung đột phát sinh trong tương lai. Tất nhiên, rủi ro trong cuộc họp chung là bạn không thể kiểm soát quá trình và cuộc họp chỉ làm leo thang xung đột.

Hãy nhớ rằng bạn không phải chọn một phương pháp họp và gắn bó với nó trong suốt quá trình. Bạn có thể chuyển đổi giữa các cách khác nhau. Tuy nhiên, nghiên cứu của chúng tôi cho thấy rằng bắt đầu một cách riêng lẻ và xây dựng sự đồng cảm rồi tiến tới họp chung sẽ hiệu quả hơn trong việc giải quyết xung đột so với bắt đầu cùng nhau và sau đó gặp gỡ riêng lẻ.

Bạn nên hoàn thành điều gì trong cuộc họp đầu tiên của mình?

Cho dù bạn có đang họp cùng nhau hay không, có một số điều bạn muốn làm trong cuộc họp đầu tiên. Giải thích rằng bạn thấy vai trò của mình là giúp họ tìm ra cách giải quyết được cả hai bên chấp nhận cho xung đột của họ, nhưng cũng để đảm bảo rằng giải pháp đó không có ý nghĩa tiêu cực đối với nhóm hoặc tổ chức. Hãy nói rõ rằng việc quyết định xem một thỏa thuận cụ thể có được chấp nhận hay không, cần có sự tham gia của họ và của bạn. Và sau đó đặt ra một số quy tắc cho bất cứ khi nào bạn gặp nhau. Ví dụ: đối xử với mỗi người một cách tôn trọng và không ngắt lời.

Mục tiêu của cuộc gặp ban đầu là để họ rời đi với cảm xúc dịu bớt và cảm thấy được bạn tôn trọng, thậm chí bạn và đồng nghiệp chưa cần hiểu nhau lúc này. Sau đó, bạn có thể tập hợp họ lại với nhau (nếu bạn không gặp nhau lần đầu tiên) và tập trung vào việc nhận được thông tin mà tất cả các bạn cần để giải quyết xung đột.

Bạn cần rút ra thông tin gì trong các cuộc họp tiếp theo?

Để giải quyết xung đột, bạn sẽ cần biết từ cả hai người về vị trí của họ (mỗi người muốn gì), sở thích (tại sao mỗi người lại đảm nhận vị trí đó, vị trí phản ánh mối quan tâm nhu cầu của họ như thế nào) và ưu tiên (điều gì nhiều hơn và ít hơn quan trọng đối với mỗi người và tại sao).

Bạn có thể thu thập thông tin này bằng cách thực hiện các câu hỏi: hỏi “tại sao?” hoặc “tại sao không?” câu hỏi để khám phá những mối quan tâm làm nền tảng cho vị trí của họ, lắng nghe cẩn thận để xác định những mối quan tâm đó, định dạng lại những gì bạn nghĩ rằng bạn hiểu về sở thích của một đồng nghiệp để đảm bảo rằng bạn hiểu và đồng nghiệp kia cũng đang lắng nghe chúng.

Những cạm bẫy cần tránh là gì?

Có một số cách mà các cuộc thảo luận này có thể bị sai. Một trong hai đồng nghiệp có thể cố gắng thuyết phục bạn rằng quan điểm của họ về các sự kiện là quan điểm đúng đắn duy nhất, rằng vị trí của họ là “đúng” hoặc rằng họ nên chiếm ưu thế vì họ có nhiều quyền lực hơn. Chúng tôi gọi đây là những sự thật, quyền và lập luận quyền lực và chúng gây bất lợi vì chúng khiến mọi người phân tâm khỏi việc tìm kiếm một giải pháp thỏa mãn lợi ích của mọi người.

Lập luận về sự thật là một điều thú vị. Cả hai đồng nghiệp có thể đã ở cùng một cảnh nhưng mỗi người nhớ lại nó một cách khác nhau. Cả hai đều nghĩ rằng xung đột chỉ có thể kết thúc nếu thuyết phục được bạn và đồng nghiệp về quan điểm của họ.

Vấn đề là ngay cả khi bạn đã ở đó, việc cố gắng thuyết phục người khác theo quan điểm của bạn sẽ phản tác dụng, vì nếu không có thông tin đáng tin cậy mới, họ khó có thể thay đổi ý định về những gì đã xảy ra. Cách tốt nhất để đóng cái bẫy này là đồng ý không đồng ý và tiếp tục. Vấn đề là ngay cả khi bạn đã ở đó, việc cố gắng thuyết phục người khác theo quan điểm của bạn sẽ phản tác dụng, vì nếu không có thông tin đáng tin cậy mới, họ khó có thể thay đổi ý định về những gì đã xảy ra. Cách tốt nhất để đóng cái bẫy này là đồng ý “không đồng ý” và tiếp tục.

Tranh luận về tính đúng sai có thể xuất hiện dưới hình thức kháng nghị sự công bằng hoặc các thông lệ trước đây. Vấn đề là đối với mọi lập luận về tính đúng đắn mà một đồng nghiệp đưa ra, người kia có thể đưa ra một lập luận khác ủng hộ quan điểm của chính họ. Điều gì một bên coi là công bằng thì bên kia coi là không công bằng và ngược lại. Nếu họ bắt đầu đòi hỏi sự công bằng, hãy đề nghị tạm thời gác cuộc thảo luận sang một bên, trong khi bạn cùng nhau tìm kiếm thông tin có thể hữu ích trong việc giải quyết xung đột.

Các lập luận quyền lực về cơ bản là mối đe dọa. Nếu bạn không đồng ý với vị trí của tôi, tôi sẽ…. Bị đe dọa khiến mọi người trở nên phòng thủ và không tin tưởng, điều này khiến họ miễn cưỡng chia sẻ thông tin về vị trí, sở thích và ưu tiên. Nếu một người đưa ra lời đe dọa, rõ ràng hoặc ẩn ý, hãy nhắc nhở đồng nghiệp của bạn về các quy tắc cơ bản về sự tôn trọng. Bạn cũng có thể lặp lại những gì bạn đang cố gắng làm – chia sẻ thông tin có liên quan để đi đến giải pháp – và cuộc thảo luận về những gì một người sẽ làm nếu không hợp tác giải quyết vấn đề vào thời điểm này.

Làm thế nào bạn có thể tiến tới một thỏa thuận?

Có thể dễ dàng tìm ra các dàn xếp tiềm năng nếu trong quá trình giúp đỡ đồng nghiệp của bạn hiểu được các vị trí và lợi ích khác nhau của họ, có thể thấy rõ rằng xung đột này chỉ là một sự hiểu lầm hoặc rằng có một con đường tiến tới tôn trọng lợi ích của cả hai bên. Nếu rõ ràng rằng lợi ích của họ có nhiều mâu thuẫn với vị trí của họ, việc tìm kiếm một giải pháp có thể khó khăn hơn, nhưng đừng bỏ cuộc.
Nghiên cứu của chúng tôi cho thấy có một số cách để tạo thuận lợi cho một thỏa thuận trong tình huống này. Đáng ngạc nhiên là các bên có thể chỉ cần thỏa thuận về cách họ sẽ tương tác hoặc giải quyết các vấn đề trong tương lai. Họ đặt quá khứ đằng sau họ, chấp nhận rằng thực tiễn trong quá khứ không có tác dụng với cái này hay cái khác hoặc cả hai và cùng nhau tiến lên. Tuy nhiên, điều này có thể phức tạp. Đôi khi một người có thể sẵn sàng tham gia vào một thỏa thuận dựa trên tương lai như thế này nhưng không tin tưởng người kia sẽ tuân theo nó. Trong những trường hợp đó, khi sự không chắc chắn là mối quan tâm, bạn có thể thử một trong các loại thỏa thuận sau:

  • Giới hạn thời gian. Hãy thử một cái gì đó trong một thời gian giới hạn và sau đó đánh giá trước khi tiếp tục.
  • Dự phòng. Các thỏa thuận phụ thuộc vào một sự kiện không xảy ra trong tương lai. Nếu sự kiện trong tương lai xảy ra, một thỏa thuận thay thế có hiệu lực.
  • Thiết lập không có tiền lệ. Các thỏa thuận bảo vệ khỏi rủi ro bởi các bên đồng ý rằng việc dàn xếp sẽ không tạo tiền lệ trong trường hợp có xung đột tương tự phát sinh trong tương lai.

Tốt nhất là đồng nghiệp của bạn có thể đề xuất các giải pháp đáp ứng lợi ích của họ và của người khác. Bạn có thể huấn luyện họ đưa ra các đề xuất như vậy bằng cách tóm tắt các mối quan tâm và ưu tiên khi bạn đã nghe chúng. Sau đó, bạn có thể yêu cầu mỗi đồng nghiệp đưa ra đề xuất có tính đến lợi ích và ưu tiên của người kia. Không khuyến khích mỗi người đưa ra những đề xuất không thực tế có thể làm mất lòng người kia. Bạn có thể cảnh báo họ không đưa ra đề nghị mà họ không thể giải thích một cách hợp lý, bởi vì làm như vậy sẽ làm giảm uy tín của họ.

Nếu bất chấp nỗ lực của mọi người, bạn không thể đạt được thỏa thuận, bạn có thể cần phải nói chuyện riêng với từng đồng nghiệp về hậu quả của việc không đạt được giải pháp. Bạn có thể hỏi, bạn nghĩ điều gì sẽ xảy ra nếu bạn không đạt được thỏa thuận? Câu trả lời tất nhiên là họ không biết. Cách duy nhất để giữ quyền kiểm soát kết quả của cuộc xung đột là tự mình giải quyết. Nếu vẫn không giải quyết được tại thời điểm này, bạn có thể cần phải từ bỏ vai trò hòa giải của mình và với tư cách là ông chủ, áp đặt một kết quả có lợi nhất cho tổ chức. Hãy chắc chắn giải thích lý do của bạn và nói rõ đây không phải là con đường bạn mong muốn. Bạn cũng có thể chỉ ra rằng mục tiêu của bạn trong việc giúp họ làm việc chăm chỉ để tự giải quyết tranh chấp là để họ được trang bị tốt hơn để làm điều đó trong tương lai và mục tiêu đó đã không được hoàn thành đầy đủ. Nhưng đừng để họ bỏ đi khi nghĩ rằng mối quan hệ của họ đã kết thúc. Cung cấp cho cả hai phản hồi về những gì họ có thể làm khác vào lần tới, làm rõ rằng khi họ bắt đầu trở lại, bạn sẽ mong đợi họ tự quản lý.

August 6, 2020by thaotrinh
Đọc

Agile Y và những điều thú vị

thaotrinh.info__agile-y-va-nhung-dieu-thu-vi

Bìa sách có gạch nối từ A tới Y có lẽ cũng là cách chơi chữ của tác giả cùng với tên sách – Agile từ A tới Y (chưa tới Z). Nội dung sách gồm 3 phần rõ ràng: Agile, tổ chức, cá nhân. Các nội dung trong sách thì mình cũng đọc, góp nhặt từ nhiều nơi, tuy vậy cũng học hỏi được rất nhiều thứ từ cách nhìn nhận của tác giả và … 1 số thứ chưa biết 😀

Về Agile – phần 1, tác giả có 2 chương đầu nói về thực trạng của việc phát triển phần mềm và đưa ra câu hỏi tu từ: “Liệu Agile có phải là giải pháp?”. Phần này mĩnh sẽ note lại trong 1 bài viết khác bới nó khá dài và có nhiều câu chuyện để cùng bàn luận mổ xẻ. Lướt tiếp phần 1 điều mình thích là ở chương 5 phần kĩ thuật và công cụ, phần này có đề cập tới database versioning và branch strategy làm mình khá tâm đắc. Thực sự với mỗi team làm phần mềm, đây là 2 thứ cực kì quan trọng và đáng giá để nghiên cứu và đưa nó vào quy trình, nhất là khi team bạn làm Agile (Scrum). Tư tưởng ở đây cho việc database versioning là coi database như một version của code, commit kèm theo source. Luôn có script update database và restore database đi cùng nhau cho 1 version, điều này khiến CSDL của bạn được đảm bảo, có truy vết và luôn ở trạng thái có thể backup được lại phiên bản ổn định. Branch strategy với tư tưởng forward-intergration (tích hợp trước) giúp việc đảm bảo luôn có sự ổn định ở branch develop là 1 ý tưởng hay có thể áp dụng ngay lập tức cho nhóm của bạn.

Chương về tổ chức, mình đọc thêm được các thông tin về việc scale up khi nhóm Scrum có rất nhiều thành viên. Thực ra trước đây có nghe nói về nexus nhưng chưa bao giờ “dấn thân” tìm hiểu – nhân tiện đọc Agile Y nên lại phải lọ mọ đọc thêm, đây cũng là 1 điểm mình học hỏi được từ Agile Y.

Chương về cá nhân mình thích cách Hiển – tác giả nói về cách định nghĩa công việc theo tiêu chí SMART. Trước đây mình không hề quan tâm tới việc này. Có lẽ vậy nên cách mình nhìn vào trạng thái công việc thường gặp vấn đề mơ hồ, không rõ ràng. Bạn có thể đọc về SMART tại bài viết khác trong blog của mình (cũng nhặt trong sách Agile Y ra).

Kết.
Nếu chưa đọc nhiều về Agile/Scrum thì sách cung cấp khá nhiều kiến thức và chia sẻ về Agile/Scrum. Nếu đã có kiến thức tổng quan về Agile/Scrum bạn cũng có thể tìm thấy những lợi ích khác từ sách: cách dùng các công cụ trong quá trình làm việc, các phát triển, tổ chức đội nhóm làm Scrum khi scale up và cách phát triển bản thân – tối ưu hóa giá trị công việc làm ra (thay vì tối ưu khối lượng công việc). Đề xuất nên đọc cho mọi anh em làm phần mềm 🙂

July 10, 2020by thaotrinh
Agile (APM)

Bàn về rủi ro trong dự án Agile

thaotrinh.info__ban-ve-rui-ro-trong-du-an-agile

Với sự hiểu biết về Agile và Scrum, bạn dễ dàng nhận thấy việc quản lý rủi ro trong dự án áp dụng Agile/Scrum được thể hiện ở các đặc điểm của Agile hay trong các sự kiện của Scrum Framework.

– Lặp và tăng trưởng: Scrum chia “dự án” thành các giai đoạn – sprint kéo dài từ 1-4 tuần. Kết quả của mỗi sprint là một phần tăng trưởng có thể sử dụng được (tuỳ thuộc định nghĩa hoàn thành, phần tăng trưởng này có thể deploy hoặc không). Việc theo dõi thường xuyên và liên tục được phần tăng trưởng này giúp khách hàng tiếp cận được kết quả sản phẩm sớm hơn và đưa ra các phản hồi. Việc này giúp tránh lãng phí nguồn lực, thời gian và chi phí. Việc theo dõi kết quả của nhóm phát triển thường xuyên cũng giúp PO (SM) nhận định được năng suất thực tế của nhóm. Từ đó đưa ra các chiến lược để tối ưu hoá được năng suất lao động.

– Giao tiếp thường xuyên và hiệu quả: Scrum định nghĩa các sự kiện, tuân theo nó, nhóm phát triển thực hiện công việc theo nhịp độ đều đặn. Từ nội dung và kết quả các sự kiện, SM giúp nhóm phát lộ các vấn đề – bằng các kĩ thuật đặt câu hỏi, từ đó xử lý hoặc đưa ra các giải pháp thích ứng. Ví dụ thông qua buổi họp daily stand up, nhóm phát triển phát hiện một vài issues có thể ảnh hưởng tới tiến độ chung của cả đội, việc tìm ra giải pháp và người chịu trách nhiệm (follow up để hỗ trợ) là cần thiết, lúc này thay vì cá nhân đang gặp issue tự giải quyết vấn đề, buổi họp daily stand up có thể giúp đội nhóm hiểu vấn đề đang có, và cùng đưa giải pháp hoặc cùng tìm kiếm giải pháp trợ giúp thành viên của nhóm. Nhóm phát triển cũng luôn giao tiếp với PO nhờ hỗ trợ giải đáp các vấn đề liên quan tới User Story – nơi được hiểu là bao gồm các yêu cầu của các bên liên quan, và khách hàng cuối. Điều này khiến nhóm phát triển luôn hiểu đúng các yêu cầu và thực hiện đúng những mong muốn của PO (hay khách hàng)

– Vòng phản hồi ngắn và thích ứng thường xuyên, minh bạch thông tin: Các sự kiện trong Scrum giúp nhóm phát triển tương tác thường xuyên, minh bạch thông tin từ đó phát hiện sớm các vấn đề để giải quyết (hoặc thích ứng).

– Công cụ hỗ trợ, bao gồm: Tích hợp liên tục CI/CD, lập trình cặp – pair programing, refactoring code, lập trình hướng kiểm thử TDD…

Scrum không nhắc đến cụ thể việc quản lý rủi ro cho dự án phần mềm, tuy nhiên cùng với triết lý Agile, Scrum Framework thiết kế các sự kiện, các vai trò, sprint và các artifact từ đó giúp nhóm phát triển vận hành và làm việc theo một khung làm việc chung, đều đặn, từ đó dần cải thiện năng suất, sớm phát hiện các vấn đề để tìm cách xử lý thích nghi.

Là 1 PM truyền thống, và giờ đóng vai trò PO trong dự án phần mềm, bạn cần làm gì để quản lý rủi ro hiệu quả?

– Giao tiếp, giao tiếp và giao tiếp: Vai trò PM hay PO khá giống nhau ở yêu cầu công việc cần giao tiếp rất nhiều. Tương tự PM, PO cần giao tiếp với các stack holder, khách hàng để chuyển hoá những yêu cầu thành các User Story trong Product backlog.PO cần dành đủ thời gian cho nhóm phát triển để giải thích về các User Story trong Sprint backlog – trong trường hợp buổi planning chưa thể làm rõ được, hoặc tiêu chí hoàn thành cần phải cập nhật cho phù hợp với điều kiện thực tế. Bởi vậy, lời khuyên đầu tiên là Hãy dành đủ thời gian – cho nhóm phát triển và product backlog.

– Product backlog là quan trọng: Hãy luôn làm rõ các hạng mục công việc trong product backlog theo độ ưu tiên, càng ở trên cao thì các yêu cầu công việc càng phải rõ ràng, có tiêu chí hoàn thành – làm thế nào nhóm phát triển có thể hoàn thành công việc nếu họ không biết thế nào là hoàn thành? Bạn sẽ tốn bao nhiêu tài nguyên và nhân lực để làm một chức năng không đúng với yêu cầu của người dùng (khách hàng)?. Làm sao PO tối ưu hoá được ROI nếu không có thứ tự ưu tiên cho các công việc? Làm thế nào các manager có thể hỗ trợ team nếu không phát hiện ra các vấn đề. Hãy chú ý lời khuyên thứ 2: Product backlog là quan trọng, làm rõ nó, minh bạch với các bên liên quan.

– Tập trung vào một sản phẩm: Tuỳ tình huống, PO có thể phải đảm nhiệm hơn 1 sản phẩm. Việc này không bị cấm, nhưng không hề được khuyến khích. Đừng tham lam, lúc này bạn và tổ chức phải đánh đổi, 1 người chuyên hay 1 người đa nhiệm?

– Dù PO sẽ bị áp lực bởi nhiều bên để đưa vào các yêu cầu mới, cập nhật các yêu cầu cũ, nhưng bạn hãy cân nhắc việc này. Đưa nó vào product backlog, đánh độ ưu tiên, tạo tiêu chí hoàn thành, tiêu chí chấp nhận được thì tốt hơn là đưa vào sprint backlog – nơi các công việc của nhóm phát triển đã được định hình. Hãy chỉ nên dừng 1 sprint khi mục tiêu của nó đã lỗi thời – không nên vì một lý do nào khác. Lời khuyên thứ 3: Chuyển các yêu cầu vào product backlog. Đánh giá các cập nhật, nếu nó không làm ảnh hưởng tới sprint goal thì có thể thương lượng với nhóm phát triển để xử lý nó đồng thời trong sprint.

– Năng suất của nhóm cần được tôn trọng: Agile hay Scrum không giải quyết tất cả các vấn đề, nó chỉ giúp sớm phát hiện các vấn đề. Đừng đưa cho nhóm phát triển khối lượng công việc quá sức của họ và bắt họ làm theo. Hãy để nhóm tự ước lượng khối lượng công việc của mình, thực hiện nó đều đặn và tăng dần năng suất. Việc PO (hay bất kì ai) can thiệp vào khối lượng công việc của nhóm sẽ làm mất tính tự tổ chức của nhóm. Và vì vậy mô hình quản lý truyền thống lại được nhắc tên. Bạn không muốn điều này đúng không? Lời khuyên thứ 4: Mặc dù vài sprint đầu, nhóm có thể có tiến độ không tốt hoặc bộc lộ nhiều vấn đề, hãy để Scrum Master xử lý các vấn đề, và nhóm tự điều chỉnh năng suất lao động. Tôn trọng nhóm và nhóm sẽ trả lại bạn giá trị tương xứng.

– Học cách xem burndown chart, burnup chart, xem bảng kanban vật lý (nếu có) của nhóm: Quan sát các biểu đồ để trích xuất thông tin, từ đó nắm được tình trạng của nhóm

Nếu bạn mới tiếp cận với Agile và Scrum, từ vai trò truyền thống Project Manager bạn phải đóng vai trò mới là Product Owner, mình thực sự khuyên các bạn nên chú ý mội vài chỉ dẫn trên. Tất nhiên, nó là không đủ trong môi trường phát triển phần mềm phức tạp, nhưng ít nhất, bạn cũng có những khái quát để tiếp cận vấn đề. Chúc bạn thành công.

July 10, 2020by thaotrinh
Page 2 of 5«1234»...Last »

About me

Tìm kiếm nhanh

Đề xuất cho bạn

Installing & Configuring Apache on macOS using Homebrew and use Sites folder (Mac Monterey)

37 NGUYÊN TẮC GIAO TIẾP CHO ĐÀN ÔNG TỪ NĂM 1875

Tạo đối tượng trong C# từ url API hoặc Json String

Git hướng dẫn cơ bản cho người mới

Git hướng dẫn cơ bản cho người mới

Không phải làm bao nhiêu mà là tạo ra bao nhiêu

Không phải làm bao nhiêu mà là tạo ra bao nhiêu

Bài mới

  • 37 NGUYÊN TẮC GIAO TIẾP CHO ĐÀN ÔNG TỪ NĂM 1875
  • Định nghĩa công việc theo phương pháp S.M.A.R.T
  • Installing & Configuring Apache on macOS using Homebrew and use Sites folder (Mac Monterey)
  • Họp xong việc và họp thêm việc
  • Giá trị của Scrum Master trong case study của Leflair

Mọi người quan tâm

  1. Cài đặt và cấu hình Apache, MySQL trên macos - Thao Trinh - Người thích tự do và lang thang như gió on Installing & Configuring Apache on macOS using Homebrew and use Sites folder (Mac Monterey)

Chuyên mục

  • Agile (APM)
  • Chuyện nghề
  • Đọc
  • Học nghề
  • Làm thợ
  • Uncategorized

Tags

Agile Dev Kanban Marketing Nhóm Scrum Sách Sản phẩm Think Tôi tự học

Người học thức, tức là người thà biết ít mà thật biết những gì mình biết, còn những gì mình không biết, thì cũng biết rõ là mình không biết. “Không có sự dốt nát nhục nhã bằng tin tưởng rằng mình đã biết trong khi mình chưa biết”. Văn hóa là một vấn đề thuộc phẩm chứ không phải thuộc lượng

© 2015 copyright thaotrinhminh@gmail.com // All rights reserved // Privacy Policy