팀 간 dependency mapping 실행하기(Run a dependency mapping exercise across teams)

팀 간 dependency는 조용히 실패하다가 갑자기 크게 터진다

가장 흔한 cross-team delivery 실패는 인정되지 않은 dependency입니다. 한 팀은 다른 팀이 무언가를 제공할 것이라 가정했지만, 정작 상대 팀은 그렇게 생각하지 않았던 경우입니다. The Pragmatic Engineer의 조직 확장 관련 글는 이 실패 패턴을 잘 설명합니다. 팀은 각자 독립적으로 움직이다가, 마일스톤 시점에 서로 다른 가정 위에서 만들고 있었다는 사실을 깨닫습니다. Atlassian의 cross-team coordination 가이드는 2주마다 갱신되는 명시적 dependency matrix가 cross-team slip 비율을 30-50% 줄인다고 봅니다.

이 프롬프트의 작동 방식

이 프롬프트는 provider와 consumer 관점을 따로 수집해, cross-reference 단계에서 unacknowledged dependency가 드러나게 만듭니다. 그다음 criticality × slack × reversibility 기준으로 위험도를 점수화하고, 상위 3개 리스크에 대해 handshake agreement를 만듭니다. 특히 "한쪽만 알고 있는 dependency"를 표시하는 것이 핵심 산출물입니다. 이런 dependency가 가장 냄새 나는 surprise를 만듭니다.

언제 사용할까

• 하나의 initiative가 3개 이상 팀에 걸칠 때
• 최근 출시가 팀 간 dependency 미스로 미끄러졌을 때
• 두 팀이 서로 다른 가정 위에서 개발하고 있을 때
• 새 PM이 처음으로 cross-team coordination을 맡았을 때
• 리더십이 팀 간 리스크 메모를 요구할 때

흔한 함정

• Consumer-side 요청만 모으는 것. 그러면 provider 관점의 unacknowledged dependency를 놓칩니다.
• Handshake commit이 없는 것. Risk matrix만 있고 handshake가 없으면 그건 문서화지 coordination이 아닙니다.
• Kickoff 때 한 번만 매핑하는 것. Dependency는 움직입니다. Coupling window 동안에는 2주마다 다시 매핑해야 합니다.

참고 자료

• The Pragmatic Engineer Newsletter — Gergely Orosz
• Agile Metrics — Atlassian
• The Linear Method — Linear
• Google re:Work — Google