애자일한 PRD 작성 (2)
메이커를 레버리지로 PRD를 만드는 문화
들어가며
지난 글에서는 PRD가 어떤 것인지와 애자일 철학에 대해서 가볍게 다루었었다. 애자일 철학 속에서 PRD는 어떻게 써야 하는지에 이번 글에서 다루고자 한다. 다만 이는 "PRD는 이렇게 써야 한다" 보다는, 어떤 생각으로 접근해야 하는지에 대한 이야기가 더 중점이 될 수도 있다. 그리고 이는 PRD 템플릿의 정답이라기보다는 PRD를 대하는 팀(PM과 메이커)의 문화에 대한 이야기일 수도 있다.
PRD의 기본 내용 복습
많고 많은 PRD에 들어가야 할 내용들 중에서도 PRD가 필수적으로 담아야 할 것, 즉 다시 말해 고객의 문제를 풀기 위해 PRD에 포함되어야 할 내용은 세 가지이다.
(1) 고객에게 불편함을 주는 문제인지를 정의한다.
(2) 그 문제는 해결할만한 가치가 있는지를 논의한다.
(3) 마지막으로 문제를 어떻게 해결할 것인지를
(1)의 내용은 이전의 글들에서 계속해서 강조해 온 고객의 문제를 고객의 언어로 작성하는 것을 의미한다.
(2)는 문제를 해결했을 때, 고객에게 어떤 임팩트를 줄 수 있고, 비용 대비 효과적인지를 의미한다.
(3)은 문제를 "어떻게" 해결하면, 어떠한 목표를 달성할지에 대한 가설과 유저스토리를 의미하며, 어떤 식으로 개발해야 할지에 대한 대략의 얼개를 그리는 것을 의미한다.
회사에서의 감동 실화
PM : 이거를 이렇게 해서 이렇게 해보고 싶어요.
개발자 : 그래서 정확하게 해결하고 싶은 문제가 뭐예요?
이 모습은 단적으로 제대로 된 문제 정의를 하지 않고, 자신의 어떤 해결책들을 개발자에게 설명하면서 뭔가를 해보려고 안간힘을 쓰는 PM의 모습을 보여준다. 대화를 끝내고 개발자는 이렇게 말했다. "PM은 문제만 정확하게 짚어 주어도 반은 먹고 들어가는 것 같아요" 이는 정말이지 감동 실화이다. 그리고 저 말을 한 개발자는 커뮤니케이션이 매우 명확하고, 무엇인가를 설명할 때 전달력이 손에 꼽게 뛰어난 개발자이다. (내가 만나 본 개발자 중에서) 뭔가 하고 싶어 하고 할 수 있을 것도 같은 것을 막 얘기하는데, 핵심적으로 어떤 문제를 풀고자 하는지가 명확하지 않으면 모두가 혼란스럽다.
다시 한번, 고객의 문제를 잘 정의하기
회사에서 가장 큰돈이 들어가는 곳은 결국 인건비다. 고객의 문제를 풀기 위해 모인 PM과 메이커들의 인건비... 이를 가장 효율적으로 사용할 수 있는 것이 어찌 보면 회사의 명운과도 관련이 될 것이고, 여기서의 효율성을 높이기 위해 애자일 철학도 나온 것이다. 가장 효율적으로 사용하기 위한 첫 단계는 어떤 프로젝트를 하는 것의 당위성과 중요도에 대해 같은 이해를 갖는 것이다. 흔히 얘기하는 OKR과 같은 목표 관리도 구성원들이 바라보고자 하는 방향을 맞추어서, 그 효율을 극대화하는 것이고, 그 속에서의 작은 프로젝트를 함에 있어서 시작이 되는 PRD 역시 그 목표를 명확히 하는 것이다.
당연한 얘기로 PRD의 목표는 고객의 문제 해결이다. (모든 직업이 문제를 해결한다고 했는데, 그 속에서 작은 문제로 쪼개어서 작은 문제를 해결하는 것이다.) 그리고 문제 해결을 가장 잘 정의하는 것은 모두가 공감하는 공통의 프레임으로 정의를 하는 것이며, 결국 고객의 입장에서의 정리이다. 애당초 조직에서 일하는 사람들은 그 근본이 고객의 문제를 풀기 위해 모인 사람들이기 때문에 그 이상의 문제 정의는 있을 수가 없다. 그리고 그 고객의 문제가 얼마나 중요한지에 따라 설득력이 달라진다.
고객의 언어로 정의하는 것이 중요한 이유는 여기에서 다시 나오는데, 모두가 공감할 수 있기 때문이다. 하지만 우리는 때론 문제정의를 이렇게 하지 않는 경우가 많다. 예를 들어서 최근 SRE 등이 강조되는데, 이것이 강조되는 것은 결국 고객에게 나쁜 영향을 미칠 수 있기 때문이다. 그런데 갑자기 사이트 퍼포먼스 점수가 낮다는 문제 정의를 하고, 함께 일을 시작하려고 하면 이런 생각부터 든다. "어쩌라고?" 사이트 퍼포먼스 점수가 낮으면 안 좋을 것이라고 예상은 하겠는데, 뭐가 얼마나 안 좋은 거지? 이게 고객에게 정말 문제가 되는 수준인가? 이거 그냥 개발자들이 자기 자랑하는 문제인가? 조금 극단적인 예를 들었지만, 이렇게 모두가 공감할 수 있는 고객의 문제로 정의되지 않으면 이걸 왜 해야 하는지부터가 삐걱거리기 시작한다. 누구나 문제라고 여기기 쉽게 하기 위해서는, 노골적으로 얘기해서 우리에게 돈을 주고, 우리에게 돈을 벌어다 줄 고객의 문제로 바꾸는 것이 핵심이다.
고객이 짜증 난다 한다고!
애자일 철학에서도 이 의미는 중요하다. 고객의 변화에 대응하기 위해서는 고객이 어떤 상태로 문제를 느끼는지를 계속해서 점검할 수 있는 것이 중요하다. (이것을 나중에 지표화 하더라도... 지표도 결국 고객의 문제를 간접적으로 볼 수 있도록 하는 도구이다. 사이트 퍼포먼스 점수는 사이트에서 고객이 느끼는 쾌적함이겠지...)
풀만한 가치가 있는 문제인지?
??? : 왜 지금 그 문제를 풀어야 하나요? 그것보다 더 중요한 문제는 없나요?
PM : 지금 고객이 매우 x100 짜증 내고 있다고요!
PM은 풀만한 가치가 있음을 보이기 위해 고객이 얼마나 짜증 내고 있는지를 알려줘야 한다. 고객이 짜증 난다는데... 해결해야지... 풀만한 가치가 있는 것은 한정된 자원 속에서 그 문제를 푸는 비용을 들였을 때, 더 큰 효과를 낼 수 있는 것을 의미한다. 그리고 우리는 그 가치가 큰 것에 높은 우선순위를 두고 일을 하게 된다. 무한한 자원이 있다면 우선순위 고려할 것도 없이 모든 일을 다하면 되지만, 한정된 자원이라는 제약이 있기에 우선순위를 두고 효율성을 따지게 된다. 다만 쉽게 판단이 어려운 부분들도 있다. 많은 힘들더라도 큰 임팩트를 내기 위해 묵묵하게 투자해야 할 필요도 있다. 이 묵묵함이 나중에 장기 임팩트를 복리로 키울 수도 있다. 작은 투자로는 해결할 수 없는 것들도 많다. 그리고 임팩트를 명료하게 보기 어려운 것도 많다. 그럼에도 불구하고 지금 이 문제를 해결해야 한다는 의사결정하기 위해 끊임없이 검토해야 하는 것이다. 그리고 이것이 PRD에 녹아 있어야 함께 문제를 푸는 팀이 문제에 집중할 수 있게 된다. PM의 가장 중요한 역량 중 하나는 "해야 할 것과 하지 말아야 할 것을 구분"하는 것인데, 풀만한 가치가 있는지를 증명하는 것은 이 역량의 표현이다.
다만 배보다 배꼽이 더 크면 안 되고, 이 우선순위를 잡기 위해 개미 발걸음도 분석하려고 해서도 안된다. 꼼꼼하고 정확한 데이터를 보려고 하면서도, 우리가 평소 가진 직관을 믿고, 합리적인 가설을 제시하여 문제 해결의 방향을 잡고, 그 결과의 임팩트를 설득하는 것이 필요하다. (풀만한 가치에 대해서는 내부의 문제 해결이나, 미래 고객의 문제를 긁어 주는 등 다양한 접근이 있다고 생각하는데, 이에 대해서는 다음에...)
문제를 어떻게 해결할 것인가?
사실 이 글을 쓰게 된 가장 큰 이유는 문제의 해결 방안을 어떻게 PRD에 녹일 것인가를 얘기하기 위함이었다. (그렇다고 엄청난 PRD의 템플릿을 제시하는 것도 아니고... PRD의 정답을 제시하는 것도 아니다. 그냥 PRD를 접근하는 마음가짐에 대한 것을 쓰기 위해...) PM이라면 위의 문제 정의와 해결의 가치를 통해, 어떻게 해결하면 어떠한 임팩트가 날 것인지에 대해 가설을 제시하고 그 결과를 평가할 수 있게 해야 한다. (가설 검증을 어떻게 할 것인지?) 다만 이것을 처음부터 구체적으로 하기 시작하면 첫 시작에 큰 힘을 들이면서 문서에 매몰되는 경험을 하게 된다.
많은 PM들은 꼼꼼하면서도 무엇인가 정말 열심히 하기 위해, 머리를 끙끙 싸매면서 기능 명세를 하곤 한다. 하지만 계속해서 얘기하고 싶은 것은 문제가 정확하게 정의가 되면 해결책은 매우 다양하고, 최선의 해결책 제안은 누가 제시할지 정확히 알기 어렵다. (다만 PM이 최선의 해결책을 제시할 확률이 높지는 않을 것이라 생각한다. 메이커들 역시 문제 해결의 달인들이다.) 모든 사람들은 자기가 바라보는 관점에서 지식을 흡수하고, 그리고 그 지식이 계속해서 자기 강화가 되는 습관이 있다. PM이 북 치고 장구 치면서 만든 해결책에 시선이 집중하게 되면, 경주마처럼 시야가 좁아질 수 있다. 하지만 다시 원점부터 고민하면 다른 제안들이 더 매력적인 경우는 얼마든지 많다. 그래서 함께 하면서 의견을 조율하는 것이 중요하고, PM은 조율하는 과정에 의견을 잘 들을 줄 아는 것도 매우 중요하다. 그럼에도 결국 최종적으로는 PM이 어느 정도 판을 주도하게 되고 어떻게 해결할지에 대해 의사결정을 하게 된다. 그렇기에 잘 듣는 것이 중요한 것이다. 이전 글에서 얘기했듯이 고객을 대변하는 것이라는 암묵적인 동의 속에서 PM은 의사 결정을 하게 되고, 메이커들은 PM의 말을 신뢰하게 되는 것이다.
아니 그래서 문제 해결은 어떻게 쓰라는 것이냐?
지겨운 얘기일 수 있겠지만, 결국 PM은 다시 문제 해결에 있어서도 고객의 관점에서 풀어야 하는 문제의 내용에 대해서 다양하게 던질 수 있어야 한다. 다르게 얘기하면 유저스토리를 다양하게 던질 수 있는 것이 문제 해결 방안을 제시하는 PM의 핵심 역할이다. 우리가 PRD를 통해서 해결하고자 하는 문제에 대해서, 다양한 유저스토리를 작성하면서 고객의 원하는(want) 결과를 이유(why)와 함께 잘 정의하는 것이 필요하다. PM의 꼼꼼함은 기능의 명세가 아닌 그 이유(why)를 얼마나 다양하게 검토하느냐라고 생각한다.
그리고 각 유저스토리를 달성하기 위한 다양한 방법과 요구사항들은 메이커들을 적극적으로 활용할 수 있어야 하고, 메이커들을 PRD 작성에 끌어들여야 한다는 것이다. 앞선 개발자의 감동 실화를 다시 보자.
PM : 이거를 이렇게 해서 이렇게 해보고 싶어요.
개발자 : 그래서 정확하게 해결하고 싶은 문제가 뭐예요?
이 대화는 PM을 질책하는 개발자의 모습이 아니다. 개발자는 해결하고자 하는 정확한 문제가 무엇인지를 되물으면서, 그 문제가 정확하게 정의가 되면, 해결책에 대해서는 자신도 적극적인 해결책을 제시해 보겠다는 훌륭한 자세이다. 좋은 PM이라면 이러한 메이커들을 적극 활용해야 한다.
좋은 리더십은 언제나 가진 인재들의 레버리지를 잘 활용할 수 있는 것이라 생각하는데, PM이라는 직무가 리더십 겸임 하게 되는 경우가 많다. 그렇다면 PM은 메이커의 역량을 레버리지 삼을 수 있어야 팀의 역량을 최대한 끌어올릴 수 있게 되고, 문제 해결의 가능성을 높인다. 그리고 그 메이커들은 단순히 수동적으로 주어진 일을 하는 사람들이 아니라, 스스로 무엇인가를 능동적으로 고민하는 사람들이다. 최근 어느 채용이든 100% 요구하는 것이 하나 있는데, "적극적으로" 혹은 "스스로" 문제를 찾아서 풀어나가는 사람을 원한다. 이는 직군을 가리지 않는다. PM은 자신의 주변에 모여 있는 이러한 메이커들의 포텐션을 뽑아내야 하는 중요한 역할을 해야 한다. 이전 글에서 얘기한 PM의 전문성을 바탕으로 그들이 "적극적"이고 "스스로" 문제 해결에 참여하도록 하게 하는 것이 필요하다. 그리고 이는 PRD를 작성하는 이른 단계에서 이루어져야 한다.
PRD는 PM이 열심히 만드는 것이 아니라, 모두가 함께 열심히 만드는 것이다. 애자일 철학은 상호 협력을 중시한다. 이러한 협력은 코딩을 할 때부터가 아니라, 문제를 정의하면서 어떻게 풀지에 대해 고민하는 초기 단계부터 이루어져야 한다. 그래야 무조건 삽질을 덜 하게 된다. 그리고 다른 모든 메이커들이 그 문제를 나의 문제로 만들고, 오너십을 가지게 된다.
변덕쟁이 고객
빠르게 변화하는 현대 사회 속에서와 같은 상투적인 표현을 쓰지 않더라도, 변덕쟁이 고객은 도무지 알 수가 없다. 그리고 정확히 어떠한 해결책을 원하는지 정말 알기 어렵다. 뭔가 해결책을 제시한 것 같은데도, 반응이 오지 않는다. 그러면 다른 반응을 보기 위해 우리는 또다시 다른 해결책을 제시해야 한다. 문제가 바뀌었을 수도 있고, 문제는 그대로이나 다른 조건과 상황들이 바뀌어서 해결책을 틀어야 할 수도 있다. 문제가 바뀌었다면 바뀐 문제에 맞게 다시 PRD를 작성해야 할 것이다. 그래서 역설적이게도 시간을 들여 꼼꼼하게 작성하는 PRD가 시의성을 갖추지 못하는 경우가 생기기도 한다. 문제가 바뀐 것이 아니라면, 변화된 상황에 맞추어서 다시 빠르게 대응을 할 준비를 해야 한다. 기존에 던진 해결책을 점검하고, 다른 가설과 해결책을 던져야 한다. 이때 다시 빠르게 메이커들과 함께 PRD를 점검할 수 있어야 한다. 고객의 변화에 대해서는 PM만이 아니라 모두가 빠르게 인지해야 하기 때문이다. 그렇기 때문에 PRD는 완성본을 만드느라 힘 빼는 것이 아니라, 꾸준히 변화를 관리하는 살아 있는 유기체로 만들어야 하는 것이다.
나가며
주저리주저리 썼지만, 결국 복잡한 기능의 명세보다는 명확한 문제 정의와 메이커들의 레버리지를 당길 수 있는 PRD를 작성하기 위해서는, 함께 해야 한다는 것이다. 그리고 괜한 꼼꼼함을 위해 시의성을 놓치지 말아야 한다. 그리고 이건 PM만이 각성하는 것이 아니라, 함께 일하는 팀의 문화로 접근해야 하는 부분이다.
이상적인 이야기이지만, 어떻게든 끄집어내는 것이 PM이 역량이 아닐까...
최근 회사에서 주니어 PM들에게 주문한 내용은 PRD에 힘을 많이 쏟기보다는, 문제를 빠르게 정의하고, 해결 방법에 대해서는 PRD를 완성시키기 전에 빠르게 메이커들과 이야기하면서 리뷰하는 자리를 마련하라는 것이었다. (그리고 그 리뷰를 통해서 메이커들을 문제에 빠르게 참여하기를 원했다.) 지금 있는 곳에 처음 입사했을 때의 기본은 PRD 리뷰를 같은 직군인 PM 내에서 낮은 연차가 높은 연차에게 받는 평가 같은 것이었고, 그게 지금도 크게 바뀌지는 않았다. 그런데 생각해 보면, 괜히 시니어랍시고 나의 스케줄에 맞추어 나에게 들고 와서 리뷰를 기다리고 하는 것들이 괜히 비효율적으로 느껴졌다. (그리고 나는 봐도 잘 모른다... 아는 척을 해야 할 뿐...) 나보다는 함께 만들어갈 사람들을 빠르게 설득하고 진행하는 것이 옳다고 생각했다. 그리고 함께 만드는 사람들의 생각은 꽤나 날카롭고, 다들 관심이 많다. 물론 회사다 보니, 팀장(?)과 같은 포지션에서 주니어들의 업무를 이해하기도 해야 하고, 실수하지 않고 잘 나아갈 수 있도록 점검하는 것도 중요하다고 생각한다. 다만 평소 보아온 실력 있고 신뢰하는 주니어들이라면 내가 병목이 되거나 괜한 꼬투리를 잡으면 안 된다는 생각이 더 크게 들었다. 나 역시 주니어들의 레버리지를 적극 활용하고 싶기도 하고... 애자일에서 얘기하는 협력은 그러한 신뢰 속에서 나오는 것이라는 생각도 든다.
신뢰와 협력을 통한 애자일한 개발 문화
이상과 실천의 간극은 있지만, 그 간극을 줄이기 위해서 꾸준한 노력이 필요하다.
이전에 얘기한 체화와 같은...
