2. 발표자 소개
• 현재 메이플스토리2 프로젝트에 참여 중
• 올해 12년 차 게임 기획자
• 2018 NDC '메이플스토리2' 악기 연주 개발 사례로 보는 시스템 기획
• 참여 프로젝트 (2007~)
• 스쿼드플로우(PC)
• 미소스
• 클럽 오디션 (PC)
• 그 외 미 출시 프로젝트들….
• 전공
• 정보보호학과
21. 기획서를 잘 쓰기 위한 팁
1. 생각하기
① 기획 의도
② 개발 방향 및 목표
2. 쓰기
① 읽는 대상에 따라 다르게 쓰기
② 기획서는 어떤 형태로 쓸까?
③ 어디까지 써야 할까?
3. 고치기
① 기획서 공유 전에 고치기
② 개발 진행 과정에서의 수정
③ 최신 버전 유지하기
22. 1-① 기획 의도 생각하기
시스템 기획서 잘 쓰는 법
1. 생 각 하 고
2. 쓰 고
3. 고 치 자
28. 기획 의도를 모른 채 진행한다면?
우리 탈것 만들 건데
우리도 몬스터 있으니까
그걸 사용해서 쉽게
캐릭터가 탈 수 있게 합시다.
이런 식으로 참고해서
가까이 가면 잡아 타는 거지….
다 있는 기능이니까
다음달에 투입할 수 있죠?
29. 기획 의도를 모른 채 진행한다면?
이거 이 일정으로는 안될 것 같은데요.
지금은 그렇게 못해요.
캐릭터를 다른데 붙일 수 없고
그렇게 하려면
개발 비용 많이 드는데 괜찮나요?
아니면 태울 수는 있는데 이동
속도는 못 바꿔요
30. 기획 의도를 모른 채 진행한다면?
일단 몬스터를 타라고 했으니까
몬스터만 타면 되겠지?
탈 것인데
속도가 그대로면 왜 타?
31. 의도를 잘 모를 때는 물어보자.
• 업무 지시를 할 때 의도를 같이 이야기 해 준다.
• 그래도 의도를 모르겠다면 상사에게 다시 확인하자.
이 시스템이 왜 추가되나요?
32. 의도를 알 수 없는 경우에도 의도를 찾자
• 의도를 말해주지 않는다면?
• 납득할 수 없는 이유라면?
사장님이
하고 싶대…
33. 의도를 알 수 없는 경우에도 의도를 찾자
• 의도를 말해주지 않는다면?
• 납득할 수 없는 이유라면?
→ 그래도 어떤 의도를 가지고
기획할 것인지 생각하자.
이걸 왜 넣고 싶었을까?
이걸 넣으면 얻는게 뭐가 있을까?
34. 의도를 알 수 없는 경우에도 의도를 찾자
• 의도를 말해주지 않는다면?
• 납득할 수 없는 이유라면?
→ 그래도 어떤 의도를 가지고
기획할 것인지 생각하자.
→ 그리고 확인해보자이런 의도를 가지고
개발해 보려고 합니다
35. 아무리 생각해도 떠오르지 않는 경우도 있다.
• 디테일만 정해서 오기도 한다
홍시 개발 요청이 와서 만들었는데
왜 홍시를 만들었냐고 물으시면
그냥 홍시를 만들어 달라고 해서 홍시를…
→ 퍼블리셔님께서
딱! 홍시를 원하십니다.
36. 그래도 역기획서를 쓴다 생각하고 고민해보자
• (원하지 않았더라도) 결국 내가 싼 X은 내가 치우게 됨
37. 의도에 따라 개발 목표가 달라지기 때문
할 것 의도 목표
커피숍 가기 너와 이야기하고 싶어
대화하기 좋은
커피숍 찾기
후식으로
단 음식이 먹고 싶어
달달한 후식을 파는
커피숍 찾기커피
마실래?
38. 기획서에도 의도를 추가하자
1. 개발 이유를 설명해주는 기획 의도
• 왜 이 시스템을 개발하는지
• 이 시스템을 만들어서 얻고자 하는 것이 어떤 것인지
2. 개발 방법을 설명해주는 기획 의도
• 어떤 것을 원하기 때문에 이렇게 했는지
• 이 UI는 왜 이렇게 설계했는지, 왜 귀찮게 팝업을 여러 번 띄우는지 등
→ 업무 지시를 받을 때 확인
→ 세부 기획 시 진행
기획 의도가 있으면 더 이해가 쉽다
39. 기획서에 기획 의도가 있으면 좋은 점
• 설득의 근거가 된다.
• 왜 하는지, 왜 이렇게 하는지에 대한 이유가 된다.
• 기획 방향이 흔들리지 않는다.
• 방법을 바꿔야 할 때 방법에 얽매이지 않고 다양한 방법을 찾아볼 수 있다.
• 개발 과정에서 더 좋은 방법을 찾을 수 있다.
• 구현 과정에서 기획 의도에 맞는 더 좋은 방법을 찾을 수도 있다.
40. 1-② 개발 방향 생각하기
시스템 기획서 잘 쓰는 법
1. 생 각 하 고
2. 쓰 고
3. 고 치 자
41. 개발 방향 생각하기
• 어떤 방향으로 개발할 것인지
• 다음 포인트 체크하고 아래 내용을 만족하는 방향으로 진행
• 시스템을 투입하는 의도 확인
• 투입 의도 외에 추가 지시 사항
• 지시 사항에는 없지만 추가로 더 신경 쓸 것
42. 개발 방향과 구현 목표
• 개발 방향
• 의도를 만족 시키기 위해 어떤 것을 신경 쓸 것인지
• 투입 의도 외의 추가적인 지시 사항을 포함하자
• 구현 목표
• 개발 방향을 만족시키기 위해 어떻게 만들 것인지
• 이 내용을 구체화하면 세부 기획 내용이 된다.
→ 개발 방향이 결정되면 어떻게 구현할 것인지가 나온다.
43. 기획 의도와 개발 방향, 목표 생각하기
• Case. 상사가 새로운 일일 미션을 만들라고 한다.
• 퍼블리셔 측에서 최고 레벨 도달 후 이탈에 대한 해결책을 제안
• 플레이 성향에 따른 일일 미션을 만들어서 가이드를 주자고 함
• 하지만, 이미 일일 미션이 있음
• 그리고 미션 외에도 유저들은 매일 해야 할 숙제가 많아 부담되는 상황
• 기간은 몇 달 남지 않음
45. 기획 의도와 개발 방향, 목표 생각하기
• 아래와 같은 형태로 써 보자.
→ 왜 하는지
→ 뭘 신경 쓸 건지
→ 어떻게 개발할 건지
46. 하위 단계에서도 계속 하기
• 목표 및 방향 설정은 세부 단계로 내려가도 계속 해야 함
해야 할 것
(Task)
왜 하는지
(Why?)
뭘 할건지
(What?)
어떻게 할건지
(How?)
47. 하위 단계에서도 계속 하기
• 목표 및 방향 설정은 세부 단계로 내려가도 계속 해야 함
해야 할 것
(Task)
왜 하는지
(Why?)
뭘 할건지
(What?)
어떻게 할건지
(How?)
왜 하는지
(Why?)
해야 할 것
(Task)
뭘 할건지
(What?)
어떻게 할건지
(How?)
48. 2-① 대상에 따라 다르게 쓰기
읽는 대상에 따라 기획서를 다르게 쓰자
시스템 기획서 잘 쓰는 법
1. 생 각 하 고
2. 쓰 고
3. 고 치 자
49. 하나의 문서에 다 있으면 읽기 힘들다
30페이지 이상
폰트 사이즈 9
목차만 3페이지
이거 하나면 끝!
50. 하나의 문서에 다 있으면 읽기 힘들다
• 실무자는 자신에게 필요한 내용만 보고싶어 한다.
제가 기획서에
다 적어 뒀는데
왜 못 찾으시죠?
그래서 A는 어디에
있죠?
51. 기획서를 보는 대상에게 필요한 내용을 쓰자
A. 프로그래머가 보는 기획서
B. UI 디자이너가 보는 기획서
C. 퍼블리셔에게 전달하는 기획서
+ @ 상사에게 제안을 위한 기획서, 개발 여부 검토를 위한 기획서
52. 프로그래머가 보는 기획서
• 실제 구현에 필요한 내용을 적는다.
• 필요에 따라 테이블 구조, 데이터 속성 값, UI 동작 및 조작 프로세스, 각종 예외
처리
53. 프로그래머가 보는 기획서
• 실제 구현에 필요한 내용을 적는다.
• 필요에 따라 테이블 구조, 데이터 속성 값, UI 동작 및 조작 프로세스, 각종 예외
처리
54. 프로그래머가 보는 기획서
• 처음부터 완벽하게 쓰기는 힘들다.
• 다듬기 과정이 너무 오래 걸리지 않도록
• 시간이 부족하면 쪼개서 전달 할 수도 있다.
→ 어차피 수정해야 함
63. 기획서에 공통으로 있어야 하는 것
• 기획 의도 및 제공 방향
• 전반적인 기능에 대한 설명, 이용 흐름
→ 작업 과정에서 더 좋은 방법을 고민할 수 있음
64. 공통으로 있어야 하는 것
• 기획 의도 및 제공 방향
• 전반적인 기능에 대한 설명, 이용 흐름
→ 작업 과정에서 더 좋은 방법을 고민할 수 있음
65. 2- ② 어떤 내용이 들어가야 할까?
시스템 기획서 잘 쓰는 법
1. 생 각 하 고
2. 쓰 고
3. 고 치 자
66. 시스템 기획서 – 순서도 = 0?
• 꼭 순서도가 있어야 하는 것은 아니다.
→ 순서도가 필요한 이유는 흐름을 정리하는 용도
67. 시스템 기획서 – 순서도 = 0
• 문서에는 순서도가 없어도 괜찮다
• 너무 간단한 것까지 적을 필요 없음.
• 오히려 잘못된 순서도는 혼란만 가중시킴
• 필요에 따라 순서도를 사용하자
• 순서도가 필요할 만큼 복잡하다면 추가
• 순서도는 흐름을 파악하기 위한 것
• 흐름을 정리하는 용도의 FLOW는 필요하다.
• 기획 정리를 할 때는 순서도로 흐름을 확인하면 편하다.
68. 순서도의 좋은 점?
• 세부 사항에 대한 흐름까지 체크
• 놓친 부분을 확인하기 좋다.
• 예외처리 사항 체크가 쉽다.
→ 도움이 되는 도구이지만 순서도가 꼭 있어야 하는 것은 아님
69. 순서도보다 흐름에 집중하기
• 순서도도 중요하지만 다른 내용들도 중요
• 순서도를 그릴 때는 논리흐름이 잘 맞는지 확인하기
→ 전체 흐름에 대한 전달이 더 중요
70. 시스템 기획서에는 뭘 써야 할까?
• 급하게 기획서를 가져갈 경우 많이 듣는 질문들
이거 왜 만들어요? 꼭 해야 해요?
이건 어떻게 동작해요?
이런 상황에서는 어떻게 하나요?
→기획 의도
→ 기능에 대한 디테일한 설명
→ 예외처리
71. 시스템 기획서에 들어가야 하는 것
• 예외처리
• 룰에서 벗어난 경우 어떻게 할 것인지
• 특별한 경우 강조하기 위한 예외처리
→ 특히 프로그래머가 보게 되는 기획서!
→ 시간이 부족해도 많이 발생할 수 있는 예외 상황은 꼭 넣자
72. 시스템 기획서에는 뭘 써야 할까?
• UX를 고려한 데이터 설정 구조
• 유저를 위한 UX 고려하기
• 개발자를 위한 UX 고려하기
설계할 때 미리 고려하자
73. 시스템 기획서의 필수 요소
• 기획 의도
• 기능에 대한 설명
• 기능을 구현하기 위한 내용
• 데이터 설정 방식에 대한 내용
시스템 기획서는
기획 의도를 만족시키고, 방향에 맞는 결과물을 만들 수 있게 설명하는 도구
→ 읽는 대상에 따라
74. 2-② 어떤 문서 도구로 쓸까?
Word? PowerPoint? Excel? 어떤 것이 좋을까?
시스템 기획서 잘 쓰는 법
1. 생 각 하 고
2. 쓰 고
3. 고 치 자
75. 보는 사람이 읽기 좋은 포맷이 좋다
• 기획서의 목적은 잘 전달하는 것
• 전달하고자 하는 내용을 가장 잘 표현할 수 있는 도구 사용
• 팀마다 정해진 양식이 있는 경우도 있으나, Office 를 제한하지는 않음
76. 상황에 따라 다양한 형태로 남기도 한다.
• 바쁠 경우 Redmine과 같은 BTS, E-mail 등으로 대체할 때도 있다.
→ 단, 이 경우 나중에 찾기 힘들 수 있다.
77. 가장 효과적으로 전달할 수 있는 포맷 선택
• UI가 많다면 Power Point로, 테이블이 많다면 Excel 등
• 말하고자 하는 내용을 잘 표현할 수 있는 포맷 선택
Word PowerPoint Excel Redmine
78. 문서 작성하기
• 대상에 따라 다르게 쓰자
• 양식보다는 필요한 내용 위주로 쓰자
• 문서를 보고 결과물을 만들어 낼 수 있어야 한다
• 흐름은 필요하지만 꼭 순서도일 필요는 없다
• 기획 의도는 항상 중요하다
80. 기획서 공유 전에 읽고 고치기
• 당연하고 모두 아는 이야기지만 지키기 어려움
• 바쁘고 정신 없으면 지키기 힘들다
• 공유 전에 기획 의도와 방향에 맞는지 잘 살펴보자
• 기획서를 쓰다 보면 산으로 가는 경우가 있다.
81. 3-② 개발 진행 중 수정 사항
시스템 기획서 잘 쓰는 법
1. 생 각 하 고
2. 쓰 고
3. 고 치 자
82. 개발 진행 시 수정 사항이 생긴다.
• 완벽한 기획서는 없다.
• 기획 의도를 만족시키는 방법을 다양하게 고민해 보아야 함
• 기획서 작성 후 충분히 변경될 수 있다.
• 개발 회의에서 변경되는 경우
• 작업 도중 예상치 못한 이슈로 변경되는 경우
• 변경되더라도 기획 의도는 만족시켜야 한다.
• 기획 의도가 시스템을 개발하는 목적
83. 3-③ 최신 버전 유지하기
시스템 기획서 잘 쓰는 법
1. 생 각 하 고
2. 쓰 고
3. 고 치 자
84. 개발 진행 시 변경 사항 반영하기
• 기획서 작성 후 내용이나 방향이 변경될 수 있음
• 개발 회의에서 변경되는 경우
• 작업 도중 예상치 못한 이슈로 변경되는 경우
• 변경되더라도 기획 의도를 만족시키는 방향으로 변경되어야 함.
• 변경된 기획 내용을 반영하기
85. 기획서는 항상 최신 버전으로 유지하자
• 다 알고 있지만 생각만큼 잘 안된다.
• 막상 업데이트 후 정리할 시간 부족
• 나중으로 미루다가 쌓여서 손대지 못하는 상황이 온다.
• 히스토리 파악 및 인수인계가 힘들다.
• 어떤 문서가 최신인지 알기 힘들다
• 구전으로 내려오는 내용이 많을수록 인수인계가 힘들다.
일반적으로
시스템 기획이라고 하면 뼈대를 만든다고 많이 얘기 하고요
게임의 규칙을 정의하는 걸 시스템 기획이라고 합니다.
반면에
콘텐츠 기획은 살을 붙인다고 해요.
이미 만들어진 기능들을 사용해서 다양한 즐길 거리들을 제작한다고 해요
이렇게
기획 의도는 결국
이걸 왜 할까에 대한 이야기인데요
(클릭하면서)
기능 개발 이야기를 해 보자면,
첫번째로 이야기 한
기획 의도 생각하기에 이어
다음으로
생각해야 하는 내용은 개발 방향입니다.
어떻게 할건지가 나오면,
다시
해야할 것, 그리고 뭘할건지와 어떻게 할건지 이런 식으로 내려가게 됩니다.
결국
그 상위 단계에서 뭘 할건지에 따라서 하위 단계에서 왜 하는지가 나오는데요.
이때 이 단계의 왜 하는지는 여전히 상위 단계의 왜 하는지를 가리키고 있어야 합니다.
(물마시기)
테이블 이름 같은 경우는 기획자도 같이 보는 영역이라서
기획자가 보고 이해하기 쉬운 이름으로 정하는 경우가 많은데요
코드 내의 변수를 뭘 쓴다거나 변수 이름까지 정해줄 필요는 없습니다.
데이터 자료형같은 경우에도,
꼭
자료형을 알아야 한다기 보다는
여기에서는 양수를 쓸 거고 어느정도 범위까지 필요해요 이런 정보들이 필요합니다.
그럼
알아서 구현할 때 거기에 맞는 자료형을 써 줍니다.
(물마시기)
(프로그래머용 끝)