brunch

You can make anything
by writing

C.S.Lewis

IT 서비스 기획, 교과서가 없다고?

떠돌아다니는 흔적의 기획서들로 교과서를 만들어보자.

프로젝트를 시작하자 디자이너와 개발자가 질문한다.


‘지난번 작업할 때 이렇게 안 하기로 했어요.'

'더 보기 버튼, B페이지랑 동일하게 하면 안 되나요?'


신입이든 경력이든 새로운 회사에 기획자로 입사하면 알기 어려운 몇 가지가 있다.


1) 입사 전 작업들의 히스토리

2) 공통으로 정해진 정책들

3) 이 조직에서만 사용하는 용어


작업 때마다 히스토리에 대해 선임 기획자나 개발자에게 질문을 할 수는 있지만 어떤 걸 모르는지, 어떻게 질문을 해야 하는 지도 왠지 고민된다.


'어느 페이지를 봐야 알 수 있지?'

'어떤 분이 담당하는 페이지지?'

'이 내용은 공용 폴더에 있지 않을까?'


그래서 이런 자료, 저런 자료들을 찾아 읽어본다. 프로젝트 히스토리가 잘 정리되어 있는 회사도 있고 그렇지 않은 회사도 있겠지만 프로젝트를 진행하는 협업 툴(Jira와 같은)이 있다면 대략의 히스토리와 기획서가 떠돌아다닌다.


그중 담당 프로젝트와 유사해 보이는 UID(이하 기획서)를 하나 다운로드한다. 기획서를 열어 읽다 보면 약간은 이해가 되는 것 같다. 다운로드한 기획서를 그냥 읽으면 참고자료로만 사용하게 되지만 그 기획서를 잘 정리해 보면 기획의 교과서처럼 만들어 볼 수 있다.




기획서 자체로 보기보다
아래의 순서대로 정리해 보는 것이다.


담당자

목차

프로젝트 목적

변경 내용

작업 범위

개별 페이지

정의 케이스

정책

용어

서비스 Flow

기타

스펙 OUT



1. 담당자

우선 기획서를 참고할 때 담당자가 누구인 지 기입해 두면 함께 일하고 있는 기획자들이 각각 어떤 업무를 하는지 좀 더 빨리 파악할 수 있다. 그러면 이후 프로젝트 중 연관 이슈가 발생하거나 조율이 필요할 때 담당자를 찾기도 쉽고 히스토리 확인도 더 빨라진다.


2. 목차

이제 목차에서 살펴보아야 할 것은 작업의 비중이다. ‘아, 이 기획서는 이런 목차로 구성되었구나.'가 아니라, '이 내용을 왜 별도로 구분했을까?'를 살펴보는 것이 좋다.


예를 들어, Push 발송 관련 내용을 어딘가 포함하여 작성하지 않고 별도로 구분하여 목차로 작성했다면 Push 발송의 개발범위가 크거나 담당자가 별도로 있는 작업일 수 있다. 기존 구조와 달리 수동 발송을 위한 어드민이 필요하거나, 발송 대상자를 새로 추출하기 위한 별도의 테이블 생성이 필요하는 등 특이사항이 있을 수 있다.


3. 프로젝트 목적

프로젝트의 목적은 부서에서 또는 조직에서 중요하게 생각했던 과제에 대한 히스토리를 이해하는데 도움이 된다. 예를 들어, 프로젝트의 목적이 '사용자 LTV 증대'라고 기재되어 있다면 프로젝트 당시, 부서에서 관련 고민을 했거나 KPI일 수 있다.


4. 변경 내용

변경 내용을 살펴볼 때는 AS-IS와 TO-BE를 비교하기 전에 프로젝트 목적 달성을 위해 필요한 작업이었는 지를 먼저 생각해 보면 좋다.


앞서 예를 든 '사용자 LTV 증대'가 프로젝트의 목적인데, 변경 내용이 '로그인 페이지에 서비스 홍보배너 추가'라면 적절한 변경이었을까? 만약 리더가 '사용자 LTV 증대를 위한 방안'을 세워보라고 하면 같은 내용의 프로젝트를 제안했을지 상상해 보면 더 나은 기획이 떠오를 수도 있다.


이미 작업된 내용이긴 하지만 새로 입사했을 땐 가장 날 선 시각으로 바라볼 수 있기 때문에 이 과정을 가져보는 게 좋다.


5. 작업 범위

작업 범위를 통해서는 해당 프로젝트의 대상 페이지가 PC Web, 모바일 Web, 모바일 App, 어드민, 기타 등등 어디에 구축되어 있는지 알 수 있다.


예를 들어, 1) PC에는 있는데 App에는 아직 없거나 2) 모바일 Web가 App에는 있는데 PC에는 없는 페이지가 있을 수도 있다. 3) App만 존재해서 Web페이지가 없는 경우도 있고 4) 어드민은 아직 구축되지 않은 경우도 있다.


6. 개별 페이지

프로젝트에서 각각 페이지 정의는 프로젝트가 어떤 페이지에 영향을 미쳤는지 살펴보는 것과 동시에 관련된 페이지들을 알게 한다.


1) 새로 생성된 페이지

2) 연결된 페이지

3) 진입 경로로 활용되는 페이지

4) 콘텐츠 노출 페이지 등


이렇게 각 페이지 간 연관성을 살펴볼 수 있다. 서비스 Flow를 통해서도 페이지 간 연결을 살펴볼 수 있지만 Flow에서는 더 중요한 내용을 살펴보기로 한다.


7. 정의 케이스

기획서에서 정의된 케이스들에 대해서는 따로 리스트업을 하면 큰 도움이 된다.


1) 비로그인 상태로 진입한 경우

2) 웹에서 진입한 경우

3) 공유하기를 통해 진입한 경우

4) 페이지에 접근할 수 없는 경우

5) 서버에서 사진을 호출할 수 없는 경우 등등


기획을 하다 보면 예상하지 못한 케이스가 왕왕 발생하는데 선임 기획자가 기획서에 이미 녹여 둔 케이스들을 참고하여 따로 기입해 두면서 나만의 케이스 정리 노트가 생긴다. 기획서를 추가로 여러 개 보다 보면 예외 케이스들도 더 많이 발견할 수 있다. 그렇게 나만의 케이스 노트가 완성될수록 놓치는 케이스도 줄어들고 더 완성된 기획을 할 수 있다.


8. 정책

공통 정책이 정의된 페이지가 있다면 이 페이지는 꼼꼼하게 읽어보는 게 좋다. 정책은 서비스마다 각각 다르기 때문에 타 서비스 벤치마킹을 통해 참고하는 것보다 선임 기획자의 기획서를 참고하는 것이 더 좋다.


예를 들어, 작성 가능한 글자 수, 특수문자 입력, 이모지 입력 등에 제한 정책이 표기되어 있는 경우에는 입력 관련 기능을 기획할 때 공통적으로 제한 내용을 기획할 수 있다. 또 썸네일 정책이나, 배치, Push 발송 정책, 개인정보보호 정책, 서비스 문구 정책, 페이지 또는 기능 별 이용회원 구분 등 다양한 영역의 공통 정책은 미리 숙지하면 정책 정의가 필요할 때 더 잘 정의할 수 있다.


9. 용어

신입 기획자는 익숙하지 않은 용어가 많고 경력 기획자의 경우에도 서비스마다, 회사마다 사용하는 용어가 조금씩 다르기 때문에 기존 기획서를 통해 이 회사에서는 어떤 용어를 사용하고 있는지 따로 리스트업 하는 것이 좋다.


용어를 다르게 사용하면 커뮤니케이션을 비효율적으로 할 수밖에 없다. 제대로 이해하지 못하거나, 다르게 이해해서 발생하는 혼선은 프로젝트 개발 시 더 큰 이슈로 이어지기 때문에 용어에 대해서는 번거롭더라도 리스트업 하며 익숙해지는 게 필요하다.


10. 서비스 Flow

서비스 Flow가 중요한 이유는 화면 간 이동 보다도 예외 케이스 발견에 용이하기 때문이다. 예를 들어, 편집 페이지에서 내용을 작성하고 '완료' 시킬 때까지의 Flow를 작성하다 보면 '필수 내용을 작성했는지' '글자 수를 초과하지 않았는지' '작성 내용에 비속어는 없는지' 등 로직 상 확인해야 하는 다양한 케이스들을 미리 파악해 볼 수 있다.


또 '완료' 버튼을 누르는 시점에 로직 상 오류가 있는 케이스에 대해 어떤 팝업을 띄워야 하는지, 팝업들의 우선순위는 뭘 지 등도 기획할 수 있다. 참고하는 기획서는 이미 서비스가 론칭되었을 가능성이 높기 때문에  Flow를 직접 그려 보고 실제로 상상한 Flow 대로 서비스가 구현되는지 체험해 보면 자연스러운 Flow가 어떤 것인 지 참고해 볼 수 있다.


11. 기타

앞서 언급되지 않은 기타 페이지들도 존재한다. 프로젝트에서 발생하는 팝업 페이지만 모아둔 페이지, 사용되는 컴포넌트만 모아둔 페이지, 데이터 테이블만 모아둔 페이지, 카카오 알림톡이 발송되는 경우 알림톡 문구모음 페이지, 홍보 배너 디자인이 작업 범위에 포함된 경우 배너 모음 페이지까지!


기획자가 얼마나 상세하게 기획서에 담는지에 따라 다양할 수 있다. 이런 기타 페이지들도 참고해 보면 어떤 내용은 별도로 추리는 게 도움이 되는지 알 수 있다.


12. 스펙 OUT

기획서를 보다 보면 처음 기획된 내용에서 제외된 기능들이 있다. OUT스펙들 중에는 개발 공수가 너무 커서 일정 상 미뤄지는 경우도 있고 해당 기능 구현에 불필요하여 OUT 되는 경우도 있다. 이런 케이스들도 미리 살펴보면 프로젝트 진행 시 개발 공수를 미리 예측해 볼 수 있다.




기획서 하나를 이렇게 정리해 보면 그냥 읽어보는 것보다 프로젝트에 대해 더 많은 내용을 이해하게 된다. 그렇게 참고하는 기획서가 하나 둘 늘어나면 하얀 PPT를 홀로 외롭게 채우던 때보다 조금은 감이 온다.


물론 모든 선임 기획자의 기획서가 교과서로 삼을 만큼 잘 작성되어 있지는 않을 수도 있다. 작업 범위가 작을 수도 있고, 개발자와 직접 커뮤니케이션하면서 조율한 경우도 있다. 업데이트가 덜 된 기획서도 있을 수 있다.


그럼에도 검색을 통해 기획서 작성법을 찾거나 온라인 강의를 신청하는 것보다(신입시절 했던 방법들...) 재직 중인 회사의 서비스 이해를 위해서는 히스토리, 여러 이슈들을 파악할 수 있는 선임 기획자의 기획서가 큰 도움이 될 것이다.






이전 02화 사수 없이 론칭까지! IT 서비스 기획자가 되었다면?
brunch book
$magazine.title

현재 글은 이 브런치북에
소속되어 있습니다.

작품 선택

키워드 선택 0 / 3 0

댓글여부

afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari