개발자가 읽고 바로 움직이는 PRD 작성법

PRD는 명세서이기 전에 설득 문서입니다

PRD는 Product Requirements Document, 제품 요구사항 문서의 약자입니다. 만들려는 것이 무엇이고 왜 만들어야 하는지를 적어 개발자, 디자이너, 이해관계자가 같은 그림을 보게 만드는 문서입니다. 처음 쓰는 사람이 가장 많이 하는 오해가 여기 있습니다. PRD를 기능 명세서로 알고 화면과 버튼 목록부터 채우는 것입니다.

기능 목록만 있는 문서를 받은 개발자는 둘 중 하나를 합니다. 목록을 그대로 구현하며 이상한 부분을 그때그때 되묻거나, 자기 해석으로 빈칸을 채우거나. 어느 쪽이든 회의가 늘어납니다. 좋은 PRD는 반대로 읽는 사람을 설득합니다. 이 문제가 진짜이고, 이 방향이 맞고, 여기까지가 범위라는 것을요. 설득된 개발자는 되묻는 대신 더 나은 구현을 제안합니다.

문서의 절반은 문제 정의입니다

누가, 어떤 상황에서, 얼마나 자주 겪는 문제인지 구체적으로 적습니다. 데이터가 있으면 숫자를 붙이고, 없으면 사용자 인터뷰나 문의 내역 같은 근거를 답니다. 문제 정의가 두루뭉술한 기능은 우선순위 회의에서 밀리기 시작하면 지킬 방법이 없습니다.

문제를 적다가 근거가 얇다고 느껴진다면 그것은 문서의 문제가 아니라 기획의 문제입니다. PRD는 그 얇음을 출시 전에 드러내는 장치이기도 합니다. 근거를 보강하든 방향을 바꾸든, 가장 싸게 할 수 있는 시점은 코드를 쓰기 전입니다.

안 하는 것을 적으면 회의가 줄어듭니다

범위에서 뺀 것을 명시하는 non-goals 절은 구글 엔지니어들의 설계 문서에서 표준처럼 자리 잡은 관행입니다. 합리적으로 기대할 법하지만 이번에는 하지 않기로 한 것을 문서에 박아 두는 것입니다. 이번 검색 개선에서 오타 교정은 다루지 않는다, 같은 식입니다.

이 절이 없으면 같은 논쟁이 개발 내내 반복됩니다. 이것도 되어야 하는 것 아니냐는 질문이 나올 때마다 처음부터 설명해야 하니까요. 안 하기로 한 결정과 이유가 문서에 있으면 링크 하나로 끝납니다. 범위가 슬금슬금 늘어나는 것을 막는 가장 싼 장치입니다.

요구사항은 검증 가능한 문장으로

요구사항 문장의 기준은 하나입니다. 완성됐는지를 제삼자가 판정할 수 있는가. 개선한다, 편리하게 한다 같은 동사는 판정이 불가능하므로 요구사항이 아니라 소망입니다.

성공 지표는 출시 전에 정합니다

출시 후에 지표를 고르면 반드시 오르는 지표를 고르게 됩니다. 그래서 성공 지표는 만들기 전에, 목표 수치와 측정 방법까지 적어 둡니다. 출시 4주 뒤 장바구니 이탈률이 60%에서 45% 아래로 내려오면 성공, 같은 식입니다.

지표가 미리 정해져 있으면 출시가 끝이 아니라 실험의 시작이 됩니다. 목표에 못 미친 결과도 어떤 가정이 틀렸는지를 알려 주는 데이터로 남고, 다음 PRD의 문제 정의가 그만큼 두꺼워집니다.

한 장짜리 뼈대

형식은 팀마다 달라도 답해야 하는 질문은 같습니다. 아래 다섯 절이면 한 장으로도 PRD 구실을 합니다.

출시까지 계속 고쳐 쓰는 문서입니다

PRD는 한 번 쓰고 결재받는 문서가 아니라 출시까지 계속 갱신되는 작업 문서입니다. 개발 중에 요구사항이 바뀌면 문서를 먼저 고치고, 바꾼 날짜와 이유를 남깁니다. 문서와 실제 만들고 있는 것이 어긋나는 순간부터 PRD는 아무도 안 여는 문서가 됩니다.

다 쓴 뒤에는 가장 바쁜 개발자 한 명에게 먼저 보여주고 어디서 읽다 막히는지 물어보세요. 질문이 나온 자리가 문서의 구멍입니다. 그만큼 고치고 나서 전체에 공유하면, 킥오프 회의가 설명회가 아니라 토론이 됩니다.

자주 묻는 질문