반응형
IT쪽에서 일한지도 대학시절까지 하면 근 15년이 되어가는듯 하다.
IT쪽에 다양한 분야(개발, 경영, 웹기획, 서비스기획, PM 등)의 일을 접하며 가장 많이 느끼는 부분은 사람이다.
IT만큼 사람이 주가되는 것도 흔치 않은듯 하다. 어떤 제품을 만드는 제조공정이야 일정한 Process를 따라가면 되지만 IT는 정답이 없기에 항상 긴장하게 된다. 설령 똑같은 일인데도 사람에 따라서 방향과 처리하는 속도가 다르게 된다.
그만큼 사람에 따라서 처리방식과 결과가 전혀 다르게 나타나기 때문에 사람의 중요성을 가장 많이 인식하게 된다.
이런 사람들이 모여서 하나의 팀을 이루고 그 팀이 하나의 프로젝트를 통해서 완성된 하나의 결과물을 만들어 낼때 가장 많은 고민을 하게 되는 것도 결국 사람과의 관계와 Communication이다.
적게는 4~5명, 많게는 100여명의 사람들이 함께 일을 하게 되면 사람간의 소통이나 관계로 인한 다툼과 불화가 항상 반복적으로 일어나게 되고 PM의 덕목으로 이런 통솔능력이 중시되는 것이 이때문일 것이다. 하지만 PM 조차도 이런 상황에서 해결이나 중재자가 아닌 또 다른 분쟁이 씨앗이 되는 경우도 있어서 곤란한 상황도 반복된다.
사람들과 일을 하면서 가장 많이 듣는 말 중에 하나는 바로 "저 사람은 틀렸어. 이것이 맞아"라는 말이다.
사실 저 말이 맞을 수도 있고 틀릴 수도 있지만 오늘 강조하고자 하는 단어는 바로 "틀렸다"라는 단어다.
틀렸다라는 단어를 사용할때는 어떤 기준에 빗대어 판단하게 된다. 그런데 재미난 것은 그 기준이 여러개일때도 이런 틀렸다는 말을 하는 것이 맞냐는 것이다. 하나의 기준에서 보면 그 사람의 의견이 틀리게 보일수도 있지만 다른 기준에서 보면 그 사람의 기준이 맞을수도 있다.
대학때 수학시험 중 하나의 문제를 기존 책에서 나온 공식이 아닌 다른 공식을 대입하여 풀어본 적이 있었다. 그때 뭐 대부분 그랬겠지만 책대로 안풀었으니 틀렸다고 생각할 수도 있겠지만 반대로 다른 관점의 문제 접근이라는 점에서 오히려 성적은 좋게 나왔던 기억이 있다.
흔히들 사람들이 틀렸다고 말하는 배경은 바로 자신의 기준, 나만의 방식과 상식에 근거하여 말을 한다. 개발자들은 개발소스를 보며 자신의 방식과 다르다는 것으로 코딩을 문제삼거나 기획자들은 남의 기획을 폄하하는 것에는 모두 자신만의 방식이 자리잡고 있다.
재미난 것은 그 내용들을 잘 들여다보면 결과적으로 얻고자 하는 것은 대부분 비슷하다. 단지 과정이 다를 뿐이다.
그 과정속에서 정말 옳바른 방식이 존재한다. 어떤 사람은 1000줄로 코딩이 가능한데 어떤 사람은 10000줄로 코딩을 하는 사람도 있다. 결과는 같지만 과정상에 우위는 단연 1000줄짜리 코딩일 것이다.
하지만 여기서 중요한 것은 10000줄짜리 코딩이 틀린게 아니라는 것이다. 단지 그 사람 입장에서 코딩을 할때 그렇게 코딩이 된 것이지 틀린것은 아니기 때문이다. 개발이 완료되어도 1000줄짜리와 동일한 기능을 한다면 그것은 틀린것이 아닌 개발 방식이 다른 것이다.
흔히들 프로젝트 Leading을 하면서 사람들에게 말하는 말중에 가장 많이 하는 말이 있다.
"10명이 모이면 10개의 가치관이 존재하고 100명이 모이면 100개의 가치관이 존재한다"
프로젝트가 작던 크던 그 사람 수 만큼의 서로다른 생각이 존재한다. 그 서로다른 생각들이 서로간의 부딛치며 서로가 서로에게 상처를 주게 된다. 간혹 이런 경우 서열싸움으로 보이기도 하는데 자신의 생각앞에 남을 굴복하도록 하고자 하는 생각이 강한데 있다.
하지만 이런 경우 프로젝트의 진행자체가 매끄럽지 못하게 된다. 굴복시킨 사람이나 굴복한 사람이나 어떤 합의에 의한 것이 아니라 일방적인 상황으로 인한 피해자기이기 때문이다. 굴복시킨 사람은 자신의 생각이 맞다는 것을 보여주기 위해서 문제가 생길때 무리하게 돌파하려는 경향이 있고, 굴복당한 사람은 그 일이 잘 안되어게 하여 자신의 생각이 맞았다는 것이 증명되기를 바란다.
이런 일들의 근본에는 나와 다른 생각을 가진 사람은 틀렸다라는 것에 기인하는듯 하다.
나와 다른 생각이 있으면 배척하고 나와 동조하는 사람은 포용하여 자신과 맞는 사람들로 인력을 구성한다. 그래서 주위의 반대의견들을 자기들끼리 뭉쳐서 이겨내려고 하지 귀 기울여 듣지 않는다.
가끔 프로젝트 할때 PM들이 하는 말 중에 "이런 이런 사람이면 좋겠다"라는 말을 종종 듣게 된다. 즉 자신의 가치관과 맞는 사람과 같이 일하려 한다. 뭐 그렇게 된다면 좋겠지만 내 입맛에 맞는 사람과 일하는것은 쉽지 않다. 또 내 입맛에 맞는 다고 생각했는데 조금 하다보면 나와 다른 점으로 또 다른 불화가 발생하기도 한다.
이런 문제를 해결하기 위해서는 방법은 딱 한가지다. 간단할수도 있고 어려울수도 있지만 상대를 먼저 인정해 주는 것이다. 상대의 말이 틀렸다고 말하기 보다는 다른 생각과 관점을 소유하고 있어서 그 사람 자체를 인정해 주는 것이다. 그리고 대화할 때 상대방의 의견이 틀렸다는 표현이 아니라 다르다는 말을 하는 것이다.
서로간의 다른 관점과 생각을 이해하고 서로를 보다 사실적으로 바라볼 수 있게되면 오히려 해결의 실마리는 쉽게 풀리게 된다. 사람들은 대부분 이해받기를 원한다. 그래서 자신의 이야기를 들어주는 사람에게 문을 열어주게 된다. 이렇듯 서로를 이해하는 바탕에서 출발해야 서로간의 소통도 원활하고 이해를 하게 되어 앞으로 나아갈 수 있게된다.
틀림이 아님 다름으로 시각을 전환해 보자. 사람과의 대화에 있어서 서로간의 차이점을 인정하고 그 인정하는 것을 바탕으로 논의하다보면 어느순간 우리서로가 공통의 관심사로 한방향으로 나가는 것을 느끼게 될 것이다.
IT쪽에 다양한 분야(개발, 경영, 웹기획, 서비스기획, PM 등)의 일을 접하며 가장 많이 느끼는 부분은 사람이다.
IT만큼 사람이 주가되는 것도 흔치 않은듯 하다. 어떤 제품을 만드는 제조공정이야 일정한 Process를 따라가면 되지만 IT는 정답이 없기에 항상 긴장하게 된다. 설령 똑같은 일인데도 사람에 따라서 방향과 처리하는 속도가 다르게 된다.
그만큼 사람에 따라서 처리방식과 결과가 전혀 다르게 나타나기 때문에 사람의 중요성을 가장 많이 인식하게 된다.
이런 사람들이 모여서 하나의 팀을 이루고 그 팀이 하나의 프로젝트를 통해서 완성된 하나의 결과물을 만들어 낼때 가장 많은 고민을 하게 되는 것도 결국 사람과의 관계와 Communication이다.
적게는 4~5명, 많게는 100여명의 사람들이 함께 일을 하게 되면 사람간의 소통이나 관계로 인한 다툼과 불화가 항상 반복적으로 일어나게 되고 PM의 덕목으로 이런 통솔능력이 중시되는 것이 이때문일 것이다. 하지만 PM 조차도 이런 상황에서 해결이나 중재자가 아닌 또 다른 분쟁이 씨앗이 되는 경우도 있어서 곤란한 상황도 반복된다.
사람들과 일을 하면서 가장 많이 듣는 말 중에 하나는 바로 "저 사람은 틀렸어. 이것이 맞아"라는 말이다.
사실 저 말이 맞을 수도 있고 틀릴 수도 있지만 오늘 강조하고자 하는 단어는 바로 "틀렸다"라는 단어다.
틀렸다라는 단어를 사용할때는 어떤 기준에 빗대어 판단하게 된다. 그런데 재미난 것은 그 기준이 여러개일때도 이런 틀렸다는 말을 하는 것이 맞냐는 것이다. 하나의 기준에서 보면 그 사람의 의견이 틀리게 보일수도 있지만 다른 기준에서 보면 그 사람의 기준이 맞을수도 있다.
대학때 수학시험 중 하나의 문제를 기존 책에서 나온 공식이 아닌 다른 공식을 대입하여 풀어본 적이 있었다. 그때 뭐 대부분 그랬겠지만 책대로 안풀었으니 틀렸다고 생각할 수도 있겠지만 반대로 다른 관점의 문제 접근이라는 점에서 오히려 성적은 좋게 나왔던 기억이 있다.
흔히들 사람들이 틀렸다고 말하는 배경은 바로 자신의 기준, 나만의 방식과 상식에 근거하여 말을 한다. 개발자들은 개발소스를 보며 자신의 방식과 다르다는 것으로 코딩을 문제삼거나 기획자들은 남의 기획을 폄하하는 것에는 모두 자신만의 방식이 자리잡고 있다.
재미난 것은 그 내용들을 잘 들여다보면 결과적으로 얻고자 하는 것은 대부분 비슷하다. 단지 과정이 다를 뿐이다.
그 과정속에서 정말 옳바른 방식이 존재한다. 어떤 사람은 1000줄로 코딩이 가능한데 어떤 사람은 10000줄로 코딩을 하는 사람도 있다. 결과는 같지만 과정상에 우위는 단연 1000줄짜리 코딩일 것이다.
하지만 여기서 중요한 것은 10000줄짜리 코딩이 틀린게 아니라는 것이다. 단지 그 사람 입장에서 코딩을 할때 그렇게 코딩이 된 것이지 틀린것은 아니기 때문이다. 개발이 완료되어도 1000줄짜리와 동일한 기능을 한다면 그것은 틀린것이 아닌 개발 방식이 다른 것이다.
흔히들 프로젝트 Leading을 하면서 사람들에게 말하는 말중에 가장 많이 하는 말이 있다.
"10명이 모이면 10개의 가치관이 존재하고 100명이 모이면 100개의 가치관이 존재한다"
프로젝트가 작던 크던 그 사람 수 만큼의 서로다른 생각이 존재한다. 그 서로다른 생각들이 서로간의 부딛치며 서로가 서로에게 상처를 주게 된다. 간혹 이런 경우 서열싸움으로 보이기도 하는데 자신의 생각앞에 남을 굴복하도록 하고자 하는 생각이 강한데 있다.
하지만 이런 경우 프로젝트의 진행자체가 매끄럽지 못하게 된다. 굴복시킨 사람이나 굴복한 사람이나 어떤 합의에 의한 것이 아니라 일방적인 상황으로 인한 피해자기이기 때문이다. 굴복시킨 사람은 자신의 생각이 맞다는 것을 보여주기 위해서 문제가 생길때 무리하게 돌파하려는 경향이 있고, 굴복당한 사람은 그 일이 잘 안되어게 하여 자신의 생각이 맞았다는 것이 증명되기를 바란다.
이런 일들의 근본에는 나와 다른 생각을 가진 사람은 틀렸다라는 것에 기인하는듯 하다.
나와 다른 생각이 있으면 배척하고 나와 동조하는 사람은 포용하여 자신과 맞는 사람들로 인력을 구성한다. 그래서 주위의 반대의견들을 자기들끼리 뭉쳐서 이겨내려고 하지 귀 기울여 듣지 않는다.
가끔 프로젝트 할때 PM들이 하는 말 중에 "이런 이런 사람이면 좋겠다"라는 말을 종종 듣게 된다. 즉 자신의 가치관과 맞는 사람과 같이 일하려 한다. 뭐 그렇게 된다면 좋겠지만 내 입맛에 맞는 사람과 일하는것은 쉽지 않다. 또 내 입맛에 맞는 다고 생각했는데 조금 하다보면 나와 다른 점으로 또 다른 불화가 발생하기도 한다.
이런 문제를 해결하기 위해서는 방법은 딱 한가지다. 간단할수도 있고 어려울수도 있지만 상대를 먼저 인정해 주는 것이다. 상대의 말이 틀렸다고 말하기 보다는 다른 생각과 관점을 소유하고 있어서 그 사람 자체를 인정해 주는 것이다. 그리고 대화할 때 상대방의 의견이 틀렸다는 표현이 아니라 다르다는 말을 하는 것이다.
서로간의 다른 관점과 생각을 이해하고 서로를 보다 사실적으로 바라볼 수 있게되면 오히려 해결의 실마리는 쉽게 풀리게 된다. 사람들은 대부분 이해받기를 원한다. 그래서 자신의 이야기를 들어주는 사람에게 문을 열어주게 된다. 이렇듯 서로를 이해하는 바탕에서 출발해야 서로간의 소통도 원활하고 이해를 하게 되어 앞으로 나아갈 수 있게된다.
틀림이 아님 다름으로 시각을 전환해 보자. 사람과의 대화에 있어서 서로간의 차이점을 인정하고 그 인정하는 것을 바탕으로 논의하다보면 어느순간 우리서로가 공통의 관심사로 한방향으로 나가는 것을 느끼게 될 것이다.
반응형