기획서에 대한 생각
나는 어떻게 ‘기획서’라는 문서를 작성하게 되었을까?
내가 꼬꼬마 신입 기획자로 입사하게 된 N사는 기획 – 디자인 – 개발 – QA 로 이어지는 일반적인(?) Waterfall 프로세스를 채택하고 있는 곳이었다.
내 명함엔 ‘기획’이라는 글자가 어디에도 없었지만, 사내에서 우리는 ‘기획서’를 쓰는 팀이었다. 아, 정확하게 말하면 ‘상세기획서’를 썼다. 어디에선가(?) ‘상위기획’ 이라는 게 내려오면 팀장님이 그 업무를 나에게 할당하셨고, 나는 열심히 PPT에다가 Flow 그리고 화면 와이어프레임 잡고 어쩌고저쩌고 하면서 수십 페이지(혹은 수백 페이지)짜리 상세기획 문서를 만든다. (팀 내에서 ‘표준기획서’ 양식을 만드는데 엄청난 노력을 쏟아붓지만, 실제 그 ‘표준’을 지키면서 작성된 문서는 단 하나도 없었다.)
그리고는 담당 디자인부서와 개발부서, QA 부서에 연락해서 미팅을 잡고는 ‘기획 리뷰’라는 걸 한다. 기획서의 디테일에 대해서 까는 건 우리 팀과 한판 붙자!는 의미로 받아들여졌기 때문에 (심지어 이름에 UX도 들어갔던 부서인데…ㅎㅎ) 회의 참석자들로부터의 불편한 질문들은 ‘기획 의도’ 라는 애매모호한 용어로 피해갔고, 때로는 우리도 본 적 없는 ‘사용자’를 데려와서는 문서의 정당성을 주장하기도 했다. (‘사용자 관점’에서는 이게 맞다니깐!) 아, 간혹 구현에 이슈가 될 만한 스펙이 있으면 그런 부분은 관대하게(?) 조정하기도 한다. 거기서 고집부리다가는 개발팀과 한판 붙자!고 선전포고를 하게 될 수도 있고…
음 아무튼. 눈에 보이는 수십 장의 문서가 있으니, 뭔가 일을 열심히 하긴 하는 것 같은 느낌을 받을 수 있었다.
‘완벽한(?) 기획서’를 만들어 보겠다고 의욕에 불타던 시절이 있었다.
나름대로는 엄청나게 꼼꼼하게(?) 문서를 작성한다고 했지만, 디자인-개발의 실제 구현과정을 거치다 보면 디자이너와 개발자들의 질문이나 피드백을 받으며 (혹은 내가 애초에 잘못 생각했던 부분이 하나둘씩 튀어나오면서) 문서를 엄청나게 고쳐야 했다. 내가 처음에 쓴 문서는 “기획서.ppt” 였지만, QA를 할 때쯤, 아니면 실제 그 기능을 출시할 때쯤 되면 “기획서_검토완료_최종본_수정_v31.ppt” 같은 말도안되는 이름의 파일이 생기곤 했다 -_-;;;
문서를 지속적으로 수정/공유하는 것 자체도 스트레스였지만 (수정해서 보낼때마다, 매번 이게 ‘진짜’ 최종이라고 하면서 동료들에게 미안해하는 게 너무 싫었다 -_-; 물론 그게 진짜 ‘최종’이라고 믿은 사람은 없었겠지만…) 개인적으로 느낀 더 큰 문제(?)는 어느 시점에선가 기획서와 Product의 속도가 거의 비슷하거나, 때로는 역전된다는 점이었다.
Waterfall 방식으로 프로젝트를 진행하려면 일단 가이드가 되는 문서가 나오고 그걸 바탕으로 구현이 이루어져야 하는데, 실제로 일을 하다 보면 스펙 변경사항을 메일이나 메신저로 협의하고, 기획서가 나오기 전에 먼저 개발이 진행되는 경우가 비일비재하게 발생했다. 즉, 변경사항들이 쌓여서 기획서를 꾸역꾸역 고쳐서 쓰고 있으면, 디자인이나 개발이 먼저 휘리릭 진행되는 경우였다. 이쯤 되면 도대체 내가 쓰는 기획서라는 문서가 디자인-개발을 가이드하기 위한 문서인지, 그냥 프로젝트 로그를 남기기 위한 문서인지 애매모호해지면서 나는 이토록 ‘실력없는 기획자’인가 -_- 하는 고민에 빠지게 된다.
매번 프로젝트를 새로 진행할 때마다 ‘이번에는 진짜 완벽한 기획서를 써서, 프로젝트 중간에 막 바쁘게 업데이트하고 끊임없이 수정했다고 메일 보내고 이런거 안해야지!’ 라고 굳은 결심을 하지만… N사에서 일하던 4년 내내 단 한번도 그런 ‘완벽한’ 기획서를 쓴 적은 없다.
도구가 ‘완벽한’ 기획서를 쓰는 데 도움을 줄 수 있을까?
나만 그런 고민을 했던 건 아닌 것 같다. 사내에서는 ‘기획 스펙들이 너무 자주 바뀐다’ ‘기획서가 표준화되어 있지 않다’ ‘기획서 업데이트를 메일로 커뮤니케이션 하는 게 좋지 않다’ 등등의 이야기가 끊임없이 나왔고, 결국 회사에서는 PPT를 대체할 수 있는 기획서 작성 Tool을 만들기도 했다. 기획서에 들어가는 버튼, 입력폼, 서식들을 표준화했고, 링크 이동이나 탭 변경 같은 간단한 interaction은 해당 Tool 안에서 그대로 구현이 가능했다.
그중에서도 개발자와 PM(기획자 말고, 프로젝트 일정관리를 하던 매니저)들이 특별히 좋아하는 기능이 있었는데, 그건 프로젝트를 ‘기획 완료’ 상태로 만들면 더이상 스펙을 추가하거나 변경할 수 없게 하는 기능이었다 ㅋㅋ (PM이 별도 승인해야지 변경이 가능했었나… 그랬던 걸로) 어쨌든 기능상으로는 기존의 PPT 기획서가 가진 여러 단점들을 보완할 것처럼 생긴(?) 툴이었다. 근데 막상 써보니깐, 내 주위의 모든 기획자, 디자이너, 개발자, PM들이 다 그 툴을 싫어했다 -_-;;; 힘겹게 새로운 툴의 기능을 익히긴 했지만, 결과적으로는 여전히 기획 스펙 변경은 끊임없이 발생했고(이젠 스펙 변경시마다 PM의 컨펌 단계가 있으니 더 귀찮…), 기획-디자인-개발 간 커뮤니케이션 코스트도 변함이 없었고, 기획서 작성과 유지보수에 드는 공수도 줄어들지 않았다. 뭐가 문제인거지?
‘기획서’의 문제는 단지 그 문서 하나가 아니라, ‘업무 프로세스’의 문제로 수렴한다.
생각해보면, ‘기획서 내 스펙이 자주 바뀌는 게 문제이므로 스펙 변경을 못하게 한다’는 식으로 문제 해결을 하는 게 얼마나 어처구니없는 일인가 싶지만 ㅋㅋㅋ 저 때는 진짜 저런 기능이 있었다 -_-;;; 결국 해결해야 하는 문제는 이런 거다. 왜 스펙 변경이 끊임없이 일어나지? 왜 기획자-개발자-디자이너의 커뮤니케이션 코스트는 안 줄어들지?
‘기획서’를 어떻게 하면 잘 쓸 수 있는가… 하는 문제는 ‘어떻게 일을 해야 하는가’ 라는 문제로 수렴하게 된다. (이젠 지겹고 식상하지만) 과연 Waterfall 형태로 일하는 게 최선인가? 라는, ‘업무 프로세스’에 대한 근본적 질문으로 또 다시 돌아오게 된다는 의미다. 사실 애초에 기획자 한 사람의 머릿속에서 나온 문서가 다른 개발자, 디자이너, 운영자들의 생각과 온전히 일치해서 더이상 수정이 필요없을 정도의 ‘완벽한’ 문서일 가능성은 제로에 가깝기 때문이다.
사실 Waterfall에서의 기획문서는 프로젝트 멤버 간의 커뮤니케이션 material이라기보다는, 기획자가 한 homework에 가깝다고 생각한다. 애초에 커뮤니케이션을 위해 만들어진 문서가 아니다보니 그 문서를 바탕으로 구현을 위한 커뮤니케이션을 하는 게 엄청나게 비효율적일 수밖에 없다.
개인적으로 생각하는 ‘기획자 원맨쇼로 만들어진 기획서의 태생적 문제’를 몇 가지 짚어보면,
“기획자인 내가 생각한다. 너희들은 생각하지 말고 이대로 구현만 해” 에서 오는 시야의 협소함. 나는 이게 기획자가 가질 수 있는 가장 위험하고 멍청한 스탠스라고 생각하는데, 생각보다 이렇게 생각하는 기획자들이 많다 -_-; 애초에 ‘기획자’라는 이름이 잘못된 선입견을 가져다주는 것 같기도 하고…
위에서 언급한 ‘기획 리뷰’를 한다고 해서 다른 멤버들의 참여가 이루어진다고 볼 수는 없다. 기획자가 어쨌든 PPT 100장 만들어 왔는데-_- 거기다가 대놓고 ‘이건 잘못됐어’ 라고 말하긴 여러모로 쉽지 않다. 기획 리뷰라는 것 자체가 co-work 보다는 criticize에 적합한 프로세스이다. “일단 내가 다 했어. 뭐 의견 있으면 이야기 해봐, 한번 생각은 해 볼께…” 라는 상황에서 건설적인 의견 개진을 통한 논의가 이루어질 확률이 얼마나 되겠는가.
문서에 기반해서 구현과정이 좌지우지되는 환경에서는 ‘기획서 현상유지의 유혹’이 늘 따라다닌다. “이 스펙이 조금 불편하긴 하지만, 이 조그만거 고치자고 문서 수정해서 메일 보내고, 디자인/개발에 스펙 변경되었다고 커뮤니케이션 하면서 욕먹느니… 뭐 큰 것도 아닌데 일단 초기 기획안대로 놔두지 뭐…” 경험담인 것 맞고, 반성한다… -_-;;;
마찬가지로, ‘문서 신봉주의’가 프로젝트 멤버들에게 빠르게 전파될 수 있다. 좀 더 개선할 수 있는 포인트가 눈에 들어오더라도, “나는 하라는 거 다 했는데? 그건 문서에 없잖아” 라고 한 발 빠져버린다거나.
결과적으로 가장 안좋은 건, ‘분명히 이게 최선이 아닌 걸 알지만, 프로세스에 따라서 그냥 하게 된다’. 아 이건 말하고나니깐 좀 슬프네. 진짜 이랬던 적이 있는 것 같아서 -_-;;;
좋은 기획서에 대해 이야기하려면, 결국 ‘기획서라는 문서를 왜 쓰는건가?’ 라는 질문으로 돌아와야 한다.
기획서는 어떤 산출물을 만들어내기 위한 커뮤니케이션 도구로써의 역할을 해야한다고 생각한다. 사실 종이에 연필로 슥슥 그리거나, 혹은 말로 몇마디 이야기하는 것으로 충분히 커뮤니케이션이 된다면, 당연히 수십 장짜리 PPT 문서를 만들 필요가 없는 것 아닐까? 커뮤니케이션이라는 건 일단 서로의 생각들을 함께 나누고 그것들을 정리하는 과정에서 출발하는건데, ‘생각을 함께 나누는’ 과정이 생략된 상태에서 만들어진 기획서가 좋은 문서가 될 수는 없다고 생각한다. 기획서가 ‘기획자’라는 명함을 가진 사람들의 ‘숙제’처럼 여겨져서는 곤란하다.
간혹, 나중에 참고할만한 ‘로그’를 쌓고 이전 히스토리들을 꾸준히 트래킹하기 위해서 기획서가 필요하다고 보는 입장도 있는데 나는 여기에도 좀 회의적이다. 훗날 추가 기획이나 아니면 다른 의사결정에 참고할만한 로그로써의 역할을 하려면 기획 의도나 기획 시에 고려했던 원칙에 대한 정리가 훨씬 더 중요하다고 생각하는데… 사실 대부분의 기획서는 화면이나 기능 단위의 description에 초점을 맞추고 있는 경우가 많다. 이건 업데이트때마다 관리하기 힘든 ‘문서’의 형태보다는, 그 결과로 나온 산출물 그 자체가 더 의미있는 로그가 아닐까 싶다. 로그가 필요하다면, 화면 상세설계서보다는 초기 기획의도나 의사결정의 변곡점들, 그리고 IA와 기능의 우선순위를 정리할 때 고민했던 사항들을 따로 정리한 내용들이 ‘로그’로서 훨씬 더 가치있는 내용일 것이다.
스타트업에서 기획업무를 진행하면서 스스로 달라졌다고 느꼈던 점은, ‘Product’가 ‘기획서’를 앞질러 갈 때 더이상 초조하거나 그로 인해 스트레스를 받지 않았다는 점이었다. 전에는 어떻게든 ‘기획서를 최신 버전으로 유지하려고’, 이미 멤버들이 다 알고 있고 심지어 Product에 반영되어서 릴리즈 된 내용에 대해서도 어떻게든 상세기획서 혹은 화면설계서 같은 문서에 그 내용을 꾸역꾸역 뒤늦게 업데이트하곤 했었다. 하지만 스타트업에서는 이미 완성된 기능에 대한 기획서 따위는(?) 아무도 보지 않는다는 걸 알았기에 ㅋㅋ 멤버들 간의 커뮤니케이션이 이미 충분히 진행되어서 Product에 반영되었다고 생각되면 화면 단위의 기능기획문서를 남기기보다는, 관련된 의사결정 히스토리나 달라진 로직에 대한 큰 그림만 남겨놓으려고 노력했었다. 그러다보니 자연스럽게 처음에는 ‘기획서’를 가지고 커뮤니케이션 하다가 어느 순간 기획서보다 Product를 가지고 커뮤니케이션 하는 게 더 효율적이라고 느껴지는 순간이 되면, 기획서는 그냥 골방으로 들어가고…그냥 Product 자체가 커뮤니케이션 material이 되었는데, 그냥 그것으로 충분했다.
그래서 이 긴 이야기의 결론은 ㅎㅎ
호랑이는 죽어서 가죽을 남기고, 사람은 죽어서 이름을 남기는 것처럼,
기획자는 프로젝트가 종료되면 기획서가 아니라 Product를 남겨야 한다고 생각한다.
기왕 집착할거면, 문서 말고 Product에 집착하는 기획자가 될 것.
더 공부하고 싶다면?
그로스해킹 : 데이터와 실험을 통해 성장하는 서비스를 만드는 방법
