전지적 참견 시점 - 게임개발PM

우리는 어떠한 일을 진행하기 전에 계획을 세웁니다. 그 계획은 이루고자 하는 것에 비례해 거대해 집니다. 우린 이 계획을 지키기 위해 어떠한 노력을 할까요? 게임을 개발하는 것은 무척 재미있는 일이지만 매우 높은 복잡성을 가지고 있습니다. 이러한 게임 개발을 진행하는데 있어 우리는 모두 그럴듯한 계획을 세웁니다. 이 계획은 얼마나 잘 수행될까요? 본 세션에선 개발 일정관리부터 팀 내 커뮤니케이션, 로드 밸런싱 등 다양한 역할을 수행하는 게임 개발PM 직무와 프로젝트를 달성하는 방법에 대해 이야기 합니다.

물론, 은탄환은 없습니다.

Transcript

1. 왓 스튜디오 이해봄 개발PM은 왜 필요하고 무엇을 하는 존재일까? 전지적 참견시점:게임개발PM
2. 이번 발표는 이런 분들께 좋아요 와 구독 알람설정 • 개발PM이라는 단어를 처음 들어보신 분 • 개발PM이 무엇을 하는지 궁금하신 분 • 개발PM이 되고 싶은 분
3. 발표자소개 안광섭 • 넥슨 왓스튜디오 소속 • 5명의 개발PM이 존재 • 3년차 개발PM • 문과 → 경영학과 • 대학원생 (19학번) 자세한 소개는 haebom.dev 이해봄
4. 게임개발PM: 게임이 개발 되도록 하는 사람. ‘게임이 완성 되게', ‘일이 진행 되게’하는 것 아무리 제품이 좋아도 출시/완성 되지 않으면 사람들은 제품을 볼 수 없다. 즐길 수 없다. → 가난 → 탕진잼 불가 → 스트레스 → 건강악화 → 죽음 돈도 벌 수 없다
5. 오늘 이야기 할 주제
6. 오늘 이야기 할 주제
7. 오늘 이야기 할 주제
8. 오늘 이야기 할 주제
9. 뭐든지 합니다
10. 우리는 계획을 세워 본 적이 있다.
11. 그럼 얼마나 지켰나요?
12. 왜 이런 일이 일어날까?
13. Planning Fallacy
14. 그 일은 항상 당신이 예상한 것보다 더 오래 걸린다, 비록 호프스태터의 법칙을 고려했다고 해도 말이다. 호프스태터의 법칙 일을 마치는 데 예상한 것보다 더 오랜 시간이 걸리는 현상 계획오류 앞으로 닥칠 일에 대한 낙관적인 전망 때문에 실제 계획했던 일보다 더 많은 비용과 노력이 들어가는 오류 계획오류는 계획을 세울 때 부터 시작된다.
15. 계획: 6년안에 7백만 달러로 완공 현실: 16년에 1억 달러로 완공
16. 로저 뷸러의 연구 “계획 오류”에 대한 고찰: 왜 사람들은 업무완료 시간을 예측하지 못하는가? Exploring the "Planning Fallacy": Why People Underestimate Their Task Completion Times
17. 졸업논문을 작성하는데 소요되는 시간을 예측해 제출하세요.
18. 졸업논문을 작성하는데 소요되는 시간을 예측해 제출하세요. 단, “최선의 예상"과 "낙관적 예상“ 그리고 “비관적 예상"을 적어주세요.
19. 모든 것이 잘 풀린다면 27.4일 최선의 조건이라면 33.9일 모든 것이 엉망이어도 48.6일 ...정도 걸릴 것 같아요. 교수님!
20. 실제 논문 작성에 걸린 시간
22. 소망적 사고로 인한 낙관적편향
23. 다양한 직군의 다양한 이해관계의 충돌 직접 계획을 세우고 관리하면?
26. 다시! 오늘 이야기 할 주제
27. Project Manager 프로젝트 매니저 프로젝트 매니저(Project Manager)는 한시적인 일을 수행하는 데 있어서 관리 방법론에 따라 가장 효율적으로 추진하는 것으로 프로젝트의 계획과 실행에 있어서 종합적인 책임을 가진 직책 또는 직무이다. 위키피디아
28. 프로젝트 매니저 Project Manager
29. 프로젝트 매니저 Project Manager
30. 연예인 매니저 연예인이 한정된 시간에 최대의 효율을 낼 수 있게. • 연예인의 스케쥴 관리 • 새로운 프로그램 잡기 • 연예인 섭외 요청 대응
31. 프로젝트 매니저 프로젝트가 한정된 시간에 최대의 완성도를 낼 수 있게. • 프로젝트의 스케쥴 관리 • 새로운 일감 잡기 • 일감 추가 요청 대응
32. 그럼 게임개발PM은 어떤 일을 하나요?
33. 프로세스를 단순하게 표시하면... 디자인 & 기획 담당자 지정 및 개발 계획 수립 개발 진행 배포 및 후속조치
34. 디자인/기획 단계 무엇을 만들 것인가?
35. 문서 작성 확인 아이디어 기획문서 실무자
36. 우선 순위 정하기 S A B C 게임 진행 불가 이슈 게임 운영 불가 이슈 게임 플레이 지장 이슈 추후 스노우볼링 이슈 큰 문제는 없지만 수정되는 것이 좋은 이슈 수정 여부가 서비스에 큰 지장이 없는 이슈
37. WBS(Work Breakdown Structure) 피처 태스크 하위 태스크 하위 태스크 태스크 하위 태스크
38. WBS(Work Breakdown Structure)
39. 누가 어떻게 만들 것인가? 담당자 지정 / 개발 계획 수립
40. 일감 회의 • “문서가 없는 일은 진행하지 않는다”가 원칙 • 해당 문서로 일의 규모파악이 가능하도록 • 개발 파트장은 해당문서를 회의 전에 읽고 참여 • 이것을 “검토”라고 한다 • 검토 과정에서 작업일을 산정 • 일감 회의에선 산정한 작업일을 실제 배치하고 확정
41. 버퍼 확보 A작업 B작업 C작업 버퍼 A작업 버퍼 B작업 버퍼 C작업 버퍼
42. 문서화는 항상 중요합니다. 문서화 시간 < 전체 커뮤니케이션 시간
43. 개발 진행 희망편 현실편
44. 개발 진행 체크 하기 이삭 줍기
45. 체크 하기
46. 이삭 줍기
47. 배포 및 후속조치
48. 패치 노트 작성 초안 공지
49. 점검 진행
50. = 인프라 수치 등 후속 조치
51. 중간 광고 본 프로세스의 실제 예시는 여기서! 4월 25일 18시 10분 넥슨 B1 발표장
52. 이걸 더 자세히 들여다봅시다.
53. PM 업무 상기 시키기 분배 하기 결정 돕기 전달 하기
54. 상기 시키기 Reminding
55. 빈칸이 없는지 확인 작업자 인지 확인 변동 없는지 확인 작업자들은 잘 알고 있을까?
56. 다양한 협업툴 활용하기
57. 분배 하기 Load balancing
58. 폭이 좁아서 생기는 현상 사고로 인해 생기는 현상 병목 현상
59. 전달 하기 Messaging
60. 좋지 않은 소식을 전하는 것은 전달자에게도 유쾌한 일은 아닙니다. 그래도 누군간 말해야합니다.
61. 그래서.. 어떻게.. 뭐가.. 바뀐거지.. 밀도 낮은 정보 전달
62. 밀도 낮은 정보 전달
63. 밀도 높은 정보 전달 바뀌게 된 이유, 어떻게 바뀌는 지, 업무의 히스토리 등
64. 언제나 유용한 문서화
65. 결정 돕기 Decision Making
66. 결정 돕기
67. PM
68. 누가 “개발PM은 뭐하는 직업이래?” 물어봐도 대답 할 수 있습니다.
70. 그럼 개발PM은 어떤 역량을 가지면 좋나요?
71. PM 역량 맥락적 이해 능력 새로운 지식 습득 타협 하기 신뢰 주기
72. 맥락적 이해능력
73. 맥락적 이해능력 상황을 구조화하여 원인이 무엇인지 찾아보기 - 원인을 찾는 비용은 좋은 투자 이다.
74. 맥락적 이해능력 토마스 제퍼슨 기념관 이야기 기념관 벽과 바닥이 계속 부식된다... 왜?
75. 새로운 지식의 습득
76. 다양한 직군들 다양한 직군분들이 계시는 듀랑..아니 게임개발실
77. 새로운 지식의 습득
78. 주변에 있는 Specialist에게 물어보기
79. 신뢰 주기
80. 양치기 소년이 되지 않기 위해서... 거짓말도 손에 무엇이 들렸는지 보고...
81. 타협 하기
82. 변수의 발생 좋아서 만들어지는 변수는 없습니다.
83. 소프트 스킬 정성적인 능력이지만 매우 중요한 능력입니다.
84. 모두 급행열차엔 탈 수 없다. 모두 급행을 탄다면 일반 열차는 어떻게 될까요?
85. 약 3년 동안 게임개발PM을 하며 느낀점
86. 잘 기록하고 잘 정리하고 잘 결정하자
88. 질문 Q&A 의 시간이 부족하니 haebom.li@gmail.com 메일 주세요..
89. 감사합니다.