애자일한 PRD 작성 (1)
애자일 소프트웨어 개발 철학과 PRD
들어가며
이전 글에서 PM은 고객의 문제를 고객의 언어로 끊임없이 정의하는 직군이라 정의(마에스트로와 잡부 사이 어디, PM - Product Manager의 본질에 대한 단상)하고, 고객의 언어로 정의한다는 것이 무슨 의미(고객의 언어로 문제 정의 - 힘들지만 PM의 가치를 높여 주는 핵심 역량)인지에 대해서도 간단히 언급했다. 이 글은 PM 이렇게 고객의 문제를 정의한 것을 어떻게 표현하고, 공유한 뒤, 문제를 해결해 나가는지에 대한 것이다. 그래서 PM(혹은 서비스기획)이라면 가장 많이 접하게 되는 PRD에 대해서 얘기하고자 한다. 내용이 길어질 것 같아서, 1분에서는 애자일 소프트웨어 개발 철학에서의 PRD의 의미를 짚은 뒤, 2부에서 PRD를 어떤 식으로 작성하면 좋을지에 대해 정리하겠다.
PRD란 무엇인가?
PRD에 대한 아틀라시안의 정의
A product requirements document (PRD) defines the requirements of a particular product, including the product’s purpose, features, functionality, and behavior. It serves as a guide for business and technical teams to help build, launch, or market the product. Building a great product requires tons of research and comprehensive planning. But where do you start? Product managers often start with a PRD.
How to create a product requirements document (PRD) by Atlassian
PRD에 대한 코드스테이츠의 블로그에 올라온 정의
PRD(Product Requirements Document)는 제품을 만들거나 업데이트하기 위해 기능을 기획하는 단계에서 요구사항을 개괄적으로 설명하는 문서로, 제품 개발 프로세스 전반에 걸쳐 필수적인 중요 문서입니다.
PRD(제품 요구사항 정의서)의 모든 것ㅣ뜻, 작성 방법, 포함 요소 by 함윤제 PM 코드스테이츠 블로그
PRD에 대해서는 인터넷에 많은 글들이 있고, 다양한 PRD 양식들도 많이 공개되어 있다. 하나하나의 내용들에는 제품을 만들기 위한 어떠한 내용들이 담겨야 하는지에 대한 PM과 메이커들의 고심이 담겨 있다. PRD를 가장 간단하게 요약하자면 "제품의 기획을 시작하는 문서"라고 요약할 수 있을 것 같다. 제품을 기획한다는 것은 고객의 문제를 풀기 위한 계획을 세우는 것과 같은 의미로, PM이 고객의 문제를 해결하기 위해 마주하는 첫 번째 산출물임을 의미하기도 한다. 문서 형태를 띠는 것은 여러 사람과 협업하는 과정에서 공유가 됨을 의미하고, 나름 신경을 써서 작성해야 하는 것을 뜻한다.
PRD를 작성한다는 것의 부담
상기한 PRD를 작성하는 많은 방법과 내용들은 매우 알차고 좋은 내용들이 많이 담겨 있다. 하나씩 살펴보면 제품을 잘 만들기 위해서( = 고객의 문제를 잘 해결하기 위해서) 필요한 내용들이다. 남들과 함께 공유하고 기록에 남기는 것이다 보니, 친절한 설명을 위해 자세한 설명과 꼼꼼함을 요구되며, 문서를 잘 쓰기에 꽤 많은 에너지가 들어간다. 하지만 광범위한 내용을 보다 보면, 배보다 배꼽이 더 큰 것이 아닌가 하는 걱정을 지울 수가 없다. 제품을 더 잘 만들기 위해 PRD를 잘 쓰는 과정들이, 때론 PRD 자체에 집중하게 만들어 제품을 만드는 데에 방해(문서 작성에 며칠이 걸려 개발이 시작 되지를 않는...)가 되는 그런 상황들이다.
고객은 제품을 기다려 주지 않는다. 기술들은 빠르게 변하고, 고객들은 더 빠르게 변화한다. 그런 상황에서 며칠이나 걸려 문서를 작성하는 것은 비효율적이고 시장에서 뒤처질 가능성은 높이게 된다. 그러한 흐름 속에서 애자일 소프트웨어 개발 철학이 태동했고, 그 철학이 담긴 애자일 선언문에서는 PRD와 같은 문서 작업에 큰 힘을 쏟는 것을 경계한다.
애자일 소프트웨어 개발 철학
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
© 2001, the Agile Manifesto authors
This declaration may be freely copied in any form, but only in its entirety through this notice.
애자일 소프트웨어 개발 철학은 고객의 빠른 변화에 대한 대응과 협업을 강조한다. 그 과정 속에서 포괄적인 문서보다는 작동하는 소프트웨어, 계획에 따르기보다는 변화를 수용하는 것 등을 강조하고 있다. 계속되는 고객의 변화에 대응하고 변화하기 위해서는 완벽한 계획을 미리 짜두는 것은 불가능하다. Following a plan이 작동하지 않게 되는데, 그 계획을 PRD에 꼼꼼하게 적어 두는 것은 어려울 뿐만 아니라, 비효율적이다. (계속해서 수정해야 하기 때문에) 그래서 가벼운 계획으로, 메이커들이 함께 협업하면서 제품을 하나씩 차곡차곡 쌓아야 한다. PRD는 천재 PM이 만드는 제품 개발의 마스터플랜이 아니라, PM과 메이커들이 함께 만들어 가기 위한 준비물이 되어야 하는 것이다.
주변에는 종종 아파트 건축으로 비유를 한다. 100층 아파트를 PM이 세운 완벽한 계획으로 올리는 것이 아니라, 1층씩 메이커들과 우당탕탕 만들어야 한다. 완벽하지 않지만, 1층씩 함께 올리면서 변화에 대응하는 것이다. PRD 역시 이러한 변화를 대응하도록 준비되어야 한다.
인천홈페이지 제작의 이미지...애자일 철학 속에서의 PRD
애자일 선언이 문서 작업을 전혀 하지 말라는 것은 아니다. (선언의 마지막에 왼쪽에 더 가치를 둔다고 했지, 오른쪽의 내용이 가치가 없음을 얘기하지 않는다.) 실제 규모가 작을 때야, 아무 문서 없이도 개발은 잘할 수 있다. 하지만 규모가 커지면 반드시 히스토리를 관리해야 하고, 미래의 생산성을 위해서 일정 수준의 문서화 작업을 하는 것은 필수적이다. 2~3명이서 개발하는 것이 아니라 5~6명이 넘어가기 시작하면 내용을 동기화하는 것도 일이기에 문서라는 것이 필요하다. 그렇기에 PRD를 작성하지 않는 것이 아니라, 애자일한 PRD를 어떻게 작성해야 할지 고민하는 것이 필요하다. 고객의 변화에 반응하는 제품이라는 것은, 다르게 말해서 고객의 변화에 반응하는 PRD를 뜻한다. 이는 PRD 역시 유연하게 변화할 수 있어야 하며, 가볍게 움직일 수 있어야 한다는 것을 의미한다.
많고 많은 PRD에 들어가야 할 내용들 중에서도 PRD가 필수적으로 담아야 할 것, 즉 다시 말해 고객의 문제를 풀기 위해 PRD에 포함되어야 할 내용은 세 가지이다.
(1) 고객에게 불편함을 주는 문제인지를 정의한다.
(2) 그 문제는 해결할만한 가치가 있는지를 논의한다.
(3) 마지막으로 문제를 어떻게 해결할 것인지를
위의 세 가지 내용을 얼마나 콤팩트하게 잘 정리하는지가 PRD의 1차 과제이다. 이후 PRD를 가지고 계속해서 메이커들과 협업하는 것이 2차 과제이자 최종 과제이다. 1차 과제는 대략적인 방향을 제시할 수 있어야 하고, 2차 과제는 메이커들을 참여시켜 조금 더 구제화할 수 있어야 한다.
1차 과제로서 위의 세 가지 내용을 간단히 정리하면 아래와 같다.
(1)은 앞 선 글들에서 계속해서 강조해 온 고객의 문제를 고객의 언어로 작성하는 것을 뜻한다.
(2)는 문제를 해결했을 때, 고객에게 어떤 임팩트를 줄 수 있고, 비용 대비 효과적인지를 의미한다.
(3)은 문제를 "어떻게" 해결하면, 어떠한 목표를 달성할지에 대한 가설과 유저스토리를 의미하며, 어떤 식으로 개발해야 할지에 대한 대략의 얼개를 그리는 것을 의미한다.
함께 PRD를 만들어 가는 것
(1)과 (2)를 통해서, 조직이 풀고자 하는 문제를 명확히 하고, 고객의 문제를 해결하는 것이 가치가 있음을 인식하게 된다. 제 아무리 실력이 좋은 메이커들이 함께 한다고 해도, 위의 (1)과 (2)가 동기화되지 않으면 제 실력을 발휘하기 어렵다. 각자가 문제를 이해하는 방식이 달라진다. 그리고 왜 해야 하는지 납득이 안되면 최선의 힘을 쏟기가 힘들어진다. (1)과 (2)가 잘 동기화되어야 (3)의 단계로 넘어가서, 실력 좋은 메이커들이 문제를 해결하기 위한 방법을 함께 고민하게 된다. 유저스토리를 보면서 이렇게 해결하는 것이 좋을까요?에 대한 활발한 논의들이 PRD에 담기게 된다. 애자일한 PRD는 메이커들이 함께 만들어 가는 것이다.
함께 잘 만들기, PRD 부터 시작...PRD 작성에 대한 더 자세한 내용은 다음 글에서...
