컴사랑의 이런 저런 이야기

컴사도 예전에는 sub Project Leader 도 했었구요. (지금은 아닙니다 ^^)
운이 좋게도 부하 직원들을 꽤 일찍 만났었습니다.

그러면서 일과 커뮤니케이션에 대해서 많이 생각해보고 느끼게 되었는데요...
관련해서 하고 싶은 이야기는 꽤 많이 있지만. 하나씩 풀어나가 보려고 합니다.


일단.... 먼저 "말로 전달 되는 것에는 loss가 있다" 라는 것에서 출발하고자 합니다.
이건 여러 곳에서 언급되는 것이기 때문에 더 부연 설명은 하지 않겠습니다.

일단 제 머리 속의 생각이 100 이라고 하면,
제가 말로 전달하면서 이미 60~70 전달 되면 많이 전달되는 것이고.
받는 사람은 다시 거기서 60~70 받아 들이면 많이 받아들이는 것 같습니다.

결국, 보통 50%도 제대로 전달되지 않는 것이죠.
(수치는 그냥 제가 느낀 대로 쓴 것입니다. 근거는 없습니다만 찾아보면 정확한 수치가 나올 것도 같네요)

그래서 저 사실을 인지하는 것이 communication의 base 입니다.

일단 위 문제를 극복하는 방법은 말하는 사람, 듣는 사람 모두 skill up이 필요하겠지만.
개인적으로 가장 쉽게 그리고 당연히 해야 할 것 중의 하나가 "반복" 입니다.

한 번만 이야기해주지 마십시오. 계속 해서 자신의 의사를 전달해야 합니다. (물론 번복 없이 반복 해야 합니다.)


중요한 내용이라면 더욱 반복 하십시오.
한달 전에 말한 내용이 그 때는 행해졌을 지 몰라도, 지금까지 상대방이 기억하고 그대로 행할 것이라고 믿지 마십시오.

Posted by 컴사랑

얼마 전에 "업무에서 이메일 활용에는 문제점이 있다" 라고 이야기를 했는데, 구체적으로 어떤 문제점이 있는지 궁금해 하시는 분들도 계시고, 나도 나름대로 정리를 해보기 위해서 실제 한계점들에 대해서 이야기 해보고자 한다.

각 내용의 요점은, "(시간이 지나면) 마지막 내용(결론)을 알기 힘들다" 로 요약될 수 있겠다.
(참고. 대부분은 현재 컴사 팀의 문제이지 않을까 싶습니다 ^^)


1. 편지가 오가던 중 메일 수신인이 변한다면
예컨데, 처음에는 A,B,C,D,E 다섯명에게 메일을 보냈다.
몇번 메일이 오가던 중에 D와 E에게는 왠지 스팸이 될 것 같다는 생각이 들었다.
그래서 메일 중간에 D와 E를 수신인에서 뺐다.
D와 E는 메일이 어떻게 진행되었는지 모른다. (물론 관심이 없을 수도 있지만, 나중에 필요하게 되었다면?)


2. 메일로 토론을 하고 있었다면
간혹, 메일로 토론을 하는 경우도 많이 본다.
예를 들면, 코딩 스타일에서 데이터 타입을 알려주는게 좋은지 (헝가리언 노테이션인가요?) 아닌게 좋은 지 등등...
한참 메일로 주고 받다가, 가까운 곳에 있다면 결국 만나서 이야기 하게 되는 경우가 많다.

다른 사람들은 결론을 모른다. ^^


3. 특정 사항에 대해서 수정된 사항이 계속 발생했을 경우
어떤 사항에 대해서 정리를 해서 알려 주었다.
앗. 수정사항이 발생했다. 다시 보낸다.
또 수정사항이 발생했다. 다시 보낸다.
메일을 받은 사람은, 한참 뒤에 관련 내용을 찾았는데, 운 나쁘게 두번째 편지를 찾았다 (한번 더 수정되었는데 쯧쯧)


등등 여러가지 경우가 있을 것 같다.
대부분은 트래킹이 어렵고, 마지막 내용을 잘 모르는 경우가 생길 수 있다 라는 것이다.
또 수신인을 정하는게 어려울 때도 많다. 누가 받아야 할 지...
또 그 때는 관심없었는데, 나중에 관심이 생길 수도 있다.


아직, 컴사도 구체적인 해결 방법을 고민 중이지만,
혹시나 비슷한 고민을 하시는 분들이 계실까봐,

마지막 "수신인을 정하는 것과 과거에 받지 않은 메일이 필요한 경우" 메일 아카이브를 이용하면 해결 할 수 있을 듯 하다.

그 외에는 위키나 BBS(게시판) 등이 좋은 해결책이 될 수 있을 것 같기도 하다.
물론 메일 아키이브 + 위키도 가능하다 ^^

다만 위키는 배우기를 꺼려하는 사람도 있고, 불편해 하는 사람도 많더라는 단점도 있다.
또 메일이 편한 경우도 많다. ^^

Posted by 컴사랑