일만 잘할 수 있으면
좋은 기획서 아닌가요?
기획서를 잘 쓰기 위해서 중요한 건 프레임이 아니다
'기획서를 잘 쓰는 것'과 '좋은 기획을 하는 것'은 많이 닮아있는 듯하지만, 사실은 닮아있지 않다. 얼마나 닮았는가 굳이 따지자면, 사용자 경험하는 이름을 가진 부모에게서 태어난 이란성쌍둥이 정도 될 것 같다. 만약 일란성 쌍둥이었다면, '기획서를 잘 쓰는 사람'이 곧 '좋은 기획을 하는 사람'이 되겠지만, 우리 주변의 기획자들, 아니 친구들만 보더라도 사실 이 둘은 일치하지 않는 것을 볼 수 있다. 우리 주변에 기발한 아이디어를 잘 내는 사람들은 쉽게 찾아낼 수 있으나, 그 기발한 아이디어를 현실화하는 사람들은 쉽게 찾아내기 어렵다. 사용자 경험을 기획하는 것과 사용자 경험을 만들 수 있는 기획서를 쓰는 것도 똑같다. 기획서를 잘 쓰는 사람을 찾는 것이 훨씬 어렵다.
이란성 쌍둥이하면 스타워즈가 생각나는 나란 사람...이런 것까지 적어야 하나요?
사용자 경험 개선을 위한 기능 개발 기획서를 작성하다 보면, 자주 드는 생각이다. 기획자가 갖추고 있는 배경 지식은 기획서를 읽는 개발자, 그래픽 디자이너, 오퍼레이터, 경영진을 비롯한 이해관계자들과 동일하지 않다. 그렇기에 처음 기획을 배울 때, '기획서를 쓸 때 다양한 환경을 고려해야, 모든 사람들이 기획서를 쉽게 이해할 수 있다'라고 배운다. 그럼 정말 이렇게 작성된 기획서가 좋은 기획서일까? 이런 기획서를 쓰는 사람이 기획서를 잘 쓰는 사람일까?
· 이번에 개발하고자 하는 기능 개발이 왜 수행되어야 하는가?
· 이 기능이 개선/개발되어서 우리가 얻을 수 있는 이득은 무엇인가?
· 이 기능이 개선/개발되어서 사용자 경험은 어떻게 바뀔 것인가?
· 이 기능이 개선/개발이 우리 서비스를 제공하기 위한 이해관계자 관계도에 영향을 미치는가?
· 만약 영향을 미친다면, 어떠한 변경점이 있는가?
· 이 기능은 전체 서비스 와이어프레임에서 어디에 위치하는가?
· 이 기능의 동작은 전체 서비스에 어떠한 영향을 끼치는가?
· .
· .
· .
이제 막 기획에 입문한 주니어는 RFP, SOW, 스토리보드, 히스토리보드 등등 다양한 프레임을 통해서 위와 같은 배경지식을 생각하고 작성하는 방법에 대해서 배운다. 잘 알려진 프레임을 모두 활용하여 작성한 서비스 기획서는 영역별로 잘 정리되어 있어서 보기도 좋을뿐더러, 조직 간 커뮤니케이션이나 실무 수행에 문제가 발생할 가능성도 적다. 하지만, 나는 이러한 기획서 작성이 꼭 좋은 것만은 아니라고 생각한다. 작성하는데 적지 않은 시간이 걸리기 때문이다. 그리고 프레임에 잘 맞춰서 기획서를 작성하는 사람이 모두 기획서를 잘 쓰는 사람은 아니라고 생각한다. 기획서를 읽고 실무를 수행할 이해관계자가 이해하고, 업무를 수행할 수 있을 정도로만 작성하는 것으로도 좋은 기획서라고 불리기에 충분하다. 누군가 텍스트만 몇 글자 적혀있는 기획서 밖에 작성 못한다고 하더라도 모두가 업무를 수행하는데 문제가 없다면, 그 사람은 기획서를 잘 쓰는 사람이라고 칭해도 괜찮을 것이다.
이런 사람들이 읽어볼 만합니다:
· 제품을 개발하는 스타트업 기획자/개발자
· 기획서 쓰는 게 막막한 주니어 기획자
· 서비스 기획자 꿈나무
기획서 작성의 목적
기획서를 작성할 때는 목적이 무엇일까? 우리가 작성하는 기획서는 배경지식이 전혀 없는 사람도 읽고 기능 개발을 수행할 수 있는 매뉴얼인가, 실무자들이 업무를 수행하기 위한 지침서인가? 나는 후자라고 생각한다.
기획서를 작성할 때, 업무에 연관된 담당자들끼리 공유되는 기본 지식을 생략하면, 훨씬 간결한 서비스 기획서를 작성할 수 있다. 실제로 나는 하루에도 세네 개의 각기 다른 기능 개발 기획서를 작성하여 개발팀과 논의하기도 하는데, 만약 내가 모든 배경 지식을 기획서에 담으려고 했다면, 하루에 기획서 한 개를 작성하는 것도 어려웠을 것이다.
우리 조직에서 공유되는 기획서 수준우리 조직에서 공유되는 기획서는 대체로 위 이미지처럼 작성된다. 내용을 확인해보면 알겠지만, 책자를 통해서 혹은 온라인을 통해서 공유되는 제품 기획서 프레임과 크게 닮아있지 않다. 하지만, 이 기획서는 적어도 우리 조직에서는 좋은 기획서이다. 이 기획서의 의도대로 기능이 구현되는 과정에서 커뮤니케이션이 원활했을 뿐만 아니라, 기획자의 의도대로 기능 개발이 완료되었기 때문이다.
기획서를 작성하는 목적은 보기 아름다운 문서를 만드는 것이 아니라, 기획자의 의도대로 업무를 수행할 수 있도록 하는 것이다. 기획 문서를 작성하는 툴, 이용하는 프레임은 기획자의 의도를 전달하기 위한 도구로서 사용되어야지, 작성 툴과 프레임에 맞도록 작성하는 것이 목적이 되어서는 안 된다. 어떠한 형태를 하고 있더라도, 기획자의 의도가 정확히 전달되고, 기획자의 의도대로 서비스 개발이 수행된다면 그것은 좋은 기획서라고 해도 괜찮다.
짧은 시간 안에 좋은 기획서를 만들기 위해서
파워포인트를 이용해서, 잘 알려진 프레임들을 배치하여 작성된 기획서는 당연히 보기에 좋다. 다양한 프레임을 사용해서 문서의 완성도가 높아지면, 별도의 협업 도구 없어도 문서 안에서 모든 작업을 관리할 수 있게 되기도 한다. 가장 큰 단점은 문서를 만들고 수정하는데 비교적 많은 시간이 걸린다는 것이다.
자금과 시간을 포함한 모든 자원을 여유롭게 사용할 수 있는 대기업과는 달리, 내가 속한 스타트업에서는 모든 상황과 조건을 고려하여 좋은 기획서를 쓸 시간적 여유가 없다. 우리 조직은 자원을 조금 더 효율적으로 사용하기 위해서, 서비스 기획서를 작성하는 시간을 단축하기 우리 조직의 노하우를 조금 소개한다:
· 일관적인 UI 디자인 규칙
· 협업 도구를 이용한 커뮤니케이션 및 기록
· 기획 의도 데모 영상 작성
· 일관적인 UI 디자인 규칙
서비스에 사용하는 버튼의 모양, 색상, 폰트 등에 일관적인 규칙이 적용되어 있다면, 모든 UI에 그래픽 디자이너가 개입하지 않아도 개발을 진행할 수 있다. 우리 조직의 경우에는 내부에서 '리모콘'이라고 부르는 인터페이스를 구성하여, 각 상황에서 필요한 버튼 형태와 콘텍스트를 통일하였다.
조직 내에서 공유되는 '기본 배경'이 많아지면 많아질수록, 기획자와 그래픽 디자이너가 반복적으로 작업해야 하는 양이 줄어든다. 더 나아가서 서비스를 관통하는 일관적인 UI 디자인은 사용자가 서비스의 퀄리티를 높다고 생각하게 될 가능성을 높여주기도 하고, 제품의 아이덴티티를 형성하기도 한다.
이러한 개발 방법론은 Google에서도 사용되기도 하는데, https://material.io/ 에 접속하면 Google이 일관적인 UI를 부여하기 위해서 어떤 방법을 사용하고 있는지 확인할 수 있다.
· 협업 도구를 이용한 커뮤니케이션 및 기록
우리 조직은 마이크로소프트에서 제공하는 Teams를 협업 도구로 사용하고 있다. 우리는 효과적인 협업을 위해서 우리 조직에서 통용되는 협업 도구 사용 규칙을 만들어서 업무를 수행한다. 예를 들어, 제품 개발을 할 대, 우리는 각 서비스 기획서 별로 채널을 생성하여 관리하고 있으며, 개발이 완료되면 채널 이름에 완료 표시를 하고 별도 보관한다.
우리 조직이 생각하는 좋은 기획서는 곧 업무를 수행하는데 지장이 없는 기획서이다. 하루에 생성되는 서비스 기획 문서가 많은 편에 속하는 우리 조직은 최초 공유되는 기획서에서 큰 작업에 대해서만 정의되고, 주요 상세 내용이 누락되어있는 경우가 있다. 그럼에도 불구하고 이는 여전히 좋은 기획서인데, 협업 도구 내에서 누락되어있는 내용을 빠르게 논의하고 각자가 채울 수 있는 영역을 채워가는 방향으로 업무가 수행되기 때문이다. 협업 도구를 통한 커뮤니케이션은 서로를 멘션 할 수 있고, 기록이 완전하게 남기 때문에 필요한 경우 원 기획자가 개입하여 기획 의도를 일관성 있게 유지할 수 있다.
이 글을 적기 전에, 다양한 서비스 기획서 프레임워크를 검색해보았다. 그 과정에서 가장 흥미로운 부분은, PPT 문서에서 문서 변경 이력을 확인할 수 있는 슬라이드를 추가하여 공유하는 것이었다. 기획서를 토대로 실제 개발을 진행하다 보면 다양한 커뮤니케이션과 작업 이력이 남기 마련이다. 나는 이를 기록하기 위해서 슬라이드에 표 기입하고, 커뮤니케이션 및 작업 내역을 정리하는 것은 좋은 사용자 경험이 아니라고 생각한다. 하나의 작업을 수행하고 적용하기 위해서, [신규 문서 다운로드 -> 작업 -> 작업 내역 슬라이드 정리 -> 파일 이름 규칙을 염두하여 저장 -> 업로드] 과정이 반복 수행되기 때문이다. 협업 도구의 도입은 이러한 반복 작업 역시 최소화할 수 있다.
협업 도구를 잘 사용하는 것만으로도, 얼기설기 구성한 기획서가 좋은 기획서가 되기도 한다.· 백문이 불여일견
사용자 경험을 디자인하다 보면, 사용자의 행동에 따른 인터랙션을 구성해야 할 때가 있다. 이러한 인터랙션을 기획자가 머릿속에 떠올리는 대로 문서화하기란 정말 쉽지 않다. HCI가 대두되고, 기술의 발전에 따라 다양한 인터랙션이 만들어지면서, 이러한 인터랙션들을 문장으로 정의하는 것이 거의 불가능에 가까워졌다.
애플 사이트의 Mac Pro 상품 소개 페이지. 이 페이지의 사용자 경험을 정적인 그림 혹은 문장으로 작성할 수 있을까?기획자가 개발적 인사이트를 갖고 있어서, 세부 사항을 직접 구현한다면 모르겠지만, 개발적 인사이트가 없는 기획자가 머릿속으로 구성한 사용자 경험을 문장 혹은 정적인 이미지를 통해서 전달하는 것은 매우 어려운 일이다. 이러한 불편함을 한 번에 해결할 수 있는 방법이 있으니, 이는 동영상이다.
나는 보다 나은 사용자 경험을 구성하기 위해서 반드시 필요하다고 생각하는 인터랙션이 있는 경우, 반드시 그 인터랙션을 동영상 데모로 구성하여 기획서에 첨부한다. 조금 번거롭더라도 동영상을 만들어서 공유하면, 문서를 통해서 애니메이션이 어떻게 나와야 하는가, 색상이 어떻게 변해야 하는가, 어떤 느낌으로 화면이 전환되어야 하는가를 설명하는 것보다 훨씬 더 효과적으로 기획자의 기획 의도를 전달할 수 있다. IT 서비스 기획자를 꿈꾸는 주니어 기획자라면, 동영상을 편집하는 기술은 배워두면 정말 유용하다. (나중에 유튜버 전직 찬스가 있을지도 모른다.)
사실 이런 이야기는 이미 업무 스타일이 확립된 큰 조직에는 어울리지 않는 이야기일 수도 있다. 만약 이 글을 읽으신 분이 큰 조직 내 의사결정권자라고 하더라도, 기존의 기획 프로세스를 우리 조직과 같은 형태로 바꾸는 것은 별로 추천하고 싶지 않다. 이미 익숙한 프로세스를 개선하는 과정에서 오히려 업무 생산성을 낮추게 될 가능성이 높기 때문이다. 기획서를 작성하는 기간은 단축되겠지만, 업무 생산성이 낮아진 시점에서 이미 그 기획서는 좋은 기획서가 아니게 된다. 하지만, 기획 의도를 영상으로 전달하는 것 정도는 한 번쯤 시도해볼 만할 것이다.
만약, 이 글을 읽으신 기획자가 속한 조직이 애자일 하게 움직일 수 있는 조직이라면, 혹은 이제 막 시작하는 조직이어서 서비스 개발팀과 기획팀 간에 아직 아무런 약속도 없는 상태라면, 한 번쯤 우리와 같은 형태의 기획 문화를 도입해보는 것을 추천해보고 싶다.
기획서 작성의 본질적 목적은 잘 정리되고 시각적으로 아름다운 문서를 만드는 것이 아니다. 기획자인 나의 의도를 업무 하는 사람에게 명확하게 전달하는데 목적이 있다. 그 방법은 많이 알려진 프레임이 아니라, 각자의 조직에, 혹은 나 자신에게 있을지도 모른다. 기획서 작성에는 답이 없다. 남들이 한다고 모든 것을 따라 할 필요 없다. 남들의 기획서처럼 아름답지 않다고 주눅 들 필요도 없다. 업무만 잘되면 장땡이다.
