의존 관계 매핑 워크숍: 팀 간 업무 인계를 정리하는 방법

각 팀의 업무 목록만 보면 출시 준비가 순조로워 보여도, 실제로는 출시가 불가능한 상황이 생길 수 있습니다. 개발팀은 승인된 문구를 기다리고, 마케팅팀은 작동하는 데모를 기다리며, 고객지원팀은 그 데모에서 어떤 동작을 보여 줄지조차 모릅니다. 모두 자기 업무는 보고 있지만, 팀 사이에서 무엇을 주고받아야 하는지는 보지 못하는 상태입니다.

의존 관계 매핑 워크숍은 이런 업무 연결을 하나의 보드에 드러내는 자리입니다. 한 팀이 다른 팀으로부터 무엇을 언제까지 받아야 하는지, 받지 못하면 어떻게 대응할지를 합의하는 것이 목표입니다.

의존 관계 맵에 무엇을 표시해야 할까요?

의존 관계란 다른 곳에서 제공하는 자료, 결정, 역량 또는 자원이 없으면 계획대로 업무를 진행할 수 없는 관계입니다. 디자이너가 제품 소개 문구에 대한 승인을 받아야 작업할 수 있다면 의존 관계가 있습니다. 반면 디자이너 두 명이 같은 회의에 참석한다는 사실만으로 의존 관계가 있다고 볼 수는 없습니다.

Atlassian의 의존 관계 매핑 가이드는 영향을 받는 시스템, 위험, 책임 주체, 지속적인 조율을 함께 살펴봅니다. 여러 팀이 참여하는 출시에서는 이 넓은 관점을 구체적인 산출물 인계 합의로 바꿔야 합니다. 우리 팀이 받아야 하는 선행 자료와, 우리 팀의 결과물을 기다리는 후속 업무를 모두 포함하세요.

타임라인은 활동을 언제 진행하는지 보여 줍니다. RACI 매트릭스는 업무 참여와 의사결정의 책임을 구분합니다. 의존 관계 맵이 답하는 질문은 다릅니다. 이 업무가 다음 단계로 넘어가려면 무엇이 먼저 준비되어야 할까요? 세 가지 도구가 모두 필요할 수 있지만, 같은 내용을 반복해서 정리할 필요는 없습니다.

하나의 결과를 중심으로 워크숍을 준비하세요

“회사 전체를 매핑한다”보다 “새로운 고객 온보딩 경험을 출시한다”처럼 범위를 정하세요. 보드 상단에는 목표 출시일과 이번 논의에 포함하지 않을 범위를 명시합니다. 날짜가 잠정적이라면 반드시 그렇게 표시하세요. 그렇지 않으면 누구도 확약하지 않은 일정을 기준으로 참가자들이 계획을 맞추게 됩니다.

산출물 전달 조건을 확인할 수 있는 사람을 초대하세요. 제공하는 팀과 받는 팀의 대표, 그리고 범위나 일정 충돌을 조정할 수 있는 담당자가 필요합니다. 검토 대기열, 예정된 휴가, 환경 접근 권한, 외부 업체의 소요 기간처럼 실제 제약을 가져오도록 요청하세요. 프로젝트 조정 담당자만 참석한 회의에서는 확인되지 않은 약속을 보기 좋게 정리하는 데 그칠 수 있습니다.

회의 전에 팀별로 가로 레인을 하나씩 만들고, 최종 결과를 오른쪽에 배치하세요. 미해결 질문을 모아 둘 공간도 따로 마련합니다. 특정 날짜에 대한 논쟁 때문에 전체 작업이 멈추지 않도록 하기 위해서입니다.

최종 결과에서 거꾸로 연결하세요

산출물을 받는 팀부터 시작합니다. “이 일을 마치려면 무엇을 받아야 하나요?”라고 질문하세요. 다음 선행 조건을 해당 팀이 직접 통제할 수 있거나 워크숍 범위 밖에 있는 지점까지 거슬러 올라갑니다. 기억에 의존해 모든 업무를 나열하는 것보다 결과에서 역으로 살펴보는 편이 빠진 선행 조건을 발견하기 쉽습니다.

산출물 카드에는 “온보딩 소개 문구 승인”, “테스트 엔드포인트 공개”, “에스컬레이션 경로 확정”처럼 구체적인 대상과 행동을 적으세요. 제공하는 쪽의 카드를 받는 쪽의 카드와 연결하고, 화살표에는 “승인된 문구”, “테스트 인증 정보”, “승인된 정책”처럼 짧은 설명을 붙입니다. 화살표 방향의 의미를 작은 범례로 정한 뒤 일관되게 사용하세요.

모든 화살표가 같은 의미는 아닙니다. 반드시 완료되어야 하는 선행 조건과 임시 자료로 시작할 수 있는 업무를 구분하세요. 예를 들어 초안 스크린샷이 있으면 가이드 집필은 시작할 수 있지만, 게시 전에는 최종 스크린샷이 필요합니다. 이 차이를 표시하면 의존 관계가 사라진 것처럼 가장하지 않고도 대안을 찾을 수 있습니다.

예시: 셀프서비스 체험판 출시

소프트웨어 팀이 사용자가 직접 가입하는 체험판을 준비한다고 가정해 보겠습니다. 제품 기획팀은 제공 조건을 정하고, 개발팀은 접근 기능을 구현하며, 마케팅팀은 가입 페이지를 게시하고, 고객지원팀은 문의 대응을 준비합니다. 처음 만든 맵에는 서로가 서로를 기다리는 관계가 드러납니다. 마케팅팀은 완성된 체험판의 스크린샷을 원하고, 개발팀은 체험판 이용 규칙을 마무리하기 전에 최종 페이지 문구를 원합니다.

팀은 제공 조건에 대한 결정과 시각 자료 제작을 분리합니다. 제품 기획팀이 먼저 이용 규칙을 승인하고, 마케팅팀은 임시 이미지를 넣어 페이지 초안을 작성할 수 있습니다. 개발팀은 실제 출시 전에 테스트 환경을 제공할 수 있습니다. 이렇게 나누면 더 작고 확인 가능한 전달 단위가 맵에 나타납니다.

각 산출물의 전달 날짜는 실제로 만들고 받는 사람들이 정해야 합니다. 보드에 더 이른 마감일을 적는다고 처리 역량이 늘어나지는 않습니다.

중요한 연결을 구체적인 합의로 바꾸세요

결과에 영향을 줄 수 있는 인계 지점마다 제공 담당자, 받는 담당자, 필요한 날짜, 제공 예정일, 인수 조건을 기록하세요. 필요한 날짜와 제공 예정일은 별도로 관리해야 합니다. 두 날짜의 차이를 보면 하나의 “마감일” 뒤에 가려질 수 있는 충돌이 드러납니다.

받는 담당자가 무엇을 받아야 실제로 사용할 수 있는지 직접 설명하게 하세요. “API 준비 완료”는 어떤 사람에게는 명세 공개를, 다른 사람에게는 안정적인 운영 환경 접근을 의미할 수 있습니다. 대신 “테스트 엔드포인트가 합의한 예시 응답 데이터를 반환하고, 연동 담당 팀이 인증할 수 있다”처럼 합의하면 더 명확합니다.

날짜가 충돌하면 무조건 압박을 높이기 전에 더 작은 자료를 먼저 제공할 수 있는지, 모의 구현을 쓸 수 있는지, 순서나 범위를 조정할 수 있는지 살펴보세요. 중요한 선택과 그에 따른 장단점은 의사결정 기록부에 남깁니다. 의존 관계 보드에는 해당 결정의 링크를 넣으면 됩니다. 보드를 또 하나의 회의록으로 만들 필요는 없습니다.

집중해서 살펴볼 의존 관계를 찾으세요

하나의 제공 팀에 여러 팀이 의존하는 지점, 일정 여유가 없는 긴 연결, 아무도 인수를 맡지 않은 산출물, 날짜가 추정에 불과한 외부 의존 관계를 찾으세요. 순환 구조도 살펴봐야 합니다. 반복적인 협업을 나타낼 때도 있지만, 양쪽 모두 누가 먼저 움직여야 하는지 모르는 상황일 수도 있습니다.

모든 의존 관계에 “중요” 표시를 붙이지 마세요. 위험한 화살표 옆에 “교육을 시작할 수 없음”, “보안 검토를 다시 해야 함”, “이 보고서 없이도 출시 가능”처럼 구체적인 영향을 적으세요. 빨간 카드로 가득한 보드보다 이런 설명이 유용합니다. 또한 맵만으로 프로젝트의 임계 경로가 계산되지는 않습니다. 임계 경로를 구하려면 소요 기간과 일정 계산 방식이 필요합니다.

회의가 끝난 뒤에도 맵을 활용하세요

Boardmix에서 체험판 예시를 제품 기획, 개발, 마케팅, 고객지원의 네 레인으로 배치해 보세요. 도형은 산출물에, 설명을 붙인 연결선은 산출물 인계에 사용합니다. 승인된 체험판 규칙을 테스트 환경 및 가입 페이지 문구와 연결한 다음, 테스트 환경을 스크린샷 및 고객지원 리허설과 연결하세요. 중요한 화살표 옆에는 제공 담당자, 받는 담당자, 인수 조건을 적습니다. Boardmix를 열어 맵을 만들고 팀이 이미 관리하는 실제 업무 항목을 연결하세요.

정기 현황 회의 때만 맵을 확인하지 마세요. 입력 자료가 바뀌거나, 제공 예정일이 이동하거나, 받는 팀이 산출물을 인수하지 못했을 때도 검토해야 합니다. 영향을 받는 팀에 자신의 업무가 어떻게 달라지는지 물어보세요. 그 답에 따라 순서나 범위가 달라진다면 프로젝트 계획도 수정합니다. 화살표가 완료되었다는 표시는 제공자가 무언가를 보냈다는 뜻이 아니라, 받는 팀이 필요한 것을 확보했다는 뜻이어야 합니다.