팀의 개발자 간 충돌을 처리하는 방법은 무엇입니까? [닫은]


26

이것은 모든 팀에서 일어나고 있습니다.

어떤 이유로 팀에서 충돌이 발생하여 전반적인 동기와 생산성에 영향을 미칩니다.

일반적인 문제를 해결하기 위해 권장되는 방법은 무엇입니까?

:

  • 팀의 한 부분은 의존성 주입을 구현하기를 원하고, 다른 부분은 시간 낭비라고 생각합니다.
  • 일부 개발자는 나머지 팀원이 개발 속도를 늦추고 있다고 생각합니다 (일정이 늦어진 이유를 설명합니다)
  • 하나 이상의 개발자 간의 개인 비 호환성
  • 한 개발자는 명백한 이유없이 다른 개발자와의 대화를 거부합니다.

4
나는 그 질문이 괜찮다고 생각합니다. 차이점은 질문이 프로그래머와 관련이 없다면 우리가 반대 할 수 있지만 질문이 프로그래머와 관련이 있지만 다른 것들과 관련이 있다면 문제가 없다는 것입니다. 이 사이트에서 허용되는 프로그래밍의 많은 것들이 다른 많은 주제와 영역에도 적용될 수 있습니다.
Jasarien

1
여러 가지 유형의 충돌이 있으며, 각각 고유 한 방식으로 처리합니다. 더 자세하게 얘기해 주 시겠어요.
Geek

3
@David-사이트 자체의 기준은 프로그래밍과 관련된 질문입니다. 다른 것과 관련이 없다고 말하는 곳은 없습니다. 개발자라는 용어를 바꾸면 대답이 비슷하기 때문에 다른 질문을하는 것입니다. 같은 질문이 아닙니다. 3 + 3이란 무엇입니까? 6. 곤충에는 다리가 몇 개나 있습니까? 6. 두 질문은 완전히 다르지만 정답은 같습니다. 개발자는 비상 서비스 팀원과 완전히 사회적으로 다를 수 있습니다. 둘 다 갈등이 있고 갈등을 해결하는 다른 방법이 있습니다.
Jasarien

1
@Pierre :이 질문을 예고, 의견 또는 더 나은 장소를 얻을 수있는 기회없이 닫으시겠습니까? 이 질문은 모든 사무직에 관한 것입니다.
Maniero

1
이 질문은 직장 관계에 관한 것이기 때문에 주제가 아닌 것 같습니다. 예제는 프로그래머에 관한 것이며 언급 된 충돌 중 일부는 프로그래밍과 관련이 있지만, 핵심은 그룹의 사람들이 함께 잘 일하도록하는 방법입니다.
Bryan Oakley

답변:


26

나는 2 년 동안 10 명으로 구성된 팀이 충돌 (목재)없이 있었는데 운이 좋거나 바른 일을하고있을 수 있습니다. 충돌을 처리하는 가장 좋은 방법은 더 이상 충돌을 일으키지 않는 것입니다. 전파 할 수있는 몇 가지 핵심 가치가 있습니다.

  1. 팀 정신
  2. 모든 것의 공정성 (보상 / 보상)
  3. 감사하기
  4. 인정하고 책임을 져라
  5. 자유를 주다
  6. 사람들이 팀보다 크지 않다는 것을 알리십시오
  7. 개인적인 성공은 팀이 실패해도 아무 의미가 없습니다
  8. 사람들에게 개인적으로 붙이다
  9. 당신이 줄 의도가없는 당근을 보여주지 마십시오
  10. 팀을 망칠 수있는 사람을 고용하지 마십시오
  11. 더 자주 의사 소통하는 등
  12. 누군가가 일을 넘어 설 때마다 감사
  13. 성능에 대한 정기적 인 피드백을 제공하고 매월 기대치를 설정하십시오.
  14. 사람들이 아이들처럼 행동 할 때 알려주십시오.

이 모든 것들은 어떤 사람의 노력을 기울입니다.

소프트웨어는 거의 팀 게임 개인의 광채는 일반적으로 수명이 짧습니다. 내가 당신의 모범으로 가면 :

  1. 우리는 의존성 주입을하기로 결정했습니다. 기간. 그것이 최선의 방법인지 아닌지를 알게 될 것입니다. 그렇지 않다면 협력하기 전까지 초콜릿을 얻습니다.
  2. 팀의 나머지 인원이 당신을 늦추고 있다면, 당신이 더 빠른 팀원이되도록 도와주십시오. 나는 당신이 좋다는 것을 알고 있습니다.
  3. 그들 모두에게 환경을 망치고 있다고 말하십시오. 아무것도 효과가 없다면 그들 중 하나 또는 둘 다를 제거하십시오.

내가 매우 효과적이라고 생각하는 것은 "우리는 좋은 팀입니다"를 반복하고 "우리는 외로운 사람의 팀입니다"를 반복하는 것입니다.


11
난 당신에게 1000 upvotes을 줄 것이다. 팀 갈등은 관리자의 책임입니다. 관리자가 많지 않은 갈등이 많은 팀에 가본 적이 없습니다. 말했듯이 가장 좋은 방법은 갈등이 오래 지속되지 않도록하는 것입니다. 너무 많은 관리자들이 갈등을 해결함으로써 사람들을 화나게하는 것을 두려워합니다. 결과적으로 그들은 더 많은 사람들을 화나게하고 생산성에 더 많은 영향을줍니다. 사람들을 존중하는 태도로 대할 것이며 팀의 다른 사람들을 존중하지 않는 사람도 용납하지 않을 것이 분명하다면 많은 갈등이 사라집니다. 당신은 일하기 좋은 사람처럼 보입니다.
HLGEM

1
+1 아주 좋은 답변입니다! 그러나 관리자로서 당신은 완벽한 팀 이 없으며 항상 어느 정도의 갈등이 있다는 것을 머리 뒤로 가져야합니다 . 그것은 인간의 본성입니다!
Amir Rezaei

"모든 것의 공정성 (보상 / 보상)"공개하지 않고 어떻게 할 수 있습니까?
Den

11

그것은 분명히 갈등에 ​​달려있다. 그들은 여러 가지 맛이 있습니다.

  • 종교적 주장 ( "공백 대신 탭을 계속 사용하는 이유는 무엇입니까?!?")

이 경우 명확하게하는 것은 원칙적으로 어느 것이 옳은지는 중요하지 않으며 실제로 전체 팀이 동일한 접근 방식을 사용하는 것이 훨씬 더 중요하다는 것입니다. 소수의 의견 보유자에게 설명하십시오 (그리고 반드시 올바른 결정일 필요는 없지만 피를 뽑을 정도로 중요하지 않음을 강조하십시오). 예를 들어 소스 제어 사용을 거부하거나 코드 검토에 제출하는 것을 거부하는 개발자의 경우가 이에 해당합니다. 그것은 관리 문제이며, 솔직히 불량 개발자를 보내지 않고 해결하는 방법을 모릅니다.

  • 개인적인 논쟁 ( "나는 너를 좋아하지 않아")

실제로이를 완화 할 방법이 없습니다. 두 팀 모두에게 논쟁의 여지가 없으며, 같은 팀의 생산적인 구성원이 되려면 문에서 자신의 개인적인 원한을 점검해야 함을 분명히하십시오 (이것은 관리자인지 여부에 관계없이 작동합니다) 자신이 충분히 확신한다면 동료들은 놀랍도록 영향력을 가질 수 있습니다.) 그래도 문제가 해결되지 않으면 조직도에서 분할하여 전문가 / 물리적 근접성을 줄이거 나 자신과 책상을 멀리하십시오.

  • 기술적 논증

이것과 다른 충돌 유형의 주요 차이점은 정답 일 가능성이 있다는 것입니다. 일반적으로 하나 또는 다른 개발자가 소유 한 코드 및 작동 방식 (때로는 더 큰 아키텍처 인수)과 관련이 있습니다. 여기서 파악해야 할 핵심 사항은 정답이 있어도 모르는 것 입니다. 당신이 할 수있는 최선의 방법은 그것이 확실한 주장인지 확인하기 위해 중재하는 것이며, 어느 쪽이든 확신 할 수 있기를 바랍니다. 다시, 당신은 그들이 당신에게보고 여부에 관계 없이이 작업을 수행 할 수 있지만, 당신이 동료 인 경우, 당신은 그들이 결론을 내릴 수 있더라도 경기를 다시 실행하기 위해 관리자에게 갈 수 있습니다.


5

제 3 자 편견이없는 중재자가 분쟁 당사자 모두와 함께 앉게하여 대화를 나누도록합니다.

중재자가 문제를 겪고있는 사람이 편안하게 대화 할 수있는 사람이라면 여전히 도움이되고


2

그들이 둘 다 성숙하게 행동 할 수없고 전문가를 얻는다면, 계약자 / 누군가 프리랜서일까요?


2

내 경험상 이러한 성격의 대부분의 충돌은 성격 충돌로 귀결됩니다. 그들 중 일부는 다른 요소를 가지고 있지만 가장 일반적으로 이것들은 의견 차이를 일으키는 수단으로 사용되기 때문에 논쟁의 여지가있는 문제를 해결하더라도 다른 일이 일어나기 전에 시간 문제입니다.

나의 충고:

1) 첫 번째는 두 사람에게 갈등이 심하게 반영되고 승자와 패자가 없을 것이며, 학위가 다른 두 명의 패자가 될 것이라는 점을 두 사람에게 분명히하는 것입니다.

2) 두 사람 모두 직업적으로 행동 할 것으로 예상되는 일이 무엇인지 명확하게하십시오. 그들은 서로를 좋아할 필요는 없지만 민사적이고 효율적이며 조직적이어야합니다. 연례 평가 및 검토에 반영되는지 확인하십시오. 팀 동료와 함께 할 수 없다는 것은 성과에 중대한 문제입니다.

3) 서로의 문제에 귀를 기울이고 동정심이있는 경우에는이 영역에서의 실패를 지적하고 누가 옳고 그른지에 대한 연장 된 토론이나 판단에 빠지지 않도록하십시오. 내가 95 %의 사례에서 말했듯이 (나머지 5 %는 징계 문제로 올바르게 다루어야하는 진정한 괴롭힘 등), 그들은 틀 렸으며 이해해야합니다.

4) 가능하면 쉽게 분리하여 보관하십시오. 나는 일반적으로 사람들을 함께 던지는 것이 그것을 자극하는 것 이상을한다는 것을 알지 못한다. 그들이 "화해"하려고한다면 어쨌든 일어날 것이고 나는 그들이 서로의 얼굴에 계속해서 있지 않을 때 일어날 가능성이 더 높다고 생각합니다.


1

"테크 오프"에서 전투를 벌여야합니다. 각 기계에는 분해 된 컴퓨터가 있습니다. 그는 기계를 조립하고 첫 승리를 거둔 사람입니다.

그것이 당신에게 효과가 없다면, 당신은 마체 테 싸움이나 전기 톱 싸움을 시도해야합니다.


전기 톱. 모든 소프트웨어 엔지니어는 DOOM을 사용하여 전기 톱 전문가입니다. 어떤 고기를 찾으십시오.
Adam Crossland

@ 아담 크로스 랜드 ROFL
Muad'Dib

1

TKI 는 일부 문제를 해결하는 방법에 대한 아이디어 일 수있는 충돌 해결을위한 몇 가지 서로 다른 기술을 식별합니다. 프레임 워크를 사용하는 것과 같은 합법적 인 문제가 있지만,이를 해결하기위한 한 가지 방법으로 무언가에 투표하는 팀이나 일종의 관리자처럼 더 높은 권한으로 가면서 처리 될 수 있습니다. 특정 판결을 얻기 위해 프로젝트 관리자 또는 비즈니스 분석가에게 가서 가장 잘 처리되는 요구 사항을 해석하는 데 분쟁이있을 수 있습니다. 모든 것이 아무것도 없다고 말합니다.

성격 상 갈등이 더 심하면, 문제는 각자가 문제를 얼마나 잘 알고 있으며 이것이 지속되면 어떻게 될 것인가가 문제가됩니다. 이것은 "당신이 이것을 해결할 수 없다면, 적어도 당신 중 하나를 제거하여 해결할 것입니다."라고 생각하는 것만 큼 유휴 위협은 아닙니다. 물론 이것은 수동적 공격적 행동과 다른 유치한 쓰레기에 대한 잠재력을 가지고 있지만, 밝은 자원이 많은 사람들이 적을 해결하기 위해 전통적인 무기를 사용하지 않는 방식으로 진입 할 때 일어나는 일입니다. "Mean Girls" 에는 이런 종류의 행동에 대한 몇 가지 예가 있습니다.


1

베이비 시팅 관리 측면에서 견딜 수 없을 것 같습니다. 나는 그들에게 죽음에 대한 결투로 해결하라고 말했다.


이 답변에 대해 죄송합니다 -1 :-)
Geek

1
마체 또는 전기 톱과 관련된 한 결투는 좋습니다 :)
Muad'Dib

아기가 앉는 것처럼 느낄 수있는 날이 있다는 것을 이해하기 위해 +1
존 홉킨스

1

"팀 계약"이 유용하다는 것을 알았습니다.

팀원이 공동으로 개발해야합니다.

팀이 이미 싸우고 있다면 조금 늦었습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.