PM/PO를 위한 제품 스펙 및 인수 조건 작성법
제품 스펙은 왜 그리고 어떻게 작성되어야 하는가?
스타트업의 생명은 빠른 실행과 실험이라고 흔히들 이야기합니다. 같은 측면에서, 스타트업에서 어떠한 제품을 런칭 또는 기능을 개선한다고 가정했을 때 제품 스펙의 작성이 꼭 필요한가? 에 대한 의문도 자주 제기되는 것 같습니다. 물론 규모가 아주 작거나, 1인 스타트업인 경우에는 구체적인 제품 스펙이나 인수 조건의 작성 없이도 일의 추진이 원활히 가능할지 모릅니다. 오히려 더 속도를 낼 수 있을 테고요. 하지만 함께 일하는 이해관계자가 적지 않고, 제품이나 서비스가 일정 수준 이상으로 고도화되었다면 그때부터는 제품 스펙의 작성이 필연적일 수 있습니다.
https://buildd.co/product/product-specification필연적이라고 표현한 이유는 다음과 같아요.
우선, 함께 일하는 이해관계자들이 공동의 목표와 방향을 이해하고 이를 달성하기 위해 사전에 인지하고 있어야 할 위험 요소를 파악할 수 있기 때문입니다. 사전 논의 없이 되는 대로 달려 나가다 보면 예상 못한 장애물을 맞닥트려 도리어 일의 진척이 늦어질 수 있고, 심지어는 배포 후 치명적인 결함을 발견하게 될 수도 있습니다. 이런 끔찍한 사태를 미연에 방지할 수 있다는 것만으로도 이유가 될 수 있을 거예요.
두 번째는 커뮤니케이션 비용을 줄일 수 있다는 이점입니다. 하나의 기능을 개선한다고 가정해 볼게요. 현재 어떤 문제가 있고, 어떤 문제를 해결해야 하며(목표), 이 문제의 원인은 무엇으로 예상되고(가설), 이 문제를 해결하기 위해 생각해야 할 전제 조건에는 어떤 것들이 있으며(제약), 어떤 솔루션이 가장 적합한 해결 방법일지에 관해 프로젝트 시작 전 미리 소통하고 이를 문서화한다면 이해관계자들이 각자 머릿속으로 그리고 있는 방향성을 조율하는 데 큰 도움이 될 겁니다. 추후 불필요한 소통 비용도 줄어들 테고요. 만약 앞의 단계가 생략된다면 어떤 사고가 터질지 누구도 보장할 수가 없고, 운이 좋아 사고가 터지지 않는다 하더라도 계속해서 슬랙 또는 구두로 비효율적인 소통이 발생하겠죠.
세 번째는 팀이나 조직의 제품 개발 문화를 위함입니다. 조직이 커진다는 것은 제품의 성장이나 고도화를 뜻하기도 하지만, 그만큼 팀의 인원이 증가함을 말하기도 합니다. 그동안 제품이 어떻게 개발되어 왔는지 그 변천사를 모두 겪어온 구성원들도 있겠지만, 그 구성원들이 퇴사하거나 이동하게 되면 히스토리가 모두 유실되는 상황이 발생할 수 있습니다. 신규 입사자들에게 경험 공유나 지식 전파도 어려울 테고요. 장기적인 관점에서 제품 스펙 등의 문서화는 오히려 개발 속도를 저하시키는 것이 아닌, 향상시키는 방향이 될 수 있습니다.
제품 스펙은 어떻게 작성되어야 할까?
팀마다 일하는 방식이 다르기에 일원화될 필요는 없지만, 기본적으로 제품 스펙을 작성할 때는 1-pager와 유사한 형태로 써 내려가는 것이 좋습니다. 문서화 시에는 협업하는 팀원이 읽고 확인하기 쉬운 도구로 작성해야 합니다.
1. 문제 정의 (Problem Statement)
문제는 누구나 이해할 수 있는 문장으로 최대한 간결하고 명확하게 정의합니다.
2. 가설 (Hypothesis)
문제가 발생하는 이유나 원인에 대해 기술합니다.
그리고 이러한 가설을 세우게 된 배경이나 데이터를 제시합니다.
3. 목표 (Success Metrics)
문제 해결과 맞닿아있는, 측정 가능한 정량적 목표를 수립합니다.
정량화할 수 없는 정성적 목표도 함께 기술하면 좋습니다.
4. 해결책 (Solution)
문제를 해결할 수 있을 것으로 기대되는 해결 방안을 작성합니다.
5. 걱정점 (Concern)
이 해결책이 기술적으로 구현 가능한 범주인지, 예상되는 부수 효과(사이드 이펙트)는 없는지 개발 관점에서의 걱정점을 추론해 봅니다.
이 해결책으로 인해 영향을 받을 다른 기능 또는 지표가 없는지 기획 관점에서의 걱정점을 추론해 봅니다.
6. 타임라인 (Timeline)
해당 솔루션이 구축되는 데까지 필요한 작업들의 일정을 추산합니다.
예상 일정은 상황에 따라 조정될 수 있습니다.
제품 스펙은 우선 담당 PM/PO 또는 기획자가 작성하며, 작성한 초안을 기반으로 함께 일하는 이해관계자(운영팀, 개발자 누구든 될 수 있습니다.) 들과 모여 미팅을 가지게 됩니다. 이야기를 나누다 보면 기술적 제약 사항 또는 한정적인 개발 기간으로 인해 일의 진행 방향이 조정되는 경우가 자주 발생합니다. 뿐만 아니라, 해당 기능과 연관된 이해관계자들이 우려하는 예외 사항(엣지 케이스)들을 걱정점이나 전제 조건에 포함시킬 수 있기 때문에 기획적으로도 더 탄탄한 구성이 됩니다.
이러한 논의를 통해 스펙을 수정하고 픽스 후 공유하면 이후에 발생될, 사실은 예견되었던 문제들을 방지할 수 있습니다.
유저 스토리와 인수 조건 작성법
유저 스토리는 말 그대로 유저 스토리이므로, 사용자 관점에서 작성되어야 하는 것은 맞습니다. 일반적으로 위와 같은 방식으로 유저 스토리가 많이 활용되는 것을 보셨을 거예요.
“나는 [~누구]로서, [~어떤 행동을]함으로써, [어떤 목적]을 달성하길 원한다”와 같은 방식인데요.
유저 스토리의 미덕은 구체적인 How to 가 없다는 것에 있는 것 같아요. 문제에 집중해서, 이를 무엇을 통해, 왜 하길 원하는지에 초점이 맞춰져 있는 구조인데요. 문제 해결의 본질을 잃어버리지 않고, 제품을 사용할 사용자에 집중할 수 있다는 장점 그리고 일상적인 언어를 사용해 표현하기 때문에 이해관계자 전원이 쉽게 이해할 수 있다는 장점이 있습니다.
https://twitter.com/kickstartpros/status/524414603359686657하지만 유저 스토리 작성 이후 단계에는 Given-When-Then 관점에서 고민이 필요합니다. 이 패턴은 테스트 코드 작성 시 또는 테스트 케이스 작성 시에도 활용하는 방법입니다. 최근 한 프로젝트를 진행하며 개발 팀과 일을 할 때 기존의 테스트 케이스 양식을 활용하지 않고, GWT 방식을 적용해 보았더니 QA 시간을 크게 단축시킬 수 있었습니다.
예를 들어,
“로그인 유저는 수강바구니에서 특정 결제 수단으로 강의를 구매할 수 있다.”라는 유저 스토리가 있다고 가정하면, 이를 아래과 같은 조건 명세로 치환할 수 있습니다.
Given : 로그인 유저는 수강바구니 페이지에서 (로그인 유저 > 수강바구니 페이지)
When : 특정 결제 수단을 선택하고 (특정 결제 수단 선택)
Then : 결제를 완료한다. (결제 완료 페이지 발생)
여기서 Given은 곧 상태(전제 조건), When은 행동, Then은 결과를 의미합니다. 유저 스토리에 적힌 내용은 결과적으로 실제 구현이 될 내용이기 때문에 기능 명세 형태로의 작성이 요구됩니다. 이때, 위의 방식을 활용하면 이 유저 스토리를 만족시켰다고 판단할 수 있는 구체적인 방법(조건)이 생기는 셈입니다.
인수 조건(Acceptance Criteria)
인수 조건을 작성하는 이유는 크게 두 가지로 나뉘는 것 같아요. 스토리를 만족시키기 위한 요구사항을 구체적으로 나열함으로써 개발 팀의 작업이 필요한 범위를 설정하려는 목적도 있지만, 이 스토리의 달성 여부를 판가름하는 기준이 될 수 있기 때문인데요.
특정 기능 개선을 한다고 가정했을 때, 해당 유저 스토리가 성공적으로 구현했는지 판가름할 수 있는 정확한 기준이 없다면 프로젝트의 불확실성이 비약적으로 증가할 수밖에 없을 거예요. 그렇기 때문에 PM/PO 또는 기획자가 인수 조건을 작성하고, 이를 개발 팀과 함께 리뷰하는 과정이 필요합니다. 앞서 말씀드렸듯, 기준이 있어야 하기에 테스트 가능한 형태로(Pass 또는 Fail) 쓰여야 합니다. 그렇기 때문에 위해서 이야기한 GWT 역시 인수 조건을 작성할 때 사용되는 하나의 방법이기도 합니다.
로그인 유저는 수강바구니에서 특정 결제 수단으로 강의를 구매할 수 있다.”라는 유저 스토리가 있다고 가정했을 때, 인수 조건은 아래와 같이 작성해 볼 수 있습니다.
AC-1 : 수강바구니 페이지에 B2C 유저 대상으로 지원하는 결제 수단 목록을 모두 노출한다.
AC-2 : 유저가 특정 결제 수단을 선택했을 경우, 결제하기 버튼을 클릭할 수 있다.
AC-3 : 유저가 결제 수단을 선택하지 않았을 경우, 결제하기 버튼을 비활성화한다.
인수 조건 작성 시 유의해야 할 점
1. 인수조건 = 특정 스토리를 달성했는지 판단할 수 있는 요구사항의 집합
그렇기 때문에, 프로덕트 팀이 이해할 수 있는 명확한 용어로 작성되어야 합니다. 모두가 이해할 수 있는 용어로 작성된다는 것은, 통일성 있고 일관된 용어를 사용해야 한다는 뜻인데요. 하나의 대상에 대해, 작성된 인수 조건마다 용어의 언급이 달라진다면 읽는 이로 하여 혼란을 줄 수 있기 때문에 지양해야 하는 방향입니다.
2. 이해관계자가 함께 리뷰해야 합니다.
대부분 PM/PO 또는 기획자가 인수 조건을 작성하게 되는데, 1차적인 작성은 이들이 하더라도 리뷰와 검수는 해당 프로젝트를 진행하는 이해관계자들이 함께 해야 합니다. 마치 개발자가 PR로 코드 리뷰를 받듯이요. 리뷰하는 과정에서 오 작성된 내용이나 모호한 정의가 발견되기도 하기 때문인데요. 운이 좋다면 이 과정에서 흔치 않은 엣지 케이스도 발견할 수 있습니다.
마무리
오늘은 제품 스펙 및 인수 조건에 대해 간략하게 작성해 보았습니다. 사실 프로젝트의 규모나 팀이 일하는 방식에 따라 작성 방식은 달라질 수 있기 때문에 무조건적인 정답이라 보기는 어렵습니다. 위의 방식을 활용해 스펙을 잡고 인수 조건을 작성하더라도 어떤 툴을 활용해서 공유하느냐, 제품 개발 범주 내에서도 어떤 단계까지 적용해 볼 수 있느냐는 달라질 수 있는 부분인데요. 이러한 실험은 다양한 조직에서 진행되고 있는 것으로 알고 있습니다. 관련해서 더 좋은 아이디어나 의견이 있다면 함께 성장할 수 있도록 공유해 주세요!
감사합니다.
