팀 발달·갈등 전략

갈등을 대화와 결정 기록으로 풀어 봐요.

같은 상황에서도 사실·해석·이해관계·결정 권한을 섞으면 대화가 어긋납니다. 아래는 제품 팀의 품질 갈등을 푸는 창작 사례예요. 단계 모형은 관찰을 돕고, 실제 대응은 증거·긴급성·권한에 맞춰 고릅니다.

팀 발달은 관찰의 렌즈예요.

Tuckman·Jensen의 1977년 후속 검토 공개 초록은 22편 중 1편이 원래 가설의 직접 검증을 목적으로 했다고 설명합니다. 모형의 역사적 기원을 이해하는 근거이며 “모든 팀이 이 순서로 성장한다”는 보장이 아닙니다. 그림은 자체 제작한 관찰 질문이고 단계별 진단 검사나 숙련도 점수가 아닙니다.

심리적 안전과 기준은 함께 다뤄요.

질문·도움 요청·오류 보고·이견 제시를 할 때 대인관계상 불이익을 두려워하지 않는 팀의 믿음을 심리적 안전으로 봅니다. 늘 의견이 같거나 실수를 검토하지 않는다는 뜻은 아닙니다. 리더가 우려를 듣고 확인할 수 있게 반응하는 것과, 업무 기준·책임을 명확히 하는 것을 함께 연습해 봅니다.

가상 사례 · “완료”를 두고 충돌한다면

Scrum으로 일하는 가상 신청 서비스 팀입니다. 현재 긴급 사고는 없고, 약속한 시연 전에 재시도 중복 신청 결함이 발견됐습니다. 기존 완료 기준에는 재시도 때 중복 신청을 막는 테스트 통과가 포함돼 있습니다. 특정 회사·실제 Jira 데이터가 아닙니다.

대응을 고르는 세 갈래 질문

아래는 갈등 전략의 공식 진단표가 아닌 자체 점검 흐름입니다. 상황이 바뀌면 앞선 보호·기준 질문으로 돌아갑니다.

1. 즉시 보호가 필요한가?

   서비스 피해가 진행되거나 위협·괴롭힘이 있다면 보호·중단·정해진 보고 경로를 우선한다. 토론의 결론을 기다리지 않는다.

2. 증거나 기준이 불명확한가?

   재현 자료·문서 버전·기준의 적용 범위를 함께 확인한다. 필요한 정보를 모을 담당과 다시 결정할 시점을 정한다.

3. 기준은 분명하고 대안이 있는가?

   지키려는 이해와 제약을 놓고 대안을 만든다. 권한 범위 안에서 선택하고 담당·확인 증거·재검토 조건을 기록한다.

무엇을 협의하고, 무엇을 지킬까요?

Scrum Team의 자기 관리와 세 가지 책임은 Scrum에 한정한 정의입니다. 일반 프로젝트의 PM·QA·조직별 승인 구조에 그대로 대입하지 않습니다. 이 대화에서 “조정자”는 공식 Scrum 책임을 추가로 만든 명칭이 아니며, 조정을 수행하는 사람을 가리킵니다.

대화가 끝나면 남기는 결정 기록

공유 문제

재시도 중복 신청의 재현·영향·현재 기준을 확인한다. “성격 충돌”로 종결하지 않는다.

검토 대안

완료 기준을 충족하는 별도 범위가 가능한지 검토 / 결함 수정 후 재검증 / 목표·범위 예측 조정. 미검증 결과를 완료로 표시하는 안은 제외한다.

역할과 권한

Developers는 품질 기준에 맞는 구현·작업 계획, Product Owner는 가치·백로그 순서와 범위 협의, Scrum Master는 효과적인 협업·장애물 제거를 돕는다. 별도 조직 출시 승인자는 조직 규칙에 따른다.

후속 확인

재현 테스트 결과·완료 기준 충족 여부·남은 위험과 결정 근거를 기록한다. 다음 점검 전에 자료 담당을 정하고, 회고에서 재발 원인을 살핀다.

“앞으로 잘 지내자”에서 끝내지 않고, 기준의 같은 버전을 봤는지·검증할 증거가 생겼는지·이의를 다시 낼 경로가 있는지 확인합니다. 발언 횟수나 회의의 조용함만으로 심리적 안전을 점수화하지 않습니다.

내 판단을 설명해 보기

비채점 적용 연습 · 기존 수업의 채점 문제와 별개입니다.

갈등 전략의 기본 →동기와 사람을 단정하지 않기 →Scrum의 책임과 산출물 →품질과 수용의 구분 →