Epigraph:
Ngày xửa ngày xưa, Nhím và Gấu Nhỏ gặp nhau trong rừng.
- Chào Nhím!
- Chào Gấu Nhỏ!
Thế là, từng lời một, từng lời nói đùa, Nhím bị Gấu Nhỏ đánh vào mặt...
Dưới đây là cuộc thảo luận từ trưởng nhóm của chúng tôi, cũng như Giám đốc Phát triển Sản phẩm RAS, Igor Marnat, về các chi tiết cụ thể của xung đột công việc và các phương pháp khả thi để quản lý chúng.
Hầu hết các xung đột mà chúng ta gặp phải tại nơi làm việc đều phát triển theo một kịch bản tương tự như kịch bản được mô tả trong đoạn văn trên. Có một số người tham gia ban đầu có thiện cảm với nhau, họ đang cố gắng giải quyết một số vấn đề, nhưng cuối cùng vấn đề vẫn chưa được giải quyết và vì lý do nào đó mà mối quan hệ giữa những người tham gia thảo luận trở nên xấu đi.
Cuộc sống rất đa dạng và có nhiều biến thể xảy ra trong kịch bản được mô tả ở trên. Đôi khi mối quan hệ giữa những người tham gia ban đầu không tốt lắm, đôi khi thậm chí không có vấn đề nào cần giải quyết trực tiếp (chẳng hạn như trong đoạn văn), đôi khi sau khi thảo luận, mối quan hệ vẫn như trước khi bắt đầu, nhưng vấn đề cuối cùng không được giải quyết.
Điểm chung trong tất cả các tình huống có thể được coi là xung đột công việc là gì?
Thứ nhất, có hai hoặc nhiều bên. Các bên này có thể chiếm những vị trí khác nhau trong tổ chức, có mối quan hệ bình đẳng (đồng nghiệp trong nhóm), hoặc ở các cấp độ khác nhau trong hệ thống phân cấp (sếp - cấp dưới), cá nhân (nhân viên) hoặc nhóm (trong trường hợp xung đột giữa một nhân viên và một nhóm hoặc hai nhóm), v.v. Khả năng xảy ra xung đột và khả năng giải quyết dễ dàng bị ảnh hưởng rất nhiều bởi mức độ tin cậy giữa những người tham gia. Các bên càng hiểu nhau nhiều thì mức độ tin cậy càng cao thì cơ hội đi đến thỏa thuận càng cao. Ví dụ: các thành viên của một nhóm phân tán chưa bao giờ tương tác trực tiếp có nhiều khả năng gặp xung đột vì một vấn đề công việc đơn giản hơn những người đã có ít nhất một vài lần tương tác trực tiếp. Vì vậy, khi làm việc trong các nhóm phân tán, điều rất quan trọng là phải đảm bảo rằng tất cả các thành viên trong nhóm gặp nhau trực tiếp định kỳ.
Thứ hai, trong tình huống xung đột tại nơi làm việc, các bên đang trong tình thế phải giải quyết một số vấn đề quan trọng đối với một bên, đối với cả hai bên hoặc đối với toàn bộ tổ chức. Đồng thời, do đặc thù của tình huống, các bên thường có đủ thời gian và nhiều cách khác nhau để giải quyết (chính thức, không chính thức, họp, thư từ, quyết định quản lý, có mục tiêu, kế hoạch của nhóm, thực tế của một hệ thống phân cấp, vv). Điều này khác với tình huống giải quyết một vấn đề công việc (hoặc không liên quan đến công việc) trong một tổ chức, chẳng hạn như giải quyết một câu hỏi quan trọng: “Ơ, nhóc, bạn đến từ khu vực nào vậy?!” trên đường phố, hoặc xung đột từ biểu tượng. Trong trường hợp giải quyết vấn đề công việc, chất lượng của quy trình làm việc và văn hóa giải quyết vấn đề trong nhóm rất quan trọng.
Thứ ba, yếu tố quyết định xung đột (theo quan điểm thảo luận của chúng ta) là việc các bên tham gia quy trình không thể độc lập đi đến giải pháp cho vấn đề phù hợp với tất cả các bên. Tình huống này cần có sự can thiệp của bên thứ ba, trọng tài bên ngoài. Điểm này có vẻ còn gây tranh cãi, nhưng về bản chất, nếu tình huống xung đột được giải quyết thành công mà không cần sự can thiệp của trọng tài bên ngoài, vấn đề được giải quyết thành công và quan hệ các bên không xấu đi thì đây là tình huống mà chúng ta nên phấn đấu. . Rất có thể chúng ta thậm chí sẽ không biết về một cuộc xung đột như vậy hoặc chúng ta sẽ tình cờ phát hiện ra sau khi nó được giải quyết. Nhóm càng có thể tự giải quyết được nhiều vấn đề thì hiệu quả sẽ càng cao.
Một đặc điểm đặc trưng khác của cuộc xung đột đáng được đề cập đến là mức độ căng thẳng cảm xúc trong quá trình đưa ra quyết định. Xung đột không nhất thiết phải gắn liền với mức độ cảm xúc cao. Những người tham gia không cần phải la hét và vẫy tay để tình huống về bản chất trở thành một cuộc xung đột. Vấn đề không được giải quyết, một sự căng thẳng cảm xúc nào đó xuất hiện (có lẽ nó không được thể hiện rõ ràng ra bên ngoài), điều đó có nghĩa là chúng ta đang phải đối mặt với một tình huống xung đột.
Có cần thiết phải can thiệp vào các tình huống xung đột hay tốt hơn là để cho việc giải quyết của họ diễn ra theo cách tự nhiên và chờ đợi vấn đề tự giải quyết? Cần phải. Không phải lúc nào bạn cũng có khả năng hoặc năng lực để giải quyết hoàn toàn xung đột, nhưng trong mọi tình huống, ở bất kỳ quy mô xung đột nào, bạn có thể đảm nhận vai trò người lớn, từ đó lôi kéo thêm nhiều người xung quanh bạn vào đó, giảm thiểu hậu quả tiêu cực của xung đột. xung đột và góp phần giải quyết nó.
Trước khi xem xét một số ví dụ về các tình huống xung đột, chúng ta hãy xem xét một số điểm quan trọng chung của mọi xung đột.
Khi giải quyết xung đột, điều quan trọng là phải đứng trên cuộc đấu tranh chứ không phải bên trong nó (điều này còn được gọi là “thực hiện một vị trí meta”), nghĩa là không trở thành một phần của một trong các bên trong quá trình giải quyết. Mặt khác, việc nhờ một trọng tài bên ngoài hỗ trợ đưa ra quyết định sẽ chỉ củng cố vị thế của một trong các bên và gây bất lợi cho bên kia. Khi đưa ra một quyết định, điều quan trọng là nó phải được tất cả các bên chấp nhận về mặt đạo đức, như người ta nói, “đã mua”. Vì vậy, ngay cả khi các bên không hài lòng với quyết định được đưa ra thì ít nhất họ cũng chân thành đồng ý thực hiện nó. Như họ nói, để có thể không đồng ý và cam kết. Nếu không, xung đột sẽ đơn giản thay đổi diện mạo, ngọn lửa âm ỉ sẽ vẫn ở dưới đầm lầy than bùn và đến một lúc nào đó chắc chắn sẽ bùng lên trở lại.
Điểm thứ hai, một phần liên quan đến điểm thứ nhất, là nếu bạn đã quyết định tham gia giải quyết xung đột, hãy xem xét nó một cách nghiêm túc nhất có thể từ quan điểm giao tiếp và nghiên cứu bối cảnh. Nói chuyện riêng với từng bên. Riêng biệt với từng cái, dành cho người mới bắt đầu. Đừng chấp nhận thư. Trong trường hợp nhóm phân tán, ít nhất hãy nói chuyện qua liên kết video. Đừng hài lòng với những tin đồn và báo cáo của nhân chứng. Hiểu câu chuyện, mỗi bên muốn gì, tại sao họ muốn, họ mong đợi điều gì, họ đã cố gắng giải quyết vấn đề này trước đây chưa, điều gì sẽ xảy ra nếu nó không được giải quyết, họ thấy giải pháp nào, họ hình dung thế nào về lập trường của phía bên kia, họ nghĩ gì, đúng hay sai, v.v. Hãy tải tất cả bối cảnh có thể có vào đầu bạn, với tinh thần cởi mở, cho rằng mọi người đều đúng. Bạn không ở bên trong cuộc xung đột, bạn ở bên ngoài nó, trong một sự hoán chuyển. Nếu ngữ cảnh chỉ có sẵn trong một chủ đề bài đăng, ít nhất hãy đọc toàn bộ nó cũng như các chủ đề và tài liệu liên quan đến nó. Đọc xong vẫn nói bằng giọng nói của mình. Bạn gần như chắc chắn sẽ nghe được điều gì đó quan trọng nhưng không có trong thư.
Điểm quan trọng thứ ba là cách tiếp cận chung trong giao tiếp. Đây là những điều bình thường, không có gì mang tính vũ trụ, nhưng chúng rất quan trọng. Chúng tôi không cố gắng tiết kiệm thời gian, chúng tôi nói chuyện với tất cả những người tham gia, chúng tôi không chỉ trích người đó, nhưng chúng tôi xem xét hậu quả của hành động của anh ấy (không phải “bạn thật thô lỗ”, mà là “có lẽ các chàng trai có thể bị xúc phạm bởi chuyện này”), chúng tôi tạo cơ hội để giữ thể diện, chúng tôi tiến hành thảo luận trực tiếp chứ không phải trước hàng ngũ.
Xung đột thường xảy ra do một trong hai nguyên nhân. Điều đầu tiên liên quan đến việc một người tại thời điểm xung đột ở vị trí của người lớn hay ở vị trí của một đứa trẻ (xem thêm về điều này bên dưới). Điều này là do sự trưởng thành về mặt cảm xúc, khả năng quản lý cảm xúc của anh ấy (nhân tiện, điều này không phải lúc nào cũng liên quan đến tuổi tác của anh ấy). Nguyên nhân phổ biến thứ hai là sự không hoàn hảo của quy trình làm việc, tạo ra tình huống vùng xám trong đó trách nhiệm được dàn trải giữa những người tham gia, kỳ vọng của các bên không minh bạch với nhau và vai trò trong quy trình bị mờ nhạt.
Theo đó, khi giải quyết xung đột (cũng như bất kỳ vấn đề nào khác), người quản lý phải lưu ý ba khía cạnh: ngắn hạn - giải quyết vấn đề/xung đột ngay lúc này, trung hạn - để giảm thiểu khả năng xảy ra xung đột khác vì lý do tương tự và lâu dài - để nuôi dưỡng văn hóa trưởng thành trong con người của nhóm.
Mỗi chúng ta đều có một đứa trẻ bên trong, khoảng ba hoặc bốn tuổi. Anh ấy ngủ hầu hết thời gian tại nơi làm việc, nhưng đôi khi thức dậy và kiểm soát. Đứa trẻ có những ưu tiên riêng của mình. Quan trọng là anh ấy phải khẳng định đây là sandbox của anh ấy, mẹ anh ấy yêu anh ấy hơn, máy của anh ấy là tốt nhất (thiết kế là tốt nhất, anh ấy lập trình là tốt nhất, ...). Trong tình huống xung đột, trẻ có thể ấn đồ chơi, dậm chân và bẻ thìa, nhưng trẻ không thể giải quyết các vấn đề của người lớn (kiến trúc giải pháp, cách tiếp cận thử nghiệm tự động, ngày phát hành, v.v.), trẻ không nghĩ đến lợi ích. cho cả đội. Một đứa trẻ đang xung đột có thể được khuyến khích, an ủi và đưa đi ngủ bằng cách yêu cầu trẻ gọi điện cho người lớn. Trước khi bắt đầu cuộc thảo luận trong một tình huống xung đột, hãy đảm bảo rằng bạn đang nói chuyện với người lớn chứ không phải trẻ em và bản thân bạn đang ở vị trí của người lớn. Nếu mục tiêu trung thực của bạn lúc này là giải quyết một vấn đề nghiêm trọng thì bạn đang ở vị trí của một người trưởng thành. Nếu mục tiêu của bạn là dậm chân và bẻ xương bả vai thì đây là một tư thế trẻ con. Hãy đưa đứa trẻ bên trong bạn đi ngủ và gọi điện cho người lớn hoặc sắp xếp lại cuộc thảo luận. Một người đưa ra một quyết định mang tính cảm xúc và sau đó tìm kiếm lời biện minh hợp lý cho quyết định đó. Một quyết định do trẻ đưa ra dựa trên những ưu tiên của trẻ sẽ không phải là quyết định tối ưu.
Ngoài hành vi tại thời điểm xung đột, vị trí của trẻ em hoặc người lớn còn được đặc trưng bởi mức độ trách nhiệm mà một người sẵn sàng đảm nhận. Ở những biểu hiện cực đoan của nó, vị trí trẻ con của một lập trình viên mà tôi đã gặp hơn một lần là như thế này: Tôi viết mã, gửi đi xem xét - công việc của tôi đã hoàn thành. Reviewer nên xem xét và phê duyệt, QA nên kiểm tra, nếu có vấn đề gì họ sẽ báo cho mình biết. Thật kỳ lạ, ngay cả những người khá trưởng thành và có kinh nghiệm cũng đôi khi hành xử theo cách này. Đầu bên kia của thang đo là một người tự coi mình có trách nhiệm đảm bảo rằng mã của anh ta hoạt động, được kiểm tra bởi các thử nghiệm, đã được anh ta kiểm tra cá nhân, đã vượt qua đánh giá thành công (nếu cần, không có vấn đề gì khi ping người đánh giá, thảo luận các vấn đề bằng giọng nói, v.v.) và đã bị chặn, QA sẽ cung cấp hỗ trợ nếu cần thiết, các kịch bản thử nghiệm sẽ được mô tả, v.v. Trong các trường hợp bình thường, lập trình viên hoặc bắt đầu ở gần người trưởng thành hơn hoặc chuyển đến đó khi anh ta có được kinh nghiệm (với điều kiện văn hóa phù hợp được nuôi dưỡng trong nhóm). Trong những trường hợp nghiêm trọng, anh ấy vẫn tiếp tục làm việc, thường đảm nhận một vị trí trẻ con, sau đó anh ấy và nhóm định kỳ xảy ra vấn đề và xung đột.
Nuôi dưỡng văn hóa đúng đắn, trưởng thành trong nhóm là một nhiệm vụ quan trọng đối với bất kỳ nhà quản lý nào. Phải mất một thời gian dài và nỗ lực hàng ngày, nhưng kết quả là xứng đáng. Có hai cách để tác động đến văn hóa nhóm - lãnh đạo bằng gương mẫu (điều này chắc chắn sẽ được noi theo; nhóm luôn hướng về người lãnh đạo) và thảo luận và khen thưởng hành vi đúng đắn. Không có gì trừu tượng hoặc quá trang trọng ở đây, chỉ khi thảo luận về các vấn đề, hãy lưu ý rằng điều gì đó có thể đã được thực hiện ở đây, nhấn mạnh rằng bạn đã nhận thấy khi nào nó được quyết định đúng, khen ngợi, ghi chú trong quá trình đánh giá phát hành, v.v.
Hãy xem xét một số tình huống xung đột điển hình, từ đơn giản đến phức tạp:
Mâu thuẫn không liên quan đến vấn đề công việc
Khá thường xuyên có những xung đột trong công việc không liên quan đến vấn đề công việc. Sự xuất hiện và tính dễ giải quyết của chúng thường liên quan trực tiếp đến mức độ trí tuệ cảm xúc của những người tham gia, mức độ trưởng thành của họ và không liên quan đến sự hoàn hảo hay không hoàn hảo của quá trình làm việc.
Ví dụ điển hình: có người không sử dụng máy giặt hoặc vòi sen thường xuyên, điều mà người khác không thích, có người ngột ngạt, trong khi người khác mở cửa sổ thì bị gió thổi, có người quá ồn ào và có người cần im lặng để làm việc, và sớm. Tốt hơn hết là đừng trì hoãn việc giải quyết những xung đột kiểu này và đừng để chúng diễn ra theo chiều hướng của nó. Chúng sẽ không tự giải quyết được mà sẽ khiến bạn mất tập trung vào công việc hàng ngày và đầu độc bầu không khí trong nhóm. May mắn thay, việc giải quyết chúng thường không phải là vấn đề lớn - chỉ cần nói chuyện bình tĩnh (tất nhiên là trực tiếp) với một đồng nghiệp không quan tâm đến vệ sinh, cung cấp chỗ ngồi thoải mái cho những người thích im lặng/mát mẻ, mua tai nghe hấp thụ âm thanh hoặc lắp vách ngăn , vân vân.
Một ví dụ khác mà tôi gặp phải nhiều lần trong quá trình làm việc là sự không hòa hợp về mặt tâm lý giữa các thành viên trong nhóm. Vì lý do nào đó, mọi người đơn giản là không thể làm việc cùng nhau, mọi tương tác đều kết thúc bằng một vụ bê bối. Đôi khi điều này là do mọi người có quan điểm cực đoan về một số vấn đề cấp bách (thường là chính trị) và không biết cách để họ thoát khỏi công việc. Thuyết phục họ bao dung lẫn nhau hoặc thay đổi hành vi là một công việc khá vô ích. Ngoại lệ duy nhất tôi gặp phải là những đồng nghiệp trẻ có nhận thức cởi mở, cách ứng xử của họ vẫn có thể dần thay đổi thông qua những cuộc trò chuyện định kỳ. Thông thường, vấn đề được giải quyết thành công bằng cách tách họ thành các nhóm khác nhau hoặc ít nhất là tạo cơ hội cho họ có cơ hội chồng chéo trong công việc.
Trong tất cả các tình huống trên, cần nói chuyện riêng với tất cả những người tham gia, thảo luận về tình huống đó, hỏi xem họ có thấy vấn đề gì trong trường hợp này không, hỏi xem, theo ý kiến của họ, giải pháp là gì và đảm bảo họ tham gia vào việc đưa ra vấn đề này. phán quyết.
Từ quan điểm tối ưu hóa quy trình làm việc (quan điểm trung hạn mà tôi đã đề cập), ở đây không thể làm được gì nhiều, điểm duy nhất để tối ưu hóa là tính đến yếu tố tương thích khi thành lập nhóm và không đặt mọi người vào cùng nhau trước ai sẽ xung đột.
Từ góc độ văn hóa nhóm, những tình huống như vậy ít xảy ra hơn ở những nhóm có nền văn hóa trưởng thành, nơi mọi người tôn trọng nhóm và đồng nghiệp cũng như biết cách giải quyết vấn đề một cách độc lập. Ngoài ra, những xung đột như vậy được giải quyết dễ dàng hơn nhiều (thường là tự động) trong các nhóm có mức độ tin cậy cao, mọi người đã làm việc cùng nhau trong thời gian dài và/hoặc thường xuyên giao tiếp bên ngoài công việc.
Mâu thuẫn liên quan đến vấn đề công việc:
Những xung đột như vậy thường do cả hai lý do cùng một lúc, cả về tình cảm (thực tế là một trong những người tham gia không ở vị trí của người lớn) và sự không hoàn hảo của bản thân quá trình làm việc. Có lẽ loại xung đột phổ biến nhất mà tôi gặp phải là xung đột trong quá trình đánh giá mã hoặc thảo luận về kiến trúc giữa các nhà phát triển.
Tôi xin nêu ra hai trường hợp điển hình ở đây:
1) Trong trường hợp đầu tiên, nhà phát triển không thể nhận được đánh giá mã từ đồng nghiệp. Bản vá được gửi để xem xét và không có gì xảy ra. Thoạt nhìn, giữa hai bên không có xung đột rõ ràng, nhưng nếu nghĩ kỹ thì đây thực sự là một xung đột. Vấn đề công việc không được giải quyết, một trong các bên (đang chờ xem xét) cảm thấy khó chịu rõ ràng. Một loại phụ cực đoan của trường hợp này là sự phát triển trong một cộng đồng hoặc trong các nhóm khác nhau, trong khi người đánh giá có thể không quan tâm đến mã cụ thể này, do đang tải hoặc các trường hợp khác, có thể không chú ý đến yêu cầu đánh giá và trọng tài bên ngoài (một người quản lý chung cho cả hai bên)) có thể hoàn toàn không tồn tại.
Cách tiếp cận giải pháp hữu ích trong tình huống như vậy liên quan chính xác đến quan điểm lâu dài, văn hóa của người trưởng thành. Đầu tiên, hoạt động thông minh hoạt động. Bạn không nên mong đợi rằng đoạn mã treo trên bài đánh giá sẽ thu hút sự chú ý của chính người đánh giá. Chúng tôi cần giúp những người đánh giá chú ý đến anh ấy. Pingani một vài người, đặt câu hỏi trên syncape, tham gia thảo luận. Rõ ràng, sự miễn trừ có nhiều khả năng gây hại hơn là giúp ích, bạn cần phải sử dụng lẽ thường. Thứ hai, việc chuẩn bị trước diễn ra tốt đẹp. Nếu nhóm hiểu điều gì đang xảy ra và tại sao, tại sao lại cần đến mã này, thiết kế đã được thảo luận và thống nhất trước với mọi người thì mọi người sẽ có nhiều khả năng chú ý đến mã đó và chấp nhận nó cho công việc. Thứ ba, quyền lực hoạt động. Nếu bạn muốn được đánh giá, hãy tự mình đánh giá thật nhiều. Thực hiện các bài đánh giá chất lượng cao bằng các bài kiểm tra thực tế, các bài kiểm tra thực tế và các nhận xét hữu ích. Nếu biệt hiệu của bạn được nhiều người biết đến trong nhóm thì khả năng mã của bạn sẽ được chú ý sẽ cao hơn.
Từ quan điểm quy trình làm việc, những cải tiến có thể có ở đây là mức độ ưu tiên chính xác nhằm giúp nhà phát triển đạt được mục tiêu của mình và của nhóm (đánh giá những người khác, viết thư cho cộng đồng, kèm theo mã với mô tả kiến trúc, tài liệu, kiểm tra, tham gia thảo luận với cộng đồng, v.v.), ngăn các bản vá treo trong hàng đợi quá lâu, v.v.
2) Trường hợp xung đột phổ biến thứ hai trong quá trình đánh giá mã hoặc thiết kế là các quan điểm khác nhau về các vấn đề kỹ thuật, phong cách viết mã và lựa chọn công cụ. Điều quan trọng nhất trong trường hợp này là mức độ tin cậy giữa những người tham gia, thuộc cùng một nhóm và kinh nghiệm làm việc cùng nhau. Một ngõ cụt xảy ra khi một trong những người tham gia có tư thế trẻ con và không cố gắng nghe những gì người đối thoại muốn truyền đạt cho mình. Thông thường, cả cách tiếp cận do bên kia đề xuất và cách tiếp cận được đề xuất ban đầu đều có thể hoạt động thành công và về nguyên tắc việc chọn cái nào không quan trọng.
Một ngày nọ, một lập trình viên trong nhóm của tôi (hãy gọi anh ấy là Pasha) đã chuẩn bị một bản vá với những thay đổi đối với hệ thống triển khai gói, được phát triển và hỗ trợ bởi các đồng nghiệp từ bộ phận lân cận. Một trong số họ (Igor) có quan điểm mạnh mẽ của riêng mình về cách cấu hình chính xác các dịch vụ Linux khi triển khai các gói. Ý kiến này khác với cách tiếp cận được đề xuất trong bản vá và họ không thể đồng ý. Như thường lệ, thời hạn sắp hết và cần phải đưa ra quyết định nào đó, cần phải có một trong số họ đảm nhận vị trí người lớn. Pasha nhận ra rằng cả hai cách tiếp cận đều có quyền sống, nhưng anh muốn lựa chọn của mình được thông qua, bởi vì Cả lựa chọn thứ nhất lẫn lựa chọn thứ hai đều không có bất kỳ lợi thế kỹ thuật rõ ràng nào.
Cuộc thảo luận của chúng tôi trông giống như thế này (tất nhiên là rất sơ đồ, cuộc trò chuyện kéo dài nửa giờ):
- Pasha, chúng tôi sẽ tạm dừng tính năng trong vài ngày tới. Điều quan trọng là chúng tôi phải tập hợp mọi thứ lại với nhau và bắt đầu thử nghiệm càng sớm càng tốt. Làm sao chúng ta có thể vượt qua được Igor?
— Anh ấy muốn thiết lập các dịch vụ theo cách khác, anh ấy đã dán bình luận ở đó cho tôi...
- Và có gì đâu, thay đổi lớn, nhiều ồn ào?
- Không, có việc trong vài giờ, nhưng cuối cùng cũng không có gì khác biệt, kiểu nào cũng được, tại sao lại cần thiết? Tôi đã làm được điều gì đó hiệu quả, hãy chấp nhận nó.
- Nghe này, cậu đã thảo luận về chuyện này được bao lâu rồi?
- Vâng, chúng ta đã chấm giờ được một tuần rưỡi rồi.
- Ừm... liệu chúng ta có thể giải quyết một vấn đề trong vài giờ mà đã mất cả tuần rưỡi mà không làm được không?
- Đúng vậy, nhưng tôi không muốn Igor nghĩ rằng tôi đã nhượng bộ...
- Nghe này, điều gì quan trọng hơn đối với bạn, đưa ra bản phát hành, cùng với quyết định của bạn bên trong, hay giết Igor? Tuy nhiên, chúng tôi có thể chặn nó, tuy nhiên, sẽ có cơ hội tốt để vượt qua với bản phát hành.
- Chà... tất nhiên là sẽ rất tuyệt nếu lau mũi cho Igor, nhưng được rồi, việc thả ra quan trọng hơn, tôi đồng ý.
- Điều Igor nghĩ có thực sự quan trọng với bạn không? Thành thật mà nói, anh ấy không quan tâm chút nào, anh ấy chỉ muốn có một cách tiếp cận thống nhất ở những nơi khác nhau về công việc mà anh ấy chịu trách nhiệm.
- Được rồi, hãy để tôi làm như anh ấy yêu cầu ở phần bình luận và chúng ta hãy bắt đầu thử nghiệm.
- Cảm ơn Pasha! Tôi chắc chắn rằng trong hai bạn, bạn sẽ trưởng thành hơn, mặc dù Igorek lớn tuổi hơn bạn :)
Vấn đề đã được giải quyết, việc phát hành được phát hành đúng thời hạn, Pasha không cảm thấy bất mãn lắm, bởi vì chính ông đã đề xuất một giải pháp và thực hiện nó. Igor nói chung rất hài lòng, bởi vì... Ý kiến của anh ấy đã được tính đến và họ đã làm như anh ấy đề xuất.
Một loại xung đột khác về cơ bản giống nhau là sự lựa chọn giữa các giải pháp/thư viện/phương pháp tiếp cận kỹ thuật trong một dự án, đặc biệt là trong một nhóm phân tán. Trong một trong những dự án được định vị là sử dụng C/C++, hóa ra việc quản lý kỹ thuật của dự án hoàn toàn chống lại việc sử dụng STL (Thư viện mẫu tiêu chuẩn). Đây là thư viện ngôn ngữ tiêu chuẩn giúp đơn giản hóa việc phát triển và nhóm của chúng tôi đã rất quen với nó. Hóa ra là dự án gần với C hơn nhiều so với C++, điều này không truyền cảm hứng nhiều cho nhóm, bởi vì Ban quản lý đã cố gắng hết sức và tuyển dụng những cầu thủ thực sự tuyệt vời. Đồng thời, phần người Mỹ trong nhóm, cả kỹ sư và quản lý, đã làm việc ở công ty lâu năm, đã quen với tình trạng hiện tại và hài lòng với mọi thứ. Phần người Nga trong nhóm đã được tập hợp lại khá gần đây, trong vòng vài tuần (bao gồm cả tôi). Phần người Nga trong nhóm rõ ràng không muốn từ bỏ cách tiếp cận phát triển thông thường.
Những cuộc thảo luận bằng văn bản bất tận bắt đầu giữa hai lục địa, những lá thư trên ba hoặc bốn màn hình bay qua bay lại, trong thư nhóm và thư cá nhân, từ lập trình viên đến lập trình viên và nhà quản lý. Như thường lệ, những bức thư dài như thế này không được ai đọc ngoại trừ các tác giả và những người ủng hộ nhiệt thành của họ. Các cuộc trò chuyện trở nên căng thẳng, truyền tải những suy nghĩ đa màn hình theo các hướng khác nhau về lợi thế kỹ thuật của STL, mức độ thử nghiệm của nó, mức độ an toàn và nói chung, cuộc sống tuyệt vời biết bao khi có nó và thật khủng khiếp biết bao khi không có nó .
Tất cả điều này kéo dài khá lâu, cho đến khi cuối cùng tôi nhận ra rằng chúng tôi đang thảo luận về khía cạnh kỹ thuật của vấn đề, nhưng thực tế vấn đề không phải là vấn đề kỹ thuật. Vấn đề không phải là ưu điểm hay nhược điểm của STL hay khó khăn khi làm việc mà không có nó. Vấn đề là khá tổ chức. Chúng tôi chỉ cần hiểu cách thức hoạt động của công ty nơi chúng tôi làm việc. Không ai trong chúng tôi từng có kinh nghiệm làm việc ở một công ty như vậy trước đây. Vấn đề là sau khi mã được phát triển và đưa vào sản xuất, sự hỗ trợ được xử lý bởi những người hoàn toàn khác với các nhóm khác, từ các quốc gia khác. Đội ngũ kỹ thuật khổng lồ gồm hàng chục nghìn kỹ sư (tổng cộng) này chỉ có thể mua được một lượng phương tiện kỹ thuật tối thiểu hoàn toàn cơ bản, có thể nói là một mức tối thiểu tối thiểu. Bất cứ điều gì vượt quá tiêu chuẩn kỹ thuật được thiết lập trong công ty đều không thể được hỗ trợ trong tương lai. Cấp độ của một đội được xác định bởi cấp độ của các thành viên yếu nhất. Sau khi chúng tôi hiểu động lực thực sự hành động của phần người Mỹ trong nhóm, vấn đề này đã được loại bỏ khỏi chương trình nghị sự và chúng tôi đã cùng nhau phát triển và phát hành thành công sản phẩm theo các tiêu chuẩn được công ty áp dụng. Thư từ và trò chuyện trong trường hợp này không có tác dụng tốt, phải mất vài chuyến đi và rất nhiều cuộc trao đổi cá nhân để đi đến mẫu số chung.
Từ quan điểm của quy trình làm việc, trong trường hợp cụ thể này, sẽ rất hữu ích nếu có mô tả về các công cụ được sử dụng, các yêu cầu đối với chúng, các hạn chế trong việc thêm các công cụ mới và giải thích cho các hạn chế đó. Những tài liệu như vậy gần như tương ứng với những tài liệu được mô tả trong các đoạn Chiến lược tái sử dụng và Môi trường phát triển của “Sổ tay dành cho người quản lý phát triển phần mềm”, được phát triển trong . Bất chấp tuổi đời của nó, nó mô tả một cách hoàn hảo tất cả các hoạt động chính và các giai đoạn lập kế hoạch phát triển phần mềm thuộc loại này. Việc có những tài liệu như thế này giúp bạn dễ dàng thảo luận về những thành phần và phương pháp tiếp cận nào có thể được sử dụng trong một sản phẩm và tại sao.
Rõ ràng, từ quan điểm văn hóa, với một quan điểm trưởng thành hơn, trong đó các bên cố gắng lắng nghe và hiểu động cơ thực sự trong hành động và hành động của đồng nghiệp dựa trên các ưu tiên của dự án và nhóm chứ không phải cái tôi cá nhân. , xung đột sẽ được giải quyết dễ dàng và nhanh chóng hơn.
Trong một xung đột khác về việc lựa chọn giải pháp kỹ thuật, tôi cũng phải mất một khoảng thời gian đáng kể để hiểu được động cơ của một trong các bên (đó là một trường hợp rất bất thường), nhưng sau khi động cơ đã rõ ràng thì giải pháp đã rõ ràng.
Tình huống là thế này: một nhà phát triển mới xuất hiện trong một nhóm khoảng 20 người, hãy gọi anh ta là Stas. Vào thời điểm đó, công cụ tiêu chuẩn để liên lạc với nhóm của chúng tôi là Skype. Hóa ra sau này, Stas là một người rất hâm mộ các tiêu chuẩn mở và phần mềm nguồn mở, đồng thời chỉ sử dụng các công cụ và hệ điều hành có nguồn công khai và sử dụng các giao thức được mô tả công khai. Skype không phải là một trong những công cụ này. Chúng tôi đã dành nhiều thời gian để thảo luận về ưu và nhược điểm của phương pháp này, nỗ lực tung ra các phiên bản tương tự của Skype trên các hệ điều hành khác nhau, nỗ lực của Stas để thuyết phục nhóm chuyển sang các tiêu chuẩn khác, viết thư cho anh ấy qua thư, gọi điện riêng cho anh ấy trên điện thoại, mua cho anh ấy một chiếc máy tính thứ hai dành riêng cho Skype, v.v. Cuối cùng, tôi nhận ra rằng vấn đề này, về bản chất, không phải là vấn đề kỹ thuật hay tổ chức, nó đúng hơn là vấn đề tư tưởng, thậm chí có thể nói là tôn giáo (đối với Stas). Ngay cả khi cuối cùng chúng tôi kết nối Stas và Skype (mất vài tháng), vấn đề vẫn sẽ xuất hiện trên bất kỳ thiết bị nào tiếp theo. Tôi không có phương tiện thực sự nào để thay đổi thế giới quan của Stas và không có lý do gì để cố gắng thay đổi thế giới quan của một nhóm làm việc hoàn hảo trong môi trường này. Con người và công ty đơn giản là trực giao trong thế giới quan của họ. Trong những tình huống như vậy, một giải pháp tốt là tổ chức. Chúng tôi đã chuyển Stas sang một đội khác, nơi anh ấy có tổ chức hơn.
Theo tôi, nguyên nhân dẫn đến xung đột này là sự khác biệt giữa văn hóa cá nhân của một người cụ thể (người có quan điểm mạnh mẽ không cho phép anh ta thỏa hiệp) và văn hóa của công ty. Trong trường hợp này, tất nhiên đó là sai lầm của người quản lý. Ban đầu thật sai lầm khi đưa anh ấy vào một dự án kiểu này. Stas cuối cùng đã chuyển sang một dự án phát triển phần mềm nguồn mở và đã thể hiện xuất sắc ở đó.
Một ví dụ điển hình về xung đột gây ra bởi cả thái độ trẻ con của nhà phát triển và những thiếu sót trong quy trình làm việc là một tình huống trong đó, do không có định nghĩa về việc đã hoàn thành, nhà phát triển và nhóm QA có những kỳ vọng khác nhau về mức độ sẵn sàng của tính năng được chuyển sang QA. Nhà phát triển tin rằng chỉ cần viết mã và ném tính năng này qua hàng rào cho QA là đủ - họ sẽ phân loại nó ở đó. Nhân tiện, một lập trình viên khá trưởng thành và giàu kinh nghiệm, nhưng đó là ngưỡng nội tại của anh ấy về chất lượng. QA không đồng ý với điều này và yêu cầu cho họ xem và mô tả cho họ những gì anh ấy đã tự mình kiểm tra, đồng thời yêu cầu họ có một kịch bản thử nghiệm. Trước đây, họ đã gặp vấn đề với chức năng của nhà phát triển này và không muốn lãng phí thời gian nữa. Nhân tiện, họ đã đúng - tính năng này thực sự không hoạt động, anh ấy đã không kiểm tra mã trước khi gửi nó cho QA.
Để giải quyết tình huống, tôi đã yêu cầu anh ấy cho tôi thấy rằng mọi thứ thực sự đã hoạt động (nó không hoạt động và anh ấy phải sửa nó), chúng tôi đã nói chuyện với nhóm và về định nghĩa QA là đã hoàn thành (họ đã không thực hiện được điều đó). bằng văn bản, bởi vì chúng tôi không muốn làm cho quy trình trở nên quá quan liêu), à, chúng tôi đã sớm chia tay chuyên gia này (để giải tỏa chung).
Từ quan điểm của quy trình làm việc, những cải tiến có thể có trong trường hợp này là sự hiện diện của định nghĩa đã hoàn thành, các yêu cầu hỗ trợ cho từng tính năng đơn vị và các thử nghiệm tích hợp cũng như mô tả thử nghiệm do nhà phát triển thực hiện. Ở một trong các dự án, chúng tôi đã đo mức độ bao phủ của mã bằng các thử nghiệm trong CI và nếu mức độ bao phủ giảm xuống sau khi thêm bản vá, thì các thử nghiệm đó được đánh dấu là không thành công, tức là đã thất bại. bất kỳ mã mới nào chỉ có thể được thêm vào nếu có thử nghiệm mới cho nó.
Một ví dụ điển hình khác về xung đột liên quan chặt chẽ đến việc tổ chức quá trình làm việc. Chúng tôi có một sản phẩm, một nhóm phát triển sản phẩm, một nhóm hỗ trợ và một khách hàng. Khách hàng gặp vấn đề với sản phẩm và liên hệ hỗ trợ. Bộ phận hỗ trợ phân tích vấn đề và hiểu rằng vấn đề nằm ở sản phẩm và chuyển vấn đề đó cho nhóm sản phẩm. Nhóm sản phẩm đang trong thời gian bận rộn, ngày phát hành đang đến gần nên một phiếu có vấn đề từ khách hàng, bị thất lạc trong số các phiếu khác của nhà phát triển mà nó được chỉ định, bị treo trong vài tuần mà không được chú ý. Bộ phận hỗ trợ cho rằng nhà phát triển đang giải quyết vấn đề của khách hàng. Khách hàng chờ đợi và hy vọng rằng vấn đề của họ đang được giải quyết. Trên thực tế, vẫn chưa có gì xảy ra. Sau một vài tuần, cuối cùng khách hàng quyết định quan tâm đến tiến độ và yêu cầu hỗ trợ xem mọi việc đang diễn ra như thế nào. Hỗ trợ yêu cầu phát triển. Nhà phát triển rùng mình, xem qua danh sách vé và tìm thấy vé của khách hàng ở đó. Đọc phiếu yêu cầu của khách hàng, anh ta hiểu rằng không có đủ thông tin để giải quyết vấn đề và anh ta cần thêm nhật ký và bãi chứa. Bộ phận hỗ trợ yêu cầu thêm thông tin từ khách hàng. Và sau đó khách hàng nhận ra rằng suốt thời gian qua chưa có ai giải quyết vấn đề của mình. Và sấm sét sẽ tấn công...
Trong tình huống này, giải pháp cho xung đột khá rõ ràng và tuyến tính (sửa sản phẩm, cập nhật tài liệu và kiểm tra, xoa dịu khách hàng, phát hành hotfix, v.v.). Điều quan trọng là phải phân tích quy trình làm việc và hiểu ai chịu trách nhiệm tổ chức sự tương tác giữa hai nhóm và tại sao tình huống này lại có thể xảy ra ngay từ đầu. Rõ ràng những gì cần phải khắc phục trong quy trình - phải có ai đó theo dõi bức tranh tổng thể mà không cần khách hàng nhắc nhở, một cách chủ động. Vé từ khách hàng phải nổi bật so với các vé khác từ nhà phát triển. Bộ phận hỗ trợ nên xem liệu nhóm phát triển hiện có đang làm việc với phiếu của mình hay không và nếu không thì khi nào nhóm có thể bắt đầu hoạt động và khi nào có thể đạt được kết quả. Bộ phận hỗ trợ và phát triển nên liên lạc và thảo luận định kỳ về trạng thái của yêu cầu, việc thu thập thông tin cần thiết để gỡ lỗi phải được tự động hóa nhiều nhất có thể, v.v.
Cũng giống như trong chiến tranh, kẻ thù cố gắng tấn công vào điểm nối giữa hai đơn vị, nên trong công việc, điểm nhạy cảm và dễ bị tổn thương nhất thường là sự tương tác giữa các đội. Nếu người quản lý hỗ trợ và phát triển đủ tuổi, họ sẽ có thể tự khắc phục quy trình, nếu không, quy trình sẽ tiếp tục tạo ra xung đột và vấn đề cho đến khi người quản lý can thiệp và có thể khắc phục tình trạng này.
Một ví dụ điển hình khác mà tôi đã thấy nhiều lần ở các công ty khác nhau là tình huống trong đó sản phẩm được viết bởi một nhóm, các bài kiểm tra tích hợp tự động cho sản phẩm đó được viết bởi nhóm thứ hai và cơ sở hạ tầng mà nó được vận hành đều được đi kèm với một nhóm thứ ba. đội. Các vấn đề khi chạy thử nghiệm luôn phát sinh và nguyên nhân gây ra sự cố có thể là do cả sản phẩm, thử nghiệm và cơ sở hạ tầng. Thông thường, việc thống nhất ai sẽ thực hiện phân tích ban đầu về sự cố, lỗi tệp, nhật ký phân tích cú pháp của sản phẩm, kiểm tra và cơ sở hạ tầng, v.v., thường là vấn đề khó khăn. Xung đột ở đây rất thường xuyên, đồng thời, xảy ra đồng đều. Trong trường hợp cường độ cảm xúc cao, những người tham gia thường rơi vào tư thế trẻ con và các cuộc thảo luận bắt đầu theo chuỗi: “tại sao tôi phải mày mò chuyện này”, “họ thường xuyên đổ vỡ hơn”, v.v.
Từ góc độ quy trình làm việc, các bước cụ thể để giải quyết vấn đề phụ thuộc vào thành phần của các nhóm, loại thử nghiệm và sản phẩm, v.v. Tại một trong các dự án, chúng tôi đã giới thiệu nhiệm vụ định kỳ, trong đó các nhóm giám sát lần lượt các bài kiểm tra, hàng tuần. Mặt khác, phân tích ban đầu luôn được thực hiện bởi các nhà phát triển thử nghiệm, nhưng phân tích rất cơ bản và sản phẩm khá ổn định nên hoạt động tốt. Điều quan trọng là đảm bảo rằng quy trình này minh bạch, kỳ vọng rõ ràng đối với tất cả các bên và mọi người đều cảm thấy hoàn cảnh công bằng.
Xung đột có phải là một vấn đề trong một tổ chức hay không? Đó có phải là một dấu hiệu xấu khi xung đột thường xuyên (hoặc chỉ định kỳ) xảy ra trong nhóm của bạn? Nói chung là không, vì nếu có tăng trưởng, phát triển, có động lực nào đó thì nảy sinh những vấn đề chưa từng được giải quyết trước đây và khi giải quyết có thể nảy sinh xung đột. Đây là dấu hiệu cho thấy một số lĩnh vực cần được chú ý và có những lĩnh vực cần cải thiện. Thật tệ nếu xung đột nảy sinh thường xuyên, khó giải quyết hoặc mất nhiều thời gian. Đây rất có thể là dấu hiệu của quy trình làm việc chưa được sắp xếp hợp lý và đội ngũ chưa đủ trưởng thành.
Nguồn: www.habr.com