brunch

You can make anything
by writing

C.S.Lewis

by 기획하는 족제비 Jun 20. 2023

무거운 기획서, 가벼운 기획서


인트로

24주 차에 이직한 곳에서 처음으로 상세 기획을 작성했다. (생각보다 빠르게 프로젝트에 인볼브가 돼 버림.) 완성 후 사수님과 리뷰를 먼저 진행했고, 현재 상황에 맞춰서 기획서를 일부 수정한 후 개발셀장님들과 함께 리뷰를 진행할 예정이다.


새 회사에서 첫 기획서를 작성라면서 들었던 여러 생각과 경험을 데일리 노트에 작성하려다 보니 글의 덩치가 꽤 커져서 따로 글을 분리했다.


이번 글에서는 기획서의 깊이와 고찰에 대해서 다룰 예정.




프로젝트 개요

이번 기획은 그리 어려운 내용은 아니었다. 자사 제품에는 관리자가 원하는 시점에 사용자들이 스스로 자신과 동료를 평가 할 수 있는 기능이 존재하는데, 기존에는 실시간으로 연동되는 데이터를 사용자가 조회하고 사용했다면 이후에는 1) 특정 트리거를 기준으로 데이터를 스냅샷하여  원본 데이터와 사본 데이터를 구분하고, 2) 사용자가 작업 시에는 사본 데이터를 가지고 작업을 할 수 있도록 하는 변경하는 정도였다.


우선 메인 시나리오는 이것이었고, 이 시나리오에 맞춰 화면의 UXUI까지 가볍게 변경하는 정도의 기획을 진행했다.



개발자 분들은 생각하시는 것보다 훨씬 능동적이에요.

기획서를 두고 사수님과 2번의 리뷰를 진행했는데, 이때 들었던 내용 중 기억에 남는 말이 있었다.


"협업하는 개발자 분들은 생각하시는 것보다 훨씬 능동적이에요."


개발자가 능동적이라는 것은 문서와 상황의 흐름을 이해하며 더 좋은 방법을 찾아 개발하는.. 즉 개발서만 보고 개발하는 것이 아닌 보다 주도적으로 생각하고 의견을 제시하는 사람들이 아닐까.


현재 재직 중인 회사가 딱 그렇다. 직무와 상광없이 구성원들이 자신이 담당한 제품에 몰입하고 있는 상황이고, 구성원들이 제품에 대한 몰입도가 높을 때 이런 상황 자주 확인할 수 있다고 생각한다.


이 경우에는 개발자들의 상상력과 자율성을 침해하면 안 되기 때문에 너무 디테일한 부분까지 기획에서 말하는 것이 되려 손해다. 이때는 이미 우리가 학습한  멘탈모델 믿고 용기를 기획서에서 힘을 빼는 용기를 가져야 한다. (나도 이 부분이 힘들다.)

예를 들어 '전체 체크박스'의 동작 로직처럼 "하위 체크박스 중 하나라도 체크가 해지되면 전체 체크박스의 체크를 해지해 주세요."와 같은 것을 말할 수 있다.



획서를 어느 정도 깊이까지 작성할 것인가?

신입 시절, 기획서를 막 작성하기 시작했을 때는 기획서는 무조건 디테일할수록 좋다고 생각했었다. 누구나 경험적으로 알 수 있을법한 기능까지 꼼꼼하게, 일종의 백과사전을 만드는 것이 '잘하는 기획자'라고 생각했기 때문인 것 같다.


하지만 이제는 너무 디테일한 기획서는 되려 배려가 없을 수도 있다고 느낀다. 특히 기획이 디테일 해질수록 기획서를 봐야 하는 직무들이 해야 하는 생각과 역할, 그들의 영역을 침범하기 때문다.


가령 주민번호를 입력하는 인풋박스에 대한 기획을 한다고 가정해 보자.


주민번호 앞자리, 뒷자리를 입력하는 인풋박스를 각각 분리하고 디자인에도 신경을 쓴 화면을 설계하여 디자이너에게 전달했고, 인풋박스의 유효값을 걸어달라고 숫자만 입력 가능한 정규표현식까지 작성한 스토리보드를 개발자에게 전달했다.


이 기획서를 받은  디자이너와 개발자는 어떻게 될까? 이들은 깊게 생각할 필요가 없다. 디자이너는 톤앤매너에 맞게 마진 조절 등 약간의 디자인 마사지 후 디자인을 종료하면 되고, 개발자는 정규표현식을 쓰는 방향으로만 유효값을 걸어 개발하면 된다. 사실은 주민번호를 하나의 인풋박스로 디자인하는 것이 서비스의 사용자 경험에 더 좋을 수도 있고, 정규표현식 말고 다른 간편한 방법을 사용해 유효값을 거는 코드를 개발하는 것이 더 효율적일 수도 있다.


너무 디테일한 기획은 그들의 생각을 기획서에 매몰시키고, 참신한 생각할 기회를 뺐는다. 그렇기 때문에 기획서를 어느 정도 깊이로 작성할 것인지 고민해야 한다.


이 때문에 애자일을 추구하는 조직일수록 상세 기획은 유저 스토리* 정도 까지면 작성하고 이후 작업을 개발자와 디자이너들에게 맡기기도 한다. 사용자가 어떤 가치를 위해 뭘 해야 하는지만 명시해서 전달하고, 이를 해결하는 방법은 그들이 찾게 하는 것이다.


이는 나중에 애자일에 대해 학습하면서 따로 기술하겠다.

*애자일 방법론에서, 유저 스토리(User Story)는 기능의 요구사항을 사용자의 관점에서 간결하고 이해하기 쉽게 기술한 것이다. 유저 스토리는 주로 소프트웨어 개발 프로젝트에서 요구사항을 수집하고 이해하는 데 사용된다.
**유저 스토리 포맷: [누구]는 [비즈니스 가치]를 위해 [기능]할 수 있어야 한다.



무거운 기획서, 가벼운 기획서

앞서 사수님이 한 말로 돌아가서, 사수님께서 내 기획서를 보고 말씀하신 말은 상당히 정확한 이었다고 생각한다. 어느 정도 기대한 답변이기도 했다.


이번 기획서를 작성할 때 가장 고민했던 것은 '무거운 기획서'를 만들 것인지, '가벼운 기획서'를 만들 것인지였기 때문이다. 인용한 말은 아니고 남들에게 기획서를 설명할 때 내가 주로 사용하는 말이다. 간단하게 정리하면 아래 사진과 같다.

무거운 기획서 vs 가벼운 기획서 ⓒ 327roy


1. 무거운 기획서

나는 무거운 기획서를 디자이너와 개발자가 '이쁘게 디자인하는 것'과 '기획서대로 개발'에만 집중하면 되게 만드는 기획서라고 정의한다. 서비스 기획자가 디자이너와 개발자가 따라야 하는 세부 스펙(UX, UI 컨셉, 기능 동작 로직 등)까지 모두 작성한 기획서를 건네주는 것이다. 그리고 기획서를 받아 든 디자이너와 개발자는 기획서대로 UI를 그리고, 개발을 진행하도록 유도한다.


이 형태로 기획서를 만들게 되면 파일 용량이 커지거나 장표가 많아진다. 그래서 나는 이를 무거운 기획서라고 표현한다.


무거운 기획서는 기획서를 전달받은 개발자와 디자이너가 '개발'과 '디자인'에만 몰입하게 할 수 있다는 장점이 있다. 기획서를 이해하고 기획서대로만 작업하면 되기 때문이다. 이를 통해 그들이 그들의 업무 본질에 더 집중할 수 있는 환경을 만들 수 있고, 이 덕에 오히려 개발 프로세스가 빨라질 수도 있다. (특히 외주 디자인과 개발을 맡길 때 편함)


단점은 그들의 생각이 기획서에 갇힐 수 있다는 것이다. 그들이 할 수 있는 생각을 기획자가 대신해 주는 만큼 그들의 창의성이 제약되게 되고, 기획자의 업무 범위가 상당히 많아진다.


업계 선배 분들과 얘기를 나눴을 때, 이런 기획서는 업무 방식이 워터폴이 강한 회사에서 흔히 나타난다고 한다. 예를 들어 [전략/상품 기획팀의 상위 기획 → 서비스 기획자의 상세 기획  웹/서비스 디자인 개발  제품 완성]으로 업무가 이어지는 조직을 말할 수 있다.


애자일 방법론을 주축으로 사용자 관점 제품 개발의 중요성이 부각되고 있는 만큼 나는 그리 좋아하지 않는 기획서 유형이다.


2. 가벼운 기획서

나는 가벼운 기획서를 보다 덜 상세한 기획서, 즉 디자이너와 개발자에게 유저 플로우, UX 등에 대한 결정을 내릴 수 있는 더 많은 자유를 제공하는 기획서라고 정의한다. 이때 가벼운 기획서의 장점, 단점, 특징은 무거운 기획서와 서로 트레이드 오프된다고 말할 수 있다.


디자이너와 개발자는 생각의 자율성을 보장받으며, 이로 인해 디자인과 개발에 있어 훨씬 유연해진다는 장점이 있다. 또한 초기 기획 단계가 줄어드는 만큼 기획자의 공수 또한 줄어든다.  


단점은 산출물의 일관성을 유지하기 힘들 수도 있다는 것이다. 디자이너가 2명, 프론트/백엔드가 2명씩이라고 했을 때, 1명의 기획자가 만든 기획서를 보고 6명이 각자 해석을 하고 일을 진행할 수 있기 때문이다. 무거운 기획서의 경우 각 담당자들은 1명의 기획자와만 주로 소통을 하면 됐는데, 이제는 각 담당자가 나머지 6명의 담당자들과 소통을 해야 한다. 따라서 소통 비용이 증가할 수 있다. 이 때문에 기획서를 가볍게 작성할수록 기획자는 이들의 싱크가 일관되게 유지되도록 계속해서 신경을 써야 한다.

가벼운 기획서는 보통 조직의 업무 문화가 애자일해 질수록 나타난다. 실제로 극단적인 애자일을 추구하는 조직에서는 서비스 기획자가 맡던 상세 기획의 역할이 개발자에게 많이 이관되는 것을 볼 수 있다.



3. 따라서

따라서 기획서를 작성할 때는 어느 정도 깊이의 기획서를 작성할지 고민이 필요하다. 그리고 기획서의 깊이는 협업관계자들이 가장 효율을 낼 수 있는 형태가 되는 것이 바람직하다.


일단 이번 프로젝트에서 나는 디자이너와 개발자가 문서만 보면 바로 큰 고민 없이 작업을 진행하면 되는 정도로 기획서를 꽤 무겁게 작성했다.


이유는 1) 현재 조직의 파트별 담당자들의 성향을 모르고, 2) 개인적으로 구성원들로부터 의견을 들으며 이후부터 기획서의 볼륨을 덜어내는 작업을 하는 것이 더 효율적이라고 생각했기 때문이다.


단, 그들이 기획서에 매몰되지 않고, 피드백을 받기 위해 기획서 리뷰 시에 충분한 아이스브레이킹과 기획서를 왜 이렇게 만들었는지 설명하고 진행할 예정이다. 그리고 기획 시에 꾸준히 기획서 자체의 리뷰를 통해 기획서의 깊이(수준)를 점점 스펙아웃 시키며 완급을 조절할 생각이다.



그래서? 

무조건 효율적인 기획서나 무조건 정답인 기획서는 존재하지 않는다. 기획서를 읽는 사람의 수준, 배경지식, 성향, 시기 등 다양한 요인에 따라 기획서에서 받아들여지는 것이 다르기 때문이다. 


따라서 기획서를 잘 작성하기 위해서는 완급 조절이 필요하다. 그리고 완급 조절은 기획서를 읽는 사람들과 꾸준한 리뷰와 소통을 통해서 가능하다. 우리는 한 가지 유형의 기획서에 매몰되는 것을 조심하고, 상황에 맞는 기획서를 작성할 수 있는 능력을 기를 필요가 있다.


이번 글은 내 주관이 많이 담긴 글이다. 일전 유명 스타트업 출신의 전략기획팀장님과의 대화, 현재 회사의 셀장님 등 베테랑 기획자, 그리고 다양한 동료들과 협업을 하며 들었던 생각을 정리한 것이다. (사실은 그 생각을 가볍게 정리하고 싶었던 것인데 구구절절이 되어 버렸지만.) 글이 매끄럽지도, 주제가 일관된 것도 아닌 것 같지만 앞으로 생각을 더 잘 정리하기 위한 연습이라고 생각한다. 이 글은 꾸준히 읽어보며 남들에게 부끄럽지 않도록 계속 첨삭해야겠다.


부디 이 글을 정답으로 삼는 사람이 없길 빈다.



여담: 서비스 기획자, 디자이너, 개발자. 그들의 업무는 왜 겹칠까?

서비스 기획자와 디자이너 등 누구 하나의 업무 범위가 많아지면 서로의 영역을 침범하는 이유가 뭘까?


이 업계에 오래 계신 선배님들에게 이유를 물어보면 결국 서비스 기획자든, 디자이너든 IT 제품에서는 그 뿌리는 개발자기 때문이다. 웹 포털이 처음 나왔을 때는 개발자들이 HTML로 디자인도 하고, 필요시 화면에 어떤 기능을 넣어야 할지 상세 기획도 하곤 했다. 그리고 기술 빠르게 고도화되고, 영역별로 해야 할 것이 많아지니 영역은 세분화된다. 이로 인해 화면을 구현하던 개발자들은 퍼블리셔, 웹 디자이너 등으로 세분화됐고, 요구사항을 정리하고 상세 기획을 하던 사람들은 웹 기획자를 거쳐 점점 현재 우리가 생각하는 서비스 기획자가 되었다.


나는 이 때문에 IT에서 제품을 출시할 때까지 소모되는 기획↔개발↔디자이너의 업무의 총량은 비슷하고 생각한다. 그러니 기획 쪽에서 역할을 많이 가져가게 되면 나머지의 영역을 침범하는 것이고, 그 반대면 개발자와 디자이너가 기획을 하게 되는 것이 아닐까.

                    

ⓒ 327roy

매거진의 이전글 피그마로 서비스 기획 스토리보드 만들기
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari