프로덕트 오너

만들 것은 언제나 만들 수 있는 양보다 많습니다. 개발자 다섯 명이 한 달에 처리할 수 있는 일이 열 건인데 들어오는 요청은 서른 건인 상황이 기본값이라고 보면 됩니다.

문제는 요청하는 사람이 여럿이라는 데서 시작합니다. 영업은 이번 계약에 필요한 기능을 먼저 해 달라고 합니다. 고객 지원은 문의가 제일 많이 들어오는 문제를 급하다고 합니다. 대표는 다음 투자 자리에서 보여 줄 것을 원합니다. 셋 다 회사에 필요한 일이고 셋 다 자기 근거가 있습니다.

결정하는 사람이 없으면 팀은 매번 멈춰 서서 누구 말을 들을지부터 논의합니다. 목소리가 큰 사람이 이기거나, 가장 최근에 말한 사람이 이기거나, 셋 다 조금씩 하다가 아무것도 끝내지 못합니다. 개발팀이 일주일에 두 번씩 우선순위를 바꾸는 상황이 여기서 나옵니다.

프로덕트 오너는 그 논의를 끝내려고 만든 자리입니다. 순서를 정하는 권한을 한 사람에게 몰아줍니다. 대신 그 결정의 결과도 그 사람이 집니다. 권한과 책임을 함께 묶어 둔 것이 이 자리의 설계입니다.

백로그를 손보는 일이 가장 많습니다. 백로그는 앞으로 만들 것들을 순서대로 세워 둔 목록으로, 위에 있을수록 먼저 만듭니다. 새로 들어온 요청을 항목으로 정리하고 이미 있던 항목의 순서를 바꿉니다. 더는 하지 않기로 한 것은 지웁니다. 목록이 길어질수록 아래쪽은 읽히지 않으니, 실제로는 위쪽 열 개 정도를 계속 다듬는 일에 가깝습니다. 다듬는다는 건 맨 위 항목에는 왜 만드는지와 대략의 크기, 뻔한 질문에 대한 답까지 적혀 있게 만든다는 뜻입니다. 마흔 번째 줄의 항목은 누군가 급히 적어 둔 한 줄 그대로여도 괜찮습니다.

주기가 시작될 때는 스프린트 플래닝에 들어갑니다. 스프린트는 보통 2주짜리 고정 길이의 작업 주기인데, 그 시작 회의에서 이번에 무엇을 만들지 정합니다. 여기서 역할이 갈립니다. 무엇이 위에 있는지는 프로덕트 오너가 정하고, 그중 몇 개를 담을 수 있는지는 개발팀이 정합니다. 프로덕트 오너가 "다 담으세요" 라고 말할 수 없는 이유입니다.

주기 중에는 질문을 받습니다. "이 화면에서 값이 비어 있으면 어떻게 하나요", "기존 사용자한테도 이 알림이 가나요" 같은 물음이 하루에 몇 개씩 들어옵니다. 만들다 보면 미리 정하지 않은 구멍이 반드시 나오고, 그 자리에서 답이 나와야 개발이 멈추지 않습니다. 미리 인수 조건을 적어 두면 이 질문이 줄어듭니다. 인수 조건은 "무엇이 되면 이 작업을 끝난 것으로 볼지" 를 항목으로 적어 둔 것입니다.

주기가 끝나면 스프린트 리뷰에서 나온 결과물을 봅니다. 받아들일지 아니면 더 손봐야 할지를 판단하는 것이 마지막 일입니다.

개발팀과는 매일 붙어 있습니다. 순서와 이유를 설명하고, 만드는 도중에 생기는 판단을 함께 좁힙니다. 이 관계가 멀어지면 프로덕트 오너는 요청을 전달하는 창구로 전락하고, 팀은 왜 이걸 만드는지 모른 채 만듭니다.

스크럼 마스터와는 역할이 겹치지 않습니다. 프로덕트 오너는 무엇을 만들지를, 스크럼 마스터는 팀이 잘 굴러가는지를 봅니다. 회의가 길어지거나 다른 팀 때문에 일이 막혔을 때 나서는 쪽이 스크럼 마스터이고, 그 막힌 일을 뒤로 미룰지 정하는 쪽이 프로덕트 오너입니다.

이해관계자와는 요청을 받고 결과를 설명하는 관계입니다. 이해관계자는 이 제품의 결과에 영향을 받거나 영향을 주는 사람들로, 영업·고객 지원·경영진이 여기 들어갑니다. 상당한 시간이 "이건 왜 뒤로 밀렸는지" 를 설명하는 데 들어갑니다. 설명을 건너뛰면 다음번에는 프로덕트 오너를 거치지 않고 개발자에게 직접 부탁하는 일이 생깁니다.

회사 규모에 따라 이 자리의 모습이 달라집니다. 스크럼을 쓰는 큰 조직에서는 프로덕트 매니저와 프로덕트 오너가 따로 있지만, 작은 팀에서는 한 사람이 둘을 겸합니다.

"이건 PO 가 결정할 일이에요."

논의를 멈추고 권한 있는 사람에게 넘기자는 말입니다.

"백로그 순서 바꾸시려면 지현님한테 먼저 말씀하세요."

개발자에게 직접 부탁하지 말고 순서를 정하는 사람을 거치라는 뜻입니다.

"PO 가 인수 안 해 줘서 이번 스프린트에 못 넣었어요."

만들긴 했지만 합격 판정을 못 받아 완료로 세지 못했고 다음 주기로 넘어갔다는 말입니다.

페이지덱에는 프로덕트 오너라는 직함이 따로 없습니다. 45명 규모에서는 흔한 일입니다. 프로덕트 매니저인 지현이 개발팀과 붙어 있는 시간에는 사실상 프로덕트 오너로 일하고, 규원과 로드맵을 이야기할 때는 프로덕트 매니저로 돌아옵니다. 수아가 계약 건으로 급한 요청을 가져와도 순서를 바꾸는 건 지현입니다. 수아가 규원에게 먼저 이야기해 규원이 지현에게 전달하는 경로가 생기면, 그때부터 백로그는 두 사람이 정하는 것이 되고 개발팀은 다시 누구 말을 들을지 고민하게 됩니다.

직급으로 읽는 경우가 많습니다. 영어 직함이고 결정 권한이 있으니 개발팀 위에 있는 자리처럼 보입니다. 하지만 이건 스크럼이라는 틀 안에서 정의된 역할 이름이지 조직도상의 계급이 아닙니다. 명함에 적히지 않아도 백로그 순서를 최종으로 정하는 사람이 있다면 그 사람이 프로덕트 오너입니다. 계급으로 오해하면 "PO 가 시켰으니까" 로 일이 굴러가고, 팀은 이유를 묻지 않게 됩니다.

요구사항을 혼자 다 써서 넘기는 사람으로 읽는 것도 흔합니다. 무엇을 만들지 정하는 사람이니 어떻게 만들지도 정해 줘야 할 것 같기 때문입니다. 그렇게 일하면 팀은 받아 적는 쪽이 되고, 만드는 도중에 나오는 더 나은 방법도 사라집니다. 프로덕트 오너가 정하는 건 순서와 이유입니다. 어떻게 만들지는 그걸 만들 사람들이 정할 때 가장 나은 답이 나옵니다.