광고주에게서 문의가 들어옵니다. 특정 캠페인이 왜 노출되지 않는지, 리포트의 측정 기준이 정확히 무엇인지 같은 것들입니다.

이런 문의를 개발자에게 바로 넘기지 않았습니다. 기획 선에서 답을 찾아본 뒤 정말 안 되는 것만 넘기려 했습니다. 

개발자가 맥락 없는 문의에 시달리지 않게 하는 것이 제 역할이라고 생각했기 때문입니다.

기능 요청이 들어와도 마찬가지였습니다. 개발과 논의하기 전에 구현이 가능한지 제가 먼저 조사했습니다.

성실하게 일했다고 생각했는데요, 돌아보니 제가 중간에 서면서 커뮤니케이션 비용이 늘고 있었습니다. 

개발자에게 직접 물으면 한 번에 끝날 질문이 저를 거치며 두세 번 왕복했습니다.

■ 스크럼은 반대로 말합니다

올해 8월, 현재의 업무 방식을 점검하고 Agile/ Scrum 방식을 도입하고자 PSPO II를 독학했습니다. 

그 중 스크럼 가이드에서 실무에 활용할 문장이 두가지 정도 떠오르는데요.

하나는 커뮤니케이션에 관한 문장입니다. 

스크럼 팀 안에서 "이해관계자들과 스크럼 팀들 사이의 장벽을 제거하는 것"이 스크럼 마스터의 주요 할 일인데, 제거 대상인 그 장벽이 상당 부분 저였습니다. 촉진해야 할 소통을 제가 중간에서 관리하고 있었습니다.

다른 하나는 개발자에게 무엇을 넘겨야 하는가입니다. 

선정한 일을 어떻게 완료할지는 "절대적으로 개발자들의 재량"이며 "다른 누구도 개발자들에게 정해주어서는 안된다"고 되어 있습니다. 

제가 미리 조사하던 구현 방식이 여기에 해당했습니다.

구현 방식은 넘기고, 개발자와 이해관계자가 직접 이야기하도록 둘 것. 제가 붙잡고 있던 두 가지가 놓아야 할 것들이었습니다.

■ 그럼 PM는 무엇을 하는가

다 넘기고 나면 저에게는 무엇이 남는지?, 이 질문이 뒤따랐습니다.

Scrum 공인 트레이너인 Robbin Schuurman과 Chris Lukassen이 프로덕트 오너의 스탠스를 열두 가지로 정리한 자료가 있습니다. (*공식 가이드가 아닌 두 트레이너 분들의 해석입니다!) 

이 목록이 제 질문에 많은 답이 되어주었는데요, 넘긴 자리에 무엇이 들어와야 하는지 이름을 붙여 주었기 때문입니다.

먼저, 지향해야 할 6가지 스탠스입니다.

미노출 문의를 제가 파고들던 시간에 이 여섯 가지 중 어느 것도 하지 못했습니다.

반대로, 이렇게 되면 곤란합니다

제가 바빴던 이유가 이 표에 있었습니다. 문의가 전부 저에게 몰리던 모습은 주제 전문가와 문지기 사이 어딘가였습니다.

■ '오너'라는 말의 함정

'프로덕트 오너'라는 이름 때문에 오해한 것이 있습니다. 오너이니 다 알고 다 챙겨야 한다고 생각했습니다.

스크럼 가이드는 다르게 씁니다. 

프로덕트 오너는 백로그 관리 업무를 직접 하거나 "다른 사람들에게 그 책임을 위임한다"고 되어 있고, 어떤 방식이든 "최종 책임은 프로덕트 오너가 갖는다"고 덧붙입니다.

제가 오래 넘기지 못한 이유가 이 지점에 있었습니다. 넘기면 책임도 함께 간다고 믿었습니다. 

실제로는 넘기고도 최종 책임이 남습니다. 저는 이 문장을, 오너십은 넘긴 뒤에도 답할 수 있는 데서 나온다는 뜻으로 이해했습니다.

PO가 스크럼 방식으로 일한다는 것은, 제게는 열두 가지 중 지금 어디에 서 있는지 스스로 확인하는 일에서 시작합니다.