Closed fkdl0048 closed 10 months ago
옵시디언으로 주요 내용 정리하고 글감이 정해지면 글로 써서 정리 후 아카이브에 개시
PM이란, Project Manager의 약자로 프로젝트를 관리하는 사람을 말한다.
최근 GameOver라는 게임을 기획하고 팀원을 모집하면서 해당 팀내에서 디렉터 겸 PM을 맡고 있다.(사실 기획도 하고 플밍도 하고 있다.)
프로젝트를 시작하기 전엔 PM에 대해서 나름 자신감이 있었다.
전에 참여한 팀이나 지금까지 참여한 팀에 대해서 프로젝트 협업 방식이나 진행 방식이 그렇게 마음에 들지 않았고, 여러번 직접 나서서 바꾸려고 노력했기 때문이다.
이런 삐뚤어진 생각을 가지고 답답한 것보다 "내가 직접 해보지 뭐!"라는 마인드로 호기롭게 시작했던 것 같다.
과거에 실리콘 밸리의 팀장들에서 읽은 팀장으로써 역할, 솔직함, 피드백, 관계, 성장.. 등 읽고 좋은 팀을 만나고 싶다는 생각도 했기 때문에 더욱 욕심이 나긴 했다.
하지만 게임회사의 PM이라면 조금 다른걸까? 실리콘 밸리의 팀장은 너무 대기업의 큰 팀의 이야기라 인디게임 팀에 적용하기 힘들 것일까? 애자일은 정말 이상적인 방법론인가?
최근에 너무 머릿속이 복잡해지고 있다고 생각했고, 이를 정리하기 좋은 시기라고 생각해서 글을 쓰게 되었다.
나의 생각만 가지고 떠들어 댈 수 없기 때문에 2019년도에 NDC에서 안광섭님이 발표하신 전지적 참견 시점 - 게임개발PM의 내용을 참고하여 내 생각과 비교하여 작성한다.
전지적 참견 시점 - 게임개발PM
내용을 읽기전 내가 적용하고 있는 방식을 간단하게 소개한 글이다. 현재 GameOver 프로젝트 진행 방식
개발 PM은 따로 정해진 문과나 이과의 제한이 없다.
게임 개발 PM은 게임 개발 되도록 하는 사람, 게임이 완성되게, 일이 진행되게 하는 것이 PM의 역할이다.
아무리 제품이 좋아도 출시/완성 되지 않으면 사람들은 제품을 볼 수 없다.
단순하게 PM의 업무를 키워드로만 나열해도 양이 엄청나다.
마일스톤, 커뮤니케이션, 업무 구조화, 회의, 신뢰 관계, 자료 조사, 인프라, 모니터링, 프로젝트 효율성, 지표, 문서화 등등.. (아마 이외에도 더 있을 것 같다.)
누구나 그럴싸한 계획을 갖고 있다 쳐맞기 전까지는 : 마이크 타이슨 "가장 완벽한 계획이 뭔지 알아? 무계획이야. 계획을 하면 모든 계획이 다 계획대로 되지 않는 게 인생이거든" : 기생충 명대사
누구나 그럴싸한 계획을 갖고 있다 쳐맞기 전까지는 : 마이크 타이슨
"가장 완벽한 계획이 뭔지 알아? 무계획이야. 계획을 하면 모든 계획이 다 계획대로 되지 않는 게 인생이거든" : 기생충 명대사
이처럼 계획에 관한 유명한 말이 되게 많다. 이것 말고도 생각나는 말들이 많은데..
여기서 공통점은 계획이 실패한다는 공통점과 그것을 이용한 공감성을 활용한다는 것이다.
사람들은 대부분 계획을 세우고 살지만 실제로 얼마나 지켜지는 것일까?
대부분은 아쉬운 결과를 항상 봤을 것이고 일상 생활이 아니라면 더욱 더 그럴 것이다.
그 일은 항상 당신이 예상한 것보다 더 오래 걸린다. 비록 호프스태터의 법칙을 고려했다고 해도 말이다.
쉽게 말해서 스스로를 과신하고 행복회로를 돌려 계획했지만 실패로 돌아가는 것이다.
이러한 계획 오류는 계획을 세울 때 부터 시작된다.
유명한 사례로 시드니의 오페라 하우스가 있다.
이러한 계획 오류는 일생생활에서도 많이 발생하고 특히 소프트웨어 개발에서 많이 발생한다.
발표 내용과 같이 나는 어느정도 계획 오류를 인지하고 있다.
아직은 프로? 숙련공?이 아니기 때문에 불확실성에 대응하지 못하고 실패할 때가 종종 있다.
위 ToDo에서 해당 날짜에 채워지지 못한 Task들이 그렇다. (이외에도 코멘트로 작성한 문제점들도 있다.)
하지만 계속 수정해 나가며 나름대로 계획오류에 대응하려고 한다.
개인적인 생각을 좀 정리해보자면 사람은 기본적으로 자기 자신을 과대평가하는 경향이 있다.
실제로 나도 자주 그랬으며, 대부분의 사람은 스스로를 과신한다.
그래서 계획할 때 시간내 하지 못하는 능력 밖의 일을 계획하고 실패한다. 그리고 반복한다.
이런 경험을 실제로 직접 해보고 다른 사람들의 계획 오류를 보는 기회가 있으면 쉽게 메타인지가 되기도 한다.
나는 매주 토요일에 10:30분부터 12:30분까지 진행하는 모각코(모여서 각자 코딩)에 참여한다.
매주는 아니지만, 그래도 이번년도에는 많이 참가했다. 4번을 참여하면 무려 아메리카노 쿠폰을 준다..!
해당 링크에 들어가보면 진행방식을 알 수 있지만 이슈가 생성되면 코멘트로 할일을 적고 해당 시간에 구글미팅으로 참여하여 2시간동안 진행하고 이후에 각자 소감을 말하고 종료한다.
처음 참여했을 땐, "이거하고, 저것도 하고, 이것도 해야지"하며 해야할 일을 추상적으로 적거나 지키지 못할 양을 적었다.
결과는 예상할 수 있는 실패였다.
이유는 단순하게 내가 2시간동안 할 수 있다고 생각한 일정이 사실은 불가능에 가깝고, 머리로는 2시간을 쓴다고 했지만 실제 집중하는 시간은 1시간 30분정도였다.
실제 회사에서 8시간을 근무하지 않는 것처럼
지금은 목표를 명확하게 세분화하고, 할 수 있는 분량을 적지만 처음에는 그랬다.
여기서 재밌는 점이 있는데, 새로 들어오신 분들도 무조건 2~3번까지는 항상 2시간 목표 달성에 실패하는 것이다.
물론 모두가 그렇다는 것은 아닌데(아닌 사람은 뭘 해도 잘할 사람..) 대부분의 사람이 계획 오류를 겪는다는 것이다.
내가 계획오류를 극복하는데 많이 도움이 된 글은 박종천 개발자님의 GPAM이다. (내가 정리한 글도 있지만 원문을 보는 걸 추천)
이외에도 프로젝트에서 발생하는 개발자의 추정또한 계획 오류의 주범이다.
개발자의 추정관련 글
게임 프로젝트는 다양한 직군, 다양한 이해관계의 충돌의 연속이다.
이를 직접 계획을 세우고 관리한다면?
복잡도가 증가함에 따라 매우매우 힘들어진다.
사람들은 PM하면 높은 직급 무거운 느낌을 상상할 수 있지만, 실제로는 그렇지 않다.
연예인 매니저의 모습에 가깝다.
연예인 매니저(한정된 시간에 최대의 효율을 낼 수 있게)
프로젝트 매니저(프로젝트가 한정된 시간에 최대의 완성도를 낼 수 있게)
디자인/기획 -> 담장자 지정 및 개발 계획 수립 -> 개발 진행 -> 배포 및 후속조치
무엇을 만들 것 인가?
여기서 PM은 무슨 일을 할까?
문서 작성 확인은 팀 기획자분이 잘 해주시고 계시지만 PM으로써 좀 더 신경써야 하는 부분이라 생각된다.
우선 순위 정하기이건 실제로 이건 매우 좋은 방법이라고 생각해 프로젝트에 도입 예정
우선 순위 정하기
WBS는 실제로 프로젝트에 적용되어 있다.
WBS
아쉬운 점은 플밍파트에서만 적용을 해서 아트, 사운드, 기획단위에서도 좀 병합이 필요할 것 같다.
한 Feature를 모두 같이 작업하는 환경으로 재구성할 에정
누가 어떻게 만들 것인가?
현재 프로젝트는 일감 회의를 정기 회의 때 정한다. (모두가 있을 때)
매 회의 때 빌드를 뽑아서 직접 플레이할 수 있도록 하고, 각 작업자가 자신의 작업 사항을 공유하고 이후에 진행할 작업을 공유한다.
모든 작업자가 자신의 작업 사항을 공유했다면, 마일스톤을 생성하고 각자 작업을 적고 일정도 기록한다.
버퍼 확보는 사실.. 각 이슈에서 작업 날짜를 지정해서 가져가기 때문에 개인이 스스로 버퍼를 두는 것 같다.
인디게임 팀 특성 상 온라인 작업만 하다보니 버퍼자체의 개념을 도입하기 어렵다.
문서화는 회의를 포함한 모든 내용을 최대한 세세하게 기록하는 것을 원칙으로 하고 있다.
정기회의를 포함한 비정기(아트, 기획, 플밍)회의 모두 내용을 기록하고 모든 팀원이 공유받을 수 있는 환경을 만드는 것이 원칙이다.
프로젝트의 모든 이슈에는 다 기록이 되어있다.
강연자님이 강조하시긴 했지만, 가장 중요한 점은 압박감을 주지 않는다는 것이다.
자칫 잘못하면 쉽게 넘어질 수 있기 때문에 문제가 발생하면 PM에게 말하면 된다는 것을 명확히 해야 한다.
프로젝트가 대면작업으로 진행되는 것이 아니기 때문에 나는 1달에 한번 인터뷰를 통해 작업시 어려운 점을 물어보고 있다. (공통적으로 나오는 부분, 개인적인 부분은 최대한 해결해주고 있다.)
이삭줍기는 아직 개발 초기 단계라 발생한지 잘 모르겠지만, 이를 확인하고 통계를 내기 위해선 문서화가 정말 중요해 보인다.
아직....! 멀었다 정안아!
크게 4가지를 뽑아주셨다.
상기 시키기, 분배 하기, 전달 하기, 결정 돕기
한 개발자는 한 기능만 작업하지 않는다.
여러 작업을 진행하기 때문에 PM은 작업자들에게 작업을 상기시켜야 한다.
또한, 작업자가 작업을 인지했는지 확인해야 한다.
현재 프로젝트는 작업자가 직접 디테일한 부분을 가져가기 때문에 걱정은 없지만 종종 회의 때 마일스톤에 대해서 다시한번 언급하여 강조하긴 한다.
개발에서는 러닝코스트가 드는 작업들이 병목현상이 발생한다.
작업자는 해당 일을 파악하기 위해서 시간이 필요하고, 이를 통해 작업을 진행하기 때문이다.
PM은 이를 먼저 파악해야 한다. (Board에서 변화가 없거나 WBS에서 작업이 진행되지 않는다면?)
좋지 않은 소식을 전하는 것은 전달자에게도 유쾌한 일은 아닙니다.
PM은 부정적인 전달하는 경우가 많다.
하지만 누군가는 말해야 한다.
밀도 높은 정보를 전달받아야 하는 것은 당연하다.
PM이 알고 있는 정보는 결정에 매우 유용한 정보이기에 이를 활용할 수 있도록 도와야 한다.
실제로 사람들을 이끌고 결정으로 이끄는 사람이 바로 PM이다.
맥락적 이해 능력, 새로운 지식 습득, 신뢰 주기, 타협 하기
업무적 맥락을 뜻한다.
이를 위해 문서화를 잘 해두는 것이 중요하다.
'자신의 일상을 문서화하여 자신의 삶을 개선했다'와 같은 형태도 매우 좋은 방향임
가장 중요한 것은 원인을 파악하는 것이다.
게임 개발 특성상 매우 다양한 사람들과 일하기 때문에 모든 직군에 대해 이해하는 것은 매우 어렵다.
PM은 마스터나 액스퍼트의 지식을 요구하지 않는다.
따라서 Generalist에 가까워지는 것이 중요하다.
개발자는 Specialist에 가깝다.
PM은 본의아니게 거짓말을 해야하는 경우가 생긴다. (일감에 대한..)
신뢰가 무너지지 않기 위해서 사전에 미리 말해두는 것이 중요하다.
좋아서 만들어지는 변수는 없습니다.
PM이 타협을 하면 프로젝트는 어떻게 진행하지?
PM이라도 모든 불확실성에 대해서 대응할 수 없다.
여기서 중요한 능력이 소프트 스킬이다.
최근에 읽고 있는 책 제목이라 신기하다..
개인적으로 PM이라는 직군에 대해 고민도 많았고 혼란스러웠는데 역시 생각을 깊게 하고 베테랑 PM분의 강연을 듣고 나의 생각을 정리하니 많이 도움이 되는 듯하다.
중간중간 개인적인 생각을 많이 적었는데, 또 1년이나 당장 몇 개월뒤에 달라질 생각이라도 이렇게 정리해놓고 이후에 본다면 얻어가는게 분명하다고 생각한다.
옵시디언으로 주요 내용 정리하고 글감이 정해지면 글로 써서 정리 후 아카이브에 개시
게임 개발에서 PM이란?
PM이란, Project Manager의 약자로 프로젝트를 관리하는 사람을 말한다.
최근 GameOver라는 게임을 기획하고 팀원을 모집하면서 해당 팀내에서 디렉터 겸 PM을 맡고 있다.(사실 기획도 하고 플밍도 하고 있다.)
프로젝트를 시작하기 전엔 PM에 대해서 나름 자신감이 있었다.
전에 참여한 팀이나 지금까지 참여한 팀에 대해서 프로젝트 협업 방식이나 진행 방식이 그렇게 마음에 들지 않았고, 여러번 직접 나서서 바꾸려고 노력했기 때문이다.
이런 삐뚤어진 생각을 가지고 답답한 것보다 "내가 직접 해보지 뭐!"라는 마인드로 호기롭게 시작했던 것 같다.
과거에 실리콘 밸리의 팀장들에서 읽은 팀장으로써 역할, 솔직함, 피드백, 관계, 성장.. 등 읽고 좋은 팀을 만나고 싶다는 생각도 했기 때문에 더욱 욕심이 나긴 했다.
하지만 게임회사의 PM이라면 조금 다른걸까? 실리콘 밸리의 팀장은 너무 대기업의 큰 팀의 이야기라 인디게임 팀에 적용하기 힘들 것일까? 애자일은 정말 이상적인 방법론인가?
최근에 너무 머릿속이 복잡해지고 있다고 생각했고, 이를 정리하기 좋은 시기라고 생각해서 글을 쓰게 되었다.
나의 생각만 가지고 떠들어 댈 수 없기 때문에 2019년도에 NDC에서 안광섭님이 발표하신
전지적 참견 시점 - 게임개발PM의 내용을 참고하여 내 생각과 비교하여 작성한다.내용을 읽기전 내가 적용하고 있는 방식을 간단하게 소개한 글이다. 현재 GameOver 프로젝트 진행 방식
전지적 참견 시점 - 게임개발PM
개발 PM은 따로 정해진 문과나 이과의 제한이 없다.
게임 개발 PM은 게임 개발 되도록 하는 사람, 게임이 완성되게, 일이 진행되게 하는 것이 PM의 역할이다.
아무리 제품이 좋아도 출시/완성 되지 않으면 사람들은 제품을 볼 수 없다.
단순하게 PM의 업무를 키워드로만 나열해도 양이 엄청나다.
마일스톤, 커뮤니케이션, 업무 구조화, 회의, 신뢰 관계, 자료 조사, 인프라, 모니터링, 프로젝트 효율성, 지표, 문서화 등등.. (아마 이외에도 더 있을 것 같다.)
우리는 계획을 세워 본 적이 있다
이처럼 계획에 관한 유명한 말이 되게 많다. 이것 말고도 생각나는 말들이 많은데..
여기서 공통점은 계획이 실패한다는 공통점과 그것을 이용한 공감성을 활용한다는 것이다.
사람들은 대부분 계획을 세우고 살지만 실제로 얼마나 지켜지는 것일까?
대부분은 아쉬운 결과를 항상 봤을 것이고 일상 생활이 아니라면 더욱 더 그럴 것이다.
Planning Fallacy(계획 오류)
쉽게 말해서 스스로를 과신하고 행복회로를 돌려 계획했지만 실패로 돌아가는 것이다.
이러한 계획 오류는 계획을 세울 때 부터 시작된다.
유명한 사례로 시드니의 오페라 하우스가 있다.
이러한 계획 오류는 일생생활에서도 많이 발생하고 특히 소프트웨어 개발에서 많이 발생한다.
발표 내용과 같이 나는 어느정도 계획 오류를 인지하고 있다.
아직은 프로? 숙련공?이 아니기 때문에 불확실성에 대응하지 못하고 실패할 때가 종종 있다.
위 ToDo에서 해당 날짜에 채워지지 못한 Task들이 그렇다. (이외에도 코멘트로 작성한 문제점들도 있다.)
하지만 계속 수정해 나가며 나름대로 계획오류에 대응하려고 한다.
개인적인 생각을 좀 정리해보자면 사람은 기본적으로 자기 자신을 과대평가하는 경향이 있다.
실제로 나도 자주 그랬으며, 대부분의 사람은 스스로를 과신한다.
그래서 계획할 때 시간내 하지 못하는 능력 밖의 일을 계획하고 실패한다.
그리고 반복한다.이런 경험을 실제로 직접 해보고 다른 사람들의 계획 오류를 보는 기회가 있으면 쉽게 메타인지가 되기도 한다.
나는 매주 토요일에 10:30분부터 12:30분까지 진행하는 모각코(모여서 각자 코딩)에 참여한다.
매주는 아니지만, 그래도 이번년도에는 많이 참가했다. 4번을 참여하면 무려 아메리카노 쿠폰을 준다..!
해당 링크에 들어가보면 진행방식을 알 수 있지만 이슈가 생성되면 코멘트로 할일을 적고 해당 시간에 구글미팅으로 참여하여 2시간동안 진행하고 이후에 각자 소감을 말하고 종료한다.
처음 참여했을 땐, "이거하고, 저것도 하고, 이것도 해야지"하며 해야할 일을 추상적으로 적거나 지키지 못할 양을 적었다.
결과는 예상할 수 있는 실패였다.
이유는 단순하게 내가 2시간동안 할 수 있다고 생각한 일정이 사실은 불가능에 가깝고, 머리로는 2시간을 쓴다고 했지만 실제 집중하는 시간은 1시간 30분정도였다.
실제 회사에서 8시간을 근무하지 않는 것처럼
지금은 목표를 명확하게 세분화하고, 할 수 있는 분량을 적지만 처음에는 그랬다.
여기서 재밌는 점이 있는데, 새로 들어오신 분들도 무조건 2~3번까지는 항상 2시간 목표 달성에 실패하는 것이다.
물론 모두가 그렇다는 것은 아닌데(아닌 사람은 뭘 해도 잘할 사람..) 대부분의 사람이 계획 오류를 겪는다는 것이다.
내가 계획오류를 극복하는데 많이 도움이 된 글은 박종천 개발자님의 GPAM이다. (내가 정리한 글도 있지만 원문을 보는 걸 추천)
이외에도 프로젝트에서 발생하는 개발자의 추정또한 계획 오류의 주범이다.
개발자의 추정관련 글
낙관적 편향
게임 프로젝트는 다양한 직군, 다양한 이해관계의 충돌의 연속이다.
이를 직접 계획을 세우고 관리한다면?
복잡도가 증가함에 따라 매우매우 힘들어진다.
프로젝트 매니저의 진짜 모습
사람들은 PM하면 높은 직급 무거운 느낌을 상상할 수 있지만, 실제로는 그렇지 않다.
연예인 매니저의 모습에 가깝다.
연예인 매니저(한정된 시간에 최대의 효율을 낼 수 있게)
프로젝트 매니저(프로젝트가 한정된 시간에 최대의 완성도를 낼 수 있게)
실제 게임 개발 프로세스
디자인/기획 -> 담장자 지정 및 개발 계획 수립 -> 개발 진행 -> 배포 및 후속조치
디자인/기획 단계
여기서 PM은 무슨 일을 할까?
문서 작성 확인은 팀 기획자분이 잘 해주시고 계시지만 PM으로써 좀 더 신경써야 하는 부분이라 생각된다.
우선 순위 정하기이건 실제로 이건 매우 좋은 방법이라고 생각해 프로젝트에 도입 예정WBS는 실제로 프로젝트에 적용되어 있다.아쉬운 점은 플밍파트에서만 적용을 해서 아트, 사운드, 기획단위에서도 좀 병합이 필요할 것 같다.
한 Feature를 모두 같이 작업하는 환경으로 재구성할 에정
담당자 지정 및 개발 계획 수립
현재 프로젝트는 일감 회의를 정기 회의 때 정한다. (모두가 있을 때)
매 회의 때 빌드를 뽑아서 직접 플레이할 수 있도록 하고, 각 작업자가 자신의 작업 사항을 공유하고 이후에 진행할 작업을 공유한다.
모든 작업자가 자신의 작업 사항을 공유했다면, 마일스톤을 생성하고 각자 작업을 적고 일정도 기록한다.
버퍼 확보는 사실.. 각 이슈에서 작업 날짜를 지정해서 가져가기 때문에 개인이 스스로 버퍼를 두는 것 같다.
인디게임 팀 특성 상 온라인 작업만 하다보니 버퍼자체의 개념을 도입하기 어렵다.
문서화는 회의를 포함한 모든 내용을 최대한 세세하게 기록하는 것을 원칙으로 하고 있다.
정기회의를 포함한 비정기(아트, 기획, 플밍)회의 모두 내용을 기록하고 모든 팀원이 공유받을 수 있는 환경을 만드는 것이 원칙이다.
프로젝트의 모든 이슈에는 다 기록이 되어있다.
개발 진행
강연자님이 강조하시긴 했지만, 가장 중요한 점은 압박감을 주지 않는다는 것이다.
자칫 잘못하면 쉽게 넘어질 수 있기 때문에 문제가 발생하면 PM에게 말하면 된다는 것을 명확히 해야 한다.
프로젝트가 대면작업으로 진행되는 것이 아니기 때문에 나는 1달에 한번 인터뷰를 통해 작업시 어려운 점을 물어보고 있다. (공통적으로 나오는 부분, 개인적인 부분은 최대한 해결해주고 있다.)
이삭줍기는 아직 개발 초기 단계라 발생한지 잘 모르겠지만, 이를 확인하고 통계를 내기 위해선 문서화가 정말 중요해 보인다.
배포 및 후속조치
아직....! 멀었다 정안아!
PM의 업무
크게 4가지를 뽑아주셨다.
상기 시키기, 분배 하기, 전달 하기, 결정 돕기
상기 시키기(Reminding)
한 개발자는 한 기능만 작업하지 않는다.
여러 작업을 진행하기 때문에 PM은 작업자들에게 작업을 상기시켜야 한다.
또한, 작업자가 작업을 인지했는지 확인해야 한다.
현재 프로젝트는 작업자가 직접 디테일한 부분을 가져가기 때문에 걱정은 없지만 종종 회의 때 마일스톤에 대해서 다시한번 언급하여 강조하긴 한다.
분배 하기(Load balancing)
개발에서는 러닝코스트가 드는 작업들이 병목현상이 발생한다.
작업자는 해당 일을 파악하기 위해서 시간이 필요하고, 이를 통해 작업을 진행하기 때문이다.
PM은 이를 먼저 파악해야 한다. (Board에서 변화가 없거나 WBS에서 작업이 진행되지 않는다면?)
전달 하기(Messaging)
PM은 부정적인 전달하는 경우가 많다.
하지만 누군가는 말해야 한다.
밀도 높은 정보를 전달받아야 하는 것은 당연하다.
결정 돕기(Decision making)
PM이 알고 있는 정보는 결정에 매우 유용한 정보이기에 이를 활용할 수 있도록 도와야 한다.
실제로 사람들을 이끌고 결정으로 이끄는 사람이 바로 PM이다.
PM의 역량
맥락적 이해 능력, 새로운 지식 습득, 신뢰 주기, 타협 하기
맥락적 이해 능력
업무적 맥락을 뜻한다.
이를 위해 문서화를 잘 해두는 것이 중요하다.
'자신의 일상을 문서화하여 자신의 삶을 개선했다'와 같은 형태도 매우 좋은 방향임
가장 중요한 것은 원인을 파악하는 것이다.
새로운 지식의 습득
게임 개발 특성상 매우 다양한 사람들과 일하기 때문에 모든 직군에 대해 이해하는 것은 매우 어렵다.
PM은 마스터나 액스퍼트의 지식을 요구하지 않는다.
따라서 Generalist에 가까워지는 것이 중요하다.
개발자는 Specialist에 가깝다.
신뢰 주기
PM은 본의아니게 거짓말을 해야하는 경우가 생긴다. (일감에 대한..)
신뢰가 무너지지 않기 위해서 사전에 미리 말해두는 것이 중요하다.
타협 하기
PM이 타협을 하면 프로젝트는 어떻게 진행하지?
PM이라도 모든 불확실성에 대해서 대응할 수 없다.
여기서 중요한 능력이 소프트 스킬이다.
최근에 읽고 있는 책 제목이라 신기하다..
느낀점
개인적으로 PM이라는 직군에 대해 고민도 많았고 혼란스러웠는데 역시 생각을 깊게 하고 베테랑 PM분의 강연을 듣고 나의 생각을 정리하니 많이 도움이 되는 듯하다.
중간중간 개인적인 생각을 많이 적었는데, 또 1년이나 당장 몇 개월뒤에 달라질 생각이라도 이렇게 정리해놓고 이후에 본다면 얻어가는게 분명하다고 생각한다.
전지적 참견 시점 - 게임개발PM