앞선 글에서는 커뮤니케이션에서 오는 스트레스를 개인적인 차원에서 다루는 여러가지 방법에 대해서 살펴봤다.
그러나 말했듯이 직장에서 생기는 커뮤니케이션 문제는 개인적인 차원에서 온전히 소거해버릴 수 있는 것이 아니다. 절에 가도 그런 스트레스가 있고, 수도원에 들어가도 그런 스트레스는 생긴다. 사람과 함께 일할 수 밖에 없는 것이 인간의 운명이므로, 어쩔 수 없는 일이다. 조직이 있는 한 어쩔 수 없는 스트레스다. 문제는 그 수준이 어느 정도냐다.
커뮤니케이션 오버헤드가 어떤 임계치를 넘어서면, 조직원으로부터 대략 두 가지 정도의 반응이 나온다. 일이니까 어쩔 수 없다는 반응과, 대체 왜 그런 일에 업무 시간을 써야 하는지 이해하기 어렵다는 반응 정도로 요약할 수 있다. 회사에서의 커뮤니케이션도 업무라는 관점에서 본다면 두 번째 반응은 지나치게 개인적으로 비춰질 수 있다.
그러나 그런 해석은, 회사에서 일하는 개인들을 지나치게 얕잡아 보는 것이다. 설마 그렇게 어려운 과정을 거쳐서 회사에 입사한 사람들이 일과 사생활도 제대로 구별 못하겠는가? (물론 간혹 가다 그런 사람도 있긴 하다.)
따라서 두 번째 종류의 반응이 나오기 시작하면, 그런 반응을 보이는 사람들을 질책하기 보다는 그 반응이 어디서 오는지를 제대로 살펴야 한다. 그리고 이런 일은 조직이 해야 하는 일이다.
조직의 책무
조직에게 이런 책무가 있다는 사실을 조직이 깨닫지 못하면, 다시 말해서 구성원의 스트레스 레벨 관리 또한 조직이 응당 신경써야 (not 전적으로 책임져야) 하는 부분임을 깨닫지 못하면, 그 조직의 구성원들은 아마 다른 직장을 찾기 시작할 것이다. 그런 일이 벌어지기 시작하면 해당 조직 입장에서도 힘들어지기 때문에, 미리 미리 관리를 하는 것이 좋다.
이런 문제를 관리하는 좋은 방법 중 한 가지는, 관리자 레벨에 있는 사람들을 '관리'하는 것이다. 보통 대부분의 조직에서 커뮤니케이션의 허브 역할을 하는 사람들은 관리자이므로, 그런 사람들에게 있는 문제를 관리하는 것이 요령이다. 관리자가 커뮤니케이션 문제를 다루는 데 능숙하면 조직원들이 스트레스를 덜 받지만, 관리자가 아무 생각이 없거나 자기 멋대로면 그 관리자에 연결된 모든 구성원들이 대단한 피해를 보기 시작한다. 그리고 아마 실제로 관리에 들어가보면 확인할 수 있는 사실이겠지만, 대부분의 커뮤니케이션 문제는 대체로 관리자 때문에 생긴다 (목소리가 클 수 밖에 없기 때문이다).
따라서 관리자와 구성원 간의 상호작용 문제에 있어서 만큼은 상향평가를 어느 정도 하는 것이 바람직하다.
문제는 상향 평가를 어떤 식으로 하는 것이 좋느냐이다. 한국은 암묵적인 도제식 군문화가 지배해왔던 사회라 상향 평가에 굉장히 민감했었지만 (대기업일 수록 더 그렇다) 최근들어 상황이 많이 바뀌기 시작한 것 같다. 따라서 어떤 식으로든 일단 커뮤니케이션 부분에 관해서 만큼은 상향 평가를 시작하고 보는 것이 좋다. 대부분의 IT 관련 개발조직에서 사람들에게 가장 많은 스트레스를 주는 부분이 커뮤니케이션이기 때문이다 (아마 대부분의 실무레벨 개발자들이 그럴 것이다).
그러니 '어떤 식으로 해야 하지?'라는 문제에 너무 골몰하지 말고, 일단 하고 보자. 모 회사 처럼 트위터 스타일로 한줄 평만 받아도 좋다. 일단 하기 시작하면 큰 도움이 된다.
IT 프로젝트의 어쩔 수 없는 오버헤드(?)들
조직 내의 커뮤니케이션 오버헤드를 적절히 관리하는 또 한 가지 요령은, IT 프로젝트 진행 과정상 어쩔 수 없이 겪어야만 하는 커뮤니케이션 오버헤드의 상당수는 (스탠드 업 미팅, 요구사항 회의, 디자인 리뷰, 코드 리뷰) 개인의 창의성과 시간을 측정 가능한 수단으로 환산하고 관리해야만 하는 '관리상의 필요' 때문에 어쩔 수 없는 부분이라는 것을 모든 개발자에게 납득시키는 것이다. 이런 오버헤드는 공장에서 공정관리를 위해 필수적으로 요구하는 절차와 같은 수준의 오버헤드기 때문에, 사실 제거할 수 없다. 그런 것 까지 안하는 조직은 보통 그만 그만한 수준의 소프트웨어만 만들어내다가 망하게 마련이고, 그런 곳에서 일하는 개발자는 보통 더 크고 유명한 회사에 가서 왕창 깨져보고 나서야 왜 그런 절차들이 필요했는지 깨닫는다.
그리고 이걸 납득시키는 가장 좋은 방법은, 프로젝트 괸리에 숙달된 사람을 적어도 한 명 이상 프로젝트에 포함시키는 것이다. 보지 않으면 믿지도 않는 것이 사람 심리고 개발자들도 예외는 아니다. 프로젝트의 '공정' 관리가 어떻게 이루어지는 지 알도록 해야 잡음이 생기지 않는다. 기한에 맞춰서 납품만 하는 것이 소프트웨어 개발 프로세스가 아니다. 리스크를 지정 수준 이하로 괸리하는 것이 그 핵심이고, 그 노하우를 활용하지 않으면 결국 그 결과물로 가장 많은 피해를 보는 사람은 개발 당사자다. 그 사실을 똑바로 보도록 하는 것이 중요하다.
다음 글에서는 직장인의 커리어 관리에 관한 스트레스에 대해서 집중적으로 살펴보자.