by
Jun 20. 2023
무거운 기획서, 가벼운 기획서
인트로
24주 차에 이직한 곳에서 처음으로 상세 기획을 작성했다. (생각보다 빠르게 프로젝트에 인볼브가 돼 버림.) 완성 후 사수님과 리뷰를 먼저 진행했고, 현재 상황에 맞춰서 기획서를 일부 수정한 후 개발셀장님들과 함께 리뷰를 진행할 예정이다.
새 회사에서 첫 기획서를 작성라면서 들었던 여러 생각과 경험을 데일리 노트에 작성하려다 보니 글의 덩치가 꽤 커져서 따로 글을 분리했다.
이번 글에서는 기획서의 깊이와 고찰에 대해서 다룰 예정.
프로젝트 개요
이번 기획은 그리 어려운 내용은 아니었다. 자사 제품에는 관리자가 원하는 시점에 사용자들이 스스로 자신과 동료를 평가 할 수 있는 기능이 존재하는데, 기존에는 실시간으로 연동되는 데이터를 사용자가 조회하고 사용했다면 이후에는 1) 특정 트리거를 기준으로 데이터를 스냅샷하여 원본 데이터와 사본 데이터를 구분하고, 2) 사용자가 작업 시에는 사본 데이터를 가지고 작업을 할 수 있도록 하는 변경하는 정도였다.
우선 메인 시나리오는 이것이었고, 이 시나리오에 맞춰 화면의 UXUI까지 가볍게 변경하는 정도의 기획을 진행했다.
개발자 분들은 생각하시는 것보다 훨씬 능동적이에요.
기획서를 두고 사수님과 총 2번의 리뷰를 진행했는데, 이때 들었던 내용 중 기억에 남는 말이 있었다.
"협업하는 개발자 분들은 생각하시는 것보다 훨씬 능동적이에요."
개발자가 능동적이라는 것은 문서와 상황의 흐름을 이해하며 더 좋은 방법을 찾아 개발하는.. 즉 개발서만 보고 개발하는 것이 아닌 보다 주도적으로 생각하고 의견을 제시하는 사람들이 아닐까.
현재 재직 중인 회사가 딱 그렇다. 직무와 상광없이 구성원들이 자신이 담당한 제품에 몰입하고 있는 상황이고, 구성원들이 제품에 대한 몰입도가 높을 때 이런 상황 자주 확인할 수 있다고 생각한다.
이 경우에는 개발자들의 상상력과 자율성을 침해하면 안 되기 때문에 너무 디테일한 부분까지 기획에서 말하는 것이 되려 손해다. 이때는 이미 우리가 학습한 멘탈모델 믿고 용기를 기획서에서 힘을 빼는 용기를 가져야 한다. (나도 이 부분이 힘들다.)
예를 들어 '전체 체크박스'의 동작 로직처럼 "하위 체크박스 중 하나라도 체크가 해지되면 전체 체크박스의 체크를 해지해 주세요."와 같은 것을 말할 수 있다.
기획서를 어느 정도 깊이까지 작성할 것인가?
신입 시절, 기획서를 막 작성하기 시작했을 때는 기획서는 무조건 디테일할수록 좋다고 생각했었다. 누구나 경험적으로 알 수 있을법한 기능까지 꼼꼼하게, 일종의 백과사전을 만드는 것이 '잘하는 기획자'라고 생각했기 때문인 것 같다.
하지만 이제는 너무 디테일한 기획서는 되려 배려가 없을 수도 있다고 느낀다. 특히 기획이 디테일 해질수록 기획서를 봐야 하는 직무들이 해야 하는 생각과 역할, 그들의 영역을 침범하기 때문이다.
가령 주민번호를 입력하는 인풋박스에 대한 기획을 한다고 가정해 보자.
주민번호 앞자리, 뒷자리를 입력하는 인풋박스를 각각 분리하고 디자인에도 신경을 쓴 화면을 설계하여 디자이너에게 전달했고, 인풋박스의 유효값을 걸어달라고 숫자만 입력 가능한 정규표현식까지 작성한 스토리보드를 개발자에게 전달했다.
이 기획서를 받은 디자이너와 개발자는 어떻게 될까? 이들은 깊게 생각할 필요가 없다. 디자이너는 톤앤매너에 맞게 마진 조절 등 약간의 디자인 마사지 후 디자인을 종료하면 되고, 개발자는 정규표현식을 쓰는 방향으로만 유효값을 걸어 개발하면 된다. 사실은 주민번호를 하나의 인풋박스로 디자인하는 것이 서비스의 사용자 경험에 더 좋을 수도 있고, 정규표현식 말고 다른 간편한 방법을 사용해 유효값을 거는 코드를 개발하는 것이 더 효율적일 수도 있다.
너무 디테일한 기획은 그들의 생각을 기획서에 매몰시키고, 참신한 생각할 기회를 뺐는다. 그렇기 때문에 기획서를 어느 정도 깊이로 작성할 것인지 고민해야 한다.
이 때문에 애자일을 추구하는 조직일수록 상세 기획은 유저 스토리* 정도 까지면 작성하고 이후 작업을 개발자와 디자이너들에게 맡기기도 한다. 사용자가 어떤 가치를 위해 뭘 해야 하는지만 명시해서 전달하고, 이를 해결하는 방법은 그들이 찾게 하는 것이다.
이는 나중에 애자일에 대해 학습하면서 따로 기술하겠다.
*애자일 방법론에서, 유저 스토리(User Story)는 기능의 요구사항을 사용자의 관점에서 간결하고 이해하기 쉽게 기술한 것이다. 유저 스토리는 주로 소프트웨어 개발 프로젝트에서 요구사항을 수집하고 이해하는 데 사용된다.
**유저 스토리 포맷: [누구]는 [비즈니스 가치]를 위해 [기능]할 수 있어야 한다.
무거운 기획서, 가벼운 기획서
앞서 사수님이 한 말로 돌아가서, 사수님께서 내 기획서를 보고 말씀하신 말은 상당히 정확한 말이었다고 생각한다. 어느 정도 기대한 답변이기도 했다.
이번 기획서를 작성할 때 가장 고민했던 것은 '무거운 기획서'를 만들 것인지, '가벼운 기획서'를 만들 것인지였기 때문이다. 인용한 말은 아니고 남들에게 기획서를 설명할 때 내가 주로 사용하는 말이다. 간단하게 정리하면 아래 사진과 같다.
무거운 기획서 vs 가벼운 기획서 ⓒ 327roy1. 무거운 기획서
나는 무거운 기획서를 디자이너와 개발자가 '이쁘게 디자인하는 것'과 '기획서대로 개발'에만 집중하면 되게 만드는 기획서라고 정의한다. 서비스 기획자가 디자이너와 개발자가 따라야 하는 세부 스펙(UX, UI 컨셉, 기능 동작 로직 등)까지 모두 작성한 기획서를 건네주는 것이다. 그리고 기획서를 받아 든 디자이너와 개발자는 기획서대로 UI를 그리고, 개발을 진행하도록 유도한다.
이 형태로 기획서를 만들게 되면 파일 용량이 커지거나 장표가 많아진다. 그래서 나는 이를 무거운 기획서라고 표현한다.
무거운 기획서는 기획서를 전달받은 개발자와 디자이너가 '개발'과 '디자인'에만 몰입하게 할 수 있다는 장점이 있다. 기획서를 이해하고 기획서대로만 작업하면 되기 때문이다. 이를 통해 그들이 그들의 업무 본질에 더 집중할 수 있는 환경을 만들 수 있고, 이 덕에 오히려 개발 프로세스가 빨라질 수도 있다. (특히 외주 디자인과 개발을 맡길 때 편함)
단점은 그들의 생각이 기획서에 갇힐 수 있다는 것이다. 그들이 할 수 있는 생각을 기획자가 대신해 주는 만큼 그들의 창의성이 제약되게 되고, 기획자의 업무 범위가 상당히 많아진다.
업계 선배 분들과 얘기를 나눴을 때, 이런 기획서는 업무 방식이 워터폴이 강한 회사에서 흔히 나타난다고 한다. 예를 들어 [전략/상품 기획팀의 상위 기획 → 서비스 기획자의 상세 기획 → 웹/서비스 디자인 개발 → 제품 완성]으로 업무가 이어지는 조직을 말할 수 있다.
애자일 방법론을 주축으로 사용자 관점 제품 개발의 중요성이 부각되고 있는 만큼 나는 그리 좋아하지 않는 기획서 유형이다.
2. 가벼운 기획서
나는 가벼운 기획서를 보다 덜 상세한 기획서, 즉 디자이너와 개발자에게 유저 플로우, UX 등에 대한 결정을 내릴 수 있는 더 많은 자유를 제공하는 기획서라고 정의한다. 이때 가벼운 기획서의 장점, 단점, 특징은 무거운 기획서와 서로 트레이드 오프된다고 말할 수 있다.
디자이너와 개발자는 생각의 자율성을 보장받으며, 이로 인해 디자인과 개발에 있어 훨씬 유연해진다는 장점이 있다. 또한 초기 기획 단계가 줄어드는 만큼 기획자의 공수 또한 줄어든다.
단점은 산출물의 일관성을 유지하기 힘들 수도 있다는 것이다. 디자이너가 2명, 프론트/백엔드가 2명씩이라고 했을 때, 1명의 기획자가 만든 기획서를 보고 6명이 각자 해석을 하고 일을 진행할 수 있기 때문이다. 무거운 기획서의 경우 각 담당자들은 1명의 기획자와만 주로 소통을 하면 됐는데, 이제는 각 담당자가 나머지 6명의 담당자들과 소통을 해야 한다. 따라서 소통 비용이 증가할 수 있다. 이 때문에 기획서를 가볍게 작성할수록 기획자는 이들의 싱크가 일관되게 유지되도록 계속해서 신경을 써야 한다.
가벼운 기획서는 보통 조직의 업무 문화가 애자일해 질수록 나타난다. 실제로 극단적인 애자일을 추구하는 조직에서는 서비스 기획자가 맡던 상세 기획의 역할이 개발자에게 많이 이관되는 것을 볼 수 있다.
