이것도 경험담입니다;;;
기획자 이외의 분들에게도 도움이 될만한 것들을 슥슥;;

다 적고보니 굉장히 일반적인 것들뿐이네요. ( 평범한게 진리라고나... 하하하;; 뻘쭘;; )




0. 일단 제가 경험했던 프로젝트들에 대해서 ;;;

진영님이 겪고 있는 것과 비슷한(같을 수는 없을테니) 방법으로 개발한 것은
대략 서너번쯤 되는 듯합니다.

첫번째 경험에서는 초기에(아이디어 회의 중에) 중단되었고
두번째는 아이디어 회의하다 다들 포기하고 기획자가 기획서 써라. 라는 식으로 방향이 바뀌었고,
세번째와 네번째는 어찌어찌 잘 개발단계까지 가다가 (게임 두개가 거의 동시에 진행됬었습니다.)
하나는 프로토에서 조금 더 진행한 다음 별로다 싶어서 중단되고
나머지 하나는 무사히 개발을 계속 진행해서 나름 '가완성' 상태까지 갔습니다.
( 하지만 나중에 정체불명의 사고로 이것도 발표직전 즈음에 중단 orz )

결론은 4번 시도중 2번은 이 방법이 그럭저럭 괜찮았다. 라는 케이스인데
각각을 경험하면서 다른 파트분들에 대해 좋았던 점, 주의해야할 점을 적어보겠습니다.

※ 아래 적은 것들은 4번째에 같이 일했던 분들이 지켜주셨던 사항들입니다.
   정말 행복했어요 ;_;



1. 작업 방식을 인정하고, 존중할 것,

누군가가 어떤 작업 방식을 결정하고 밀고 나간다면, 문제가 있더라도
그 상황을 바꿀 수 없다고 판단되면, 혹은 바꿀수 있다고 생각되어도
방식을 바꾸는 그 자체에 힘을 너무 소진하게 되는 경우라면

깨끗하게 인정하고 그 작업 방식에 최대한 협조하는 것이 필요합니다.
이것은 가장 기본적인 예의이자 리더를 따르는 팀원의 자세입니다.

커다란 틀을 인정하고 그 틀을 유지한 상태에서 구체적인 방법이나
문제점이 눈에 띄였을 때 따로 대안을 고심해보는 것이 좋습니다.

주의할 점은, 지적한 다음에 바로 고쳐지지 않는다고 화내지 않는 것입니다.
많은 이유가 있겠지만, 개인적으로는 이럴 경우 왜 안좋은거 뻔히 알면서
그대로 가냐고 해봤자 좋은 경우는 별로 없었습니다 =ㅅ=;;
(지금 생각해도 참 신기합니다.)




2. 타인의 말에 경청하기

회의가 시작되면 다른 사람의 말을 잘 듣고 이해하려는 노력이 제일 중요합니다.
기본적인 커뮤니케이션의 기본이므로 굳이 설명할 필요는 없을것... 같죠? ^^;;;

그냥 사족을 붙이자면 역지사지로 다른 사람이 내말 안들어주고 자기 말만 하면 기분 나쁘자나요.
마찬가지로 그 사람도 자기 말 씹히면 기분 나쁘겠지요.
그러면 신나게 머리 달구면서 생각을 모아야할 회의가 아주 지옥 같아지겠지요. ( 이런 상황은 정말 싫지요 ;_; )





3. 서로의 의견을 긍정적으로 생각할 것,

아이디어 회의를 하다보면 어떤 사람의 의견에 반대의견이 나오고
그러다보면 반박하고 또 그러다보면 싸움 비스무리하게 되는 경우가 많습니다.

되도록이면 상대방의 의견을 반대하거나 문제점을 찾아내기 보다
괜찮은 부분을 찾아내서 더욱 발전시키거나, 괜찮네, 라고 한마디 거들어야합니다.

만약 도저히 넘어갈 수 없는 문제점이 있는데 다들 그걸 망각하고
넘어가고 오히려 거기에 뭔가를 덧붙이려는 경우가 있다면, 판단 잘해야합니다. =ㅅ=
누구의 생각이 옳은지에 대한 판단 기준은 회의에 참석한 모두가 다 다르기 때문입니다.

아이디어 회의는 문제점을 지적하는 것이 아니라
별 이상하고 생뚱맞은 아이디어라도 어찌어찌 잘 띄워보려는 것임에 있음을 명심해야합니다.





4. 내 의견을 끝까지 붙잡고 늘어지지 말기 / 혹은 안들어준다고 화내지 말기

자기 주장이 받아들여지지 않으면 누구라도 감정적인 동요가 일어나기 마련입니다.
서로 다른 게임관을 가진 사람들이 모인 아이디어 회의에는 굉장히 자주 보이는 일입니다.

이때, 누군가가 자기 의견을 다르게 해석해서 변형하거나, 반대하는 것에 동요하면 안됩니다.

그리고 다른 사람들 화제 옮겨가는데 혼자만 자기 이야기 끝까지 계속 하거나
삐져서 침울해 있거나, 얼굴을 붉히거나... 그러면 서로 힘들어집니다. ;;

특히 자기 의견이 정말 괜찮은 것 같아서 계속 고치고 고쳐서 또 말하는 경우,
불행히도 다른 사람들은 그냥 같은 이야기 또하고 또하고 그러는 줄 압니다.





5. 적극적으로 '한번 해보는 자세' 가지기

모두가 모여서 의견을 내고 검토하면서 가능성이나 문제점을 찾아내는 단계가 되면 누군가는 머리가 아파집니다.
애초에 자기 생각보다는 다른 사람들의 의견이 많은 터라 스스로도 확신을 가지기 어렵기 때문입니다.
여기에 다른 파트 사람들의 말말말(특히 아이디어 제안자)들도 장난 아니기 때문에 더더욱 스트레스 쌓입니다.
개발 방법의 특성상 '딱 이거다!'라고 말하고 진행하도록 추진력을 가지기 어렵기 때문입니다.

이럴때, 디자이너/프로그래머 분들의 협조는 프로젝트의 진행에 굉장한 도움이 됩니다.
쉽게 말해 '한번 해보는'겁니다. [ 여담이지만 이러면 어디선가 '참 말은 쉽죠?' 라는 말이 나오곤 합니다. ]

실제 게임 화면처럼 꾸민 구라샷(...)이나 구현 되었을 때의 모습을 그려보거나,
직접 프로그래머가 구현해서 같이 해보는 겁니다.

항상 그런 것은 아니지만 이렇게 하면 대부분 의견이 정리되어버립니다. 재미있다/없다.
신기한 건, 제 경험으로 이렇게 해서 재미없다가 되어 했던거 삽질한 케이스는 별로 없었습니다.
재미 없는 경우에는 또 다같이 의견을 모아서 재미있게 만든 경우도 몇번 있습니다.


※ 앗, 여기서 기획자의 역할이 굉장히 중요합니다. -_-d
   간단한 아이디어를 실제로 구현하고 재미있음을 느끼게 하는 것에는 눈에 안보이는 굉장히 많은 부분을 신경써줘야합니다.
   예를 들어 간단한 슈팅게임이라도 적이 나오는 시간 간격, 위치, 총알의 속도 등등-
   이런건 기획자가 사람들 안보이는 곳에서 잘- 잡아줘야합니다.

   이거 안되면 재밌을 것도 재미 없어지고   
   프로그래머랑 디자이너들 삽질하는 일은 많아지고,
   나중에는 '나 확실한거 아니면 안해!' 라는 소리를 듣게 됩니다. ;_;





6. 생각의 방향을 정하기 / 자기 생각을 죽이기

굉장히 실현 불가능한 것처럼 보이는 말이지만, 실제로 완전히 죽일 필요는 없습니다.
하지만 다른 사람들의 의견을 받아들이고 같이 발전시키기 위해 자기 생각의 일부를 희생할 필요는 있습니다.

예를들어 간단한 캐주얼 게임을 만드는데 MMORPG만들고 싶다. 라는 생각은 당연히 접어야하고
귀여운 여성향 게임을 만드는데 리얼하게 피튀기는 잠입 액션 같은 아이디어는 당연히 안되겠죠.

의식적으로 생각의 방향을 잘- 갈무리할 필요가 있습니다. ^^;;
(생각의 폭을 좁히는 것과는 약간 다릅니다. 미묘-한 차이인듯... 하네요)