Karen
8k
2017-11-14 15:10:58.0 작성 2017-11-21 11:00:14.0 수정됨
1
493

개발자의 삶 - 무엇이 문제인가요?


아래 글은 7년전 쯤에 그 동안의 프로젝트 경험을 정리한 것입니다.

하지만, 아직도 많은 조직에서 비슷한 공감을 얻을 수 있는 내용이라는 생각이 들어서 글을 다듬어 다시 올려봅니다.





“무엇이 문제인가요?”


회의를 들어가 보면 종종 장황한 설명과 함께 논쟁의 언어들이 오갈 때가 있다.

이 때 어디선가 들려오는 한 마디 "도대체 뭐가 문제인가요?"


나는 이 말을 그렇게 좋아하지 않는다. 이 말 자체가 말하는 사람의 힘을 빼놓기 때문이다.

그 말을 하는 사람은 마치 모든 걸 해결해 줄 것처럼 보이지만, 보통 그 문제에 대해 관심이 없는 사람이라고 보아야 한다.


대부분의 문제는 단답형 답으로 해결되는 것이 아니기 때문이다.


이 질문의 내용은 ‘난 그 문제에 관심이 없으니 내가 해야 할 일만 말해주쇼.’ 와 동일하게 보아도 될 것 같다. 그래서 이 말을 들으면 김이 팍 새는 느낌이 든다.


‘뭐가 문제야?’ 라고 묻는 이들은 문제 해결 과정 속에 있고 싶어하지 않는다.


문제를 해결하고 싶은 사람이라면, ‘다시 한 번 말해주게.’ 또는 ‘그러면, 우리가 어떻게 해야 하지?’ 라고 묻는다. 요점을 묻는 것이다.


말을 하는 것도 중요하고, 잘 듣는 것도 중요하다.

잘 듣는 것을 이야기해보려 한다.


회의실에서 무언가 두서 없는 이야기를 하는 사람들은 ‘정말로 무엇인가를 전달하고 싶어하는 사람’이다.

항상 다른 이들이 세련된 화법으로 자신이 잘 이해할 수 있게 해주길 바라는 것은 너무 기대가 큰 것이다.

그것은 모든 일이 쉽기 만을 바라는 것처럼, 일어날 수 없는 일을 기대하는 것과 같다.


일반적으로 문제는 1)문제인식, 2)전달과 공유, 3)공감 후 공동(단독) 대처의 단계를 거쳐야 종료된다.


어떤 조직은 “문제 인식” 채널이 없고, 어떤 조직은 “전달과 공유”가 어렵기도 하며, 혹은 “공동 대처”가 안되는 조직도 있다.

어느 한 곳이라도 막히면 문제는 해결되지 않은 채로 남아있게 된다.

이 과정을 원활히 하지 못하는 조직은 점점 문제가 누적되며, 결국 수습하기 힘들게 된다.


  • 첫째로, ‘문제 인식’은 조직의 구성원들을 활용해야 한다.
    문제를 직접 겪는 사람들이 다양한 시각으로 문제를 포착해내게 해야 한다.
    여기서 중요한 것은 시각이 다양해야 한다는 것이다.
    왜냐하면 문제라는 것은 입체적인 자연물과 같아서, 하나의 단면만을 가지고 판단할 수 없기 때문이다.
    문제를 입체적으로 조명할 수 없다면, 문제를 제대로 인지할 수조차 없다고 봐야 한다.
  • 둘째로, ‘전달 및 공유’는 서투르든 세련되든 자주 해야 한다.
    간결히 문제 요점을 정리해서 보고하거나 공유하는 재능을 가진 사람이 많다면 더할 나위 없이 좋을 일이다.
    그러나, 그렇지 않다고 해서 제 때 보고를 받지 못한다면 중요한 기회를 놓쳐버리기 십상이다. 하다못해 주절주절한 보고를 듣고 절반이라도 문제를 파악했다면, 그만큼의 문제는 조치할 수 있다.
  • 대부분의 사람들은 ‘잘 보고하지 못하거나 잘 전달하지 못한다.’
    보통 문제를 인식하고 불편해하는 사람들은 실무 조직이며, 문제를 조치하는 사람들은 대부분 중간관리자 이상이다.
    실무 조직의 사람들이 세련된 보고를 하기를 기다리는 것보다 관리자들이 알아서 잘 듣는 것이 더 효율적이고 중요하다.


그러면 잘 듣기 위해서는 어떻게 해야 할까?


  • 첫째, 무엇 때문에 고민이 시작되었는지 묻는 것부터 시작된다.
    물어보지 않고 그것을 이해하는 데는 많은 시간이 걸린다.
  • 둘째, 그 사람이 처한 상황이나 입장을 기준으로 들어야 한다.
    밖에서 바라보는 것이 좋을 때도 있다.
    하지만, 역시 문제를 인식하는 것은 문제의 중심에서 인식해야 한다.
    문제의 중심에서 인식하지 않았다면, 핵심을 놓쳐버리게 되고 인지하지 못했던 문제점들이 커져서 결국 다시 문제를 일으키게 된다.
  • 셋째, 당신이 이해한 것이 그 사람이 이해시키려는 것과 다를 수 있다.
    듣고 나면, 자신이 이해한 것을 다시 그 사람한테 물어보아야 한다.
    어렵고 복잡한 상황일수록 쉽게 이해하기 힘들다.
    따라서, 반드시 확인하지 않고 판단하면 문제 현상을 굴절해서 인지하게 된다.
  • 넷째, 만일 문제현상을 다르게 해석하고 판단했다면, 다 듣고 난 후에 자신의 의견이 다르다고 이야기해야 한다.
    그리고, 자신의 의견으로도 그 문제현상을 조치할 수 있는지 확인, 동의를 구하는 것은 중요하다.
  • 다섯째, 만일 타협이 필요하다면 이렇게 말하라.
    "난 당신이 그 문제를 혼자 고민해서 일처리하지 않았으면 좋겠다.
    만일 그 문제를 풀기 힘들다면 내가 맡겠다. 만일 안심이 안된다면 나한테 다시 이야기해주었으면 좋겠다."

    그러면, 그는 자신의 의견이 충분히 전달되었음을 알고 안도하고, 또다시 어떤 문제에 부딪혔을때 그것을 서슴없이 보고하고, 스스로 조치하기 위해 애를 쓸 것이다.


잘 듣는다는 것은 '사람의 말을 묵묵히 들어주는 것' 만을 의미하지 않는다.

물론 그렇게 듣는 것은 다양한 듣는 방법중의 하나이다.


잘 듣는다는 것은 '말하는 이를 잘 이해한다'는 것이다.

그 사람이 왜 그런말을 하는지 올바로 이해하지 않고서 어떻게 문제를 인식했다고 할 수 있는가?

올바로 인식하지 않는다면 과연 무엇을 기준으로 해서 움직일 수 있을 것인가?


추천하고 싶은 듣는 방법은 ‘이야기를 나누는 것(Share)’이다.

이야기를 나누려면 같은 높이에서 듣는 것이 제일 좋다.


즉, 말하는 스킬이나 듣는 스킬보다 ‘진실이 잘 전달’되도록 마음을 여는 것이 더 중요하다.


당신이 경험한 세계를 기준으로 이야기를 들으면 반드시 의미가 곡해된다.

그 사람이 처한 상황을 생각하고 듣고 난 후에야 당신의 기준에서 의견을 도출해야 한다.


당신의 세계 안에서만 다른 이의 이야기를 듣는 것은 아무것도 듣지 않는 것과 같다.



김수보 소장님 블로그 - IT의 중심에서   



1
1
  • 댓글 1

  • Floki
    174
    2017-11-15 13:50:10.0

    진실이 잘 전달되도록 마음을 여는것이 중요하다란 말은 방어적이 아닌 전향적인 자세를 말하시는 것으로 이해가 됩니다만..


    도대체 무엇이 문제죠? 라는 질문이 나올 정도면 듣는 사람의 태도가 문제가 아니라 설명을 잘못했을 가능성이 큰것 같습니다. 

    짧고 간단하게 문제를 설명하는 것이 좋지않습니까? 대부분의 엔지니어링 문제는 간단하게 설명이 가능한데요 윗글은 일반적인 조직에서 이성보다는 감성적인 부분을 강조하는 것 같습니다.


    자신이 쓴 박사 논문을 유치원생들에게 설명해서 이해를 시켜야만 논문의 내용을 이해하고 작성한것이라는 지도교수의 말이 생각납니다.


    무엇이 문제인가요? 란 질문이 나올 정도면 두가지 중의 하나입니다. 설명을 잘못했던가 설명할 필요도 없는 사람에게 설명을 했던가..


    글이 너무 추상적이고 감성적이라 한 글타래 남깁니다.

    1
  • 로그인을 하시면 댓글을 등록할 수 있습니다.