PM과 PO 차이: 외주 프로젝트에 PO 자리가 비는 이유

주간 회의록에 같은 줄이 3주째 같은 모양으로 남는 프로젝트가 있습니다.

안건: 회원가입에 소셜 로그인을 넣을 것인가
결정: 고객사 확인 후 회신

회의에는 수행사 PM이 있었고 고객사 담당자도 있었습니다. 참석자가 부족했던 것이 아닙니다. 그 방에 그 결정을 내릴 자격이 있는 사람이 없었을 뿐입니다. PM과 PO의 차이는 조직도가 아니라 이 지점에서 실질적인 의미를 갖습니다.

부르는 이름만 다르다는 오해

가장 흔한 설명은 이렇습니다. PM과 PO는 회사 규모나 문화에 따라 부르는 이름이 다를 뿐 같은 일이다. 스타트업은 PO라고 부르고 SI는 PM이라고 부른다. 애자일이면 PO, 워터폴이면 PM.

이 설명으로는 두 가지가 설명되지 않습니다. 하나는 한 프로젝트에 PM과 PO가 동시에 있고 심지어 서로 다른 회사 소속인 경우입니다. 다른 하나가 위의 회의록입니다. 이름만 다른 같은 일이라면, PM이 참석한 회의에서 범위 결정이 3주째 미뤄질 이유가 없습니다.

두 이름은 같은 일의 다른 표기가 아니라 서로 다른 두 책임입니다. 한 사람이 겸할 수 있느냐는 그다음 문제이고, 그 답은 회사 문화가 아니라 계약이 정합니다.

두 이름이 실제로 나누는 것

PM이 책임지는 질문은 언제, 얼마에, 누가, 지금 무엇이 막혀 있는가입니다. PO가 책임지는 질문은 무엇을 만들 것인가, 왜, 어떤 순서로, 그리고 무엇을 만들지 않을 것인가입니다.

마지막 항목이 핵심입니다. 만들지 않을 것을 정하는 권한이 PO를 PO로 만듭니다. PM은 「이 기능을 넣으면 2주가 늘어납니다」까지 말할 수 있지만 「그러니 넣지 맙시다」는 말할 수 없습니다. 그 문장은 예산과 사업 목표를 쥔 쪽에서만 나올 수 있습니다.

	PM	PO
책임지는 질문	언제, 얼마에, 누가	무엇을, 왜, 어떤 순서로
결정 대상	일정과 자원 배치	범위와 우선순위
실패했을 때 나타나는 것	납기 지연, 원가 초과	아무도 쓰지 않는 기능
대리가 되는가	다른 PM으로 교체 가능	대리를 세우면 사실상 공석

마지막 줄이 두 역할의 성질 차이를 가장 잘 보여 줍니다. 일정 관리는 인수인계가 되지만, 「무엇을 만들지 정하는 권한」은 위임장을 써 주지 않으면 넘어가지 않습니다.

스크럼 가이드가 PO에게 요구하는 조건

이 구분은 애자일 진영이 만든 말이 아니라 그쪽에서 가장 엄격하게 정의됩니다. 스크럼 가이드 2020은 PO를 이렇게 못박습니다.

The Product Owner is one person, not a committee.

그리고 PO가 성공하려면 조직 전체가 그의 결정을 존중해야 한다고 씁니다. 이 문장은 보통 조직문화에 대한 당부로 읽히는데, 저는 권한의 소재를 규정하는 문장에 가깝다고 봅니다. 존중받지 못하는 결정권은 결정권이 아니고, 위원회가 내리는 결정은 결정이 아니라 합의 과정입니다.

여기까지는 한 회사 안에서 제품을 만드는 상황을 전제합니다. 계약이 끼면 전제가 하나 깨집니다.

계약이 끼면 갈라지는 소속

외주는 두 회사가 하나의 제품을 만드는 구조입니다. 계약서가 정하는 것은 대개 범위, 일정, 대금, 검수 기준입니다. 그런데 「무엇을 만들지 최종적으로 정하는 사람이 누구인가」는 잘 적히지 않습니다. 적히지 않아도 답은 이미 정해져 있습니다. 대금을 지급하고 검수에 서명하는 쪽입니다.

그래서 외주 프로젝트에서 PM과 PO는 한 사람이 될 수 없습니다. PM은 수행사에 있고 PO의 권한은 발주사에 있습니다. 조직 문화나 방법론이 그렇게 만드는 것이 아니라 계약이 그렇게 만듭니다. 수행사가 아무리 제품을 잘 이해해도 「이 기능은 빼겠습니다」를 스스로 결정하면 계약 위반이 됩니다.

발주자가 모르는 채 떠맡는 자리

문제는 발주사 담당자가 자신이 그 자리에 있다는 것을 대개 모른다는 점입니다.

그 담당자에게는 본업이 따로 있고 이 프로젝트는 올해 맡은 여러 업무 중 하나입니다. 「개발은 업체가 알아서 해 주는 것」이라고 이해한 채 시작합니다. 절반은 맞는 이해입니다. 만드는 일은 업체가 합니다. 그런데 무엇을 만들지 정하는 일은 발주할 수 없습니다. 그 일만은 돈을 주고 넘길 수 없는데, 계약서 어디에도 그렇게 적혀 있지 않아서 아무도 알려 주지 않습니다.

저는 외주 프로젝트가 어려워지는 원인의 대부분이 기술이 아니라 여기 있다고 봅니다. 기술 문제는 대개 눈에 보이고 담당자가 배정되지만, 비어 있는 결정권은 아무 문서에도 나타나지 않습니다.

PO 자리가 비었을 때 나타나는 증상

가장 먼저 보이는 것은 지연입니다. 다만 지연 사유란에는 「개발 지연」이라고 적힙니다. 실제로는 답을 기다린 시간인데, 프로젝트 관리 도구에 「결정 대기」라는 상태가 없어서 개발 일정에 흡수됩니다.

두 번째는 검수 단계에서 처음 나오는 재설계 요구입니다. 「이건 생각한 거랑 다른데요」라는 말이 완성된 화면 앞에서 나옵니다. 이 말이 늦게 나오는 이유는 담당자가 무성의해서가 아니라, 그 전까지 아무도 그에게 결정을 요구하지 않았기 때문입니다. 화면이 나오기 전에는 결정할 대상이 눈에 보이지 않습니다.

세 번째는 회의 참석자가 계속 늘어나는 것입니다. 결정이 안 나면 사람을 더 부르게 되고, 사람이 늘면 결정은 더 안 납니다. 스크럼 가이드가 굳이 「위원회가 아니다」라고 한 문장을 넣어 둔 이유가 여기 있습니다.

계약과 문서에서 그 자리를 만드는 방법

이름을 적는 것에서 시작합니다. 직함이 아니라 사람 이름으로 단일 의사결정자를 적고, 그 사람이 부재할 때 누가 대신 결정하는지도 함께 적습니다. 「고객사」라고만 적힌 승인란은 아무도 채우지 않습니다.

그다음이 변경 관리 절차입니다. 요청, 영향 산정, 승인의 세 단계를 두고 승인란에 사람이 들어가야 합니다. 승인자가 비어 있는 변경관리 양식은 절차가 아니라 서식입니다.

저라면 셋 중에서 응답 기한을 가장 먼저 넣겠습니다. 「영업일 3일 내 회신이 없으면 제안한 원안대로 진행한다」 같은 문장 하나입니다. 이것이 없으면 결정을 미루는 데 아무 비용이 붙지 않고, 비용이 붙지 않는 지연은 반드시 일어납니다. 발주사에 불리한 조항처럼 보이지만 실제로는 발주사가 검수에서 겪을 재작업을 앞당겨 막아 줍니다.

여기서부터는 계약마다 다릅니다

수행사가 PO 역할까지 맡는 구조도 있습니다. 제품 위탁 개발이나 기획 컨설팅이 함께 들어가는 계약이 그렇습니다. 이때는 권한을 위임한다는 사실이 계약서에 적혀 있어야 합니다. 적히지 않은 위임은 검수 단계에서 뒤집히고, 그 시점의 재작업 비용은 수행사가 뒤집어씁니다.

「PM」이라는 직함이 가리키는 실제 업무 범위도 회사마다 다릅니다. 국내 SI에서는 PM이 영업과 수주를 겸하는 경우가 흔한데, 그러면 범위 협상에서 이해관계가 한쪽으로 기웁니다. 이 부분까지 일반화할 자신은 저도 없습니다.

확실한 것은 셋입니다. PM과 PO는 이름이 아니라 책임이 다르다는 것, 계약이 그 둘을 서로 다른 회사에 배치한다는 것, 그리고 발주사 쪽 자리는 돈을 주고 넘길 수 없다는 것입니다.