🔬디테일한 기획서의 문제 기획자라면 누구나 디테일한 기획서를 추구합니다. 그러면 뭔가 잘한 거 같고 생각을 많이 한 것 같은 느낌이 들어요. 협업 부서에서도 몇 백 장짜리 기획서를 보면 ‘얘가

🔬디테일한 기획서의 문제 기획자라면 누구나 디테일한 기획서를 추구합니다. 그러면 뭔가 잘한 거 같고 생각을 많이 한 것 같은 느낌이 들어요. 협업 부서에서도 몇 백 장짜리 기획서를 보면 ‘얘가 일 좀 했구나' 싶을 거예요. ✅ 그런데 디테일한 기획서가 항상 좋은 것은 아니라고 합니다. - 팀이 사고 과정을 기획자에게 외주 주게 만든다. - 팀이 스펙을 결정하는 데 참여하지 않게 된다. - 왜 그렇게 해야 하는가가 문서에 담기는 게 아니라 문서가 팀이 하는 일을 합리화해주게 된다. - ‘기획서에 없어서 안 만들었죠’ 분위기를 만든다. 저도 과거의 한 프로젝트 회고에서 '기획서가 너무 상세해서 참여의 여지가 없어 보이진 않았는지' 질문한 적이 있습니다. 저런 부작용을 경험했기 때문에 그랬던 것 같아요. 이런 문제들 때문에 이 아티클에서는 이제 전통적 의미의 기획서(PRD)를 쓰는 건 좀 구식인 것 같다며.. 그렇게 일하지 않는 세련된 회사들이 많다고 이야기합니다. 기획자(혹은 프로덕트 매니저)가 쓴 문서에 의존할 필요가 없지만, 그렇다고 극단적으로 항상 0에서 시작하는 것도 아닌 밸런스를 찾으면서요. ✅  모던한 기획서는 아래 요소를 포함한다고 합니다. 1. 맥락 - 뭘 만드냐, 왜 만드냐, 만들어졌을 때 무슨 일이 생기느냐 2. 범위 - 첫 이터레이션에는 무얼 만드냐 3. 백로그 - 기능 요구사항은 뭔가 - 에픽(구현을 위한 일감의 묶음 단위) - 유저스토리(프로토타입과 함께) 이 아티클에서 심플한 예시 문서들과 툴들을 모두 링크, 스크린샷과 함께 소개하고 있습니다. 각각이 무얼 말하고 어떻게 활용되는 것인지 궁금하다면 이미지들만 훑어보셔도 될 것 같습니다. 기획서를 빡빡하게 쓰는 게 일잘이 아니라는 거, 기획서가 담아야 할 코어는 지키되 나머지는 팀이 함께 제품을 만들어가도록 적절한 도구와 기술을 적용해야 한다는 걸 리마인드 해봅니다.