brunch

You can make anything
by writing

C.S.Lewis

by 담다리담 Jan 24. 2023

간단해보이지만 정말 중요한 PO의 역량, 요구사항정의

2022년의 마지막 한 달, 매니저가 떠난 후 도메인지식이 없는 채로 새로운 업무들을 휩쓸리듯 시작했다. 엄청나게 빠르게 진행하는 와중 리더십에서 빠르게 요청하는 것들을 다 잘 해내고 싶은 마음에 그냥 몰아쳤다. 내가 완벽하게 이해하지 못했지만 어련히 잘해주시겠거니 하며 문서도 없이 구두로 먼저 요청했다. 맘이 너무 급했고 위에서 요청했다고 하니 개발에서도 덩달아 급하게 움직였다. 요청받은 10개 중 내가 한 번에 잘할 수 있는 한계는 7개까지인데 10개를 다 해 보려고 아등바등한 것이다. 당연하게도 그중 대부분은 실패했다. 실수를 하거나 뭔가를 놓치거나 심지어는 요청사항이 잘못이해되거나.

마지막 한 달 동안 같이 일했던 TPM님께서 진심 어린 충고를 해 주셨다. 경험이 많은 분이고, 그럼에도 새로운 것을 배우려는 열정이 있고 그만큼 빠르게 흡수하는 분이었다. 무엇보다도 사람들에게 요청할 때 어떻게 요청해야 하는 지를 많이 배웠다. 나는 requirement를 주는 사람의 입장이지만, requirement를 받는 사람의 입장에서 뭘 줘야만 명확하게 이해할 수 있는 지를 고민하게 해 주셨다.

이번에 생긴 문제 중 하나는, A에 뭐가 필요한 지를 내가 명확하게 정의했어야 했는데, 고객입장에서 어떤 프로세스가 이루어져야 하는 지를 명확하게 정의했어야 했는데 그러지 않았다. 간단하게 요건만 던지고 빨리 해야 해요!라고 마음 급하게 요청했다. 그렇게 전달해 놓고 알아서 잘해주시기를 바랐다면 그것이 욕심이다. 아무리 능력 좋은 TPM과 개발자 분들 이언정, 내가 요청하는 요구사항을 명확하게 이해할 수 없다면 배는 산으로 갈 수밖에 없다. 내가 PO로서 해야 할 가장 명확한 것은, 개발방식을 정하는 것이 아니라 고객 입장에서 어떤 경험이 필요한 지를 명확하게 적는 것이다. "고객이 어디에 들어가면, 뭐가 보인다." 이런 템플릿이 괜히 있는 것이 아니다.

내 원페이저는 사용자 입장에서 필요하지 않은 정보가 많고, 오히려 꼭 필요한 정보는 별로 없다. 중요한 것은, 얼마나 내 원페이저의 사용자(즉 TPM과 개발자)가 내 원페이저를 보고 필요한 정보를 쉽고 빠르게 뽑아내느냐다. 내 원페이저의 독자는 다른 PO가 아니라, 개발자와 QA다. 사용자가 내 원페이저에서 알고 싶은 것은 "나는 그래서 무슨 작업을 해야 해?"다. 명확하게 적는 거보다 그게 더 중요하다. 뜬구름 잡는 소리 같다면, 아무것도 모르는 사람이 봐도 알 수 있도록, 담당자가 이전 회의에 없었어도 원페이저를 읽으면 알 수 있도록 적는 것이 포인트다.

이전 팀은 체계가 잘 짜인 팀이었고 이미 잘 만들어진 시스템 위에 작은 개선을 여러 개 일으키는 데 집중했다. 이미 잘 정리된 사이트에 개선하는 것이었기 때문에 "왜 해야 하는데?" "이거 꼭 해야 해?"가 중요했다. 그래서일까, 중요한 것은 Problem statement, Root cause였다. 그리고 이를 뒷받침할 observation까지. 이게 명확하게 잡혀있지 않으면 내 프로젝트의 모든 reasoning이 깨어진다. 그래서 나도 이 부분만 잘 쓰면 되는 거라고 생각했다. 그렇지만 이건 기본이고, 특히 지금처럼 해야 할 것이 명확한 팀에서는 오히려 중요하지 않았다. 지금 팀에서 더 많은 팀들과 일하기 위해서는 더 중요한 게 있었다. 유저가 원하는 정보를 명확하게 주는 것. 왜 해야 하는 지를 적어야 할 시기는 지났다. 그건 단지 얼라인을 하기 위한 도구에 불과하다. 더 중요한 것은, 각 팀이 뭘 해야 하는 지를

나는 아직도 "왜 해야 하는데?", 즉 목적만 얼라인이 된다면 나머지는 알아서 잘 굴러갈 거라고 생각했다. 하지만 이렇게 많은 팀과 같이 일을 할 때는 실상은 그렇지 않았다. 목적뿐만 아니라, "뭘 해야 하는데"에 대한 정의도 명확하게 주어야 한다. 나는 유저 리콰이어먼트에는 힘을 빼는 경향이 있었다. 뭘 해야 하는지에 대한 정의가 명확하지 못했다. 그리고는 바로 "어떻게 하면 되는데"에 힘을 줬다. 어떻게 할 건지는 개발자와 TPM이 정할 문제다. 나는 그들이 정한 것을 원페이저에 정리만 해도 충분하다.

예전에 서비스기획자 시절에는 개발구조와 정책을 아는 것이 힘이었으니, 그 시절에 개발을 많이 알기 위해 힘을 주던 습관이 아직 남아있다. 그때는 뭘 어떻게 해야 할 지에 대한 것은 스토리보드에 적었으니 별도로 힘을 주지 않아도 되었던 것이다. 스토리보드를 사용하지 않는 지금, 이를 대체할 만큼 명확한 것들이 필요하다. 어떻게 할지는 그들이 파악할 문제이지만, 나는 뭘 해야 할지는 명확하게 해야 한다.

내 매니저는 대부분의 개발자들이 같이 일하기 좋아한 PO였다. 어떤 개발자는 본인이 여태 함께 일한 최고의 PO라고 했다. 나는 그녀의 어떤 점이 그녀를 그런 좋은 PO로 만들었을까 궁금했다. 내 매니저의 원페이저는 가장 균형 잡힌 원페이저였다고 한다. 원페이저뿐만 아니라 의사소통을 할 때도 그랬다. 가장 중요하게, 사람들이 움직이는 데 필요한 부분들을 명확히 알았고 이를 소통했다. 만약 구멍이 있다 해도 빠른 시일 내에 Q&A를 얼라인해서 만들어냈다고 한다. 나는 내 매니저의 원페이저와 나의 원페이저가 크게 다르지 않다고 생각했다. 오히려 가끔은 내 매니저의 원페이저에는 데이터가 부족하다고 생각했다. 오만한 생각이었다. 초반에 데이터가 없는 상태에서 워낙 급하게 달려왔으니까 당연한 일이었다. 진짜 중요한 것은 이게 아니었다. 사람들이 뭘 해야 할지를 명확하게 정리해 주는 것이 중요하다. 가끔씩은 나도 내가 뭘 요청하는지 모른 채 요청할 때가 있다. 말하다 보면 꼬인다. 그렇지만 그녀는 그럴 때가 없었다. 명확하게 뭘 해야 할지를 알고 항상 요청했다. 그리고 고객 입장에서 어떤 것이 필요할지를 명확하게 말했다. 그녀와 나의 가장 큰 차이점일 것이다.

그동안 여러 도메인이 엮이는 큰 일감은 진도가 느렸다. 다른 간단한 일은 별 차이가 없었음에도 여러 도메인을 엮으면 내가 유난히 느렸다. 그 이유는 내가 도메인 지식이 없는 데다가, 요구사항을 제대로 정리하지 못했기 때문이라는 걸 차분히 깨닫는다. 가끔은 PO가 요구사항정리와 우선순위 정리만 하는 게 아닐까, 내가 하는 일이 크게 의미 있는 일일까 생각할 때가 있다. 하지만 이럴 때 보면 PO의 요구사항 정의 역량은 생각보다 많은 것을 좌우한다.

keyword

담다리담 커리어 분야 크리에이터 소속 직업 기획자

Product Owner. 나의 하루를 슬기롭게 채우고 싶습니다. 일과 서핑, 일상의 소소한 생각을 기록합니다.

구독자 131

매거진의 이전글 PO의 힘은 커뮤니케이션에 있다. 퇴사하는 매니저와의 마지막 원온원 매거진의 다음글

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari