팀 내 갈등 관리 – 균형을 잡는 행위인가, 아니면 꼭 필요한 것인가?

Epigraph :
옛날 옛적에 고슴도치와 꼬마곰이 숲에서 만났습니다.
-안녕하세요, 고슴도치님!
- 안녕, 작은 곰아!
그래서 한 마디 한 마디, 농담 하나, 고슴도치가 꼬마곰에게 얼굴을 한 대 맞았습니다...

다음은 작업 갈등의 구체적인 내용과 이를 관리할 수 있는 방법에 대해 우리 팀 리더와 RAS 제품 개발 이사인 Igor Marnat의 논의입니다.

우리가 직장에서 직면하는 대부분의 갈등은 위의 서문에서 설명한 것과 유사한 시나리오에 따라 전개됩니다. 처음에는 서로에 대해 상당히 호의적인 참가자가 여러 명 있으며, 어떤 문제를 해결하려고 노력하지만 결국 문제는 해결되지 않은 채로 남아 있으며 어떤 이유로 토론 참가자 간의 관계가 손상되는 것으로 판명됩니다.

삶은 다양하며 위에서 설명한 시나리오에서 다양한 변화가 발생합니다. 처음에는 참가자 간의 관계가 그다지 좋지 않을 때도 있고, 직접적인 해결이 필요한 문제조차 없을 때도 있고(예를 들어 비문에서처럼), 토론 후에도 관계가 시작 전과 동일하게 유지되는 경우도 있지만, 문제는 궁극적으로 해결되지 않습니다.

업무상 갈등 상황으로 정의될 수 있는 모든 상황에서 공통적으로 나타나는 것은 무엇입니까?



첫째, 두 개 이상의 측면이 있습니다. 이러한 당사자는 조직 내에서 서로 다른 위치를 차지하거나, 평등한 관계(팀의 동료)에 있거나, 계층 구조의 서로 다른 수준(상사-하급)에 있거나, 개인(직원) 또는 그룹(서로 갈등이 있는 경우)일 수 있습니다. 직원과 팀 또는 두 팀) 등. 갈등의 가능성과 해결의 용이성은 참가자 간의 신뢰 수준에 따라 크게 영향을 받습니다. 당사자들이 서로를 더 잘 알수록 신뢰 수준이 높을수록 합의에 도달할 확률도 높아집니다. 예를 들어, 대면 상호작용을 한 번도 해본 적이 없는 분산된 팀의 구성원은 최소한 몇 차례 대면 상호작용을 한 사람들보다 단순한 업무 문제로 갈등을 경험할 가능성이 더 높습니다. 따라서 분산된 팀에서 작업할 때는 모든 팀 구성원이 정기적으로 직접 만나는 것이 매우 중요합니다.

둘째, 직장에서의 갈등 상황에서 당사자는 당사자 중 한 사람, 두 사람 모두 또는 조직 전체에 중요한 문제를 해결해야 하는 상황에 있습니다. 동시에 상황의 특수성으로 인해 당사자들은 일반적으로 문제를 해결하기 위한 충분한 시간과 다양한 방법(공식, 비공식, 회의, 서신, 경영 결정, 팀의 목표 및 계획 존재, 계층 구조의 사실 등). 이는 조직 내 업무(또는 업무 외) 문제를 해결하는 상황과 예를 들어 “어, 꼬마야, 너 어느 지역 출신이야?!”라는 중요한 질문을 해결하는 상황과는 다릅니다. 거리에서 또는 비문의 갈등. 업무 문제를 해결하는 경우 업무 프로세스의 질과 팀 내 문제 해결 문화가 중요합니다.

셋째, (논의의 관점에서) 갈등의 결정 요인은 프로세스 당사자가 모든 당사자에게 적합한 문제에 대해 독립적으로 해결책을 찾을 수 없다는 사실입니다. 상황은 외부 중재자인 제XNUMX자의 개입을 필요로 합니다. 이 점은 논란의 여지가 있을 수 있지만, 본질적으로 외부 중재자의 개입 없이 갈등 상황이 성공적으로 해결되고 문제가 성공적으로 해결되었으며 당사자 간의 관계가 악화되지 않았다면 이것이 우리가 노력해야 할 상황입니다. . 우리는 그러한 갈등에 대해 전혀 알지 못할 가능성이 높으며, 갈등이 해결된 후에 우연히 알게 될 것입니다. 팀이 스스로 해결할 수 있는 문제가 많을수록 팀의 효율성은 높아집니다.

언급할 가치가 있는 갈등의 또 다른 특징은 결정을 내리는 동안의 감정적 강도의 정도입니다. 갈등이 반드시 높은 감정 수준과 연관되는 것은 아닙니다. 참가자들은 상황이 본질적으로 갈등이 되기 위해 소리를 지르거나 팔을 흔들 필요가 없습니다. 문제가 해결되지 않고, 어느 정도 감정적 긴장이 존재하며(아마도 겉으로 명확하게 표현되지 않을 수도 있음), 이는 우리가 갈등 상황에 직면해 있음을 의미합니다.

갈등 상황에 전혀 개입해야합니까, 아니면 해결 방법이 자연스럽게 진행되고 문제가 스스로 해결될 때까지 기다리는 것이 더 낫습니까? 필요하다. 갈등을 완전히 해결하는 것이 항상 당신의 힘이나 능력에 있는 것은 아니지만, 어떤 상황, 어떤 규모의 갈등에서도 당신은 성인의 입장을 취할 수 있으므로 주변에 더 많은 사람들을 데려올 수 있습니다. 갈등을 해결하고 해결에 기여합니다.

갈등 상황의 몇 가지 예를 살펴보기 전에 모든 갈등에 공통적으로 적용되는 몇 가지 중요한 사항을 살펴보겠습니다.

갈등을 해결할 때 싸움의 내부가 아니라 싸움 위에 있는 것이 중요합니다(이를 "메타 위치 취하기"라고도 함). 즉, 해결 과정에서 당사자 중 한 사람의 일부가 되지 않는 것이 중요합니다. 그렇지 않은 경우 외부 중재자가 결정을 지원하도록 하면 한쪽 당사자의 입장만 강화되어 다른 쪽 당사자에게 손해를 끼치게 됩니다. 결정을 내릴 때 모든 당사자가 "구매했다"고 말하는 것처럼 도덕적으로 받아들이는 것이 중요합니다. 따라서 당사자들은 결정에 만족하지 않더라도 적어도 이를 이행하기로 진심으로 동의했습니다. 그들이 말했듯이 동의하지 않고 저지를 수 있습니다. 그렇지 않으면 갈등은 단순히 그 모습을 바꾸고 그을린 불은 이탄 습지 아래에 남아 있으며 어느 시점에서 필연적으로 다시 타오르게 될 것입니다.

첫 번째와 부분적으로 관련된 두 번째 요점은 이미 갈등 해결에 참여하기로 결정한 경우 의사 소통 및 맥락 연구 관점에서 가능한 한 심각하게 받아들이라는 것입니다. 각 당사자와 개인적으로 대화하십시오. 우선, 각각 별도로. 메일에 안주하지 마세요. 분산된 팀의 경우 최소한 영상 링크를 통해 대화를 나누세요. 소문과 목격자 보고에 만족하지 마십시오. 이야기를 이해하고, 양측이 원하는 것이 무엇인지, 왜 원하는지, 무엇을 기대하는지, 이전에 이 문제를 해결하려고 시도했는지, 해결되지 않으면 어떤 일이 일어날지, 어떤 해결책을 보고 있는지, 양측의 입장을 어떻게 상상하는지 이해합니다. 상대방은 어떻게 생각하는가, 옳고 그름 등. 모든 사람이 옳다고 가정하고 열린 마음으로 가능한 모든 맥락을 머리에 담아보세요. 당신은 갈등 내부에 있는 것이 아니라, 갈등 외부에 있는 메타포지션(metaposition)에 있습니다. 컨텍스트가 게시 스레드에서만 사용 가능한 경우 최소한 전체 내용과 관련 스레드 및 문서를 읽어보세요. 그것을 읽은 후에도 여전히 목소리로 말하십시오. 메일에는 없는 중요한 내용을 듣게 될 가능성이 거의 확실합니다.

세 번째 중요한 점은 의사소통에 대한 일반적인 접근 방식입니다. 이것들은 평범하고 우주적인 것은 아니지만 매우 중요합니다. 우리는 시간을 절약하려고 노력하지 않고 모든 참가자와 이야기하며 그 사람을 비판하지는 않지만 그의 행동의 결과를 고려합니다 ( "당신은 무례합니다"가 아니라 "아마도 그 사람들이 기분을 상하게 할 수도 있습니다") this thing”), 우리는 체면을 세울 기회를 주고, 줄 앞에서가 아니라 직접 토론을 진행합니다.

충돌은 일반적으로 두 가지 이유 중 하나로 인해 발생합니다. 첫 번째는 갈등 당시의 개인이 성인의 입장에 있는지 아니면 어린이의 입장에 있는지와 관련이 있습니다(자세한 내용은 아래 참조). 이는 그의 감정적 성숙, 감정 관리 능력 때문입니다(그런데 항상 나이와 관련이 있는 것은 아닙니다). 두 번째 일반적인 이유는 업무 프로세스의 불완전성으로, 이는 참여자 간에 책임이 분산되고, 당사자의 기대가 서로 투명하지 않으며, 프로세스 내 역할이 모호해지는 회색 영역의 상황을 만듭니다.

따라서 갈등(및 기타 문제)을 해결할 때 관리자는 세 가지 관점을 염두에 두어야 합니다. 단기 - 지금 여기에서 문제/갈등을 해결하기 위해, 중기 - 또 다른 갈등이 발생할 가능성을 최소화하기 위해 같은 이유로 장기적으로 팀 구성원의 성인 문화를 육성합니다.

우리 각자에게는 서너 살 정도의 내면아이가 있습니다. 그는 직장에서 대부분의 시간을 자지만 가끔 일어나서 통제권을 갖습니다. 아이에게는 자신만의 우선순위가 있습니다. 이것이 그의 샌드박스이고 그의 어머니가 그를 더 사랑하며 그의 기계가 최고라고 주장하는 것이 그에게 중요합니다 (디자인이 최고이고 프로그래밍이 최고입니다 ...). 갈등 상황에서 어린이는 장난감을 누르고, 발을 구르며 주걱을 깰 수 있지만 성인 문제(솔루션 아키텍처, 자동화된 테스트에 대한 접근 방식, 출시 날짜 등)를 해결할 수 없으며 이점 측면에서 생각하지 않습니다. 팀을 위해서. 갈등을 겪고 있는 어린이는 어른에게 전화해 달라고 요청함으로써 격려하고 위로하고 잠자리에 들 수 있습니다. 갈등 상황에서 토론을 시작하기 전에, 아이가 아닌 어른과 대화하고 있는지, 자신이 어른의 입장에 있는지 확인하세요. 지금 당신의 정직한 목표가 심각한 문제를 해결하는 것이라면 당신은 어른의 입장입니다. 당신의 목표가 발을 구르고 견갑골을 부러뜨리는 것이라면 이것은 유치한 자세입니다. 내면의 아이를 침대로 보내고 어른에게 전화하거나 토론 일정을 다시 잡으십시오. 사람은 감정적인 결정을 내리고 그에 대한 합리적인 근거를 찾습니다. 어린이의 우선순위에 따라 어린이가 내리는 결정은 최적이 아닐 것입니다.

갈등 당시의 행동 외에도 어린이나 성인의 입장은 개인이 스스로 맡을 책임의 수준에 따라 결정됩니다. 극단적으로 표현하면 내가 한 번 이상 만난 프로그래머의 유치한 입장은 다음과 같습니다. 코드를 작성하고 검토를 위해 보냈습니다. 작업이 완료되었습니다. 리뷰어는 검토하고 승인해야 하며, QA는 이를 확인해야 하며, 문제가 있으면 알려주게 됩니다. 이상하게도 상당히 성숙하고 경험이 풍부한 사람들도 때때로 이런 식으로 행동합니다. 척도의 다른 끝은 사람이 자신의 코드가 작동하고, 테스트에 포함되고, 개인적으로 확인되고, 리뷰를 성공적으로 통과했는지 확인하는 책임이 있다고 생각하는 것입니다(필요한 경우 리뷰어에게 핑을 보내고 문제를 논의하는 데 문제가 없습니다). 음성 등)이 억제되었으며 필요한 경우 QA에서 지원을 제공하고 테스트 시나리오를 설명합니다. 일반적인 경우 프로그래머는 규모의 성인 수준에 더 가깝게 시작하거나 경험이 쌓이면 해당 위치로 이동합니다(팀 내에서 올바른 문화가 조성된 경우). 극단적인 경우 그는 계속해서 일하며 대개 유치한 입장을 취하고 그와 팀은 주기적으로 문제와 갈등을 겪습니다.

팀 내에서 올바르고 성숙한 문화를 조성하는 것은 모든 관리자에게 중요한 임무입니다. 오랜 시간과 매일의 노력이 필요하지만 결과는 그만한 가치가 있습니다. 팀 문화에 영향을 미치는 방법에는 두 가지가 있습니다. 모범을 보이는 것(반드시 따라야 합니다. 팀은 항상 리더를 바라봅니다)과 올바른 행동에 대해 논의하고 보상하는 것입니다. 여기에는 난해하거나 매우 공식적인 것이 없습니다. 문제를 논의할 때 여기서 뭔가 할 수 있었다는 점을 주목하고, 그것이 올바르게 결정되었을 때 주목했다는 점을 강조하고, 칭찬하고, 릴리스 검토 중에 메모하는 등의 작업을 수행합니다.

단순한 것부터 복잡한 것까지 몇 가지 일반적인 충돌 상황을 고려해 보겠습니다.

업무 문제와 관련되지 않은 갈등

업무 문제와 관련되지 않은 직장 내 갈등이 자주 발생합니다. 이러한 현상의 발생 및 해결 용이성은 일반적으로 참가자의 감성 지능 수준, 성숙도와 직접적인 관련이 있으며 작업 프로세스의 완벽성 또는 불완전성과 관련이 없습니다.

전형적인 예: 어떤 사람은 세탁기나 샤워를 자주 사용하지 않고, 어떤 사람은 싫어하고, 어떤 사람은 답답하고, 어떤 사람은 창문을 열면 바람이 불고, 어떤 사람은 너무 시끄럽고, 어떤 사람은 일하는데 침묵이 필요하고, 곧. 이런 종류의 갈등 해결을 지체하지 않고, 그 과정을 따르도록 내버려 두지 않는 것이 좋습니다. 그들은 스스로 해결하지 못할 것이며 매일 직장에서 당신의 주의를 산만하게 하고 팀의 분위기를 해칠 것입니다. 다행스럽게도 이 문제를 해결하는 것은 일반적으로 큰 문제가 아닙니다. 위생을 소홀히 하는 동료와 침착하게(물론 일대일로) 이야기하고, 조용함/시원함을 선호하는 사람들을 위해 편안한 좌석을 제공하고, 흡음 헤드폰을 구입하거나 칸막이를 설치하십시오. , 등.

제가 일하면서 여러 번 접했던 또 다른 예는 팀원들의 심리적 불일치입니다. 어떤 이유로 사람들은 함께 일할 수 없으며 모든 상호 작용은 스캔들로 끝납니다. 때때로 이는 사람들이 긴급한 문제(대개 정치적인 문제)에 대해 극단적인 견해를 갖고 있고 이를 업무 외부에 두는 방법을 모르기 때문에 발생합니다. 서로를 용인하거나 행동을 바꾸도록 설득하는 것은 다소 쓸데없는 작업입니다. 내가 만난 유일한 예외는 열린 인식을 가진 젊은 동료들인데, 그들의 행동은 여전히 ​​주기적인 대화를 통해 점차적으로 바뀔 수 있습니다. 일반적으로 문제는 서로 다른 팀으로 분리하거나 최소한 직장에서 겹치는 기회를 거의 제공하지 않으면 성공적으로 해결됩니다.

위의 모든 상황에서 모든 참가자와 개인적으로 대화하고, 상황에 대해 논의하고, 이 경우 문제가 있는지 묻고, 그들의 의견으로는 해결책이 무엇인지 묻고, 이를 만드는 데 참여하도록 보장하는 것이 좋습니다. 결정.

업무 프로세스 최적화 관점(제가 언급한 중기적 관점)에서는 여기서 할 수 있는 일이 별로 없으며, 최적화의 유일한 포인트는 인력을 배치하는 것이 아니라 팀을 구성할 때 호환성 요소를 고려하는 것입니다. 누가 갈등할지 미리 함께.

팀 문화 관점에서 볼 때 이러한 상황은 사람들이 팀과 동료를 존중하고 독립적으로 문제를 해결하는 방법을 알고 있는 성숙한 문화를 갖춘 팀에서는 훨씬 덜 자주 발생합니다. 또한 이러한 갈등은 신뢰도가 높고 사람들이 오랫동안 함께 일했거나 업무 외적으로 자주 소통하는 팀에서 훨씬 더 쉽게(종종 자동으로) 해결됩니다.

업무 문제와 관련된 갈등:

이러한 갈등은 일반적으로 감정적 (참가자 중 한 명이 성인의 위치에 있지 않다는 사실)과 작업 프로세스 자체의 불완전 성이라는 두 가지 이유에 의해 동시에 발생합니다. 아마도 제가 경험한 가장 일반적인 유형의 충돌은 코드 검토나 개발자 간의 아키텍처 논의 중 발생하는 충돌일 것입니다.

여기서는 두 가지 일반적인 사례를 강조하겠습니다.

1) 첫 번째 경우, 개발자는 동료로부터 코드 리뷰를 받을 수 없습니다. 패치가 검토를 위해 전송되었지만 아무 일도 일어나지 않습니다. 언뜻 보면 양측 사이에 뚜렷한 갈등이 없지만, 생각해보면 꽤 갈등이 있는 상황이다. 업무 문제가 해결되지 않았고, 검토를 기다리는 당사자 중 한 명이 명백한 불편함을 경험했습니다. 이 사례의 극단적인 하위 유형은 커뮤니티 또는 다른 팀에서의 개발이며, 검토자는 로드 또는 기타 상황으로 인해 이 특정 코드에 관심이 없을 수 있고 검토 요청에 전혀 주의를 기울이지 않을 수 있으며 외부 중재자는 (양측 공통 관리자) )가 전혀 존재하지 않을 수도 있습니다.

그러한 상황에 도움이 되는 해결 접근법은 바로 장기적인 관점, 즉 성인의 문화와 관련이 있다. 첫째, 스마트한 활동이 효과가 있습니다. 리뷰에 걸려 있는 코드가 리뷰어 자체의 관심을 끌 것이라고 기대해서는 안 됩니다. 우리는 리뷰어가 그를 알아차릴 수 있도록 도와야 합니다. 핑가니 몇명이 싱크케이프에 질문하고 토론에 참여합니다. 분명히, 중요성은 도움보다 해를 끼칠 가능성이 높으므로 상식을 사용해야 합니다. 둘째, 사전 준비가 잘 작동합니다. 팀이 무슨 일이 일어나고 있는지, 왜 이 코드가 필요한지 이해하고 설계에 대해 모든 사람과 사전에 논의하고 합의했다면 사람들은 그러한 코드에 주의를 기울이고 작업에 받아들일 가능성이 더 높습니다. 셋째, 권위가 작동합니다. 리뷰를 받고 싶다면 직접 리뷰를 많이 해보세요. 실제 점검, 실제 테스트 및 유용한 의견을 통해 고품질 리뷰를 수행합니다. 당신의 닉네임이 팀 내에서 잘 알려지면 당신의 코드가 주목받을 확률이 더 높아집니다.

워크플로 관점에서 볼 때 여기서 가능한 개선 사항은 개발자가 자신과 팀의 목표를 달성하도록 돕기 위한 올바른 우선 순위 지정입니다(다른 사람 검토, 커뮤니티에 편지 쓰기, 아키텍처 설명과 함께 코드 첨부, 문서, 테스트, 토론 참여). 커뮤니티 등), 패치가 너무 오랫동안 대기열에 머무르는 것을 방지합니다.

2) 코드 또는 디자인 검토 중 충돌이 발생하는 두 번째 일반적인 사례는 기술 문제, 코딩 스타일 및 도구 선택에 대한 서로 다른 견해입니다. 이 경우 가장 중요한 것은 같은 팀에 속한 참가자 간의 신뢰 수준과 함께 일한 경험입니다. 참가자 중 한 명이 유치한 입장을 취하고 대담자가 그에게 전달하려는 내용을 듣지 않으면 막 다른 골목이 발생합니다. 종종 상대방이 제안한 접근 방식과 처음에 제안한 접근 방식이 모두 성공적으로 작동할 수 있으며 원칙적으로 어느 것을 선택해야 하는지는 중요하지 않습니다.

어느 날, 우리 팀의 프로그래머(파샤라고 부르자)가 이웃 부서의 동료들이 개발하고 지원하는 패키지 배포 시스템에 대한 변경 사항이 포함된 패치를 준비했습니다. 그들 중 한 명(Igor)은 패키지를 배포할 때 Linux 서비스를 정확히 어떻게 구성해야 하는지에 대해 자신만의 강한 의견을 갖고 있었습니다. 이 의견은 패치에서 제안한 접근 방식과 달라서 동의할 수 없었습니다. 늘 그렇듯이 마감일이 다가오고 어떤 결정을 내려야했고 그들 중 한 명이 성인 자리를 맡아야했습니다. 파샤는 두 가지 접근 방식 모두 생명권이 있다는 것을 인식했지만 자신의 선택이 통과되기를 원했습니다. 하나도 두 번째 옵션도 명백한 기술적 이점이 없었습니다.

우리의 토론은 다음과 같았습니다(물론 매우 도식적으로 대화는 XNUMX분 동안 지속되었습니다).

- 파샤, 며칠 내로 기능이 중단될 예정입니다. 모든 것을 하나로 모아 가능한 한 빨리 테스트를 시작하는 것이 중요합니다. Igor를 어떻게 통과할 수 있나요?
— 그는 서비스를 다르게 설정하고 싶어서 거기에 댓글을 달았습니다...
- 그리고 거기에 무엇이 있습니까, 큰 변화, 많은 소란이 있습니까?
-아니요, 몇 시간 동안 일이 있지만 결국에는 차이가 없습니다. 어느 쪽이든 작동합니다. 이것이 왜 필요한가요? 나는 효과가 있는 것을 만들었습니다. 그것을 받아들이도록 합시다.
- 들어보세요, 이 모든 것에 대해 얼마나 오랫동안 논의하셨나요?
- 네, 지금 일주일 반 동안 시간을 ​​내어 왔습니다.
- 음... 벌써 일주일 반이 걸린 문제를 두 시간 안에 해결하고 안 할 수 있을까요?
- 네, 그렇죠. 하지만 이고르가 제가 굴복했다고 생각하지 않았으면 좋겠어요...
- 들어보세요, 내부 결정과 함께 공개를 발표하는 것, 아니면 이고르를 죽이는 것보다 당신에게 더 중요한 것은 무엇입니까? 우리는 그것을 차단할 수 있지만, 릴리스를 통해 날아갈 수 있는 좋은 기회가 있습니다.
- 글쎄요... 물론 이고르의 코를 닦아주면 좋겠지만 알겠습니다. 방출이 더 중요하다는 점에 동의합니다.
- 이고르가 생각하는 것이 당신에게 그렇게 중요합니까? 솔직히 말해서 그는 전혀 신경 쓰지 않고 자신이 담당하는 일의 여러 위치에서 통일된 접근 방식을 원합니다.
- 글쎄요. 그가 댓글에서 요청한 대로 하고 테스트를 시작하겠습니다.
- 고마워요, 파샤! Igorek이 당신보다 나이가 많지만 두 사람 중 당신이 더 성숙할 것이라고 확신했습니다 :)

문제가 해결되었고 릴리스가 정시에 출시되었으며 Pasha는 그다지 불만을 느끼지 않았습니다. 그는 스스로 솔루션을 제안하고 구현했습니다. Igor는 대체로 만족했습니다. 왜냐하면... 그의 의견이 고려되었고 그들은 그가 제안한 대로 행했습니다.

본질적으로 동일한 충돌의 또 다른 유형은 프로젝트, 특히 분산된 팀에서 기술 솔루션/라이브러리/접근 방식 간의 선택입니다. C/C++를 사용하는 것으로 포지셔닝된 프로젝트 중 하나에서 프로젝트의 기술 관리가 STL(표준 템플릿 라이브러리) 사용에 절대적으로 반대되는 것으로 나타났습니다. 이는 개발을 단순화하는 표준 언어 라이브러리이며 우리 팀은 이에 매우 익숙합니다. 이 프로젝트는 C++보다 C에 훨씬 더 가까운 것으로 밝혀졌는데, 이는 팀에 그다지 영감을 주지 못했습니다. 경영진은 최선을 다했고 정말 멋진 플러스 플레이어를 모집했습니다. 동시에 팀의 미국인 부분인 엔지니어와 관리자는 오랫동안 회사에서 일해 왔으며 기존 상황에 익숙했으며 모든 것에 만족했습니다. 팀의 러시아 부분은 아주 최근에 (나를 포함하여) 몇 주 안에 모였습니다. 팀의 러시아 부분은 개발에 대한 일반적인 접근 방식을 포기하고 싶지 않았습니다.

두 대륙 사이에 끝없는 서면 토론이 시작되었고, 서너 개의 화면에 편지가 그룹 메일과 개인 메일을 통해 프로그래머에서 프로그래머 및 관리자에게로 앞뒤로 날아갔습니다. 일반적으로 그렇듯이, 이 길이의 편지는 저자와 그들의 열렬한 지지자들 외에는 누구도 읽지 않았습니다. 긴장감으로 삐걱거리는 채팅은 STL의 기술적 이점, 얼마나 잘 테스트되었는지, 얼마나 안전한지, 그리고 일반적으로 STL이 있는 삶이 얼마나 멋진지, STL이 없으면 얼마나 끔찍한지에 대해 여러 방향으로 멀티스크린 생각을 전달했습니다. .

이 모든 것은 우리가 문제의 기술적인 측면을 논의하고 있다는 것을 마침내 깨달을 때까지 꽤 오랜 시간 동안 지속되었지만 문제는 실제로 기술적인 것이 아니었습니다. 문제는 STL의 장점이나 단점, STL 없이 작업하는 것이 어렵다는 것이 아닙니다. 문제는 오히려 조직적이다. 우리는 우리가 일하는 회사가 어떻게 일하는지 이해해야 했습니다. 우리 중 누구도 이전에 그런 회사에서 일한 경험이 없었습니다. 문제는 코드가 개발되어 프로덕션에 출시된 후 다른 팀, 다른 국가의 완전히 다른 사람들이 지원을 처리했다는 것입니다. 총 수만 명의 엔지니어로 구성된 이 거대한 엔지니어링 팀은 완전히 기본적인 최소한의 기술적 수단, 즉 최소한의 최소 금액만을 감당할 수 있었습니다. 회사에서 물리적으로 확립한 엔지니어링 표준을 넘어서는 것은 향후 지원될 수 없습니다. 팀의 레벨은 가장 약한 구성원의 레벨에 따라 결정됩니다. 우리가 이해한 후에 진정한 동기 부여 미국 팀의 조치로 인해 이 문제는 의제에서 제거되었고 우리는 함께 회사가 채택한 표준을 사용하여 제품을 성공적으로 개발하고 출시했습니다. 이 경우 편지와 채팅은 잘 작동하지 않았으며 공통 분모를 찾기 위해 여러 번의 여행과 많은 개인적인 의사 소통이 필요했습니다.

워크플로의 관점에서 볼 때, 이 특별한 경우에는 사용된 도구, 도구에 대한 요구 사항, 새 도구 추가에 대한 제한 사항, 그러한 제한 사항에 대한 타당성에 대한 설명이 있으면 도움이 될 것입니다. 이러한 문서는 "소프트웨어 개발을 위한 관리자 핸드북"의 재사용 전략 및 개발 환경 단락에 설명된 내용과 대략적으로 일치합니다. NASA. 오래되었음에도 불구하고 이 책은 이러한 종류의 소프트웨어 개발의 모든 주요 활동과 계획 단계를 완벽하게 설명합니다. 이와 같은 문서가 있으면 제품에 어떤 구성 요소와 접근 방식을 사용할 수 있는지, 그리고 그 이유를 논의하기가 매우 쉽습니다.

문화적 관점에서 볼 때, 당연히 당사자들은 동료의 행동에 대한 실제 동기를 듣고 이해하려고 노력하며 개인 자아가 아닌 프로젝트와 팀의 우선 순위에 따라 행동합니다. , 갈등은 더 쉽고 빠르게 해결될 것입니다.

기술적인 해결책을 선택하는 또 다른 갈등에서는 당사자 중 한 사람의 동기를 이해하는 데 눈에 띄는 시간이 걸렸지만(매우 특이한 경우였습니다), 동기가 분명해진 후에는 해결책도 분명해졌습니다.

상황은 이렇습니다. 20명 정도의 팀에 새로운 개발자가 등장합니다. 그를 Stas라고 부르겠습니다. 당시 우리 팀의 의사소통을 위한 표준 도구는 스카이프였습니다. 나중에 밝혀졌듯이 Stas는 개방형 표준과 오픈 소스 소프트웨어의 열렬한 팬이었으며 소스가 공개적으로 제공되고 공개적으로 설명된 프로토콜을 사용하는 도구와 운영 체제만 사용했습니다. Skype는 이러한 도구 중 하나가 아닙니다. 우리는 이 접근 방식의 장점과 단점, 다양한 운영 체제에서 Skype 유사체를 실행하려는 시도, 팀이 다른 표준으로 전환하도록 설득하려는 Stas의 시도, 우편으로 개인적으로 편지를 쓰고 개인적으로 전화하는 방법에 대해 논의하는 데 많은 시간을 보냈습니다. 전화를 걸어 Skype 등을 위해 특별히 두 번째 컴퓨터를 구입하십시오. 마지막으로 저는 이 문제가 본질적으로 기술적이거나 조직적인 문제가 아니라 오히려 이데올로기적이며 심지어 (Stas의 경우) 종교적이라고 말할 수도 있다는 것을 깨달았습니다. 결국 Stas와 Skype를 연결하더라도(몇 달이 걸렸음) 후속 장비에서 문제가 다시 발생했습니다. 나는 Stas의 세계관을 바꿀 수 있는 실질적인 수단이 없었고, 이 환경에서 완벽하게 작동하는 팀의 세계관을 바꾸려고 노력할 이유도 없었습니다. 그 사람과 회사는 그들의 세계관에서 단순히 직교했습니다. 이러한 상황에서 좋은 해결책은 조직적입니다. 우리는 Stas를 더 유기적인 다른 팀으로 옮겼습니다.

내 생각에 이러한 갈등의 원인은 특정인(타협을 허용하지 않는 강한 의견을 가진 사람)의 개인 문화와 회사 문화의 불일치 때문이라고 생각합니다. 이 경우에는 당연히 관리자의 실수입니다. 처음에 그를 이런 종류의 프로젝트에 데려가는 것은 잘못된 일이었습니다. Stas는 결국 오픈 소스 소프트웨어 개발 프로젝트로 전환하여 뛰어난 성과를 거두었습니다.

개발자의 유치한 태도와 작업 프로세스의 단점으로 인해 발생하는 갈등의 좋은 예는 완료에 대한 정의가 없는 상황에서 개발자와 QA 팀이 작업 준비 상태에 대해 서로 다른 기대를 갖는 상황입니다. 기능이 QA로 이전되었습니다. 개발자는 코드를 작성하고 기능을 QA에 맡기는 것만으로도 충분하다고 믿었습니다. 그들은 그것을 정리할 것입니다. 그건 그렇고, 상당히 성숙하고 경험이 풍부한 프로그래머였지만 그것이 품질에 대한 그의 내부 임계값이었습니다. QA는 이에 동의하지 않고 자신이 직접 확인한 내용을 보여주고 설명할 것을 요구했으며 테스트 스크립트를 요구했습니다. 그들은 과거에 이 개발자의 기능에 문제가 있었고 다시는 시간을 낭비하고 싶지 않았습니다. 그건 그렇고, 그들이 옳았습니다. 기능이 실제로 작동하지 않았고 QA에 보내기 전에 코드를 확인하지 않았습니다.

상황을 해결하기 위해 나는 그에게 모든 것이 실제로 작동했음을 보여달라고 요청했고(작동하지 않았으므로 고쳐야 했습니다), 우리는 팀과 이야기하고 QA 정의가 완료되었다고 말했습니다(그들은 성공하지 못했습니다). 글을 쓰는 동안 우리는 프로세스를 너무 관료적으로 만들고 싶지 않았기 때문에 ) 글쎄요, 우리는 곧 이 전문가와 (일반적인 안도감을 위해) 헤어졌습니다.

워크플로의 관점에서 볼 때 이 경우 가능한 개선 사항은 완료 정의, 각 단위 기능 지원 요구 사항 및 통합 테스트, 개발자가 수행하는 테스트 설명 등입니다. 프로젝트 중 하나에서는 CI 중에 테스트를 통해 코드 커버리지 수준을 측정했는데, 패치 추가 후 커버리지 수준이 떨어지면 테스트가 실패로 표시되었습니다. 새로운 코드는 새로운 테스트가 있는 경우에만 추가될 수 있습니다.

작업 프로세스 구성과 밀접하게 관련된 갈등의 또 다른 전형적인 예입니다. 우리에게는 제품, 제품 개발팀, 지원팀, 고객이 있습니다. 고객이 제품에 문제가 있어 지원팀에 문의합니다. 지원팀에서는 문제를 분석하고 제품에 문제가 있음을 파악한 후 해당 문제를 제품 팀에 전달합니다. 제품 팀은 바쁜 시간에 있고 릴리스가 다가오고 있으므로 문제가 있는 고객의 티켓이 할당된 개발자의 다른 티켓 중에서 분실되어 관심 없이 몇 주 동안 중단됩니다. 지원팀은 개발자가 고객의 문제를 해결하기 위해 노력하고 있다고 생각합니다. 고객은 문제가 해결되기를 기다리고 있습니다. 실제로는 아직 아무 일도 일어나지 않습니다. 몇 주 후에 고객은 마침내 진행 상황에 관심을 갖기로 결정하고 상황이 어떻게 진행되고 있는지 지원을 요청합니다. 지원은 개발을 요청합니다. 개발자는 몸을 떨며 티켓 목록을 살펴보고 그곳에서 고객이 보낸 티켓을 찾습니다. 고객의 티켓을 읽으면서 그는 문제를 해결하기 위한 정보가 충분하지 않으며 더 많은 로그와 덤프가 필요하다는 것을 이해합니다. 지원팀은 고객에게 추가 정보를 요청합니다. 그리고 고객은 지금까지 자신의 문제를 해결하기 위해 노력한 사람이 아무도 없다는 것을 깨닫습니다. 그리고 천둥이 칠 것이다...

이 상황에서 충돌 자체에 대한 해결책은 매우 명확하고 선형적입니다(제품 수정, 문서 및 테스트 업데이트, 고객 달래기, 핫픽스 릴리스 등). 작업 프로세스를 분석하고 두 팀 간의 상호 작용을 구성하는 책임이 누구인지, 애초에 이러한 상황이 가능해진 이유를 이해하는 것이 중요합니다. 프로세스에서 수정해야 할 사항은 분명합니다. 누군가는 고객의 알림 없이 전체 상황을 적극적으로 모니터링해야 합니다. 고객의 티켓은 개발자의 다른 티켓 중에서 눈에 띄어야 합니다. 지원팀은 개발팀이 현재 티켓 작업을 진행 중인지 확인해야 하며, 그렇지 않은 경우 언제 작업을 시작할 수 있는지, 언제 결과를 기대할 수 있는지 확인해야 합니다. 지원 및 개발은 정기적으로 티켓 상태를 전달하고 논의해야 하며, 디버깅에 필요한 정보 수집은 최대한 자동화되어야 합니다.

전쟁에서 적이 두 유닛 사이의 교차점을 공격하려고 시도하는 것처럼 작업에서 가장 섬세하고 취약한 지점은 일반적으로 팀 간의 상호 작용입니다. 지원 및 개발 관리자가 충분히 나이가 들면 프로세스를 스스로 해결할 수 있지만, 그렇지 않은 경우 상황을 해결할 수 있는 관리자가 개입할 때까지 프로세스는 계속해서 갈등과 문제를 일으킬 것입니다.

여러 회사에서 반복적으로 본 또 다른 전형적인 예는 한 팀이 제품을 작성하고, 이에 대한 자동 통합 테스트를 두 번째 팀에서 작성하고, 그것이 모두 운영되는 인프라가 세 번째 팀을 동반하는 상황입니다. 팀. 테스트를 실행할 때 문제는 항상 발생하며 문제의 원인은 제품과 테스트 및 인프라 모두일 수 있습니다. 문제의 초기 분석, 버그 신고, 제품 구문 분석 로그, 테스트 및 인프라 등을 누가 수행해야 하는지에 대해 동의하는 것은 일반적으로 문제가 됩니다. 여기서 갈등은 매우 빈번하며 동시에 균일합니다. 감정 강도가 높은 경우 참가자들은 종종 유치한 입장에 빠지고 "내가 왜 이걸 만지작거리야 하는가", "더 자주 무너지는"등의 토론이 시리즈로 시작됩니다.

워크플로 관점에서 문제를 해결하기 위한 구체적인 단계는 팀 구성, 테스트 유형, 제품 등에 따라 달라집니다. 프로젝트 중 하나에서는 팀이 매주 한 번에 하나씩 테스트를 모니터링하는 정기적인 임무를 도입했습니다. 다른 하나는 초기 분석은 항상 테스트 개발자가 했는데, 분석이 매우 기초적이고 제품도 꽤 안정적이어서 잘 작동했습니다. 핵심은 프로세스가 투명하고, 모든 당사자의 기대치가 명확하며, 상황이 모든 사람에게 공평하게 느껴지도록 하는 것입니다.

조직 내에서도 갈등이 문제인가요, 팀 내에서 갈등이 자주(또는 주기적으로) 발생하는 것은 나쁜 징조인가요? 일반적으로 아니요. 성장, 발전, 일종의 역학이 있으면 이전에 해결되지 않은 문제가 발생하고 문제를 해결할 때 갈등이 발생할 수 있기 때문입니다. 이는 일부 영역에 주의가 필요하고 개선이 필요한 영역이 있음을 나타내는 지표입니다. 갈등이 자주 발생하거나 해결하기 어렵거나 시간이 오래 걸리면 좋지 않습니다. 이는 작업 프로세스가 충분히 간소화되지 않았고 팀의 성숙도가 부족하다는 신호일 가능성이 높습니다.

출처 : habr.com