Showing Posts From

기획서는

왜 기획서는 계속 수정될 수밖에 없나

왜 기획서는 계속 수정될 수밖에 없나

왜 기획서는 계속 수정될 수밖에 없나 오늘도 기획서를 고친다 출근했다. 슬랙 알림 37개. "K님, 어제 회의에서 말씀하신 플로우인데요, 이거 로그인 없이도 가능한 거 맞죠?" 아니다. 로그인 필수라고 했다. 분명히. 회의록 찾아봤다. 내가 잘못 적었다. 로그인 "선택"이라고 적혀 있다. 기획서 열었다. v2.3이다. 수정한다. v2.4가 된다. 9시 반인데 벌써 첫 수정이다.어제 대표님이 말했다. "이 기능, 경쟁사는 이렇게 하던데요?" 경쟁사 앱 켰다. 확인했다. 우리랑 다르다. 대표님: "우리도 이렇게 가는 게 어때요?" 나: "...검토해볼게요." 기획서 수정. v2.5. 오전 10시. 완벽한 기획서는 왜 없나 신입 때는 몰랐다. "기획서 완벽하게 작성하면 수정 안 하겠지." 6년 차가 되어서 안다. 불가능하다. 이유는 세 가지다. 첫째, 사람은 글보다 화면을 보고 의견이 바뀐다. 기획서 단계: "네, 좋습니다." 디자인 시안 단계: "근데 이거 좀 이상한데요?" 개발 완료 단계: "이거 아닌 것 같은데요." 당연하다. 인간은 시각적 동물이다. 글로 "버튼이 우측 하단에 위치"라고 쓰면 모두가 상상한다. 각자 다른 버튼을. 시안이 나오면 그제야 의견이 나온다. "생각보다 크네요", "색이 튀네요", "위치가 애매한데요". 개발자는 더하다. "이거 스크롤 안에 고정인가요, 밖에 있나요?" 기획서에 분명히 적었다. 하지만 각자 해석이 다르다. 수정한다. v2.6.둘째, 요구사항은 살아 움직인다. 월요일: 마케팅팀 "이벤트 배너 하나만 넣어주세요." 화요일: 마케팅팀 "배너 두 개로 늘려주세요." 수요일: 마케팅팀 "배너 슬라이드 형식으로요." 목요일: 마케팅팀 "자동 재생 되게요." 나: "..." 기획서는 그때마다 바뀐다. v2.7, v2.8, v2.9. 개발자가 묻는다. "스펙 확정된 거죠?" 나: "네, 확정이에요." 금요일: 마케팅팀 "배너 클릭하면 팝업이 뜨게..." 나: "..." 개발자: "..." 이게 현실이다. 셋째, 내가 놓친 게 있다. 기획서 쓸 때는 완벽하다고 생각한다. 모든 케이스를 다 적었다. 개발 들어간다. 개발자가 묻는다. "인터넷 끊겼을 때는요?" "동시에 두 명이 수정하면요?" "글자 수 제한은요?" "특수문자 입력은요?" "iOS랑 안드로이드 다르게 가나요?" 아. 생각 못 했다. 기획서 수정. v2.10, v2.11, v2.12. 그럼 처음부터 완벽하게 쓰면 되지 않나 안 된다. 시도해봤다. 신입 때. 기획서 50페이지 작성했다. 모든 예외 케이스 적었다. 엣지 케이스까지. 검토 회의 잡았다. 1시간 예정. 5분 만에 끝났다. 대표님: "너무 길어요. 핵심만 보여주세요." 개발자: "이거 다 읽을 시간 없는데요." 디자이너: "화면 정의서만 주시면 안 돼요?" 50페이지 기획서. 아무도 안 읽었다. 다시 썼다. 10페이지로. 핵심만. 질문이 쏟아졌다. "이 경우는요?", "저 경우는요?" 답했다. 기획서 수정했다. v1.1, v1.2, v1.3... 결론: 처음부터 완벽한 기획서는 불가능하다.그럼 어떻게 써야 하나 깨달았다. 3년 차쯤. 기획서는 "문서"가 아니다. "대화"다. 버전 1.0은 시작점이다. 완성본이 아니다. 중요한 건 두 가지다. 하나, 핵심은 흔들리지 않게. 수정되어도 괜찮은 것:UI 디테일 (버튼 위치, 색상, 크기) 텍스트 문구 예외 케이스 처리 방식 인터랙션 세부사항흔들리면 안 되는 것:이 기능의 목적 타겟 유저 해결하려는 문제 핵심 플로우예를 들어. 우리가 만드는 건 "쉬운 결제 기능"이다. 이건 안 바뀐다. 하지만 "결제 버튼이 파란색이냐 빨간색이냐"는 바뀔 수 있다. "카드 정보를 저장하느냐 마느냐"도 바뀔 수 있다. 하지만 "쉬운 결제"라는 목적은 안 바뀐다. 기획서 첫 페이지에 적는다. 목적: 3번의 탭으로 결제 완료 타겟: 40대 이상 비결제 전환 유저 문제: 현재 평균 7번의 탭 필요, 중간 이탈률 60% 성공 지표: 평균 탭 수 3회 이하, 이탈률 30% 이하이건 회의 때마다 보여준다. 누가 뭐라고 해도 이걸 기준으로 판단한다. "버튼 색 바꾸자" → 탭 수에 영향 없다 → OK "추가 인증 넣자" → 탭 수 늘어난다 → NO 명확해진다. 둘, 수정 이력을 남긴다. Confluence 쓴다. 버전 히스토리 남는다. 중요한 변경은 코멘트 단다. v2.4 → v2.5: 로그인 필수에서 선택으로 변경 사유: 테스트 유저 피드백, 비로그인 전환율 2배 높음 영향: 개발 공수 3일 추가, 릴리즈 일정 유지 가능 승인: 대표님, 개발팀장이렇게 적으면 나중에 "왜 이렇게 했죠?"라는 질문에 답할 수 있다. 히스토리가 있으면 신뢰가 생긴다. "K님 기획서는 변경 사유가 명확해요." 이 말 들으면 기분 좋다. 수정은 실패가 아니다 예전에는 기획서 수정할 때마다 자괴감 들었다. "내가 기획을 못하나." "처음부터 왜 이걸 생각 못 했지." "개발자한테 미안하다." 지금은 안다. 수정은 당연하다. 수정이 없는 기획서는 두 가지다.아무도 안 읽는 기획서 아무도 관심 없는 기능수정이 많다는 건 사람들이 관심 있다는 거다. 의견이 나온다는 건 함께 만들고 있다는 거다. 물론 한계는 있다. 개발 들어간 후 핵심 플로우 변경: 안 된다. 대표님이 갑자기 다른 기능 추가: 우선순위 논의 필요. 마케팅팀이 매일 배너 스펙 변경: 한 번에 정리하자고 말한다. 경계는 그어야 한다. 하지만 유연해야 한다. 균형이다. 지금도 기획서를 고친다 오늘 오후 4시. 디자이너가 묻는다. "이 버튼, 비활성 상태 디자인 있나요?" 기획서 본다. 없다. 추가한다. v2.16. 오후 5시. 개발자가 묻는다. "에러 메시지 문구 뭐로 할까요?" 기획서 본다. 대충 적혀 있다. "오류가 발생했습니다." 구체적으로 수정한다. "네트워크 연결을 확인해주세요." v2.17. 오후 6시. QA팀에서 이슈 올린다. "로딩 중일 때 버튼 비활성화 안 되어 있어요." 기획서 확인한다. 누락됐다. 추가한다. "로딩 중 버튼 비활성화, 스피너 표시" v2.18. 퇴근 전 커밋 로그 본다. 개발자가 질문 없이 구현한 부분이 보인다. 기획서와 다르다. 근데 더 낫다. 개발자한테 묻는다. "이거 왜 이렇게 하셨어요?" 개발자: "이렇게 하면 코드가 더 깔끔해서요. 사용자 경험은 똑같고요." 확인한다. 맞다. 더 낫다. 기획서 수정한다. 구현된 대로. v2.19. 퇴근한다. 오늘 기획서 수정 11번. 내일도 수정할 것이다. 수정되는 기획서, 흔들리지 않는 방향 기획서는 계속 바뀐다. 바뀔 수밖에 없다. 사람들의 생각이 모이는 과정이니까. 더 나은 방법을 찾는 과정이니까. 현실을 반영하는 과정이니까. 중요한 건 방향이다. 목적이 명확하면 수정해도 괜찮다. 핵심이 흔들리지 않으면 디테일은 바뀔 수 있다. 완벽한 기획서는 없다. 하지만 계속 나아지는 기획서는 있다. v1.0에서 v2.19로. 그리고 내일의 v2.20으로.퇴근했다. 내일 또 수정한다. 괜찮다.