제품 요구 규격서를 힘들이지 않게 만드는 방법

(원문) How to Write a Painless Product Requirements Doctent

문서의 대부분은 초기 단계에서 만들어졌지만 실현 단계는 UX 설계 과정에서 가장 중요한 단계 중 하나이다.
조사, 분석, 디자인의 각 단계에서 많은 개념이 있었고, 마침내 무거운 허리를 들어올릴 때가 됐다.나는 문서가 반드시 제품과 일치하는 것은 아니라는 것을 이해하기 때문에 여기에 필요한 것만 소개한다.
이 글에서 나는 Product Hunt의 제품 요구 규격서를 최선의 실천으로 삼아 너에게 속하는 방법을 설명할 것이다.꼭 사용하세요무료 PRD 템플릿.
제품 요구 규격서 제작 방법
'시작'단계에 들어간 후 이전의 조사와 개발을 통해 팀은 제품에 대해 높은 이해를 가질 수 있을 것이다.기업이 다르기 때문에 제품 개발의 몇 단계(순서가 아닌)가 동시에 진행될 수 있다.
아무래도 5개 팀원에게 제품의 전체 목적, 기능, 발표 기준, 일정 등을 물어보면 거의 같은 답변을 받을 것으로 보인다.오늘날의 Len과 Asial의 세계에서 PRD는 절단될 수도 있고 (또는 원형으로만 표현될 수도 있다) 핵심 요소에만 주목할 수 있다.
PRD는 제품의 심장부로 디자이너, 개발자, 관계자가 제품의 상황과 목적을 이해하기 위해 생생한 문서 역할을 한다.

위에서 말한 바와 같이 요건을 문서화하지 않으면 전제조건에 큰 차이가 있을 수 있다.PRD는 과도한 디자인 사고의 위험성과 제품 리더십의 중요한 역할, 디자인 팀이 중시하는 가용성, 미학적, 공학적으로 중시하는 기능성의 균형에 대해 논의해왔다.
제품 관리회사 프로덕트 헌트에 따르면 PRD는 100페이지 이상 길이가 필요하지 않다.제품 해결 문제를 정의하고 기능의 일반적인 설명(그리고 전 단계의 모델도 많다)을 기재하면 된다.기술적인 상세한 내용은 FTD를 위해 미리 받아야 한다.

출전Product Hunt제품요구규격서
유명한 벤차트 캐피털 회사인 벤 호로위츠와 데이빗 위덴에 따르면 PRD는 제품 매니저가 관리하는 가장 중요한 문서로 마케팅, 디자인, 공정의 제품 성경이다.우수한 제품 매니저는 매일 또는 매주 PRD를 업데이트할 뿐만 아니라 PRD의 전체 과정을 지속성으로 간주한다.PRD는 절대 완전한 것이 아니라 팀의 교체에 따라 진화한 것이다.
Silicon Valley Product Group의 파트너인 Marty Cagan은 PRD의 4가지 주요 부분(목적 정의, 기능 설명, 발표 기준 설정, 대략적인 시기의 사생)에 대해 설명했고 다음과 같은 내용을 참고했다.Cagan에 따르면 PRD의 목적은'어떻게'가 아니라'무엇을 설명하는가'다.각 부분에서 풀어야 할 문제와 해법이 명확하지 않으면 팀이 잘못된 추측을 할 수도 있다.제품 솔루션을 설계하는 사람은 엔지니어, 설계자, UX 책임자입니다.PRD를 가이드가 아닌 레시피로 만들어서 화나게 하지 마세요.
I. 제품의 목적 파악
반드시 해결해야 할 사용자의 문제(해결 방안이 아님), 목표층(기업, 고객, 사용자), 각 층의 각종 용례는 반드시 토론해야 한다.
이전에도 많은 논의가 있었지만, 제품을 만들면서 재확인을 하지 않으면 개발 과정에서 길을 잃을 수도 있다.상위 1%의 제품 관리자와 상위 10%의 제품 관리자를 분리합니다기능의 균형이 반드시 요구될 때 팀이 추구하는 목적과 상하문을 이해해야 한다.

출처: Product Hunt 제품 요구 사항 문서
II. 제품의 특징을 기술하다.
기능 섹션은 PRD의 호스트입니다.
공정에 최대한 유연성을 제공하기 위해서는 상호작용 디자인과 사용자 확장을 설명해야 한다.더욱 중요한 것은 기능과 제품의 목적을 상대적으로 대응시키는 것이다.따라서 개발 과정에서 특정 기능을 잘라낼 때 비즈니스에 미치는 영향을 명확하게 파악할 수 있다.또 이러한 기능에 대한 순위 지정 일정 변경 시 또는 개발 과정에서 바꿔야 할 기능이 발견된 경우 우선순위를 설정할 수 있다.오늘날 가장 성공한 기업이 기능의 우선순위를 어떻게 결정하는지에 대해서는 UX 설계 프로세스 및 설명서를 보십시오.

출처: Product Hunt 제품 요구 사항 문서
III. 발표 기준의 개요
어떻게 제품이 베타 테스트용 발표를 할 준비가 되어 있는지 알 수 있습니까?이 섹션은 PRD에서 가장 기술적인 섹션입니다. 우리는 목표를 묘사했을 뿐 목표를 실현하는 수단을 묘사한 것이 아닙니다.다음 5개 영역에서 기준을 표시한다.
기능성 - 원시 기능에서 반드시 유지해야 할 기본 비율이 있습니까?절대적으로 필요한 기능은 무엇입니까?
용이성 - 프로그램의 외관이 아름다우니 사용자가 직관적으로 조작할 수 있습니까?모든 용례의 임무를 완성하기 전의 허용 시간은 얼마입니까?
신뢰성 - 최대 허용 고장률은?이런 고장들을 예측할 수 있습니까?시스템은 이런 고장에서 회복될 수 있습니까?
퍼포먼스. - 얼마나 걸려요?응답 시간, 처리량, 메모리 사용량의 최대치는?
지원 - 테스트 가능, 서비스 가능, 설치 가능 또는 구성 가능
발행 기준과 관련해서는 이른 시일 내 논의를 시작하고 논의를 거듭하는 것이 구축 단계에 가까워지면서 본격적인 것이 중요하다.이런 수요는 개발 초기 단계에서 관계자들이 토론하고 합의해야 한다.그렇지 않으면 제품 현황에 따라 기준을 설정한다.
IV. 제약조건 및 일정 설정
엄밀한 시기시장 변화에 따라 가능한 기능 담당에 얽매이는 것은 위험하다.대신 대략적인 일정을 짜서 유연성을 갖고 고객의 기대를 충족시키면 기능의 굼뜬 변화를 피할 수 있다.또한 업무 절차상의 제약 조건(예산과 자원 등)을 작성함으로써 시기에 영향을 주는 요소를 더욱 정확하게 파악할 수 있다.제약조건과 대략적인 날짜를 적으면 종료일자부터 역산해 각 기능에 실제 단거리 시간을 할당한다는 정보를 얻을 수 있다.
좋은 물건은 쓰고, 나쁜 물건은 버려라.
제품 개발은 현재 진행 중인 과정이기 때문에 단거리 경주에 사무적인 업무를 더하는 것을 가장 피하고 싶을 것이다.

출처: Feature Flow
그러나 혼돈 속에서 질서를 유지하기 위해서는 어느 정도의 문서화가 필요하다.철저하게 소상히 설명할 필요는 없지만, 누가 무엇을 하는지 어느 정도 알 필요가 있다.
제품 관리자가 보낸 사용자의 요구를 번역해야 합니다.서로 다른 기술 실체 간의 의존 관계를 이해해야 한다.또 변경을 정당화하기 위해서는 내부 및 외부 테스트의 피드백을 수집해야 한다.이런 작업의 틈틈이 "여러분은 어떻게 같은 페이지에 머무셨는지", "설정된 기간 내에 목표를 어떻게 이뤘는지"등 관련자들의 질문에 답할 필요가 있다.
제품 요구식 견본서는 최종 제품 테스트를 위한 발매일의 참고 자료 중의 하나다.
10년 이상 경력의 제품 매니저가 제작한Lean PRD 템플릿은 무료로 다운로드할 수 있다.
본 보도는 2014/12/15 투고, 2021/4/6 업데이트 번역입니다.