💦 나만 모르는 프로덕트 관리 이야기 [✏️ PM/PO를 위한 제품 스펙 및 인수 조건 작성법] (👀간단 요약) ✓ 함께 일하는 이해관계자가 적지 않고, 제품이나 서비스가 일정 수준 이상으로

💦 나만 모르는 프로덕트 관리 이야기 [✏️ PM/PO를 위한 제품 스펙 및 인수 조건 작성법] (👀간단 요약) ✓ 함께 일하는 이해관계자가 적지 않고, 제품이나 서비스가 일정 수준 이상으로 고도화되었다면 ✓ 그때부터는 제품 스펙의 작성이 필연적일 수 있음 📌 제품 스펙 작성이 필요한 이유 ✓ 이해관계자들이 공동의 목표와 방향을 이해하고 이를 달성하기 위해 사전에 인지하고 있어야 할 위험 요소를 파악 ✓ 사전 논의 없이 되는 대로 달려 나가다 보면 예상 못한 장애물을 맞닥트려 도리어 일의 진척이 늦어질 수 있음 ✓ 커뮤니케이션 비용을 줄일 수 있다는 이점 ✓ 어떤 문제가 있고, 어떤 문제를 해결해야 하며(목표), 이 문제의 원인은 무엇으로 예상되며 ✓ 문제를 해결하기 위해 생각해야 할 전제 조건과(제약), 어떤 솔루션이 가장 적합한 해결 방법일지 ✓ 미리 소통하고 이를 문서화한다면 이해관계자들이 각자 머릿속으로 그리고 있는 방향성을 조율하는 데 큰 도움 ✓ 팀이나 조직의 제품 개발 문화 ✓ 장기적인 관점에서 제품 스펙 등의 문서화는 오히려 개발 속도를 저하시키는 것이 아닌, 향상시키는 방향 📌 제품 스펙 문서 작성 방법 ✓ 기본적으로 제품 스펙을 작성할 때는 1-pager와 유사한 형태로 작성하는 것이 좋음 ✓ 문서화 시에는 협업하는 팀원이 읽고 확인하기 쉬운 도구로 작성해야 ✓ 제품 스펙은 우선 담당 PM/PO 또는 기획자가 작성 ✓ 작성한 초안을 기반으로 함께 일하는 이해관계자(운영팀, 개발자 누구든 될 수 있습니다.) 들과 모여 미팅 ✓ 기술적 제약 사항 또는 한정적인 개발 기간으로 인해 일의 진행 방향이 조정되는 경우가 자주 발생 ✓ 해당 기능과 연관된 예외 사항을 걱정점이나 전제 조건에 포함시킬 수 있기 때문에 기획적으로도 더 탄탄한 구성 📌 문제 정의 (Problem Statement) ✓ 문제는 누구나 이해할 수 있는 문장으로 최대한 간결하고 명확하게 정의 📌 가설 (Hypothesis) ✓ 문제가 발생하는 이유나 원인에 대해 기술 ✓ 이러한 가설을 세우게 된 배경이나 데이터를 제시 📌 목표 (Success Metrics) ✓ 문제 해결과 맞닿아있는, 측정 가능한 정량적 목표를 수립 ✓ 정량화할 수 없는 정성적 목표도 함께 기술 📌 해결책 (Solution) ✓ 문제를 해결할 수 있을 것으로 기대되는 해결 방안을 작성 📌 걱정점 (Concern) ✓ 기술적으로 구현 가능한 범주인지, 예상되는 부수 효과(사이드 이펙트)는 없는지 개발 관점에서의 걱정점을 추론 ✓ 영향을 받을 다른 기능 또는 지표가 없는지 기획 관점에서의 걱정점을 추론 📌 타임라인 (Timeline) ✓해당 솔루션이 구축되는 데까지 필요한 작업들의 일정을 추산