💦 나만 모르는 프로덕트 관리 이야기 [🤜 함께 만드는 기준, 프로덕트 스펙 문서 작성법] (👀간단 요약) 서사적으로 구성된 6페이지 메모를 쓰고도 명확한 생각을 가지지 않을 수는 없다 - 제프 베조스 효과적인 스펙 문서는 훌륭한 소프트웨어를 만드는 과정에서 결정적 역할을 한다. 개발 초기부터 비판적 사고를 하게끔 하고, 커뮤니케이션을 효율화하며, 책임 소재를 분명히 함으로써 높은 품질, 일정 리스크 축소, 시간 낭비 최소화에 기여하기 때문이다. 📌초기 단계의 스펙 문서 작성법 ✓ 문제 정의 ✓ 목표 설정 ✓ 필요 정보 리서치 ✓ 성공 기준 ✓ 실험 기준 ✓ 기타 내용 약 1시간 정도 시간을 잡고 혼자 조용한 곳에서 작성한다. 이 문서가 팀 구성원과 논의를 진행하기 위한 기본 자료가 된다. 📌스펙 문서 ✓ 문제 : 풀고 싶은 문제를 정리 중요한 것은 왜 다뤄져야 하는지를 설명하는 것 ✓ 측정 가능한 목표 : 우리가 이걸 달성했나? 라는 질문에 답변할 수 있도록 ✓ 상황 : 제안 사항에 동의할 수 있게끔 근거를 제공 ✓ 상세 해결방안 : 팀에서 보고 실행할 수 있을 정도로 자세히 기입 ✓ 일정 : 날짜별 마일스톤을 함께 작성. 1시간에서 3시간 정도의 시간을 두고 초기 단계 스펙 문서를 더 구체적으로 작성한다. 📌왜 써야 하는지? ✓ 초기부터 비판적 사고를 하게끔 한다. ✓ 커뮤니케이션을 효율적으로 할 수 있게 한다. ✓ 책임 소재를 분명히 한다. 📌어떻게 써야 하는지? ✓ 초안을 작성한다. (1-2시간) ✓ 두어 번의 30분짜리 1:1 미팅을 잡는다 (1-4시간) ✓ 스펙 문서를 작성하고 수정한다 (0.5-3일) ✓ 문서를 공유하고 미팅 준비 ✓ 스펙 리뷰 미팅 ✓ 티켓 생성 📌효율적인 작성 방법 ✓ 짧게 쓰기 ✓ 명확한 어휘와 단순한 포맷 사용 ✓ 개발팀 일정 보다 앞서서 작성 ✓ 개발자 관점에서 생각 ✓ 모두 참여할 수 있게 하기 ✓ 시각화에 대해 고민하기 ✓ 생각하고 쓰는 데 0.5-3일만 쓰기 ✓ 방향과 비전 제시하기 ✓ 읽히도록 만들기 ✓ 솔직한 피드백 받기 (👋중요한 이유가 뭔가요?) 요즘 PM, PO에 대한 이야기가 정말 많이 들려요. 기획자의 확장판(?) 아니냐. 신입도 충분히 할 수 있는 것 아니냐 등등. 그런데 사실 실리콘밸리에는 개발자 출신의 PM들이 더 많아요. 본문에도 포함된 내용 중 하나지만 개발자 관점에서 생각하라는 건, 비효율적인 커뮤니케이션을 줄이고, 일이 되게 만드는 과정을 더 단단히 만들란 얘기와도 같은데요. 비개발자 출신이 프로덕트를 관리하고 구성원들을 올바른 방향으로 나아갈 수 있게 기준을 잡아주는 건 정말 쉽지 않고, 그 출발점에서 스펙 문서는 상당히 중요한 역할을 할 수 있습니다. 저 역시 스펙 문서를 조직과 업무 스타일에 따라 변형해 계속 활용하고 있어요. 이와 더불어 활용하는 건 기능 업데이트 등 서비스 고도화 마다 사용 되는 스펙 문서 외 회사의 비전, 우리가 그동안 만들어온 기능들, 사용자들의 전반적인 피드백, 사용자 경험의 일관성 등 우리가 긴 호흡을 하며 놓치지 말아야 할 기준들이 정리된 문서에요. 이 문서를 프로덕트에 관여하는 구성원들과 함께 만들어 기준으로 삼고, 각 프로젝트 진행 시 스펙 문서를 덧붙여 비효율적인 것들을 미리 잘라 냅니다. 위의 스펙 문서 작성법이 꼭 정답은 아니에요. 하지만 분명한 사실 중 하나는, 매 번 방향이 달라지는 커뮤니케이션을 미연에 방지할 수 있도록 하는 것도 PM, PO의 중요한 역할 중 하나라는 것입니다. 그래서 우리만의 '기준'이 필요하고, 그 기준에 필요한 장치 중 하나가 스펙 문서라고 생각해요. 스펙 문서를 작성하면 뭐하나, 읽지를 안는데! 라고요? 그럼 읽게 만들어야죠. 저는 그런 분위기가 만들어지지 않을 경우 인쇄를 해서 노트북 대신 펜 하나씩 들고 주변 카페로 간 적도 몇 번 있어요. 거기서 10-15분 정도 같이 읽고 한 번씩 확인해야 할 내용들을 각자 정리해서 돌아가며 말하고 논의하고 정리하고. 작성하고, 읽게 하고, 피드백을 받아 수정하는 등의 과정을 다를 수 있지만 그렇게 만들어진 결과물은 프로젝트를 진행하는데 있어 늘 도움이 되었지 피해가 된 적은 없었습니다.