Showing Posts From

선배

선배 기획서를 보고 배운 것들 (공식으로는 배우지 못했던)

선배 기획서를 보고 배운 것들 (공식으로는 배우지 못했던)

온보딩 자료는 2페이지 입사했다. 온보딩 자료를 받았다. 2페이지다. "우리 회사 서비스 소개" "기획자 업무 프로세스" 끝. 사수가 말했다. "일단 이것저것 보면서 익혀봐." 뭘 봐야 하는데? 첫 주는 그냥 선배들 회의 듣고, 노션 페이지 구경하고, 슬랙 채널 둘러보는 게 다였다. 월급은 나가는데 뭘 하는 건지 모르겠다.노션 폴더를 뒤진다 할 게 없어서 노션을 뒤졌다. "기획서 아카이브" 폴더를 찾았다. 들어가 봤다. 와. 2년치 기획서가 있다. 50개는 넘는다. 선배가 쓴 기획서. 대표님이 쓴 초기 기획서. 심지어 안 된 프로젝트 기획서도 있다. 이게 교과서구나. 첫 번째 파일을 열었다. "회원가입 개편 기획서 v3.final.최종.진짜최종" 웃겼다. 근데 내용은 진지했다. 목차부터 달랐다 학교 과제 목차:서론 본론 결론선배 기획서 목차:배경 및 목적 현황 분석 개선 방향 상세 기획 예상 이슈 일정 및 리소스아. 이렇게 쓰는 거구나. 특히 "예상 이슈" 파트가 신기했다. 아직 안 만들었는데 이슈를 미리 쓴다고? 예상 이슈 - 개발: 기존 DB 마이그레이션 2주 소요 - 디자인: 3단계 인증 화면이 복잡해 보일 수 있음 - CS: 기존 회원 재가입 문의 예상미래를 예측하는 거였다. 문제를 먼저 말해두는 거. 회의에서 개발자가 "이거 안 돼요" 할 때, "네, 그래서 대안으로 B안을 준비했습니다" 하는 거. 나는 그냥 얼어붙는데.문장이 짧다 선배 기획서를 읽는다. 문장이 짧다. 내가 쓴 기획서: "본 기능은 사용자가 더욱 편리하게 상품을 검색할 수 있도록 필터 기능을 개선하여 사용자 경험을 향상시키고자 하는 목적으로 기획되었습니다." 선배 기획서: "검색 필터를 개선한다. 사용자가 원하는 상품을 빠르게 찾게 한다." 끝. 한 문장에 한 가지만 말한다. 주어, 동사, 목적어. "하고자 하는 목적으로" 같은 말은 없다. "함으로써" 같은 것도 없다. 그냥 한다. 개선한다. 추가한다. 삭제한다. 명확하다. 개발자가 읽었을 때, "이거 뭔 소리야?" 할 일이 없는 거다. 나는 그동안 뭘 쓴 거지. 스크린샷이 많다 선배 기획서는 스크린샷이 많다. 거의 모든 페이지에 있다. "현황" 파트: 경쟁사 앱 스크린샷 6개. 우리 앱 현재 화면 4개. 문제점에 빨간 박스 표시. "개선안" 파트: 와이어프레임. 실제 구현된 다른 서비스 예시. "이런 느낌으로" 레퍼런스. 말보다 이미지. 처음에는 귀찮아서 안 넣었다. "말로 설명하면 되지" 했다. 틀렸다. 사수가 피드백했다. "이거 화면 어떻게 되는 건지 보여줘." 말로 10분 설명할 거, 이미지 하나면 10초다. 지금은 스크린샷부터 찍는다.숫자가 구체적이다 내 기획서: "많은 사용자가 이탈합니다." 선배 기획서: "회원가입 1단계에서 42%가 이탈합니다. (지난 달 기준 1,247명)" 구체적이다. "빠르게"가 아니라 "3초 이내". "자주"가 아니라 "주 2회 이상". "많은"이 아니라 "전체의 23%". 숫자를 찾아야 한다. GA를 열어본다. 데이터팀에게 물어본다. 없으면 "추정"이라고 쓴다. "추정 20% (경쟁사 A 사례 기준)" 이렇게라도 쓴다. 숫자가 있으면 회의가 달라진다. "이게 문제인가요?"가 아니라, "42%를 30%로 줄이려면?"으로 시작한다. 목표가 생긴다. 대안이 있다 선배 기획서에는 항상 대안이 있다. A안, B안, C안. A안: 이상적. 개발 4주. 리소스 많이 듦. B안: 현실적. 개발 2주. 핵심 기능만. C안: 최소. 개발 3일. 임시방편. 회의 때 본다. 대표님이 묻는다. "이거 다음 주까지 되나요?" 선배가 답한다. "A안은 어렵고, C안으로 먼저 하고 A안은 다음 분기에 하죠." 대안이 있으니까 협상이 된다. 나는 대안이 없었다. "안 되면 어떡하죠?" 만 했다. 지금은 A, B, C를 먼저 쓴다. 회의 전에. 왜 하는지를 쓴다 초반에 내 기획서: "푸시 알림 기능을 추가합니다." 사수 피드백: "왜?" "...사용자가 편하게?" "그게 왜 지금 필요한데?" 대답 못 했다. 선배 기획서를 본다. 배경 및 목적배경: - 재방문율이 18%로 경쟁사 대비 낮음 (경쟁사 평균 32%) - 이벤트 공지를 놓치는 사용자 클레임 주 5건 이상 - 앱 푸시 허용률은 67%로 양호함목적: - 재방문율 18% → 25% 달성 - 이벤트 참여율 12% → 20% 증가Why가 먼저다. What은 그다음이다. "이게 필요해서"가 아니라, "이 문제를 해결하려고"다. 지금은 "배경 및 목적"부터 쓴다. 이게 명확하지 않으면 아래를 안 쓴다. 리스크를 먼저 말한다 예전엔 장밋빛만 썼다. "이렇게 하면 좋아질 겁니다!" 선배 기획서는 다르다. 리스크 - 개인정보 수집 동의 추가 필요 → 법무 검토 1주 - iOS 심사 시 리젝 가능성 30% (유사 사례 확인됨) - 푸시 차단 사용자는 혜택 없음 → 형평성 이슈미리 말한다. 문제를 숨기지 않는다. 회의 때 누가 "이거 법적으로 괜찮아요?" 물으면, "네, 법무팀 검토 요청했습니다. 다음 주 결과 나옵니다." 준비된 사람. 나는 "아 그건... 확인해보겠습니다" 했다. 준비 안 된 사람. 리스크 파트를 쓰면서 배운다. 기획은 좋은 것만 말하는 게 아니다. 나쁜 것까지 준비하는 거다. 일정을 역산한다 내 초기 기획서: "개발: 4주" 사수: "왜 4주야?" "...그냥요?" 틀렸다. 선배 기획서: 개발 일정 (총 4주)1주차: 기획 확정 및 디자인 (5일) 2주차: API 개발 (5일) 3주차: 화면 개발 및 연동 (5일) 4주차: QA 및 수정 (3일), 배포 (2일)여유 기간: 없음 리스크: QA에서 이슈 발생 시 일정 지연 가능쪼갠다. 역산한다. 배포일부터 거꾸로 센다. 그리고 개발자한테 물어본다. "이거 2주 안에 되나요?" 혼자 쓰는 게 아니다. 실패한 기획서도 본다 아카이브에 "보류" 폴더가 있다. 안 된 프로젝트들. 궁금해서 열어봤다. "커뮤니티 기능 기획서" 상태: 보류 사유: 리소스 부족, 우선순위 밀림 내용은 좋았다. 기획도 탄탄했다. 근데 안 됐다. 댓글이 있었다. "좋은 기획인데, 지금은 아니다. 내년에 다시 검토." 아. 좋은 기획도 안 될 수 있구나. 타이밍이 중요하구나. 실패 사례를 보면서 배운다. "이러면 안 되는구나." 성공 사례만 보면 착각한다. "이렇게 하면 되는구나." 둘 다 봐야 한다. 그래서 나는 선배 기획서를 출력했다. 5개 골랐다. 잘 쓴 것들. 형광펜 들고 분석한다.목차 구조: 노란색 좋은 문장: 파란색 데이터 쓰는 법: 초록색 리스크 쓰는 법: 빨간색내 양식을 만든다. 선배 걸 베끼는 게 아니라, 구조를 배끼는 거다. 이제 기획서 쓸 때, 백지에서 시작 안 한다. 템플릿을 연다. 선배한테 배운 구조. 채운다. 여전히 부족하다. 사수한테 혼난다. "이거 왜 이렇게 했어?" 근데 예전보단 낫다. 3개월 전에는 "기획서를 어떻게 쓰는지" 몰랐다. 지금은 "뭘 더 써야 하는지" 안다. 다르다. 회사는 학교가 아니다. 누가 앉혀서 안 가르쳐 준다. 온보딩 자료는 2페이지다. 나머지는 내가 찾는 거다.선배 기획서가 제일 솔직한 교과서다. 실전이 여기 다 있다.