부서 간 프로젝트 협업 방법: 정보 장벽과 책임 떠넘기기 줄이기
부서 간 협업이 실제로 이루어지는 지점은 한 팀의 결과물이 다른 팀의 입력 자료가 되는 순간입니다. 회의를 늘리기 전에 무엇을 넘기고 누가 준비하며 누가 확인하는지, 어떤 상태여야 사용할 수 있는지 합의하세요. 보내는 부서의 작업 완료가 받는 부서의 착수 가능 상태를 뜻하지는 않습니다. 프로젝트에서 중요한 인계 한 가지부터 살펴보면 됩니다. 모든 부서의 업무 방식을 바꾸기보다 같은 결과물과 조건을 이해하고 어느 쪽도 맡지 않은 일을 찾는 것이 우선입니다.
받는 사람의 다음 작업에서 거꾸로 보기
종이 방문 안내서를 만든다고 가정해 봅시다. 편집 담당자가 글을 준비하고 디자이너가 지면을 만들며 운영 담당자가 인쇄를 준비합니다. 설명을 위한 가상 사례입니다. 화요일에 원고를 보내겠다는 약속만으로는 확정된 글인지, 해결되지 않은 의견이 남은 초안인지 알 수 없습니다.
받는 사람에게 일을 시작하기 전 반드시 필요한 자료가 무엇인지 물어보세요. 확정 원고, 사진 설명, 페이지 순서가 필요하다면 보내는 쪽이 약속한 때까지 준비할 수 있는지 확인합니다. 파일 위치와 사용할 버전을 기존 작업에 적습니다. 인계는 한쪽의 요구 목록이 아니라 양쪽이 실행할 수 있는 약속이어야 합니다.
산출물 사이의 의존 관계 드러내기
지면 작업에는 확인된 원고가 필요하고 인쇄에는 검토된 인쇄 파일이 필요합니다. 각 관계의 양쪽 담당자를 적고 입력이 바뀔 때의 영향을 살펴보세요. 늦게 들어온 한 문단은 메일 한 통으로 끝나지 않고 지면 재검토를 필요로 할 수 있습니다. 이번 결과물에 영향을 주는 관계에 집중하면 됩니다.
Atlassian의 Dependency Mapping은 상위와 하위 작업의 영향, 담당자, 위험, 검토 방식을 정리하도록 합니다. 한 부서의 마감에 다른 부서의 처리 시간이 자동으로 포함되지는 않습니다. 조정 담당자가 모든 입력을 알지는 못하므로 영향을 받는 팀과 함께 확인하세요.
역할 사이에 남은 일을 찾기
최종 사진과 설명이 일치하는지 누가 확인하는지 불분명할 수 있습니다. 편집과 디자인 공동 담당이라고 적는 것만으로 빈자리가 채워지지는 않습니다. 누가 직접 확인하고, 누가 빠진 정보를 제공하며, 누가 결과를 사용할 수 있다고 판단하는지 구체적으로 정합니다. 이름은 본인이 받아들인 책임과 실제 가능한 시간을 반영해야 합니다.
Atlassian의 Roles and Responsibilities는 겹치는 업무에 주 담당자를 정하고, 맡은 사람이 없는 일에는 담당자를 찾을 사람과 확인 날짜를 두도록 권합니다. 작은 일이 생길 때마다 새 직책을 만들 필요는 없습니다. 기존 책임에 합리적으로 포함할 수 있는지 먼저 보고, 불가능하면 인력이나 권한의 부족을 명확히 드러냅니다.
받았다는 말의 의미 합의하기
완성된 글, 확인된 사진 설명, 별도로 표시한 미정 항목처럼 필요한 조건만 정합니다. 그러면 받는 사람은 무엇이 있고 무엇이 부족한지 구체적으로 말할 수 있습니다. 공유 폴더를 열거나 감사하다고 답한 일을 불완전한 결과물의 수락으로 간주하지 마세요.
Scrum Guide의 완료 정의는 Scrum 안에서 완료 상태를 함께 이해하기 위한 기준입니다. 일반 부서 간 프로젝트가 이 체계 전체를 도입할 필요는 없습니다. 결과에 의존하는 사람이 완료를 이해할 수 있게 한다는 원칙을 참고하면 됩니다. 시간이 부족하다고 초안을 최종본으로 부르거나, 인계 후 조건을 조용히 추가해서도 안 됩니다.
변경되면 각자의 약속을 다시 확인하기
지면 작업 후 원고가 바뀌면 영향을 받는 페이지와 다시 검토할 부분을 표시합니다. 편집 담당자는 수정 원고를, 디자이너는 지면 수정 범위를, 조정 담당자는 인쇄 일정에 미치는 영향을 확인합니다. 모두에게 소식을 전한 사람이 세 작업을 자동으로 맡는 것은 아닙니다.
첫 인계 뒤에는 받는 쪽이 사용할 자료를 얻었는지, 역할 사이에 남은 일이 있는지, 수정으로 생긴 의존 관계를 놓쳤는지 살펴보세요. 먼저 해당 약속을 개선한 뒤 확대할지 판단합니다. 각 부서의 유용한 도구는 유지하면서 연결 지점을 명확히 하면 다음 작업을 진행할 수 있습니다.