회사를 나온 후, 스타트업을 시작하고 처음으로 기획서를 썼을 때 복잡했던 심정을 잊을 수 있을까. 프로젝트 기획을 수십 개씩 해보진 않았지만, 회사에서 내 자리에 앉아 집중하기 시작하면 쭉쭉 진도가 나갔던 때랑은 완전 다른 기획서였다. 일주일이면 30-40장씩도 작업할 수 있었는데, 어떻게 된 게 두어 장 작업하기도 힘든 것이었다. 이상하다. 내가 제일 자신 있어 하는 일인데.
의사결정권
회사에 다닐 때는 팀원도 있었고, 팀장도 있었고, 본부장도 있었다. 검토에 검토, 리뷰에 피드백… 기획서가 난장판이 될 때도 있었지만, 오히려 빨간 펜 가득한 기획서를 보면 마음의 위안을 얻기도 했다. ‘이것만 고치면 웬만큼 마무리는 되겠지..?’ 피드백 주기가 짧아지고, 페이지당 수정사항이 줄어들수록 기획서가 완성되어 간다는 느낌이 들기 시작한다.
하지만 그 모든 의사 결정권이 나에게 있는, 나에게만 있는, 나눠 가질 사람도 없는 스타트업에서는 나를 가장 공포스럽게 한 것이 누구에게도 보여주지 못한 1.0 버전의 기획서였다. ‘봐줄 사람이 있었으면 좋겠다…’
기획자가 혼자라서 외롭다는 생각이 들기 시작하면서, 우울증에 걸릴 뻔 했다. 맙소사. 개발도 아니고.
지금은 일 년 반쯤 지났다. 새 문서를 만들 때마다 빈문서의 공포감은 여전하지만, 그래도 꽤 괜찮아졌다. 주위에 스타트업이 많으니 많은 이야기를 듣는데, 한결같이 ‘이게 맞는지 모르겠다.’라는 이야기를 한다. 내가 했던 고민이다. 역시.
기획도, 디자인도, 개발도, 마케팅도 거의 모든 것을 고민해야 하는 스타트업, 그리고 린보다는 완벽주의를 추구하는 한국식 기획자의 특성상 문서와 씨름하는 시간이 길어질 수밖에 없다. 사실주의 목업은 물론이고, 생각보다 생각할 게 많아서 기획서와 씨름하는 시간이 길어질수록 말은 점점 없어진다.
안 훔쳐간다
기획자는 혼자가 아니다. 정말 혼자라고 생각하고 혼자서만 생각하는 건 기획자로서 해야 할 역할을 10%도 못하는 거다. 팀에는 개발자도 있고, 디자이너도 있고, 팀원이 없으면 친구라도 있다. 그리고 사용자들도 있다.
이게 구현되나 모르겠다. 이게 사용성이 좋은지 모르겠다…만 고민하면 절대로 고민이 풀리지 않는다. 구현이 되나 안되나 모르겠지만 우선 개발자에게 물어보면 된다. 아무리 기획자가 개발에 대해서 잘 알아도 같은 연차의 개발자보다 모른다고 보면 된다. (물론 지식은 연차와 경험에 비례한다) 그러니까 혼자서 고민하지 말고 이야기하면 된다.
스타트업은 특히 비즈니스 아이디어가 중요하기 때문에 기획자끼리 만나면 절대 아이템 이야기를 안 한다. 초기 창업자에게 있어 아이디어를 말한다는 것 자체가 왠지 뺏길 것 같은데, 생각보다 다른 기획자는 내 기획에 관심이 없더라. 오히려 아이디어단계에서 검증할 수 있는 중요한 시기를 놓쳤다는 생각이 들더라.
나도 이런저런 아이디어를 들을 때마다 ‘아 그렇구나’, ‘좋은 생각이네’, ‘별로인데?’ 하는 생각은 들지만 ‘앗싸 이거다. 내가 먼저 해야지’ 하는 생각은 들어본 적이 없다. 이미 자기가 하고자 하는 게 확실해서 스타트업을 시작한 것 아닌가? 능력이 있고 역량이 있는 사람은 그 그릇에 맞는 일을 하기 마련이다. 오히려 더 좋은 이야기, 아이디어를 듣고, 고객의 이야기를 듣는다고 생각하면 마음이 편해진다.
그리고 진짜 훔쳐갈 생각이 있다면, 아이디어 단계가 아니라 개발한 후에 훔쳐간다. 견물생심, 좋은 아이디어가 시장에 나와서 검증되기 시작하면 그때 훔쳐가는 게 더 싼 값에 훔쳐갈 수 있다. 왜냐면 내가 고민하지 않아도 되거든. 이미 누군가가 많이 고민해서 내놓은 거거든. 실제로 서비스를 시작하면 비슷하게 따라 하는 아류작들이 많아지는 이유다.
일인다역은 언제나 바쁘다
기획자로 스타트업에 있다 보면 사람들을 만나고, 모임에 참여하고, 네트워킹을 하게 되고, 마케팅이나 고객대응도 해야 한다. 그래서 기획서를 잡고 있을 시간이 없다. (없어도 너무 없다 ㅠㅠ) 그래서 기획서에 시간을 쏟는 것 자체가 아까워질 때도 있다. 분명 필요하고, 해야 되는 일인데. 혼자서 잘 알지도 못하고, 잘하지도 못하는 기획서 쓰기를 수십 번 반복하는 건 스타트업에겐 굉장한 낭비다. 낭비라면, 안 하면 그만.
만약 주위에 모바일 기획이 처음이라 잘 모르겠어요, 몇 번이나 갈아엎었는지 모르겠어요, 하는 사람들의 이야기를 들으면 나는 그럼 딱 한마디로 대답한다.
“그럼 기획서 쓰지 마세요”
선개발, 후문서화가 답일지도
우리 팀은 딱히 기획서가 없이도 일이 진행된다. 우선 내가 바쁘고(…켁) 개발은 내가 기획서 그리는 것보다 빠르다. 개발자가 많은 팀이기도 하지만, 말로 이야기해서 (일명 입기획과 입코딩) 구현방법을 가이드 할 때가 훨씬 많다. 기획은 변경되기 쉽고, 기획서에 모든 것을 표현하기는 어려우며, 아무리 완벽한 기획서라도 빈틈이 있기 마련이고, 그 빈틈에 빠져 허우적대는 개발자는 허우적댄다고 말하지 않을 확률이 99.99% 다.
만약 기획서부터 작성해서 워터풀 방식으로 진행되는 프로세스라면 상황은 악으로 치닫기 쉽다. 기획서는 A라고 되어있는데, 개발문서는 A-로 되어있고, 코드는 A+ 로 되어있는 상황이라면 도대체 뭐가 잘못된 것인지 한참을 고민해야 한다. 서비스가 라이브 상태가 되면, 기획서를 수시로 업데이트하는게 힘들어진다. 긴급하게 업데이트를 하게 되는 상황이라도 오면 나중에 기획서는 ‘고故문서’(고古 아님) 취급을 받게 되고, 아무도 기획서를 읽지 않게 된다.
프로그램과 기획서가 다르면 서로에 대한 불신만 깊어진다. 기획자는 쓸데없는 잉여인력이 돼버리며, 개발자는 제멋대로 개발한 사람이 되거나 실력 없는 개발자가 돼버린다.
기획서는 기획의도도 담겨있고, 비즈니스 전략도 담겨있고, 앞으로 어떻게 변경되어야 할지 가이드도 담겨있어야 하기 마련이다. 그런데 개발과 기획의 갭이 커질수록 그 누구도 기획서를 읽지 않게 된다. 그 이후는? #자세한설명은생략한다
프로그램과 기획서가 동일하면 기획서에 대한 신뢰도가 올라간다. 기획서의 신뢰도가 높아지면, 개발자가 기획자가 서로를 믿는 신뢰도도 같이 높아진다.
그래서 구두 기획도 기획이라고, 우리 팀은 커뮤니케이션으로 개발부터 시작한다. 기획서는 그다음이다. 개발이 진행되면서 논의했던 것, 논의해야 할 것, 구현된 것 모두 자세하게 기획서로 남겨둔다. 그래서 나는 기획서를 쓰는 걸 Documentation, 즉 문서화라고 부른다. 그러면 나중에 헷갈릴 때, 업데이트를 할 때, 크리티컬한 이슈가 터질 때 어디서부터 어디를 봐야 할지 빠르게 알 수 있다. (개인적으로 가장 추천하는 이유 중에… 한땀 한땀 목업UI를 그릴 필요가 없다! 그냥 구현된 거 캡쳐하면 끝!)
대신에, 이야기는 정말 입에서 단내나도록 많이 한다. 밥 먹으면서도, 출퇴근길에서도, 아이디어가 생각나면 새벽이든 주말이든 연락해서 꼭 이야기한다. 개발자 옆에 붙어서 수시로 확인하고, 이슈는 없는지, 내가 미리 준비해야 될 것들은 없는지, 정해줘야 하는 곤란한 건 없는지, 기획이 개판이라 스트레스받고 있는 건 아닌지(…) 등등.
그리고 비슷한 이슈로 발생하는 모든 것들은 모든 개발자에게 정확하게 인지시킨다. 내부가 아니라 외부에서 들어오는 이슈들은 내가 듣고, 받고, 필터링한다. 수시로 이슈를 던지면 좋겠지만, 그럼 현 상태에 집중을 못 하니 정리해서 한 번에 이야기한다.
이렇게 이야기를 많이 하면 내 기획이 얼마나 주먹구구였는지도 알게 되고(안구에 습기가), 개발구현방법에 대해 이해도 높아지며, 누구와 이야기해도 내 프로덕트에 대해 정확히 이야기할 수 있게 된다. 상대방이 개발자라고 하더라도 꿀리지 않고 말이다.
커뮤니케이터
컴퓨터는 사람의 말을 못 알아 듣는다. 컴퓨터 언어로 말을 걸어도 못 알아 듣는 게 컴퓨터다. 그래서 인터프리터나 컴파일러 같은 프로그램이 컴퓨터 언어를 기계어로 바꿔야 컴퓨터가 알아듣고 실행으로 옮긴다.
기획도 마찬가지라고 생각한다. 내 머릿속에 있던 기획을 가장 잘 설명할 수 있는 건 기획서가 아니라 ‘나’다. 개발자에게 내가 설명하는 것이 정확하지, 기획서‘만’으로 커뮤니케이션 할 수 있다고 믿는 건 정말 아닌 것 같다. 기획과 구현에 찍혀있는 수많은 물음표를 수시로 이야기하고, 계속 상기시키며, 중요성에 대해 역설하고, 모든 사람의 이해도를 높이는 일은 문서만으로 불가능하다.
하지만 기획서만 던져놓고 ‘그대로 해주세요. 모르는 게 있으면 물어보시고요’ 하는 사람, 의외로 많다. 기획은 이미 승인됐으니 그대로 해달라고 징징대지나 않으면 다행이다.
내 직업은 기획자라고 말하고 다니는 기획자로서, 커뮤니케이터로서 빈 문서와 대화하고 있는가 개발자와 대화하고 있는가?
추신. 설계 대상의 구조적 특성을 구체화하는 사람으로서, 기획자는 Designer로 불리는 것이 옳습니다. 하지만 PPT Design 을 하지는 마세요.
업데이트
피드백은 공개적으로 주는것이 모든 사람들과 논의할 수 있어서 좋습니다. 큰맘먹고 댓글도 열어놨는데..쳇.. (멘션없이) 본인의 SNS에만 코멘트하니 제가 일일이 트래킹하긴 힘드네요. 저도 이런 생각을 함께 이야기하고 싶은데, 말걸어주는 사람이 없어요..-_-
1. 원래 제목은 ‘스타트업에서 기획자의 역할’이었죠. 아무래도 낚기좋은 떡밥스타일 제목으로 바꿨더니.. ㅎㅎ 스타트업, 특히 요즘엔 다른 분야에 있던 사람들이 IT서비스(모바일/웹)를 시작하기 때문에 잘 모르니 기획서 쓰는 것에만 목매다는 경우가 많은걸 보고 들었던 생각을 정리한 글입니다. (목매단다 = 목업의 정렬, 색감, 애니메이션, 패턴 등 기능적인 부분이 아닌 UI디자이너가 해야 될 영역에 집중하는 것을 말합니다.)
2. 기획서를 쓰지말고 말로부터 시작하라는 건 논지가 아닙니다. 기획서’만’ 쓰지말라는 얘기가 하고싶었던거죠. 기획서작성에 해당하는 UI목업, 기능정의와 커뮤니케이션 간의 주객전도는 절대 지양해야합니다. 어떤 것이 더 우선순위가 높은지 프로젝트마다 성격이 다르고, 기획서마다 성격이 다르지만, 하나에 다 포함시키는 경우라면 개인적으로 (커뮤니케이션)>스펙정의>>>>>UI목업으로 두는 편입니다.
3. 기경력자는 당연히 기획서부터 쓰는 것이 좋습니다. 또 커뮤니케이션이 빠르지 않고, 여러 사람이 참여하는 대기업 프로젝트에서도 먹히지 않습니다. 이런 대규모 프로젝트에서는 모든 사람과 일관성있게 커뮤니케이션 하기도 힘들고, 기획서기반으로 프로세스가 돌아가기 때문에 기획서의 완성도가 떨어지면 업무효율은 제로에 수렴합니다. 수십장의 기획서라도 글자하나, 토씨하나까지 전부 일관성을 가져야 할 필요도 있죠.
4. 그러니까 케바케라구요. 이런 방식이 정답일리 없잖아요!? 선개발 후문서화는 손뻗으면 개발자가 닿는 스타트업에서나 실험해볼만한 방법입니다. 스타트업은 바쁘니까요. 손도 부족하구요. 선택과 집중을 해야한다면 어떤걸 선택하시겠어요?
5. 말이 아니라 글이고, 기가막히게 잘쓰는 편도 아니어서 강약조절이 미흡하긴 합니다. 평소에 하는 생각을 정확하게 풀어내긴 힘들죠. 이래서 ‘내 머리 속’에 있는 얘기를 이렇게 첨언하는 것 같네요. 오랫만에 블로그가 흥하네요. 욕도 많이 먹겠죠. 오래 오래 살께요. (오예-)
valentino sandalsHow to Break in Boots Fast
