개발자면 가져야 할 의사소통 능력

책을 통하고 다른 사람에게 물어보기도하고 살면서 느낀 점을 정리해봤다.

 

---

 

1인 개발자가 아니라면

프로젝트는 다수가 함께 하는 작업이기 때문에

의사소통 능력이 최고의 가치를 지닌다고 생각한다.

이것에 따라 결과물이 달라질뿐아니라 근무 환경도 달라진다.

의사소통 능력이 곧 게임의 퀄리티라고 생각한다.

 

---

 

좋은 커뮤니케이션이라는 것은 서로 협업하려는 마음이 있는 것이며 배려와 이해를 바탕으로 한다.

하지만 개인의 사려만으로 모든 문제가 해결되는 것은 아니다.

 

우리가 말하는 의사소통과는 다르게 협업이라는 테두리 안에서 의사소통은 프로세스이며

상호 합의된 규칙이 필요한 목적이 명확한 행위이다.

 

각각의 작업 영역뿐만 아니라 협업에 대한 규칙을 만들어서

미리 이야기 해놓지 않으면 개인의 생각들로만 충돌이 일어나고 팀의 분위기도 나빠진다.

일단 회사에 들어가서 프로젝트를 한다면 단기로 끝나는 프로젝트가 아닌 이상 

매일 얼굴보고 살 사이인 만큼 끝까지 팀워크가 좋아야 한다.

그러면서도 당연하게 생각하는 것들이 생기면 안된다.

세세한 것들도 말하며 확인하면서 진행해야 하는 것이 바로 협업이다.

** 이것도 모르겠어? 하는 생각은 버린다.

 

---

 

하지만 모두가 의사소통 능력이 있다고 판단되어 팀으로 일하게 되지만 실제와는 다르다고 한다.

각자 알아서 자기 할 일을 하며 나중에는 쉽게 의견이 합일되는 상상을 하곤 한다.

이것은 상상 속에서만 존재한다.

실제로 아무 충돌 없이 매끄럽게 프로젝트가 진행된다는 것은 말이 안된다.

오히려 아무 일도 생기지 않으면 경계해야 한다고 말한다.

암묵적인 규칙을 서로 깨달을 때까지 지내는 것이 아니라

서로 자세히 말해주어서 다들 알고 있어야 하는 규칙을 만들어야 한다.

 

이러한 규칙 설정에서 물론 관리자의 역할이 크게 작용하겠지만

관리자 혼자만의 독단이 되어서는 안되고

모두의 동의는 아니더라도 다수의 동의를 이끌어내거나 규칙에 대한 모두의 생각을 들어보기는 해야 한다.

팀 작업의 가치는 1+1 = 2가 아니라 1+1 > 2 에서 나오는 것인데 이러한 시너지를 이끌어내기 위해서는

서로가 지켜야 할 규칙과 의사소통 프로세스를 만들어야 한다.

 

특히 게임 개발에 대해 3가지로 파트를 나눈다고 하면

기획, 프로그래밍, 아트가 있는데 

각각의 사람들은 자기 분야의 스페셜리스트지만 다른 분야에서는 문외한인 사람이 대부분이다.

때문에 파트 별로 규칙을 만들고 파트 간의 대화에서는 서로의 규칙을 지켜가며 의사소통을 해야할 것임은 자명하다.

 

---

 

불만 역시 무조건 나와야만 하는 의사소통 요소 중 하나인데

이러한 불만을 못나오게 하는 방법이 아닌 불만을 해소하는 방법을 알아야 한다.

작업을 하면서 나오는 불만은 당연히 있을 수 밖에 없다. 

없으면 참고 있는 것이다.

결과물이 게임 캐릭터의 모습이 뜻대로 되지 않아서 불만이 생기거나

기획이 프로그래머들과 서로 합의한 요소에서 프로그래머들은 이런 의미로 받아들였는데 사실

기획파트가 잘못이해했다거나 등등 

많은 불만이 결과물을 보고 생기기 마련이다.

결과물에서도 중간 중간 산출물을 서로 교환하는 과정도 마찬가지다.

분명 맘에 들지 않는 부분이나 개선해야할 점이 있는 것이 당연하다.

소통에서 처음부터 나의 의도를 상대가 다 알아챈다면 그것은 운이 좋은 것이지

내가 잘 말했다고 생각하면 안된다.

특히 피드백을 줄 때, 부정적인 피드백을 주거나 불만만 말하고 어떠한 방향을 제시하지 않거나 하는 행동들은더욱 경계해야 한다.

-> 비판이 비난이 되어서는 안된다.

사실 결과물에 대해서 비판적으로 이야기해야하는 것은 사실이나 실제로 일정이나 제약이 주어졌을 때는 비난에 더 가까운 말을 쏟아내곤 한다.

이러한 태도는 작업을 하는 작업자 입장으로 중간 산출물을 보이는 것을 꺼리게 되며 이러한 맘을 가지고 있는 사람에게 결과물을 요구하는 사람 또한 더욱 불만이 생기기 마련이다.

중간 산출물에 대해 서로 공유하지 않아서 문제가 생긴다면 그것이 협업에 있어서 일어나서는 안될 일이라고 생각한다.

때문에 이러한 불만에 대해서는 확실히 하고 넘어가야 한다.

결과물에 대한 비판이 해당 사람에게 이어져서는 안되며 비난으로 이어지는 것은 더욱 경계해야 한다.

위에서 말했다시피 규칙을 만들든지 해당 피드백에 대한 합리적인 프로세스를 만들어 실제로 문제 해결만을 위한 작업이 필요하다.

 

---

 

불만을 해소하는 방법이 곧 피드백을 하는 자세나 피드백을 받는 태도에 관한 일인데 이에 대해서 말해보자

 

또한 팀원들의 신뢰같이 눈에 보이지 않는 것도 프로젝트의 큰 줄기를 차지한다.

처음에 게임을 이러저러한 재미를 느껴서 사람들이 하게될 것이다라고 생각하며 개발했지만

중간 프로토타입을 보며 플레이를 해보면 맘에 들지 않는 경우가 있다.

오히려 팀원들은 지금까지 해온 것이 있기 때문에 맘에 들지 않아도 숨기는 경향이 있다.

하지만 누군가 맘에 들지 않는다면 꼭 말해야 한다.

즉, 누가 말해도 팀원들이 존중하는 그러한 관계가 되어야 한다.

** 의견을 자유롭게 표출해도 되는 팀 분위기

 

사람이 싫어서 해당 의견을 묵살하는 분위기가 된다면 어느 누구도 반대 의견을 내지 않을 것이다.

만약 반대 의견이 없어서 팀이 잘 굴러가고 있다고 생각하면 그것도 큰 오산이다.

꼭 그렇다고는 할 수 없지만 반대 의견이 있을수록 발전한다고 생각한다.

**반대 의견을 다른 말로하면 개선시키는 방법을 찾자라는 말로 해석할 수 있다.

 

내가 주도하는 프로젝트에 대해 설사 반대 의견이 나오더라도 팀원들의 신뢰가 두텁다면 나는 그에 다시 반대하여 ~까지 구현하면 우리가 예상한 재미를 이끌어낼 수 있을 것이다라는 말도 할 수 있어야 한다. 

** 누구나 말할 수 있어야 하고 누구나 해당 말에 귀를 기울여야 한다는 말이다.

 

다시 말하자면 주장하는 사람에게도 충분한 ~~한 생각이 있어서 ~~를 했다는 것을 충분히 말해야하고

반대하는 사람도 ~~한 생각이 있어서 ~~를 해야할 것 같다는 것을 충분히 말해야 한다.

즉, 찬성과 반대라 말했지만 결국 우리는 한 쪽의 의견을 채택하는 것이 아닌

절충, trade-off

을 해나가는 작업이다. 

** 프로그래밍에서 많이 듣던 단어가 여기서도 쓰인다.

 

 

---

 

좋은 커뮤니케이션은 곧 프로젝트의 효율성을 높여준다.

서로의 결정을 존중하기 때문에 설득하지 않아도 되고

서로의 감정적인 소비가 줄어들기 때문에 팀의 분위기와 신뢰도가 높아지고

더욱 긍정적인면이 많아진다.

프로젝트가 시작되면 길게는 몇 년간 같이 볼 사이인데 서로 배려하고 존중하고 친해지고 즐겁고 재미있게 일하고 싶다.